Mailman 3 November 2006 - Python-announce-list

A Call for Community Input re PyCon Slogans/Swag
by Jeff Rush Nov. 27, 2006

Nov. 27, 2006

The PyCon organizers have established a short online poll to collect input from the Python community regarding the shirts, tote bag and slogans to be used at PyCon 2007, being held in Addison (Dallas), Texas Feb 23-25 2007. When we put out a prior call for slogan suggestions, we received 104 submissions. We've since reviewed them, narrowed them down to a number reasonable for voting on, and now you can help us decide the winner! Actually we're looking for two winners, one slogan for the T-shirt and another for the tote bag. Please take the poll at the following page. We've tried to keep it short, to respect your time. http://us.pycon.org/swagpoll Thanks! Jeff Rush Co-Chair PyCon 2007

1 0

Announcing: Keynote Speakers for PyCon 2007
by Jeff Rush Nov. 27, 2006

Nov. 27, 2006

The PyCon organizers would like to announce the slate of keynote speakers who have accepted our invitation to speak at PyCon 2007! PyCon 2007 is taking place in Addison (Dallas), Texas on Feb 23-25 2007. For photos, biographies and more, check out: http://us.pycon.org/TX2007/Keynotes Ivan Krstić (speaking Friday AM) Topic: "The Python machine: Python and One Laptop per Child" Adele Goldberg (speaking Saturday AM) Topic: TBD (probably something related to Zope 3 and Education) Guido van Rossum (speaking Saturday Lunch) Topic: "Python 3000" Robert M. Lefkowitz ("r0ml") (speaking Sunday AM) Topic: "The Importance of Programming Literacy" -Jeff Co-Chair PyCon 2007

1 0

python-dev Summary for 2006-11-01 through 2006-11-15
by steven.bethard＠gmail.com Nov. 27, 2006

Nov. 27, 2006

python-dev Summary for 2006-11-01 through 2006-11-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-11-01_2006-11-15] ============= Announcements ============= -------------------------- Python 2.5 malloc families -------------------------- Just a reminder that if you find your extension module is crashing with Python 2.5 in malloc/free, there is a high chance that you have a mismatch in malloc "families". Unlike previous versions, Python 2.5 no longer allows sloppiness here -- if you allocate with the ``PyMem_*`` functions, you must free with the ``PyMem_*`` functions, and similarly, if you allocate with the ``PyObject_*`` functions, you must free with the ``PyObject_*`` functions. Contributing thread: - `2.5 portability problems <http://mail.python.org/pipermail/python-dev/2006-November/069967.html>`__ ========= Summaries ========= ---------------------------------- Path algebra and related functions ---------------------------------- Mike Orr started work on a replacement for `PEP 355`_ that would better group the path-related functions currently in ``os``, ``os.path``, ``shutil`` and other modules. He proposed to start with a `directory-tuple Path class`_ that would have allowed code like:: # equivalent to # os.path.join(os.path.dirname(os.path.dirname(__FILE__)), "lib") os.path.Path(__FILE__)[:-2] + "lib" where a Path object would act like a tuple of directories, and could be easily sliced and reordered as such. As an alternative, glyph proposed using `Twisted's filepath module`_ which was already being used in a large body of code. He showed some common pitfalls, like that the existence on Windows of "CON" and "NUL" in *every* directory can make paths invalid, and indicated how FilePath solved these problems. Fredrik Lundh suggested a reorganization where functions that manipulate path *names* would reside in ``os.path``, and functions that manipulate *objects* identified by a path would reside in ``os``. The ``os.path`` module would gain a path wrapper object, which would allow "path algebra" manipulations, e.g. ``path1 + path2``. The ``os`` module would gain some of the ``os.path`` and ``shutil`` functions that were manipulating real filesystem objects and not just the path names. Most people seemed to like this approach, because it correctly targeted the "algebraic" features at the areas where chained operations were most common: path name operations, not filesystem operations. Some of the conversation moved on to the `Python 3000 list`_. .. _PEP 355: http://www.python.org/dev/peps/pep-0355/ .. _directory-tuple Path class: http://wiki.python.org/moin/AlternativePathClass .. _Twisted's filepath module: http://twistedmatrix.com/trac/browser/trunk/twisted/python/filepath.py .. _Python 3000 list: http://mail.python.org/mailman/listinfo/python-3000 Contributing threads: - `Path object design <http://mail.python.org/pipermail/python-dev/2006-November/069712.html>`__ - `Mini Path object <http://mail.python.org/pipermail/python-dev/2006-November/069775.html>`__ - `[Python-3000] Mini Path object <http://mail.python.org/pipermail/python-dev/2006-November/069776.html>`__ ------------------ Replacing urlparse ------------------ A few more bugs in ``urlparse`` were turned up, and `earlier discussions about replacing urlparse`_ were briefly revisited. Paul Jimenez asked about `uriparse module`_ and was told that due to the constant problems with ``urlparse``, people were concerned about including the "incorrect" library again, so requirements were a little stringent. Martin v. Lowis gave him some guidance on a few specific points, and Nick Coghlan promised to try to post his `urischemes module`_ (a derivative of Paul's `uriparse module`_) to the `Python Package Index`_. .. _earlier discussions about replacing urlparse: http://www.python.org/dev/summary/2006-06-01_2006-06-15/#rfc-3986-uniform-r… .. _uriparse module: http://bugs.python.org/1462525 .. _urischemes module: http://bugs.python.org/1500504 .. _Python Package Index: http://www.python.org/pypi Contributing threads: - `patch 1462525 or similar solution? <http://mail.python.org/pipermail/python-dev/2006-November/069707.html>`__ - `Path object design <http://mail.python.org/pipermail/python-dev/2006-November/069712.html>`__ ---------------------------------- Importing .py, .pyc and .pyo files ---------------------------------- Martin v. Lowis brought up `Osvaldo Santana's patch`_ which would have made Python search for both .pyc and .pyo files regardless of whether or not the optimize flag, "-OO", was set (like zipimporter does). Without this patch, when "-OO" was given, Python never looked for .pyc files. Some people thought that an extra ``stat()`` call or directory listing to check for the other file would be too expensive, but no one profiled the various versions of the code so the cost was unclear. People were leaning towards removing the extra functionality from zipimporter so that at least it was consistent with the rest of Python. Giovanni Bajo suggested that .pyo file support should be dropped completely, with .pyc files being compiled at various levels of optimization depending on the command line flags. To make sure all your .pyc files were compiled at the same level of optimization, you'd use a new "-I" flag to indicate that all files should be recompiled, e.g. ``python -I -OO app.py``. Armin Rigo suggested using .pyc files only as a means of caching bytecode for speed reasons, and introducing a new filename extension for importable bytecode files. This would have avoided a commonly encountered problem where Python uses stale .pyc files instead of the more up-to-date .py files. This can happen, for example, when a .py file is deleted without deleting the accompanying .pyc file -- if a new .py file of the same name is introduced somewhere else, it may be hidden unintentionally by the .pyc file. There was some support for Armin's solution, but it was not overwhelming. .. _Osvaldo Santana's patch: http://bugs.python.org/1346572 Contributing thread: - `Importing .pyc in -O mode and vice versa <http://mail.python.org/pipermail/python-dev/2006-November/069822.html>`__ --------------------------------------------------------------- The buffer protocol and communicating binary format information --------------------------------------------------------------- The discussion of extending the buffer protocol to more binary formats continued this fortnight. Though the PIL_ had been used as an example of a library that could benefit from an extended buffer protocol, Fredrik Lundh indicated that future versions of the PIL_ would make the binary data model completely opaque, and instead provide a view-style API like:: view = object.acquire_view(region, supported formats) ... access data in view ... view.release() Along these lines, the discussion turned away from the particular C formats used in ``ctypes``, ``numpy``, ``array``, etc. and more towards the best way to communicate format information between these modules. Though it seemed like people were not completely happy with the proposed API of the new buffer protocol, the discussion seemed to skirt around any concrete suggestions for better APIs. In the end, the only thing that seemed certain was that a new buffer protocol could only be successful if it were implemented on all of the appropriate stdlib modules: ``ctypes``, ``array``, ``struct``, etc. .. _PIL: http://www.pythonware.com/products/pil/ Contributing threads: - `PEP: Adding data-type objects to Python <http://mail.python.org/pipermail/python-dev/2006-November/069706.html>`__ - `PEP: Extending the buffer protocol to share array information. <http://mail.python.org/pipermail/python-dev/2006-November/069709.html>`__ - `idea for data-type (data-format) PEP <http://mail.python.org/pipermail/python-dev/2006-November/069733.html>`__ ----------------- dir() and __dir__ ----------------- Tomer Filiba continued his `previous investigations`_ into adding a ``__dir__()`` method to allow customization of the ``dir()`` builtin. He moved most of the current ``dir()`` logic into ``object.__dir__()``, with some additional logic necessary for modules and types being moved to ``ModuleType.__dir__()`` and ``type.__dir__()`` respectively. He posted a `patch for his implementation`_ and it got approval for Python 2.6. There was a brief discussion about whether or not it was okay for an object to lie about its members, with Fredrik Lundh suggesting that you should only be allowed to *add* to the result that ``dir()`` produces. Nick Coghlan pointed out that when a class overrides ``__getattribute__()``, attributes that the default ``dir()`` implementation sees can be blocked, in which case removing members from the result of ``dir()`` might be quite appropriate. .. _previous investigations: http://www.python.org/dev/summary/2006-07-01_2006-07-15/#adding-a-dir-magic… .. _patch for his implementation: http://bugs.python.org/1591665 Contributing thread: - `__dir__, part 2 <http://mail.python.org/pipermail/python-dev/2006-November/069865.html>`__ -------------------------------- Invalid read errors and valgrind -------------------------------- Using valgrind, Herman Geza found that he was getting some "Invalid read" read errors in PyObject_Free which weren't identified as acceptable in Misc/README.valgrind. Tim Peters and Martin v. Lowis explained that these are okay if they are reads from Py_ADDRESS_IN_RANGE. If the address given is Python's own memory, a valid arena index is read. Otherwise, garbage is read (though this read will never fail since Python always reads from the page where the about-to-be-freed block is located). The arenas are then checked to see whether the result was garbage or not. Neal Norwitz promised to try to update Misc/README.valgrind with this information. Contributing thread: - `valgrind <http://mail.python.org/pipermail/python-dev/2006-November/069884.html>`__ --------------------------- SCons and cross-compilation --------------------------- Martin v. Lowis reviewed a `patch for cross-compilation`_ which proposed to use SCons_ instead of distutils because updating distutils to work for cross-compilation would have involved some fairly major changes. Distutils had certain notions of where to look for header files and how to invoke the compiler which were incorrect for cross-compilation, and which were difficult to change. While accepting the patch would not have required SCons_ to be added to Python proper (which a number of people opposed), people didn't like the idea of having to update SCons configuration in addition to already having to update setup.py, Modules/Setup and the PCbuild area. The patch was therefore rejected. .. _patch for cross-compilation: http://bugs.python.org/841454 .. _SCons: http://www.scons.org/ Contributing thread: - `Using SCons for cross-compilation <http://mail.python.org/pipermail/python-dev/2006-November/069917.html>`__ ---------------------------- Individual interpreter locks ---------------------------- Robert asked about having a separate lock for each interpreter instance instead of the global interpreter lock (GIL). Brett Cannon and Martin v. Lowis explained that a variety of objects are shared between interpreters, including: * extension modules * type objects (including exception types) * singletons like ``None``, ``True``, ``()``, strings of length 1, etc. * many things in the sys module A single lock for each interpreter would not be sufficient for handling access to such shared objects. Contributing thread: - `Feature Request: Py_NewInterpreter to create separate GIL (branch) <http://mail.python.org/pipermail/python-dev/2006-November/069815.html>`__ --------------------------- Passing floats to file.seek --------------------------- Python's implementation of ``file.seek`` was converting floats to ints. `Robert Church suggested a patch`_ that would convert floats to long longs and thus support files larger than 2GiB. Martin v. Lowis proposed instead to use the ``__index__()`` API to support the large files and to raise an exception for float arguments. Martin's approach was approved, with a warning instead of an exception for Python 2.6. .. _Robert Church suggested a patch: http://bugs.python.org/1067760 Contributing thread: - `Passing floats to file.seek <http://mail.python.org/pipermail/python-dev/2006-November/069948.html>`__ ---------------------------------------- The datetime module and timezone objects ---------------------------------------- Fredrik Lundh asked about including a ``tzinfo`` object implementation for the ``datetime`` module, along the lines of the ``UTC``, ``FixedOffset`` and ``LocalTimezone`` classes from the `library reference`_. A number of people reported having copied those classes into their own code repeatedly, and so Fredrik got the go-ahead to put them into Python 2.6. .. _library reference: http://docs.python.org/lib/datetime-tzinfo.html Contributing thread: - `ready-made timezones for the datetime module <http://mail.python.org/pipermail/python-dev/2006-November/069951.html>`__ ================ Deferred Threads ================ - `Summer of Code: zipfile? <http://mail.python.org/pipermail/python-dev/2006-November/069955.html>`__ - `Results of the SOC projects <http://mail.python.org/pipermail/python-dev/2006-November/069968.html>`__ ================== Previous Summaries ================== - `The "lazy strings" patch [was: PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom] <http://mail.python.org/pipermail/python-dev/2006-November/069816.html>`__ =============== Skipped Threads =============== - `RELEASED Python 2.3.6, FINAL <http://mail.python.org/pipermail/python-dev/2006-November/069752.html>`__ - `[Tracker-discuss] Getting Started <http://mail.python.org/pipermail/python-dev/2006-November/069811.html>`__ - `Status of pairing_heap.py? <http://mail.python.org/pipermail/python-dev/2006-November/069820.html>`__ - `Inconvenient filename in sandbox/decimal-c/new_dt <http://mail.python.org/pipermail/python-dev/2006-November/069896.html>`__ - `test_ucn fails for trunk on x86 Ubuntu Edgy <http://mail.python.org/pipermail/python-dev/2006-November/069904.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-November/069909.html>`__ - `Last chance to join the Summer of PyPy! <http://mail.python.org/pipermail/python-dev/2006-November/069913.html>`__ - `[Python-checkins] r52692 - in python/trunk: Lib/mailbox.py Misc/NEWS <http://mail.python.org/pipermail/python-dev/2006-November/069919.html>`__ - `PyFAQ: help wanted with thread article <http://mail.python.org/pipermail/python-dev/2006-November/069965.html>`__ - `Arlington sprint this Saturday <http://mail.python.org/pipermail/python-dev/2006-November/069966.html>`__ - `Suggestion/ feature request <http://mail.python.org/pipermail/python-dev/2006-November/069985.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from November 01, 2006 through November 15, 2006. 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 python-dev summary is the 16th written by Steve Bethard. To contact me, please send email: - Steve Bethard (steven.bethard at gmail.com) Do *not* post to comp.lang.python if you wish to reach me. 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 ------------------------- 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. .. _python-dev: http://www.python.org/dev/ .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _Python Software Foundation: http://python.org/psf/ .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

python-dev Summary for 2006-10-16 through 2006-10-31
by steven.bethard＠gmail.com Nov. 27, 2006

Nov. 27, 2006

python-dev Summary for 2006-10-16 through 2006-10-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-10-16_2006-10-31] ============= Announcements ============= -------------------------------------- Roundup to replace SourceForge tracker -------------------------------------- Roundup_ has been named as the official replacement for the SourceForge_ issue tracker. Thanks go out to the new volunteer admins, Paul DuBois, Michael Twomey, Stefan Seefeld, and Erik Forsberg, and also to `Upfront Systems`_ who will be hosting the tracker. If you'd like to provide input on what the new tracker should do, please join the `tracker-discuss mailing list`_. .. _SourceForge: http://www.sourceforge.net/ .. _Roundup: http://roundup.sourceforge.net/ .. _Upfront Systems: http://www.upfrontsystems.co.za/ .. _tracker-discuss mailing list: http://mail.python.org/mailman/listinfo/tracker-discuss Contributing threads: - `PSF Infrastructure has chosen Roundup as the issue tracker for Python development <http://mail.python.org/pipermail/python-dev/2006-October/069528.html>`__ - `Status of new issue tracker <http://mail.python.org/pipermail/python-dev/2006-October/069658.html>`__ ========= Summaries ========= --------------------------------------------------------------- The buffer protocol and communicating binary format information --------------------------------------------------------------- Travis E. Oliphant presented a pre-PEP for adding a standard way to describe the shape and intended types of binary-formatted data. It was accompanied by a pre-PEP for extending the buffer protocol to handle such shapes and types. Under the proposal, a new ``datatype`` object would describe binary-formatted data with an API like:: datatype((float, (3,2)) # describes a 3*2*8=48 byte block of memory that should be interpreted # as 6 doubles laid out as arr[0,0], arr[0,1], ... a[2,0], a[1,2] datatype([( ([1,2],'coords'), 'f4', (3,6)), ('address', 'S30')]) # describes the structure # float coords[3*6] /* Has [1,2] associated with this field */ # char address[30] Alexander Belopolsky provided a nice example of why you might want to extend the buffer protocol along these lines. Currently, there's not much you can do with a basic buffer object. If you want to pass it to numpy_, you have to provide the type and shape information yourself:: >>> b = buffer(array('d', [1,2,3])) >>> numpy.ndarray(shape=(3,), dtype=float, buffer=b) array([ 1., 2., 3.]) By extending the buffer protocol appropriately so that the necessary information can be provided, you should be able to pass the buffer directly to numpy_ and have it understand the format itself:: >>> numpy.array(b) People were uncomfortable with the many ``datatype`` variants -- the constructor accepted types, strings, lists or dicts, each of which could specify the structure in a different way. Also, a number of people questioned why the existing ``ctypes`` mechanisms for describing binary data couldn't be used instead, particularly since ``ctypes`` could already describe things like function pointers and recursive types, which the pre-PEP could not. Travis said he was looking for a way to unify the data formats of all the ``array``, ``struct``, ``numpy`` and ``ctypes`` modules, and felt like using the ``ctypes`` approach was too verbose for use in the other modules. In particular, he felt like the ``ctypes`` use of type objects as binary-format specifiers was problematic because type objects were harder to manipulate at the C level. The discussion continued on into the next fortnight. .. _numpy: Contributing threads: - `PEP: Adding data-type objects to Python <http://mail.python.org/pipermail/python-dev/2006-October/069602.html>`__ - `PEP: Extending the buffer protocol to share array information. <http://mail.python.org/pipermail/python-dev/2006-October/069681.html>`__ ------------------------ The "lazy strings" patch ------------------------ Discussion continued on Larry Hastings `lazy strings patch`_ that would have delayed until necessary the evaluation of some string operations, like concatenation and slicing. With his patch, repeated string concatenation could be used instead of the standard ``.join()`` idiom, and slices which were never used would never be rendered. Discussions of the patch showed that people were concerned about memory increases when a small slice of a very large string kept the large string around in memory. People also felt like a stronger motivation was necessary to justify complicating the string representation so much. Larry was pointed to some `code that his patch would break`_, which was using ``ob_sval`` directly instead of calling ``PyString_AS_STRING()`` like it was supposed to. He was also referred to the `Python 3000 list`_ where the recent discussions of `string views`_ would be relevant, and his proposal might have a better chance of acceptance. .. _lazy strings patch: http://bugs.python.org/1569040 .. _code that his patch would break: http://www.google.com/codesearch?hl=en&lr=&q=ob_sval+-stringobject.%5Bhc%5D… .. _Python 3000 list: http://mail.python.org/mailman/listinfo/python-3000 .. _string views: http://mail.python.org/pipermail/python-3000/2006-August/003280.html Contributing threads: - `PATCH submitted: Speed up + for string Re: PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom <http://mail.python.org/pipermail/python-dev/2006-October/069459.html>`__ - `Python-Dev Digest, Vol 39, Issue 54 <http://mail.python.org/pipermail/python-dev/2006-October/069468.html>`__ - `Python-Dev Digest, Vol 39, Issue 55 <http://mail.python.org/pipermail/python-dev/2006-October/069485.html>`__ - `The "lazy strings" patch [was: PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom] <http://mail.python.org/pipermail/python-dev/2006-October/069506.html>`__ - `The "lazy strings" patch <http://mail.python.org/pipermail/python-dev/2006-October/069509.html>`__ -------------- PEP 355 status -------------- BJorn Lindqvist wanted to wrap up the loose ends of `PEP 355`_ and asked whether the problem was the specific path object of `PEP 355`_ or path objects in general. A number of people felt that some reorganization of the path-related functions could be helpful, but that trying to put everything into a single object was a mistake. Some important requirements for a reorganization of the path-related functions: * should divide the functions into coherent groups * should allow you to manipulate paths foreign to your OS There were a few suggestions of possible new APIs, but no concrete implementations. People seemed hopeful that the issue could be resurrected for Python 3K, but no one appeared to be taking the lead. .. _PEP 355: http://www.python.org/dev/peps/pep-0355/ Contributing thread: - `PEP 355 status <http://mail.python.org/pipermail/python-dev/2006-October/069570.html>`__ -------------------------------------------------- Buildbots, configure changes and extension modules -------------------------------------------------- Grig Gheorghiu, who's been taking care of the `Python Community Buildbots`_, noticed that the buildbots started failing after a checkin that made changes to ``configure``. Martin v. Lowis explained that even though a plain ``make`` will trigger a re-run of ``configure`` if it has changed, there is an issue with distutils not rebuilding when header files change, and so extension modules are sometimes not rebuilt. Contributions to fix that deficiency in distutils are welcome. Martin also pointed out a handy way of forcing a buildbot to start with a clean build: ask the buildbot to build a non-existing branch. This causes the checkouts to be deleted and the build to fail. The next regular build will then start from scratch. .. _Python Community Buildbots: http://www.pybots.org/ Contributing thread: - `Python unit tests failing on Pybots farm <http://mail.python.org/pipermail/python-dev/2006-October/069479.html>`__ --------------- Sqlite versions --------------- Skip Montanaro ran into some problems running ``test_sqlite`` on OSX where he was getting a bunch of ``ProgrammingError: library routine called out of sequence`` errors. These errors appeared reliably when ``test_sqlite`` was run immediately after ctypes' ``test_find``. When he started linking to sqlite 3.1.3 instead of sqlite 3.3.8, the problems went away. Barry Warsaw mentioned that he had run into similar troubles when he tried to upgrade from 3.2.1 to 3.2.8. Contributing thread: - `Massive test_sqlite failure on Mac OSX ... sometimes <http://mail.python.org/pipermail/python-dev/2006-October/069504.html>`__ --------------------------------------------- Threads, generators, exceptions and segfaults --------------------------------------------- Mike Klaas managed to `provoke a segfault`_ in Python 2.5 using threads, generators and exceptions. Tim Peters was able to whittle Mike's problem down to a relatively simple test case, where a generator was created within a thread, and then the thread vanished before the generator had exited. The segfault was a result of Python's attempt to clean up the abandoned generator, during which it tried to access the generator's already free()'d thread state. No clear solution to this problem had been decided on at the time of this summary. .. _provoke a segfault: http://bugs.python.org/1579370 Contributing thread: - `Segfault in python 2.5 <http://mail.python.org/pipermail/python-dev/2006-October/069464.html>`__ ---------------- ctypes and win64 ---------------- Previously, Thomas Heller had asked that ctypes be removed from the Python 2.5 win64 MSI installers since it did not work for that platform at the time. Since then, Thomas integrated some patches in the trunk so that _ctypes could be built for win64/AMD64. Backporting these fixes to Python 2.5 would have meant that, while the MSI installer would still not include it, _ctypes could be built from a source distribution on win64/AMD64. It was unclear whether this would constitute a bugfix (in which case the backport would be okay) or a feature (in which case it wouldn't). Contributing thread: - `ctypes and win64 <http://mail.python.org/pipermail/python-dev/2006-October/069495.html>`__ ------------------------------ Python 2.3.X and 2.4.X retired ------------------------------ Anthony Baxter pushed out a Python 2.4.4 release and was pushing out the Python 2.3.6 source release as well. He indicated that once 2.3.6 was out, both of these branches could be officially retired. Contributing thread: - `state of the maintenance branches <http://mail.python.org/pipermail/python-dev/2006-October/069474.html>`__ --------------------------------------- Producing bytecode from Python 2.5 ASTs --------------------------------------- Michael Spencer offered up his compiler2_ module, a rewrite of the compiler module which allows bytecode to be produced from ``_ast.AST`` objects. Currently, it produces almost identical output to ``__builtin__.compile`` for all the stdlib modules and their tests. He asked for feedback on what would be necessary to get it stdlib ready, but had no responses. .. _compiler2: http://svn.brownspencer.com/pycompiler/branches/new_ast/ Contributing thread: - `Fwd: Re: ANN compiler2 : Produce bytecode from Python 2.5 AST <http://mail.python.org/pipermail/python-dev/2006-October/069589.html>`__ ================== Previous Summaries ================== - `Python 2.5 performance <http://mail.python.org/pipermail/python-dev/2006-October/069438.html>`__ - `Promoting PCbuild8 (Was: Python 2.5 performance) <http://mail.python.org/pipermail/python-dev/2006-October/069440.html>`__ - `2.3.6 for the unicode buffer overrun <http://mail.python.org/pipermail/python-dev/2006-October/069442.html>`__ - `2.4.4: backport classobject.c HAVE_WEAKREFS? <http://mail.python.org/pipermail/python-dev/2006-October/069494.html>`__ =============== Skipped Threads =============== - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-October/069437.html>`__ - `Problem building module against Mac Python 2.4 and Python 2.5 <http://mail.python.org/pipermail/python-dev/2006-October/069441.html>`__ - `svn.python.org down <http://mail.python.org/pipermail/python-dev/2006-October/069447.html>`__ - `BRANCH FREEZE release24-maint, Wed 18th Oct, 00:00UTC <http://mail.python.org/pipermail/python-dev/2006-October/069449.html>`__ - `who is interested on being on a python-dev panel at PyCon? <http://mail.python.org/pipermail/python-dev/2006-October/069457.html>`__ - `RELEASED Python 2.4.4, Final. <http://mail.python.org/pipermail/python-dev/2006-October/069472.html>`__ - `Nondeterministic long-to-float coercion <http://mail.python.org/pipermail/python-dev/2006-October/069477.html>`__ - `Promoting PCbuild8 <http://mail.python.org/pipermail/python-dev/2006-October/069490.html>`__ - `OT: fdopen on Windows question <http://mail.python.org/pipermail/python-dev/2006-October/069503.html>`__ - `Modulefinder <http://mail.python.org/pipermail/python-dev/2006-October/069518.html>`__ - `Optional type checking/pluggable type systems for Python <http://mail.python.org/pipermail/python-dev/2006-October/069520.html>`__ - `readlink and unicode strings (SF:1580674) Patch http://www.python.org/sf/1580674 fixes readlink's behaviour w.r.t. Unicode strings: without this patch this function uses the system default encoding instead of the filesystem encoding to convert Unicode objects to plain strings. Like os.listdir, os.readlink will now return a Unicode object when the argument is a Unicode object. What I'd like to know is if this can be backported to the 2.5 branch. The first part of this patch (use filesystem encoding instead of the system encoding) is IMHO a bugfix, the second part might break existing applications (that might not expect a unicode result from os.readlink). The reason I did this patch is that os.path.realpath currently breaks when the path is a unicode string with non-ascii characters and at least one element of the path is a symlink. Ronald <http://mail.python.org/pipermail/python-dev/2006-October/069524.html>`__ - `readlink and unicode strings (SF:1580674) <http://mail.python.org/pipermail/python-dev/2006-October/069526.html>`__ - `RELEASED Python 2.3.6, release candidate 1 <http://mail.python.org/pipermail/python-dev/2006-October/069553.html>`__ - `__str__ bug? <http://mail.python.org/pipermail/python-dev/2006-October/069554.html>`__ - `Hunting down configure script error <http://mail.python.org/pipermail/python-dev/2006-October/069558.html>`__ - `Python 2.4.4 docs? <http://mail.python.org/pipermail/python-dev/2006-October/069571.html>`__ - `DRAFT: python-dev summary for 2006-09-01 to 2006-09-15 <http://mail.python.org/pipermail/python-dev/2006-October/069598.html>`__ - `DRAFT: python-dev summary for 2006-09-16 to 2006-09-30 <http://mail.python.org/pipermail/python-dev/2006-October/069603.html>`__ - `[Python-checkins] r52482 - in python/branches/release25-maint: Lib/urllib.py Lib/urllib2.py Misc/NEWS <http://mail.python.org/pipermail/python-dev/2006-October/069605.html>`__ - `Typo.pl scan of Python 2.5 source code <http://mail.python.org/pipermail/python-dev/2006-October/069608.html>`__ - `build bots, log output <http://mail.python.org/pipermail/python-dev/2006-October/069617.html>`__ - `PyCon: proposals due by Tuesday 10/31 <http://mail.python.org/pipermail/python-dev/2006-October/069647.html>`__ - `test_codecs failures <http://mail.python.org/pipermail/python-dev/2006-October/069662.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from October 16, 2006 through October 31, 2006. 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 python-dev summary is the 15th written by Steve Bethard. To contact me, please send email: - Steve Bethard (steven.bethard at gmail.com) Do *not* post to comp.lang.python if you wish to reach me. 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 ------------------------- 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. .. _python-dev: http://www.python.org/dev/ .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _Python Software Foundation: http://python.org/psf/ .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

python-dev Summary for 2006-10-01 through 2006-10-15
by steven.bethard＠gmail.com Nov. 27, 2006

Nov. 27, 2006

python-dev Summary for 2006-10-01 through 2006-10-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-10-01_2006-10-15] ============= Announcements ============= ----------------------------- QOTF: Quotes of the Fortnight ----------------------------- Martin v. Lowis on a small change to Python that wouldn't affect many applications: I'm pretty sure someone will notice, though; someone always notices. Contributing thread: - `Caching float(0.0) <http://mail.python.org/pipermail/python-dev/2006-October/069175.html>`__ Steve Holden reminds us that patch submissions are dramatically preferred to verbose thread discussions: This thread has disappeared down a rat-hole, never to re-emerge with anything of significant benefit to users. C'mon, guys, implement a patch or leave it alone :-) Contributing thread: - `Caching float(0.0) <http://mail.python.org/pipermail/python-dev/2006-October/069190.html>`__ ========= Summaries ========= -------------- Caching floats -------------- Nick Craig-Wood discovered that he could save 7MB in his application by adding the following simple code:: if age == 0.0: age = 0.0 A large number of his calculations were producing the value 0.0, which meant that many copies of 0.0 were being stored. Since all 0.0 literals refer to the same object, the code above was removing all the duplicate copies of 0.0. Skip Montanaro and played around a bit with floatobject.c, and found that Python's test suite allocated a large number of small integral floats (though only a couple hundred were generally allocated at the same time). Kristjan V. Jonsson played around with caching for float values between -10.0 and 10.0 with the EVE server and got a 25% savings in allocations. There was some concern that for systems with both +0.0 and -0.0, the cache might cause problems, since determining which zero you have seemed difficult. However, James Y Knight showed how to do this fairly easily in C with a double/uint64_t union. Eventually, people agreed that it should be fine to just cache +0.0. Kristjan V. Jonsson and Josiah Carlson proposed patches, but nothing was posted to SourceForge. Contributing threads: - `Caching float(0.0) <http://mail.python.org/pipermail/python-dev/2006-September/069049.html>`__ - `Caching float(0.0) <http://mail.python.org/pipermail/python-dev/2006-October/069092.html>`__ -------------------------------------------- Buffer overrun in repr() and Python releases -------------------------------------------- The implications of PSF-2006-001_, a buffer overrun problem in repr(), were considered for the various Python releases. The bug had been fixed before Python 2.5 was released, and had been applied to the Python 2.4 branch shortly before Python 2.4.4 was released. The security advisory provided patches for both Python 2.3 and 2.4, but to make sure that full source releases were available for all major versions of Python still in use, it looked like there would be a source-only 2.3.6 release (source-only because neither Mac nor Windows builds were affected). .. _PSF-2006-001: http://www.python.org/news/security/PSF-2006-001/ Contributing threads: - `Security Advisory for unicode repr() bug? <http://mail.python.org/pipermail/python-dev/2006-October/069247.html>`__ - `2.3.6 for the unicode buffer overrun <http://mail.python.org/pipermail/python-dev/2006-October/069327.html>`__ --------------------------- Build system for python.org --------------------------- Anthony, Barry Warsaw, Georg Brandl and others indicated that the current website build system was making releases and other updates more difficult than they should be. Most people didn't have enough cycles to spare for this, but Michael Foord said he could help with a transition to rest2web_ if that was desirable. Fredrik Lundh also suggested a few options, including his older proposal to `use Django`_. No definite plans were made though. .. _rest2web: http://www.voidspace.org.uk/python/rest2web/ .. _use Django: http://effbot.org/zone/pydotorg-cache.htm Contributing thread: - `2.3.6 for the unicode buffer overrun <http://mail.python.org/pipermail/python-dev/2006-October/069327.html>`__ -------------------- String concatenation -------------------- Larry Hastings posted a `patch for string concatenation`_ that delays the creation of a new string until someone asks for the string's value. As a result, the following code would be about as fast as the ``''.join(strings)`` idiom:: result = '' for s in strings: result += s To achieve this, he had to change ``PyStringObject.ob_sval`` from a ``char[1]`` array, to a ``char *``. Reaction was mixed -- some people really disliked using ``join()``, while others didn't see the need for such a change. .. _patch for string concatenation: http://bugs.python.org/1569040 Contributing thread: - `PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom <http://mail.python.org/pipermail/python-dev/2006-October/069224.html>`__ ---------------------------- PEP 315: Enhanced While Loop ---------------------------- Hans Polak revived the discussion about `PEP 315`_, which proposes a do-while loop for Python that would allow the current code:: while True: <setup code> if not <condition>: break <loop body> to be written instead as:: do: <setup code> while <condition>: <loop body> Hans was hoping to simplify the situation where there is no ``<loop body>`` following the ``<condition>`` test and a number of syntax suggestions were proposed to this end. In the end, Guido indicated that none of the suggestions were acceptable, and Raymond Hettinger offered to withdraw the PEP. .. _PEP 315: http://www.python.org/dev/peps/pep-0315/ Contributing threads: - `PEP 351 - do while <http://mail.python.org/pipermail/python-dev/2006-September/069088.html>`__ - `PEP 351 - do while <http://mail.python.org/pipermail/python-dev/2006-October/069100.html>`__ - `PEP 315 - do while <http://mail.python.org/pipermail/python-dev/2006-October/069205.html>`__ ------------------------------ PEP 355: path objects rejected ------------------------------ Luis P Caamano asked about the status of `PEP 355`_, which aimed to introduce an object-oriented reorganization of Python's path-related functions. Guido indicated that the current "amalgam of unrelated functionality" was unacceptable and pronounced it dead. Nick Coghlan elaborated the "amalgam" point, explaining that `PEP 355`_ lumped together all the following: - string manipulation operations - abstract path manipulation operations - read-only traversal of a concrete filesystem - addition and removal of files/directories/links within a concrete filesystem Jason Orendorff pointed out some other problems with the PEP: - the motivation was weak - the API had too many methods - it didn't fix all the perceived problems with the existing APIs - it would have introduced a Second Way To Do It without being clearly better than the current way There were some rumors of a new PEP based on Twisted's filepath_ module, but nothing concrete at the time of this summary. .. _PEP 355: http://www.python.org/dev/peps/pep-0355/ .. _filepath: http://twistedmatrix.com/trac/browser/trunk/twisted/python/filepath.py Contributing threads: - `PEP 355 status <http://mail.python.org/pipermail/python-dev/2006-September/069059.html>`__ - `PEP 355 status <http://mail.python.org/pipermail/python-dev/2006-October/069093.html>`__ ---------------------------------- Processes and threading module API ---------------------------------- Richard Oudkerk proposed a module that would make processes usable with an API like that of the threading module. People seemed unsure as to whether it would be better to have a threading-style or XML-RPC-style API. A few other relevant modules were identified, including PyXMLRPC_ and POSH_. No clear winner emerged. .. _PyXMLRPC: http://sourceforge.net/projects/py-xmlrpc/ .. _POSH: http://poshmodule.sourceforge.net/ Contributing thread: - `Cloning threading.py using proccesses <http://mail.python.org/pipermail/python-dev/2006-October/069297.html>`__ ------------------------------------ Python 3.0: registering methods in C ------------------------------------ After a brief exchange about which ``tp_flags`` implied which others, there was some discussion on how to simplify ``tp_flags`` for Python 3000. Raymond Hettinger suggested that the NULL or non-NULL status of a slot should be enough to indicate its presence. Martin v. Lowis pointed out that this would require recompiling extension modules for every release, since if a new slot is added, extension modules from earlier releases wouldn't even *have* the slot. Fredrik Lundh suggested a `dynamic registration method`_ instead, which would look something like:: static PyTypeObject *NoddyType; NoddyType = PyType_Setup("noddy.Noddy", sizeof(Noddy)); PyType_Register(NoddyType, PY_TP_DEALLOC, Noddy_dealloc); PyType_Register(NoddyType, PY_TP_DOC, "Noddy objects"); ... PyType_Register(NoddyType, PY_TP_NEW, Noddy_new); if (PyType_Ready(&NoddyType) < 0) return; People thought this looked like a good idea, and Fredrik Lundh planned to look into it seriously for Python 3000. .. _dynamic registration method: http://effbot.org/zone/idea-register-type.htm Contributing thread: - `2.4.4: backport classobject.c HAVE_WEAKREFS? <http://mail.python.org/pipermail/python-dev/2006-October/069235.html>`__ ----------------------------------------- Tracker Recommendations: JIRA and Roundup ----------------------------------------- The PSF Infrastructure Committee announced their recommendations for trackers to replace SourceForge. Both JIRA and Roundup were definite improvements over SourceForge, though the Infrastructure Committee was leaning towards JIRA since Atlassian had offered to host it for them. Roundup was still under consideration if 6-10 admins could volunteer to maintain the installation. (More updates on this in the next summary.) Contributing thread: - `PSF Infrastructure Committee's recommendation for a new issue tracker <http://mail.python.org/pipermail/python-dev/2006-October/069139.html>`__ ----------------------------- PEP 302: import hooks phase 2 ----------------------------- Brett Cannon announced that he'd be working on a C implementation of phase 2 of `PEP 302`_. Phillip J. Eby pointed out that phase 2 could not be implemented in a backwards-compatible way, and so the code should be targeted at the p3yk branch. He also suggested that rewriting the import mechanisms in Python was probably going to be easier than trying to do it in C, particularly since some of the pieces were already available in the pkgutil module. Neal Norwitz strongly agreed, pointing out that string and list manipulation, which is necessary in a variety of places in the import mechanisms, is much easier in Python than in C. Brett promised a Python implementation as part of his research work. .. _PEP 302: http://www.python.org/dev/peps/pep-0302/ Contributing thread: - `Created branch for PEP 302 phase 2 work (in C) <http://mail.python.org/pipermail/python-dev/2006-October/069133.html>`__ ------------------------------------------ Web crawlers and development documentation ------------------------------------------ Fredrik Lundh noticed that Google was sometimes finding the `development documentation`_ instead of the `current release documentation`_. A.M. Kuchling added a ``robots.txt`` to keep crawlers out of the development area. .. _development documentation: http://docs.python.org/dev/ .. _current release documentation: http://docs.python.org/ Contributing thread: - `what's really new in python 2.5 ? <http://mail.python.org/pipermail/python-dev/2006-October/069158.html>`__ ----------------------------------------- Buildbots, compile errors and batch files ----------------------------------------- Tim Peters noticed that bsddb was getting compile errors on Windows but the buildbots were not reporting anything. Because some additional commands were added after the call to ``devenv.com`` in the ``build.bat`` script, the error status was not getting propagated appropriately. After Tim and Martin v. Lowis figured out how to repair this, the buildbots were again able to report compile errors. Contributing thread: - `2.4 vs Windows vs bsddb <http://mail.python.org/pipermail/python-dev/2006-October/069283.html>`__ --------------------------------- Python 2.5 and Visual Studio 2005 --------------------------------- Kristjan V. Jonsson showed that using Visual Studio 2005 instead of Visual Studio 2003 gave a 7% gain in speed, and a 10% gain when performance guided optimization (PGO) was enabled. While the "official" compiler can't get changed at a point release, everyone agreed that making the PCBuild8 directory work out of the box and adding an appropriate buildslave was a good idea. Kristjan promised to look into setting up a buildslave. Contributing thread: - `Python 2.5 performance <http://mail.python.org/pipermail/python-dev/2006-October/069338.html>`__ ---------------------------------- Distributing debug build of Python ---------------------------------- David Abrahams asked if python.org would be willing to post links to the ActiveState debug builds of Python to make it easier for Boost.Python_ users to obtain a debug build. People seemed to think that Boost.Python_ users should be able to create a debug build of Python themselves if necessary. .. _Boost.Python: http://www.boost.org/libs/python/doc/index.html Contributing thread: - `Plea to distribute debugging lib <http://mail.python.org/pipermail/python-dev/2006-October/069325.html>`__ ----------------------------------------- Unmarshalling/Unpickling multiple objects ----------------------------------------- Tim Lesher proposed adding a generator to marshal and pickle so that instead of:: while True: try: obj = marshal.load(fobj) # or pickle.load(fobj) except EOFError: break ... do something with obj ... you could write something like:: for obj in marshal.loaditer(fobj): # or pickle.loaditer(fobj) ... do something with obj ... when you wanted to load multiple objects in sequence from the same file. Both Perforce and Mailman store objects in a way that would benefit from such a function, so it seemed like such an API might be reasonable. No patch had been submitted at the time of this summary. Contributing thread: - `Iterating over marshal/pickle <http://mail.python.org/pipermail/python-dev/2006-October/069277.html>`__ ------------------------------- spawnvp and spawnvpe on Windows ------------------------------- Alexey Borzenkov asked why spawnvp and spawnvpe weren't available in Python on Windows even though they were implemented in the CRT. He got the usual answer, that no one had submitted an appropriate patch, but that such a patch would be a reasonable addition for Python 2.6. Fredrik Lundh pointed out that the subprocess module was probably a better choice than spawnvp and spawnvpe anyway. Contributing thread: - `Why spawnvp not implemented on Windows? <http://mail.python.org/pipermail/python-dev/2006-October/069342.html>`__ ================== Previous Summaries ================== - `difficulty of implementing phase 2 of PEP 302 in Python source <http://mail.python.org/pipermail/python-dev/2006-October/069116.html>`__ - `Python Doc problems <http://mail.python.org/pipermail/python-dev/2006-October/069252.html>`__ - `Signals, threads, blocking C functions <http://mail.python.org/pipermail/python-dev/2006-October/069334.html>`__ =============== Skipped Threads =============== - `Removing __del__ <http://mail.python.org/pipermail/python-dev/2006-September/068875.html>`__ - `Tix not included in 2.5 for Windows <http://mail.python.org/pipermail/python-dev/2006-October/069095.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-October/069098.html>`__ - `HAVE_UINTPTR_T test in configure.in <http://mail.python.org/pipermail/python-dev/2006-October/069103.html>`__ - `OT: How many other people got this spam? <http://mail.python.org/pipermail/python-dev/2006-October/069117.html>`__ - `2.4.4 fixes <http://mail.python.org/pipermail/python-dev/2006-October/069160.html>`__ - `2.4.4 fix: Socketmodule Ctl-C patch <http://mail.python.org/pipermail/python-dev/2006-October/069189.html>`__ - `[Python-checkins] r51862 - python/branches/release25-maint/Tools/msi/msi.py <http://mail.python.org/pipermail/python-dev/2006-October/069201.html>`__ - `Fwd: [ python-Feature Requests-1567948 ] poplib.py list interface <http://mail.python.org/pipermail/python-dev/2006-October/069223.html>`__ - `Can't check in on release25-maint branch <http://mail.python.org/pipermail/python-dev/2006-October/069256.html>`__ - `if __debug__: except Exception, e: pdb.set_trace() <http://mail.python.org/pipermail/python-dev/2006-October/069271.html>`__ - `2.5, 64 bit <http://mail.python.org/pipermail/python-dev/2006-October/069275.html>`__ - `BUG (urllib2) Authentication request header is broken on long usernames and passwords <http://mail.python.org/pipermail/python-dev/2006-October/069284.html>`__ - `[Python-3000] Sky pie: a "var" keyword <http://mail.python.org/pipermail/python-dev/2006-October/069292.html>`__ - `Proprietary code in python? <http://mail.python.org/pipermail/python-dev/2006-October/069294.html>`__ - `DRAFT: python-dev summary for 2006-08-16 to 2006-08-31 <http://mail.python.org/pipermail/python-dev/2006-October/069299.html>`__ - `BRANCH FREEZE, release24-maint for 2.4.4c1. 00:00UTC, 11 October 2006 <http://mail.python.org/pipermail/python-dev/2006-October/069302.html>`__ - `2.4 vs Windows vs bsddb [correction] <http://mail.python.org/pipermail/python-dev/2006-October/069310.html>`__ - `RELEASED Python 2.4.4, release candidate 1 <http://mail.python.org/pipermail/python-dev/2006-October/069326.html>`__ - `ConfigParser: whitespace leading comment lines <http://mail.python.org/pipermail/python-dev/2006-October/069337.html>`__ - `Exceptions and slicing <http://mail.python.org/pipermail/python-dev/2006-October/069363.html>`__ - `Proposal: No more standard library additions <http://mail.python.org/pipermail/python-dev/2006-October/069398.html>`__ - `[py3k] Re: Proposal: No more standard library additions <http://mail.python.org/pipermail/python-dev/2006-October/069399.html>`__ - `Modulefinder <http://mail.python.org/pipermail/python-dev/2006-October/069412.html>`__ - `VC6 support on release25-maint <http://mail.python.org/pipermail/python-dev/2006-October/069426.html>`__ - `os.utime on directories: bug fix or new feature? <http://mail.python.org/pipermail/python-dev/2006-October/069431.html>`__ - `Problem building module against Mac Python 2.4 and Python 2.5 <http://mail.python.org/pipermail/python-dev/2006-October/069434.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from October 01, 2006 through October 15, 2006. 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 python-dev summary is the 14th written by Steve Bethard. To contact me, please send email: - Steve Bethard (steven.bethard at gmail.com) Do *not* post to comp.lang.python if you wish to reach me. 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 ------------------------- 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. .. _python-dev: http://www.python.org/dev/ .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _Python Software Foundation: http://python.org/psf/ .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

ANN: pycairo release 1.2.6 now available
by Steve Chaplin Nov. 27, 2006

Nov. 27, 2006

Pycairo is a set of Python bindings for the multi-platform 2D graphics library cairo. http://cairographics.org http://cairographics.org/pycairo A new pycairo release 1.2.6 is now available from: http://cairographics.org/releases/pycairo-1.2.6.tar.gz http://cairographics.org/releases/pycairo-1.2.6.tar.gz.md5 166b04c4800c01aba1a6c8b14e87e0bc pycairo-1.2.6.tar.gz Overview of changes from pycairo 1.2.2 to pycairo 1.2.6 ======================================================= * Pycairo 1.2.6 requires cairo 1.2.6 (or later). * mingw32 compiler fixes (Cedric Gustin) * setup.py improvements (Cedric Gustin) * ImageSurface.get_data() new method added ImageSurface.get_data_as_rgba() method removed Send instant messages to your online friends http://au.messenger.yahoo.com

1 0

ANN: Pyflix-0.1
by George Sakkis Nov. 26, 2006

Nov. 26, 2006

Hi there, I'm happy to announce Pyflix, a small Python package that provides an easy entry point for those wishing to get up and running at the Netflix Prize competition (http://www.netflixprize.com/). For those who are not aware of it, the Netflix Prize challenge is to write a recommendation algorithm that improves the accuracy of predictions about how much someone is going to love a movie based based on their past ratings. Netflix offers $1,000,000 (one million dollars) to the first team that provides an algorithm that outperforms Cinematch (TM), the movie recommendation system developed by Netflix, by 10% or more; there's also a $50,000 Progress Prize awarded to the team with the most improvement over the previous year's accuracy. Pyflix requires Python 2.4 or later and Numpy 1.0. It combines an efficient storage scheme with a high-level API that allows contestants to focus on the real problem, the recommendation system algorithm. You may download Pyflix and find more about it at http://pyflix.python-hosting.com. Enjoy and good luck! George

1 0

Ruby & Python Conference 2007
by Katarzyna Bylec Nov. 26, 2006

Nov. 26, 2006

Hello, we would like to invite you to one of the biggest Ruby and Python events in central-eastern Europe next year. RuPy Conference dedicated to Ruby and Python programming languages will take place in April 14-15, 2007 in Poznan, Poland and the idea behind it is to put together experts with young programmers and to support a good communication channel for East-West exchange of prospective ideas. If you think you have something interesting to present or some ideas to share with other enthusiasts, we would be more then happy to welcome you as a Speaker. Proposals of lectures (i.e. title and short abstract) can be submitted to rupy-talks(a)wmid.amu.edu.pl . <rupy-talks(a)wmid.amu.edu.pl> Speakers' registration includes attendance at lecture sessions on both days of the Conference, all refreshments during the coffee breaks and Conference lunches. For each participant Organizers guarantee free accommodation and full board during the Conference. As a Speaker you will also be entitled to partial reimbursement for the travel expenses.You are also more than welcome to participate in all extra events including guided sightseeing, conference Banquet and other entertainments provided by Organizers. All information can be found on RuPy website: http://rupy.wmid.amu.edu.pl Looking forward to seeing you in Poland, RuPy Committee

1 0

RuPy: Ruby & Python Conference 2007
by Katarzyna Bylec Nov. 26, 2006

Nov. 26, 2006

Hello, we would like to invite you to one of the biggest Ruby and Python events in central-eastern Europe next year. RuPy Conference dedicated to Ruby and Python programming languages will take place in April 14-15, 2007 in Poznan, Poland and the idea behind it is to put together experts with young programmers and to support a good communication channel for East-West exchange of prospective ideas. If you think you have something interesting to present or some ideas to share with other enthusiasts, we would be more then happy to welcome you as a Speaker. Proposals of lectures (i.e. title and short abstract) can be submitted to rupy-talks(a)wmid.amu.edu.pl . <rupy-talks(a)wmid.amu.edu.pl> Speakers' registration includes attendance at lecture sessions on both days of the Conference, all refreshments during the coffee breaks and Conference lunches. For each participant Organizers guarantee free accommodation and full board during the Conference. As a Speaker you will also be entitled to partial reimbursement for the travel expenses.You are also more than welcome to participate in all extra events including guided sightseeing, conference Banquet and other entertainments provided by Organizers. All information can be found on RuPy website: http://rupy.wmid.amu.edu.pl Looking forward to seeing you in Poland, RuPy Committee

1 0

LDBackup Release 00.08.01
by daftspaniel＠gmail.com Nov. 25, 2006

Nov. 25, 2006

Release 00.08.01 This is the fifth public release of LD Backup and it is not quite 'ready'. The purpose of this release is to get some feedback and maybe find a developer or two to contribute. It is a small project to encourage newbies to Python to take part in OSS software. The program has been tested on Windows XP SP2 and on Ubuntu Linux 6.06 so it may still need some work on other platforms. Cross-platform support is a high priority for version 1.0. http://www.latedecember.com/sites/software/LDBackup/

1 0