Mailman 3 January 2006 - Python-announce-list

Fredericksburg, VA ZPUG Meeting: January 11, 7:30-9:00 PM
by Gary Poster 05 Jan '06

05 Jan '06

Please join us January 11, 7:30-9:00 PM, for the seventh meeting of the Fredericksburg, VA Zope and Python User Group ("ZPUG"). Squid and Zope! Python and Zope roundtable! Free food! * Andrew Sawyers will discuss using the open source cache server Squid with Zope, including a discussion of the O'Reilly book about Squid (this talk was moved from our November meeting). * We will have a Python and Zope roundtable for questions and ideas about Zope or Python. Have a question you want to ask a Zope core developer or a Python core developer or a community Zope or Python user? Come by! * We will serve delicious food and soft drinks. We've had a nice group for all the meetings. Please come and bring friends! We also are now members of the O'Reilly and Apress user group programs, which gives us nice book discounts (prices better than Amazon's, for instance) and the possibility of free review copies. Ask me about details at the meeting if you are interested. General ZPUG information When: second Wednesday of every month, 7:30-9:00. Where: Zope Corporation offices. 513 Prince Edward Street; Fredericksburg, VA 22408 (tinyurl for map is http://tinyurl.com/duoab). Parking: Zope Corporation parking lot; entrance on Prince Edward Street. Topics: As desired (and offered) by participants, within the constraints of having to do with Python or Zope. Contact: Gary Poster (gary(a)zope.com)

1 0

ZODB 3.6.0 final released
by Tim Peters 05 Jan '06

05 Jan '06

I'm pleased to announce the release of ZODB 3.6 final. This corresponds to the ZODB included (or that will be included) in Zope 2.9 final and Zope 3.2 final. You can download a source tarball or Windows installer from: http://zope.org/Products/ZODB3.6 Note that there are two Windows installers, for Python 2.3 (2.3.5 is recommended) and Python 2.4 (2.4.2 is recommended). Because Zope 2.9 and Zope 3.2 require Python 2.4.1+, it's unlikely that a Python 2.3 Windows installer will be built for later releases in the ZODB 3.6 line (I built one this time out of habit, but expect most people would rather see the time applied to something more generally useful). ZODB 3.6 adds a few new features, and incorporates all the bugfixes made to date in the ZODB 3.4 and 3.5 lines. Note that this is the first public release of ZODB 3.6 as a standalone package; 10 internal releases were made since last September to support ongoing Zope 2.9 and 3.2 development. See the NEWS file for details: http://zope.org/Products/ZODB3.6/NEWS.html The current status of all active ZODB lines can be seen here: http://www.zope.org/Wikis/ZODB/CurrentStatus Note that ZODB 3.2 is now officially "retired", corresponding to the retirement of the Zope 2.7 line (no new releases in the Zope 2.7 or ZODB 3.2 lines are planned).

1 0

ANN: unicode 0.6
by garabik-news-2005-05＠kassiopeia.juls.savba.sk 05 Jan '06

05 Jan '06

unicode is a simple python command line utility that displays properties for a given unicode character, or searches unicode database for a given name. It was written with Linux in mind, but should work almost everywhere (including MS Windows and MacOSX), UTF-8 console is recommended. Changes since previous versions: * fix embarrassing mistake causing the script not to run without ~/.unicode directory already existing (thanks to Tim Hatch) * remove absolute path from z?grep, rely on OS's default PATH to execute the command(s) * add default path to UnicodeData.txt for MacOSX systems Author: Radovan Garabík URL: http://kassiopeia.juls.savba.sk/~garabik/software/unicode/ License: GPL -- ----------------------------------------------------------- | Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ | | __..--^^^--..__ garabik @ kassiopeia.juls.savba.sk | ----------------------------------------------------------- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread!

1 0

[ANNOUNCE] MyHDL 0.5 released
by Jan Decaluwe 05 Jan '06

05 Jan '06

I'm pleased to announce the release of MyHDL 0.5. MyHDL is an open-source package for using Python as a hardware description and verification language. Moreover, it can convert a design to Verilog. Thus, MyHDL provides a complete path from Python to silicon. For a complete overview, go here: http://myhdl.jandecaluwe.com/doku.php/overview The manual is here: http://www.jandecaluwe.com/Tools/MyHDL/manual/MyHDL.html To find out the details of what's new, go here: http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5 Pythoneers may be interested in MyHDL's use of decorators: http://myhdl.jandecaluwe.com/doku.php/meps:mep-100 You can download the release from SourceForge: http://sourceforge.net/project/showfiles.php?group_id=91207 Best regards, Jan Decaluwe -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com

1 0

PSF: Funding available for attending PyCon
by A.M. Kuchling 04 Jan '06

04 Jan '06

The Python Software Foundation has allocated some funds to help people attend PyCon 2006. If you'd like to come to PyCon but can't afford it, maybe the PSF can help you. The funding can cover any or all of: * Your registration for PyCon. * Your hotel room at the conference hotel * Your flight or other transportation. To apply, send an e-mail to <pycon at python.org>. Please state your name, location, and what you would like to have funded. If you want assistance with your transportation costs, please provide a rough estimate (say, to the nearest US$100) of how much a round-trip flight/train ride/etc. will cost. You should also say why you should come to PyCon, and what you'll be doing. We don't need an essay, but please provide a few sentences of explanation. Messages must be received by January 22 2006. Upon receiving your message, we'll send you a notice of receipt. The PSF's PyCon committee (David Ascher, Steve Holden, Jeremy Hylton, A.M. Kuchling) will discuss the applications and allocate funding to a subset of the applicants. You should be notified of acceptance/rejection by January 31 2006. Cost notes: PyCon registration is US$185. Hotel rooms are around $90/night ~= $300 for the duration of the conference, $700 for conference + sprints. The hotel cost can be lower if you find someone to share a room with. The PSF can't cover your meals during the conference, or registration fees for tutorials. Priority will be given to people who can contribute significantly to PyCon or to Python, e.g. students working on a task, conference speakers, sprint leaders or developers critical to a sprint, or people doing public service work with Python. We'll be trying to maximize the benefit of the funding, so the committee is more likely to fund three people who need small amounts than one person who needs a large amount. To improve your chances, please try to request the minimum amount of funding you need to attend PyCon. A.M. Kuchling amk(a)amk.ca Chair, PyCon 2006 http://us.pycon.org

1 0

csvdatmix Project Feedback
by Terrence A. Pietrondi 04 Jan '06

04 Jan '06

Hello, I have been working on a project written in Python and I would like to share to get some feedback. The name of the project is 'CSV Data Mix'(csvdatamix). The whole concept behind the project is to accept comma separated values as input, randomize that input and then output it. The objective is to conceal the original state of the data in situations where privacy is an issue, but similar data might be wanted for testing purposes. The project page is listed on Sourceforge.net at: http://sourceforge.net/projects/csvdatamix/ . Please feel free to send comments and suggestions. Thank you. Terrence A. Pietrondi tepietrondi(a)yahoo.com __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

1 0

[ANN] The Enthought Tool Suite
by Prabhu Ramachandran 04 Jan '06

04 Jan '06

Greetings, This is to announce the *existence* of the Enthought Tool Suite (ETS). ETS is a collection of several useful components that together provide a powerful application framework with special emphasis on scientific and engineering applications. There are a large number of components, some stable and some under heavy development. These include: * Traits: (general purpose: stable) - Traits allow one to define special Python object attributes that elegantly support initialization, validation, delegation, notification and visualization (i.e. automatic generation of user interfaces) * Endo: (general purpose: stable) - Endo is a Traits aware API documentation tool. * PyFace: (user interface: stable) - PyFace is a collection of Traits-based MVC components for wxPython. * Envisage: (general purpose: UNSTABLE) - Envisage is an extensible Traits-based application framework. It offers a plug-in based architecture similar to the Java Eclipse framework. While most of the existing plug-ins are stable, the overall package itself, and the UI plug-in in particular, are still under heavy development. * Kiva: (graphics: stable) - Kiva is a multi-platform Display PDF 2D drawing engine that supports multiple output backends, including wxWidgets on Windows, GTK, and Carbon, a variety of raster image formats, PDF, and Postscript. * Chaco: (plotting: being re-factored) - Chaco is a Python toolkit for producing interactive plotting applications. Chaco applications can range from simple line plotting scripts up to GUI applications for interactively exploring different aspects of interrelated data. Chaco leverages other Enthought technologies such as Kiva, Enable, and Traits to produce highly interactive plots of publication quality. * TVTK: (graphics: stable) - TVTK is a Pythonic VTK wrapper for visualization, graphics and imaging in 2D/3D. It transparently supports Traits and Numeric/numarray/scipy arrays. * MayaVi2: (scientific/engineering: semi-stable, unfinished) - MayaVi2 is an Envisage plug-in for 2D/3D scientific data visualization. It is the next generation of the MayaVi scientific data visualizer. These tools together form the Enthought Tool Suite (ETS). ETS has been under heavy development for the last year or two. While some of the tools are still under heavy development, many of them like Traits, PyFace, Kiva, TVTK and others are stable enough for general use. Enthought's enhanced Python distribution (Enthon) and installers for several of the stable ETS components mentioned above are available here: http://code.enthought.com/ The source code is released under a BSD-like license. Up-to-date installers for the ETS are on their way and will be announced when ready. Those who are interested in the components that are still under development should check out the SVN repository (a fresh working copy is likely to occupy about 250MB). Trac interface (Wiki, code, issue tracker): http://www.enthought.com/enthought Build instructions: http://www.enthought.com/enthought/wiki/GrabbingAndBuilding Mailing list: http://mail.enthought.com/mailman/listinfo/envisage-dev ETS is developed and funded by Enthought, Inc., Austin, TX. Enjoy using the Enthought Tool Suite! Cheers, The Enthought Tool Suite Team

1 0

PyCon early-bird registration extended until January 15th
by A.M. Kuchling 03 Jan '06

03 Jan '06

Due to various issues with the hotel's reservation desk, the early bird registration for PyCon has been extended until January 15th. So, if you've been delaying registering for PyCon, you still have a chance to register at the lower early-bird price. The registration form is at http://www.python.org/pycon/2006/register What's going on: some sprint attendees have called the Dallas Marriott Quorum's reservation line and been told that the PyCon room rate is no longer available, and that they'll have to book at the regular hotel rate of $199/night. This is incorrect; the reservation line is confused, and we're trying to resolve the problem. Please don't be frightened away from PyCon if you've called the hotel and been told you have to pay $199/night. You can register for PyCon and book your hotel rooms later after this problem is resolved. You have until February 1st to book rooms at the PyCon rate. I'll post an announcement once the reservation issues are resolved. Regards, A.M. Kuchling amk(a)amk.ca Chair, PyCon 2006 http://us.pycon.org

1 0

PyCon schedule available
by A.M. Kuchling 03 Jan '06

03 Jan '06

A close-to-final draft of the PyCon 2006 schedule has now been posted to the web: http://www.python.org/pycon/2006/schedule If you're a presenter, please check that your timeslot is OK for you, and let us know if there's a problem. Regards, A.M. Kuchling amk(a)amk.ca Chair, PyCon 2006 http://us.pycon.org

1 0

python-dev Summary for 2005-11-16 through 2005-11-30
by Tony Meyer 01 Jan '06

01 Jan '06

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-11-16_2005-11-30.html] ===================== Summary Announcements ===================== -------------------------------------- Reminder: Python is now on Subversion! -------------------------------------- Don't forget that the Python source code is now hosted on svn.python.org as a Subversion (rather than CVS) repository. Note that because of the way the subversion conversion was done, by-date revision specifications for dates prior to the switchover won't work. To work around this, you must find a revision number using svn log or svn blame, and then supply that revision number to the appropriate command (e.g. svn diff or svn up). Removing the CVS repository from sourceforge isn't possible without hacks (as a result of their "open source never goes away" policy). However, it's no longer available from the project page, and the repository is now filled with files pointing people to the new repository. Contributing threads: - `Is some magic required to check out new files from svn? <http://mail.python.org/pipermail/python-dev/2005-November/058168.html>`__ - `svn diff -r {2001-01-01} <http://mail.python.org/pipermail/python-dev/2005-November/058269.html>`__ - `CVS repository mostly closed now <http://mail.python.org/pipermail/python-dev/2005-November/058348.html>`__ [TAM] ========= Summaries ========= ---------------------------- Memory management in the AST ---------------------------- Thomas Lee's attempt to implement `PEP 341`_ brought up some issues about working with the new AST code. Because the AST code used its own custom objects instead of PyObjects, it also introduced its own set of allocation/deallocation functions instead of the existing Py_INCREF and Py_DECREF. There was some discussion about how best to simplify the scheme, with the two main suggestions being: (1) Convert all AST objects into PyObjects so Py_INCREF and Py_DECREF work (2) Create an arena API, where objects are added to the arena and then can be freed in one shot when the arena is freed Neal Norwitz presented an example from the current AST code using the various asdl_*_free functions, and he, Greg Ewing and Martin v. Löwis compared how the code would look with the various API suggestions. While using ref-counting had the benefit of being consistent with the rest of Python, there were still some who felt that the arena API would simplify things enough to make the extra learning curve worthwhile. It seemed likely that branches or patches for the various APIs would appear shortly. While the C API is still undergoing these changes, and thus the Python API is still a ways off, a few implementations for the Python API were suggested. If the AST code ends up using PyObjects, these could be passed directly to Python code, though they would probably have to be immutable. Brett Cannon suggested that another route would be a simple PyString marshalling like the current parser module, so that Python code and C code would never share the same objects. .. _PEP 341: http://www.python.org/peps/pep-0341.html Contributing threads: - `Memory management in the AST parser & compiler <http://mail.python.org/pipermail/python-dev/2005-November/058156.html>`__ - `ast status, memory leaks, etc <http://mail.python.org/pipermail/python-dev/2005-November/058220.html>`__ - `a Python interface for the AST (WAS: DRAFT: python-dev...) <http://mail.python.org/pipermail/python-dev/2005-November/058294.html>`__ [SJB] ----------------------- Profilers in the stdlib ----------------------- Armin Rigo summarised the current Python profiler situation, which includes profile.Profile (ages-old, slow, pure Python profiler with limited support for profiling C calls), hotshot (Python 2.2+, faster than profile.py, but very slow to convert the log file to the pstats.Stats format, possibly inaccurate, doesn't know about C calls), and `lsprof`_ (Brett Rosen, Ted Czotter, Michael Hudson, Armin Rigo; doesn't support C calls, incompatible interface with profile.py/hotshot, can record detailed stats about children). He suggested that lsprof be added to the standard library, keeping profile.py as a pure Python implementation and replacing hotshot with lsprof. There was concern about maintenence of the library; however, since Armin and Michael are core developers, this seems covered. Martin suggested that lsprof be distributed separately for some time, and then included when it is more mature. Many people were concerned about having so many profilers included (with the preference for a single profiler that would suit beginners, since advanced users can easily install third-party modules, which could be referenced in the documentation). Tim Peters explained that the aim of hotshot wasn't to reduce total time overhead, but to be less disruptive (than profile.py) to the code being profiled, while that code is running, via tiny little C functions that avoid memory allocation/deallocation. Hotshot can do much more than the minimalistic documentation says (e.g. it could be used as the basis of a tracing tool to debug software, to measure test coverage); you won't find them discussed in the documentation, which makes user experience mostly negative, but you do find them in Tim's e-mails. Discussion centered around whether lsprof should be added to the standard distribution, and whether hotshot and/or profile.py should be removed. Armin indicated that he favours removing hotshot, adding lsprof, which would be added as "cProfile" (c.f cPickle/Pickle, cStringIO/StringIO), and possibly rewriting profile.py as a pure Python version of lsprof. Floris Bruynooghe (for Google's Summer of Code) wrote a `replacement for profile.py`_ that uses hotshot directory. This replacement didn't fix the problems with hotshot, but did result in pstats loading hotshot data 30% faster, and would mean that profile.py could be removed. There was a little debate about whether any profiler should even be included in the standard library, but there were several people who opined that it was an important 'battery'. A few people also liked the idea of adding a statistical profiler to the standard library at some point (e.g. http://wingolog.org/archives/2005/10/28/profiling). Aahz suggested that Armin write a PEP for this, which seems the likely way that this will progress. Contributing thread: - `s/hotshot/lsprof <http://mail.python.org/pipermail/python-dev/2005-November/058212.html>`__ .. _lsprof: http://codespeak.net/svn/user/arigo/hack/misc/lsprof .. _replacement for profile.py: http://savannah.nongnu.org/projects/pyprof/ [TAM] ---------------------------------------------- The tp_free slot and multiple inheritance in C ---------------------------------------------- Travis Oliphant started a thread discussing a memory problem in some new scipy core code where a huge number of objects were not being freed. Making the allocation code use malloc and free instead of PyObject_New and PyObject_Del made these problems go away. After an intense discussion, Armin Rigo figured out that the problem arose in a type that inherited both from int and from another scipy type. The tp_free slot of this type was being inherited from its second parent (int) instead of its first parent (the scipy type), and thus "deallocated" objects were put on the CPython free list of integers instead of being freed. It was unclear as to whether the code in typeobject.c which made this decision could be "fixed", so Armin suggested forcing the appropriate tp_alloc/tp_free functions in the static types instead. Contributing threads: - `Problems with the Python Memory Manager <http://mail.python.org/pipermail/python-dev/2005-November/058155.html>`__ - `Problems with mro for dual inheritance in C [Was: Problems with the Python Memory Manager] <http://mail.python.org/pipermail/python-dev/2005-November/058323.html>`__ [SJB] -------------------------------------- Patches for porting Python to a new OS -------------------------------------- Ben Decker asked for some feedback on patches porting Python to DOS/DJGPP. This lead to a discussion of what the requirements for accepting a porting patch were. Guido made it clear that he wanted porting patches included in Python whenever reasonable so that the various obscure ports would be able to upgrade to new versions of Python when they were released. The basic conditions were that the submission came from a reputable platform maintainer, and that if the patches caused problems in future Python versions, the maintainer would either need to update the patch appropriately, or have it removed from Python. Contributing thread: - `Patch Req. # 1351020 & 1351036: PythonD modifications <http://mail.python.org/pipermail/python-dev/2005-November/058177.html>`__ [SJB] --------------------------------------- Making StringIO behave more like a file --------------------------------------- Walter Dörwald identified a number of situations where StringIO (but not cStringIO) does not behave like a normal file: - next() after close() raises StopIteration instead of ValueError - isatty() after close() returns False instead of raising ValueError - truncate() with a negative argument doesn't raise an IOError These were determined to be bugs in StringIO and will likely be fixed in an upcoming Python release. Contributing threads: - `Iterating a closed StringIO <http://mail.python.org/pipermail/python-dev/2005-November/058187.html>`__ - `isatty() on closed StringIO (was: Iterating a closed StringIO) <http://mail.python.org/pipermail/python-dev/2005-November/058198.html>`__ - `Another StringIO/cStringIO discrepancy <http://mail.python.org/pipermail/python-dev/2005-November/058199.html>`__ - `isatty() on closed StringIO <http://mail.python.org/pipermail/python-dev/2005-November/058207.html>`__ [SJB] ----------------------------------- User-defined data for logging calls ----------------------------------- Vinay Sajip explained that on numerous occasions, requests have been made for the ability to easily add user-defined data to logging events. For example, a multi-threaded server application may want to output specific information to a particular server thread (e.g. the identity of the client, specific protocol options for the client connection). While this is currently possible, you have to subclass the Logger class and override its makeRecord method to put custom attributes in the LogRecord; the approach is usable but requires more work than necessary. Vinay proposed a simpler way of achieving the same result, which requires use of an additional optional keyword argument ("extra") in logging calls. The "extra" argument will be passed to Logger.makeRecord, which extend the logRecord's __dict__ with this argument; however, if any of the keys are already present (values calculated by the logging package), then a KeyError will be raised. Contributing thread: - `Proposed additional keyword argument in logging calls <http://mail.python.org/pipermail/python-dev/2005-November/058286.html>`__ [TAM] ------------------------------------- Updating urlparse to support RFC 3986 ------------------------------------- Paul Jimenez complained that urlparse uses a table of url schemes to determine whether a protocol (e.g. http or ftp) supports specifying a username and password in the url (e.g. https://user:pass@host:port). He suggested that all protocols should be capable of using this format. Guido pointed out that the main purpose of urlparse is to be RFC-compliant. Paul explained that the current code is valid according to `RFC 1808`_ (1995-1998), but that this was superceded by `RFC 2396`_ (1998-2004) and `RFC 3986`_ (2005-). Guido was convinced, and asked for a new API (for backwards compatibility) and a patch to be submitted via sourceforge. Contributing thread: - `urlparse brokenness <http://mail.python.org/pipermail/python-dev/2005-November/058301.html>`__ .. _RFC 1808: http://www.ietf.org/rfc/rfc1808.txt .. _RFC 2396: http://www.ietf.org/rfc/rfc2396.txt .. _RFC 3986: http://www.ietf.org/rfc/rfc3986.txt [TAM] --------------------------------------------- Magic methods on the instance and on the type --------------------------------------------- Nick Coghlan pointed out that the current semantics of `PEP 343`_ look up methods on the instance instead of on the type, and noted that slots are generally invoked as ``type(obj).__slot__(obj)`` instead. Guido explained that in general, using ``__xxxx__`` methods in an undocumented way (e.g. relying on them being looked up in the instance) was not supported, and code relying on that could be expected to break if the ``__xxxx__`` method was ever upgraded to a slot. So, it was okay that the `PEP 343`_ support looked up methods on the instance, but anyone depending on this behavior was asking for trouble. .. _PEP 343: http://www.python.org/peps/pep-0343.html Contributing thread: - `Metaclass problem in the "with" statement semantics in PEP 343 <http://mail.python.org/pipermail/python-dev/2005-November/058360.html>`__ [SJB] ---------------------------------- Releasing the GIL in the re module ---------------------------------- Duncan Grisby has a multi-threaded program that does a lot of complex regular expression searching, and has trouble with threads blocking because the GIL is not released while the re engine is running. He wanted to know whether there was any fundamental reason why the re engine could not release the interpreter lock. Fredrik Lundh pointed out that SRE can operate on anything that implements the buffer interface. This means that the objects that the engine is accessing might be mutable, which could cause problems. Several people suggested that a better solution would be using more efficient regular expressions; Duncan explained that the expressions are user-entered, which makes this difficult. Eric Noyau put together a `patch to release the GIL` when the engine performs a low level search, if (and only if) the object searched is a [unicode] string. .. _patch to release the GIL: http://python.org/sf/1366311 Contributing threads: - `(no subject) <http://mail.python.org/pipermail/python-dev/2005-November/058316.html>`__ - `Re: Regular expressions <http://mail.python.org/pipermail/python-dev/2005-November/058318.html>`__ - `SRE should release the GIL (was: no subject) <http://mail.python.org/pipermail/python-dev/2005-November/058329.html>`__ - `Regular expressions <http://mail.python.org/pipermail/python-dev/2005-November/058333.html>`__ [TAM] =============== Skipped Threads =============== - `str.dedent <http://mail.python.org/pipermail/python-dev/2005-November/058148.html>`__ - `Behavoir question. <http://mail.python.org/pipermail/python-dev/2005-November/058149.html>`__ - `Conclusion: Event loops, PyOS_InputHook, and Tkinter <http://mail.python.org/pipermail/python-dev/2005-November/058150.html>`__ - `DRAFT: python-dev Summary for 2005-09-16 to 2005-09-30 <http://mail.python.org/pipermail/python-dev/2005-November/058178.html>`__ - `DRAFT: python-dev Summary for 2005-10-01 to 2005-10-15 <http://mail.python.org/pipermail/python-dev/2005-November/058179.html>`__ - `DRAFT: python-dev Summary for 2005-10-16 to 2005-10-31 <http://mail.python.org/pipermail/python-dev/2005-November/058180.html>`__ - `Coroutines (PEP 342) <http://mail.python.org/pipermail/python-dev/2005-November/058192.html>`__ - `Enjoy a week without me <http://mail.python.org/pipermail/python-dev/2005-November/058209.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2005-November/058210.html>`__ - `How to stay almost backwards compatible with all these new cool features <http://mail.python.org/pipermail/python-dev/2005-November/058211.html>`__ - `test_cmd_line on Windows <http://mail.python.org/pipermail/python-dev/2005-November/058271.html>`__ - `Fwd: [Python-checkins] commit of r41497 - python/trunk/Lib/test <http://mail.python.org/pipermail/python-dev/2005-November/058272.html>`__ - `[Python-checkins] commit of r41497 -python/trunk/Lib/test <http://mail.python.org/pipermail/python-dev/2005-November/058275.html>`__ - `DRAFT: python-dev Summary for 2005-11-01 through 2005-11-15 <http://mail.python.org/pipermail/python-dev/2005-November/058281.html>`__ - `something is wrong with test___all__ <http://mail.python.org/pipermail/python-dev/2005-November/058292.html>`__ - `PEP 302, PEP 338 and imp.getloader (was Re: a Python interface for the AST (WAS: DRAFT: python-dev...) <http://mail.python.org/pipermail/python-dev/2005-November/058300.html>`__ - `registering unicode codecs <http://mail.python.org/pipermail/python-dev/2005-November/058324.html>`__ - `reference leaks <http://mail.python.org/pipermail/python-dev/2005-November/058330.html>`__ - `Bug bz2.BZ2File(...).seek(0,2) + patch <http://mail.python.org/pipermail/python-dev/2005-November/058334.html>`__ - `Python 3 <http://mail.python.org/pipermail/python-dev/2005-November/058346.html>`__ - `For Python 3k, drop default/implicit hash, and comparison <http://mail.python.org/pipermail/python-dev/2005-November/058349.html>`__ - `Bug day this Sunday? <http://mail.python.org/pipermail/python-dev/2005-November/058367.html>`__ - `Short-circuiting iterators <http://mail.python.org/pipermail/python-dev/2005-November/058423.html>`__ - `Standalone email package in the sandbox <http://mail.python.org/pipermail/python-dev/2005-November/058431.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from November 16, 2005 through November 30, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 8th summary written by the python-dev summary contingent of Steve Bethard and Tony Meyer (happy holidays!). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. -------------------- Commenting on Topics -------------------- To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) with a subject line mentioning what you are 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`_! ------------------------- How to Read the Summaries ------------------------- The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://svn.python.org/projects/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo :); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to 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: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _last summary: http://www.python.org/dev/summary/2005-11-01_2005-11-15.html .. _original text file: http://www.python.org/dev/summary/2005-11-16_2005-11-30.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0