Mailman 3 February 2003 - Python-announce-list

RELEASE: ClientCookie 0.3.0b
by jjl＠pobox.com Feb. 6, 2003

Feb. 6, 2003

http://wwwsearch.sourceforge.net/ClientCookie/ Changes since 0.2.0b: * Fixed several important bugs. * Response objects now have lazy read, readline, readlines and seek methods. Seekable responses are now optional (but on by default, as before). Non-seekable objects are just the standard urllib2 response objects (and hence are lazy, too). * Added backwards-compatible (ie. off by default) support for META HTTP-EQUIV and zero-time Refresh header redirection. * Added blocked_domains accessor methods. * Improved documentation. * Removed Apple Mac-specific code, since it has never been tested. If anybody wants it back, let me know. * Refactored Cookies.add_cookie_header and .extract_cookies methods. * Removed Python 1.5.2-compatible urllib2 / urllib. Now separately downloadable. * Added UNTESTED (ie. non-working) Microsoft Internet Explorer (MSIE) cookie support (reading only). I don't have a networked MS machine ATM, so testers are very welcome. Requires Python >= 1.5.2. urllib2 is recommended. 1.5.2-compatible urllib2 / urllib is at http://wwwsearch.sourceforge.net/ ClientCookie is a Python module for handling HTTP cookies on the client side, useful for accessing web sites that require cookies to be set, and returned later. It also provides some other (optional) useful stuff: HTTP-EQUIV handling, zero-time Refresh handling, and lazily-seekable responses. It is a port of Gisle Aas' Perl module HTTP::Cookies, from the libwww-perl library. import ClientCookie response = ClientCookie.urlopen("http://foo.bar.com/") This function behaves identically to urllib2.urlopen, except that it deals with cookies automatically. That's probably all you need to know. John

1 0

[Module] Sten.py 0.10
by Blake Wedel Feb. 5, 2003

Feb. 5, 2003

Sten.py 0.10 ------------ Allows you to hide text messages inside an image file. Stenography is the process of taking a text file and "hiding" it inside an image file without currupting the image file (of course). Right now with Sten.py you can "hide" anything that is in a text format. Either a regular text file or even pickled python objects, as long as they are saved in a file. URL: http://www.geocities.com/itcram/python/python.html Requires: Python Imaging Library Categories: Graphics Blake Wedel (itcram(a)yahoo.com) www.geocities.com/itcram -- <a href="http://www.geocities.com/itcram/python/python.html">Sten.py 0.10</a> -- Allows you to hide text messages inside an image file.

1 0

public Python training session, Feb 18-20
by Mark Lutz Feb. 4, 2003

Feb. 4, 2003

Greetings, I will be holding another public Python training session in Colorado, on February 18-20, 2003. This 3-day class is open to individual enrollments. For more details about this session, please visit this page: http://www.rmi.net/~lutz/feb03-longmont-class.html General course details are maintained here: http://www.rmi.net/~lutz/mytrain.html --Mark Lutz (http://www.rmi.net/~lutz)

1 0

[ANN] QuantLib-Python 0.3.1
by Ferdinando Ametrano Feb. 4, 2003

Feb. 4, 2003

QuantLib-Python 0.3.1 --------------------- http://quantlib.org QuantLib-Python is a SWIG wrap of QuantLib. QuantLib is a free/open-source quantitative finance C++ library for modeling, pricing, trading, and risk management in real-life. A tool for derivatives and financial engineering. Version 0.3.1 of the C++ library and the Python extension have been released. What's new ------------ - in sync with QuantLib 0.3.1 - migrated to SWIG 1.3.17 - merged under a global QuantLib-SWIG project - bug fixing URL: http://quantlib.org License: BSD style Categories: Miscellany Ferdinando Ametrano (ferdinando(a)ametrano.net) http://www.ametrano.net -- <P><A HREF="http://quantlib.org">QuantLib-Python 0.3.1</A> - A module for quantititative finance. (4-Feb-03)</P> --

1 0

python-dev Summary for 2003-01-16 through 2003-01-31
by drifty＠bigfoot.com Feb. 4, 2003

Feb. 4, 2003

+++++++++++++++++++++++++++++++++++++++++++++++++++++ python-dev Summary for 2003-01-16 through 2003-01-31 +++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from January 16, 2003 to January 31, 2003. It is intended to inform the wider Python community of on-going developments on the list that might be of interest. To comment on anything mentioned here, just post to python-list(a)python.org or comp.lang.python with subject line delineating what you discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join python-dev! This is the tenth summary written by Brett Cannon (double digits, baby!). All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_; you can safely ignore it (although I suggest learning reST; its simple and is accepted for PEP markup). Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the original text file. .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. contents:: ====================== Summary Announcements ====================== To make the Summaries more thorough I have decided to make a list of threads that I have decided not to summarize and give my reasoning behind why I decided to skip it which should also explain what the thread is about. I doubt anyone will have complaints about doing this, but if you do let me know. You can find this section entitled "Skipped threads" at the end of the summary. Some PyCon_ announcements to make. Registration is scheduled to start next week. Also, the list of accepted papers is expected to be announced on-time. The conference is shaping up and getting organized. It should be a lot of fun *and* educational, so make sure you come to PyCon_ ! .. _PyCon: http://www.python.org/pycon/ ========================================= `Adding Japanese Codecs to the distro`__ ========================================= __ http://mail.python.org/pipermail/python-dev/2003-January/032197.html MA Lemburg brought up a patch on SourceForge by Hisao SUZUKI (I am assuming the capitalization of the last name is a Japanese thing so I will stick with it in the summary) to add "codecs for the Japanese encodings EUC-JP, Shift_JIS and ISO-2022-JP" and donate the code to the `Python Software Foundation`_. MAL's reason for wanting to use these codecs over the current ones most commonly used with Python (written by Tamito KAJIYAMA whose codecs can be found at http://www.asahi-net.or.jp/~rd6t-kjym/python/ ) was that Hisao's were smaller and written in pure Python. Martin v. Löwis thought it was fine to add the codecs but thought Tamito's should be the defaults if any codecs were added to Python. His reasoning was that they have been in active development for a while and thus have been independently verified, in a way, to be correct. He also didn't like the "absence of the cp932 encoding in Suzuki's codecs" since the "suggestion to equate this to "mbcs" on Windows is not convincing". He also thought it would be best to add the C version only. He also suggested "that it might be more worthwhile to expose platform codecs, which would give us all CJK codecs on a number of major platforms, with a minimum increase in the size of the Python distribution, and with very good performance". In response to Martin's comments, MAL thought that the benefit of the Python versions of the codecs was that they were easier to modify. He suggested that the C version then be made available to download as a separate entity (which apparently has been suggested multiple times). As for the independent verification, Hisao built his based on Java's codecs which MAL thought was pretty good verification that they should work. MAL agreed that exposing more platform codecs would be good. Martin didn't go for the "easier editing" argument. He noted that since the table was autogenerated you would need to know the algorithm that made the table in order to be able to edit it. Hye-Shik Chang responded with the support of the C version since it allows for much easier interprocess communication. It also beat the Python version when it came to memory consumption by a large margin. Guido asked how Tamito would feel about adding these codecs, whether both sets outputted the same, and whether Tamito's codecs would still be preferred by people doing a lot of Japanese work. Martin reponded that he didn't think they produced the same result and that people would continue to use JapaneseCodecs (Tamito's codecs) as long as Python didn't include the cp932 codec. Barry Warsaw commented that Mailman used Tamito's codecs and no one has ever complained. He said he would love to see one of the codecs included in Python. Apparently their tend to be license issues with the various Asian codecs. The KorenCodecs_ (or KoCo) are licensed under LGPL, but Hye-Shik Chang said he would "like to make an essence of KoreanCodecs in PSF License if python needs it". Atsuo Ishimoto voted for Tamito's codecs. He said that the Japanese community would continue to use them regardless of what went into Python. And in regards to the question of maintaining the codecs, Atsuo said the Japanese Python community would be willing to help Tamito with his but did not expect that kind of support for Hisao's codecs (Hisao has volunteered to maintain his codecs, though). MAL pointed out that "Tamito's codecs have an installed size of 1790kB while Hisao's codecs are around 81kB" and that was an issue. Martin said that it was only 690kB if you only counted the C version. The issue of size became a major point. It was pointed out that Tamito's covered more codecs and being in C meant it only needed to be loaded in memory once for interprocess use. Tamito chimed in finally and commented that he was busy and would not be able to maintain the codecs until he graduated from graduate school. MAL suggested that he start maintaining it when he had the time and Tamito agreed. I am not sure where the situation stands as of this moment. .. _PSF: .. _Python Software Foundation: http://www.python.org/psf/ .. _KorenCodecs: http://sf.net/projects/koco ========================================== `make install failing with current cvs`__ ========================================== __ http://mail.python.org/pipermail/python-dev/2003-January/032213.html Jack Jansen was having issues with ``make install`` because he had various packages in site-python that had inconsistent tab usage and thus was raising a TabError during the ``compileall()`` step. Jack asked if site-packages could either be skipped by this step or at least not lead to the abortion of the install. All of this was from a change in ``compileall()`` that caused it to exit with a non-zero value if any errors were raised (although it continued to run). That feature was left in; the Makefile was modified so as to skip site-packages. =============================================== `logging package -- rename warn to warning?`__ =============================================== __ http://mail.python.org/pipermail/python-dev/2003-January/032220.html Guido said that he would "like to change 'warn' to 'warning' (and WARN to WARNING)" in the logging_ package. His argument that nothing else was a verb in the package. Vinay Sajip (who wrote the logging package) said he was fine with the change, but warned it would break existing code that already used the package. He suggested putting both names in with a warning that ``warn`` was deprecated. This was shot down since a new package does not need to start with anything deprecated. Then the discussion of whether to ditch fatal/FATAL since they are synonyms for crictical/CRITICAL came up. Guido said the reverse should happen; keep FATAL and ditch CRITICAL (for the rest of this summary I will only refer to the capitalized version to keep things simple). Some opposition came up, holding the view that CRITICAL was closer to the truth. Vinay suggested SEVERE as a replacement. Guido said it didn't "tickle" his "fancy like fatal/FATAL does"; CRITICAL was okay if no agreed upon replacement could be found. A quick grepping of the package by me shows that CRITICAL is staying as well was WARN (will most likely not be documented, though, so don't use it for new code). .. _logging: http://www.python.org/dev/doc/devel/lib/module-logging.html =============================== `sys.exit and PYTHONINSPECT`__ =============================== __ http://mail.python.org/pipermail/python-dev/2003-January/032217.html Kevin Altis discovered that invoking the interpreter with the ``-i`` argument does not prevent the interpreter from exiting if SystemExit is raised (``sys.exit()`` will raise the exception). He thought it would be good if ``-i`` would override even the SystemExit exception. `Bug #670311`_ was created for this, but no patch has been written yet (anyone care to step up and do this?). .. _bug #670311: http://sourceforge.net/tracker/index.php?func=detail&aid=670311&group_id=54… ============================ `disable writing .py[co]`__ ============================ __ http://mail.python.org/pipermail/python-dev/2003-January/032270.html Splinter threads: - `Proto-PEP regarding writing bytecode files <http://mail.python.org/pipermail/python-dev/2003-January/032342.html>`__ In the thread `Parallel pyc construction`_ (as covered in the last summary), Paul Dubois brought up how he would like to be able to disable the writing of .py[co] files. Well, this led to a long discussion that culminated into the creation of `PEP 304`_ by Skip Montanaro. If this topic interests you then read the PEP. .. _Parallel pyc construction: http://www.python.org/dev/summary/2003-01-01_2003-01-15.html#parallel-pyc-c… .. _PEP 304: http://www.python.org/peps/pep-0304.html ================================================ `Re: GadflyDA in core? Or as add-on-product?`__ ================================================ __ http://mail.python.org/pipermail/python-dev/2003-January/032295.html The idea was proposed to add Gadfly_ to the stdlib. Two issues came up about doing this. One was that it would require having to deal with another license. Aaron Watters (the original author of Gadfly) was emailed to ask if he would be willing to donate the code to the `Python Software Foundation`_, but he did not respond (at least to the list). The other issue was the use of kjbuckets_. Guido was -1 on letting it into the stdlib because he had "heard it's some of .the hairiest C code ever written". But Richard Jones said that Anthony Baxter is working on removing the dependency on kjbuckets by rewriting the code using the Sets_ module introduced in Python 2.3. As of this writing the decision as to whether to add Gadfly has been put on hold until both of the above issues are resolved. .. _Gadfly: http://gadfly.sourceforge.net/ .. _Sets: http://www.python.org/dev/doc/devel/lib/module-sets.html .. _kjbuckets: http://starship.python.net/crew/aaron_watters/kjbuckets/ ==================================== `Mixed-type datetime comparisons`__ ==================================== __ http://mail.python.org/pipermail/python-dev/2003-January/032414.html Tim Peters sent an email to the list saying that he had made changes to the datetime_ type so that it returned NotImplemented if the thing being compared to had a ``timetuple()`` method so as to allow other implementations to provide the functionality. He also mentioned how you still can't compare datetimes and timedeltas. This caused MA Lemburg to ask why not. Tim said it just wouldn't make any sense since they don't even measure time in the same units. Tim ended on saying that if MAL and Fredrik Lundh could come up with a good proposal Tim would get it in, otherwise his time on datetime for Python 2.3 is spent. .. _datetime: http://www.python.org/dev/doc/devel/lib/module-datetime.html ============== `Itertools`__ ============== __ http://mail.python.org/pipermail/python-dev/2003-January/032508.html Raymond Hettinger checked in his itertools_ module into the sandbox for testing and asked for feedback. He got it and has subsequently checked the module into the stdlib. .. _itertools: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modul… ======================================== `Idea for avoiding exception masking`__ ======================================== __ http://mail.python.org/pipermail/python-dev/2003-January/032492.html Raymond Hettinger discovered that "trapping an exception (a TypeError for a mutable argument passed to a dictionary) resulted in masking other errors that should have been passed through (potential TypeErrors in the called iterator for example)". Raymond proposed a new function named PyErr_FormatAppend that would append the extra info. Ka-Ping Yee suggested adding the original exception to the new exception as an attribute. This was generally viewed as a good solution. Questions of how to store traceback information and how to handle this in the C code has yet to be resolved. ============================= `Extended Function syntax`__ ============================= __ http://mail.python.org/pipermail/python-dev/2003-January/032498.html Splinter threads: - `Property syntax <http://mail.python.org/pipermail/python-dev/2003-January/032591.html>`__ - `thunks (for all the fish) <http://mail.python.org/pipermail/python-dev/2003-January/032616.html>`__ - `question??? <http://mail.python.org/pipermail/python-dev/2003-January/032663.html>`__ - `Syntax-wise <http://mail.python.org/pipermail/python-dev/2003-January/032669.html>`__ - `How about a meta-reserved word? <http://mail.python.org/pipermail/python-dev/2003-January/032684.html>`__ This threads wins the award for longest thread summarized here (and possibly ever for a summary written by me). Fair warning if you decide to read the actual thread. Also, none of this applies to Python 2.3; Guido promised syntactic stability for this next release and you will get it. Guido remembered that a proposal for extending the syntax of Python to make using things such as ``property()``, ``staticmethod()``, etc. much easier and wanted a reminder on where more info was. The suggeted syntax was:: def name(arg, ...) [expr1, expr2, expr3, ...]: ...body... where ``expr, ...`` would be evaluated like ``name = expr3(expr2(expr1(name)))``. Michael Hudson wrote up a patch which can be found at http://starship.python.net/crew/mwh/hacks/meth-syntax-sugar-3.diff with the original python-dev thread on this at http://mail.python.org/pipermail/python-dev/2002-February/020005.html . All of this led to an explosion of other syntax suggestions. One that garnered some support was to make something like:: class Foo: def Foo.bar(self, a, b, c): ...body... work by basically making a def statement work like ``Foo.bar=new.function(CODE, GLOBS, 'Foo.bar')``. If properties were made assignable then you could just use this syntax to assign to a property you instantiated. People also came up with metaclass implementations of some things (which Guido didn't like because they "all abuse the class keyword for something that's definitely not a class"). An idea that Walter Dörwald suggested was:: class Foo(object): property myprop: """Doc string for myprop.""" def __get__(self): ...body... def __set__(self, arg): ...body... def __delete__(self): ...body... Guido's objection was that it turned property into a keyword. But he admitted that a new keyword would be okay if an elegant solution came about. Guido then made the suggestion of:: foo = property: ... This also garnered some support. The problem with this is that it would require the parser to be able to go from '"expression parsing mode" to "block parsing mode"' in a new way. But Guido seemed to solve it. It would also allow the generalization of this to something along the lines of:: v = e: # Possibility for adding args -- v = e:(x, y): S # Creates a thunk which would be equivalent to:: v = e(T) # T is a thunk created from S None of this is meant to replace the suggested [expr, ...] syntax that started this whole thread. Another syntactic suggestion was:: def foo as property: def __get__(self): ... def __set__(self, x): ... Which seemed to grab a lot of people's fancies. This would allow for "... as class", "... as generator", etc. But the problem with all of these proposals is how to deal with namespaces. Should, for instance, the thunks Guido suggested have their own namespace or use the one of their parent? Should their be only one type of thunk or multiple types with different scoping rules based on the situation? The namespace issue (especially for thunks) is still playing out. =========================== `Capabilities in Python`__ =========================== __ http://mail.python.org/pipermail/python-dev/2003-January/032672.html This thread actually came out of the whole property/thunk thing summarized directly above but was so tangential that I thought it deserved its own summary. Ben Laurie had apparently suggested that capabilities be added to Python. Jeremy Hylton gave a pretty good description of a capability as "a ticket. The ticket is good for some event and possession of the ticket is sufficient to attend the event"; limit abilities of objects based on what capabilities you possess. The problem is that Python's introspection lets you see everything and thus you can get around restrictions; you can get into the event by sneaking out back and crawling under the fence all without having a ticket. Jeremy mentioned Zope's proxy which fully wraps an object and forces all interaction through the proxy. Then Ka-Ping Yee stepped up to discuss the topic. He made the point that "creating a capability is equivalent to creating an object -- which you can only do if you hold the constructor". Ping said that "To build a capability system, all you need to do is to constrain the transfer of object references such that they can only be transmitted along other object references. That's all." In order to pull this off you would need to restrict access to only the declared interface of an object and have "no global namespace of modules". In other words have something like a private declaration for things and get rid of ``sys.modules``. Ping suggested coming up with a "secure-mode" Python where these restrictions would be turned on. Neil Schemenauer liked this idea. ================ Skipped Threads ================ `test_logging failing on Windows 2000 <http://mail.python.org/pipermail/python-dev/2003-January/032191.html>`__ Since it dealt with a bug that received a patch I didn't worry about it. `PyConDC sprints <http://mail.python.org/pipermail/python-dev/2003-January/032216.html>`__ Meant for the people on python-dev directly, so no point in telling the general community about it. `String method: longest common prefix of two strings <http://mail.python.org/pipermail/python-dev/2003-January/032228.html>`__ Didn't go anywhere; Guido said he doesn't want to add every useful thing as a string method since there are already so many. `very slow compare of recursive objects <http://mail.python.org/pipermail/python-dev/2003-January/032234.html>`__ Discussed a patch about recursive compares. Basically led to no change and dealt with how to make a tuple recursive. `test_email always supposed to be skipped? <http://mail.python.org/pipermail/python-dev/2003-January/032240.html>`__ Glitch in Makefile.pre.in which got fixed. `extending readline functionality (patch) <http://mail.python.org/pipermail/python-dev/2003-January/032449.html>`__ Someone sending a patch directly to python-dev; big no-no! Use SourceForge_ for any all patches. `Re: [Python-checkins] python/dist/src Makefile.pre.in,1.111,1.112 <http://mail.python.org/pipermail/python-dev/2003-January/032284.html>`__ No one ever responded to the email; problem was probably solved. `Cookie.py too strict <http://mail.python.org/pipermail/python-dev/2003-January/032313.html>`__ Barry Warsaw wanted to make the Cookie_ module less strict in acceptance. Michael Chermside suggested adding an argument to be able to specify whether the acceptance of data should be strict or not. `HTMLParser patches <http://mail.python.org/pipermail/python-dev/2003-January/032469.html>`__ Mentions two patches for HTMLParser_ to fix some parsing problems. `Name space pollution (fwd) <http://mail.python.org/pipermail/python-dev/2003-January/032355.html>`__ Someone on `c.l.py`_ didn't like the naming of a function ``destructor`` in the core because it is such a common name and thus can clash with other code. Guido said submit a patch or use some ``#define`` tricks. `logging package -- spurious package contents <http://mail.python.org/pipermail/python-dev/2003-January/032373.html>`__ Guido didn't like the config file for the logging_ package nor the extra handlers. It was agreed to ditch the config file but keep the handlers. `logging package -- documentation <http://mail.python.org/pipermail/python-dev/2003-January/032415.html>`__ Better docs for the logging_ package were uploaded and are ready to be applied. `Re: [Zope3-dev] PosixTimeZone tzinfo implementation <http://mail.python.org/pipermail/python-dev/2003-January/032374.html>`__ Single email mentioning the tm_gmtoff attribute of the datetime type. `test_ossaudiodev hangs <http://mail.python.org/pipermail/python-dev/2003-January/032388.html>`__ The ossaudiodev_ module was hanging in tests. It has been disabled in `setup.py`_. `Looking for a Windows bsddb fan <http://mail.python.org/pipermail/python-dev/2003-January/032400.html>`__ Tim Peters upgraded the Windows distribution to berkeleydb 4.1.25; doing so caused a huge amount of test failures. Turned out they were race conditions in the tests inherit in such complicated tests. `Extension modules, Threading, and the GIL <http://mail.python.org/pipermail/python-dev/2003-January/032429.html>`__ Mention of how the GIL puts a cramp into writing PyGTK_. This thread started last month ( http://www.python.org/dev/summary/2003-01-01_2003-01-15.html#extension-modu… ). `the new 2.3a1 settimeout() with httplib and SSL <http://mail.python.org/pipermail/python-dev/2003-January/032417.html>`__ There was a problem with the new timeout mechanism in socket_ and SSL. There is a a patch at http://www.python.org/sf/676472 to fix the problem. `non-blocking sockets and sendall <http://mail.python.org/pipermail/python-dev/2003-January/032457.html>`__ Brian Ellin noticed that ``socket.sendall()`` and non-blocking sockets don't work together. `Re: [Python-checkins] python/dist/src/Lib/bsddb dbshelve.py,1.4,1.4.4.1 <http://mail.python.org/pipermail/python-dev/2003-January/032477.html>`__ Skip Montanaro asking whether bsddb185 should become "a fallback to the fallback". `xmlparse.c no longer compiles on Windows <http://mail.python.org/pipermail/python-dev/2003-January/032428.html>`__ Tim Peters discovered `xmlparse.c`_ had some #define lines for the non-existent case of no ``memmove()`` function. `fixing traceback.extract_stack() line numbers <http://mail.python.org/pipermail/python-dev/2003-January/032506.html>`__ Greg Klanderman noticed that ``traceback.extract_stack()`` only gives the first line of the method and not of the actual line that caused an issue. `python2.3 on m68k-nommu uClinux, really slow <http://mail.python.org/pipermail/python-dev/2003-January/032511.html>`__ Brad Clements got Python working on an m68k processor and performance was horrible. He asked if anyone had any ideas on how to speed it up. `native code compiler? (or, OCaml vs. Python) <http://mail.python.org/pipermail/python-dev/2003-January/032519.html>`__ Someone asked if Python was ever going to have a native code compiler. The answer is "if you want to write one" and to ask the question nicely. It also became a debate over how difficult a native code compiler would be. `Re: RHSA-2002:202-25 <http://mail.python.org/pipermail/python-dev/2003-January/032525.html>`__ Skip Montanaro sent an email about a security hole found in ``os.exec*p()`` method that was patched back in August. It has subsequently been back-patched to 2.1. `map, filter, reduce, lambda <http://mail.python.org/pipermail/python-dev/2003-January/032587.html>`__ Andrew Koenig commenting on the discussion from the `last summary`_. `Global interpreter lock/import mechanism <http://mail.python.org/pipermail/python-dev/2003-January/032543.html>`__ Joerg Budischewski asked some questions about the proper way of doing some things in a C extension. `Should Cygwin Python use --enable-runtime-pseudo-reloc? <http://mail.python.org/pipermail/python-dev/2003-January/032544.html>`__ Title of this thread makes what it is about obvious. `New PEP 306 needs proof reading. <http://mail.python.org/pipermail/python-dev/2003-January/032549.html>`__ Another thread whose content is obvious by the title. `StringIO not an iterator? <http://mail.python.org/pipermail/python-dev/2003-January/032605.html>`__ Misunderstanding initially. Guido then suggested that (c?)StringIO become its own iterator which became a bug report. `SF patch #677429 (PEP293 callbacks) <http://mail.python.org/pipermail/python-dev/2003-January/032638.html>`__ Walter Dörwald asking for someone to look over a patch since Martin v. Löwis in on vacation (and this explains why I have not been bringing up the character palette so much in this summary for inserting umlauts =). `rexec/bastion <http://mail.python.org/pipermail/python-dev/2003-February/032685.html>`__ Someone asking an improper question on the list (Mailman lists this in February, but I am on Pacific time so I say it is in January =). `PEP 42: sizeof(obj) builtin <http://mail.python.org/pipermail/python-dev/2003-January/032597.html>`__ Raymond Hettinger asked if people still wanted ``sizeof()`` in Python. One person said yes. The difficulty of doing this correctly was also pointed out along with the suggestion that if this function is written it be a part of the ``sys`` module. `PEP 305 - CSV File API <http://mail.python.org/pipermail/python-dev/2003-January/032678.html>`__ "A new PEP (305), "CSV File API", is available for reader feedback". `New version of PEP 304 <http://mail.python.org/pipermail/python-dev/2003-January/032654.html>`__ A new version of PEP 304 is up. `import.c:load_source_module() confusion <http://mail.python.org/pipermail/python-dev/2003-January/032635.html>`__ Skip Montanaro had a question about returning when a possible error was signalled on an import. .. _SourceForge: http://www.sf.net/projects/python .. _Cookie: http://www.python.org/dev/doc/devel/lib/module-Cookie.html .. _c.l.py: http://groups.google.com/groups?q=comp.lang.python&ie=ISO-8859-1&hl=en&btnG… .. _ossaudiodev: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modul… .. _setup.py: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/setup… .. _PyGTK: http://www.daa.com.au/~james/pygtk/ .. _HTMLParser: http://www.python.org/dev/doc/devel/lib/module-HTMLParser.html .. _xmlparse.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modul… .. _last summary: http://www.python.org/dev/summary/2003-01-01_2003-01-15.html .. _socket: http://www.python.org/dev/doc/devel/lib/module-socket.html

1 0

Updated Cygwin Package: python-2.2.2-5
by Jason Tishler Feb. 3, 2003

Feb. 3, 2003

New News: === ==== I have updated the version of Python to 2.2.2-5. The tarballs should be available on a Cygwin mirror near you shortly. The main purpose of this release is to rebuild the _tkinter module against the latest Cygwin tcltk package, tcltk-20030128-3 (i.e., Tcl/Tk 8.4.1). Note that you must define TCL_LIBRARY and TK_LIBRARY using Win32 style paths: $ export TCL_LIBRARY=$(cygpath -w /usr/share/tcl8.4) $ export TK_LIBRARY=$(cygpath -w /usr/share/tk8.4) in order for _tkinter to function properly. Old News: === ==== Python is an interpreted, interactive, object-oriented programming language. If interested, see the Python web site for more details: http://www.python.org/ Please read the README file: /usr/doc/Cygwin/python-2.2.2.README since it covers requirements, installation, known issues, etc. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. Note that we have recently stopped downloads from sources.redhat.com (aka cygwin.com) due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/ is a reliable high bandwidth connection. In Germany, ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/ is usually pretty good. In the UK, http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/ is usually up-to-date within 48 hours. If one of the above doesn't have the latest version of this package then you can either wait for the site to be updated or find another mirror. The setup.exe program will figure out what needs to be updated on your system and will install newer packages automatically. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin(a)cygwin.com . I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question, the Cygwin mailing list is the appropriate place. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com(a)cygwin.com Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

1 0

extremely light, all python, XML parser
by Peter Ohler Feb. 3, 2003

Feb. 3, 2003

I've written a very small non-validating XML parser. The parser and print routines are written completely in python and require no C compilation. It does not follow the DOM or SAX interfaces but instead produces a simple list or rather list hierarchy of the XML file or string. This module, xmlite, is useful for simple XML files such as those used for configuration. This is my first python code but the code has been tested. Can anyone tell me how to make the module available to others? Pete Ohler peter(a)ohler.com

1 0

Pre-announce: PyCon registration
by Aahz Feb. 2, 2003

Feb. 2, 2003

I'll post again when we have the form set up, but I figure people ought to know now what the costs and dates will be: $150 through Feb 28 $200 through Mar 15 $250 at the door We'll take charge and checks for pre-reg; cash and charge at the door. The pre-con sprint is still not settled, but will cost around $30-50. PyCon PyCon is a community-oriented Python conference emphasizing accessibility and low cost. It is designed to complement the International Python Conference (IPC), which will be a track at the O'Reilly Open Source Convention (OSCON) starting in 2003. PyCon DC 2003 The first PyCon will be held 26-28 March, 2003, at George Washington University's Cafritz Conference Center in Washington DC. There will be a development sprint Mon/Tues before the conference. As always, current info is available at http://www.python.org/pycon/ -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach

1 0

[ANN] Pyblosxom 0.6
by Wari Wahab Feb. 2, 2003

Feb. 2, 2003

pyblosxom is a CGI-based Weblog program written in Python. It uses ordinary text files as your entries, and in addition to the features of blosxom, on which it is based, it can be easily extended with preformatters and plugins. This release includes the following changes (listed in no particular order): * In addition to flavour overrides, we now have configuration overrides with flavours. * Better documentation available at the [http://wiki.subtlehints.net/moin/PyBlosxom Wiki Site] * Change XML content-type detection for content-type other than just text/xml * Plugins, from simple `$templateVariables` type to CallbackChains type * Lot's of new features available just by dropping in plugins * Weblogs.com and blo.gs pings available with plugins * Conditional HTTP is now a plugin Fixes: * Fixed directory recursions * Fixed entry display by category to honor num_entries * Example flavours fixes Demo Site: http://roughingit.subtlehints.net/pyblosxom Documentation: http://wiki.subtlehints.net/moin/PyBlosxom SourceForge Site: http://sf.net/projects/pyblosxom Download: https://sourceforge.net/project/showfiles.php?group_id=67445&release_id=137…

1 0

PyObjC Article at O'Reilly
by Bill Bumgarner Feb. 1, 2003

Feb. 1, 2003

> http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html

1 0