Mailman 3 July 2006 - Python-announce-list

python-dev Summary for 2006-06-01 through 2006-06-15
by Steven Bethard 06 Jul '06

06 Jul '06

python-dev Summary for 2006-06-01 through 2006-06-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-06-01_2006-06-15] ============= Announcements ============= ------------------- Python 2.5 schedule ------------------- Python 2.5 is moving steadily towards its next release. See `PEP 356`_ for more details and the full schedule. .. _PEP 356: http://www.python.org/dev/peps/pep-0356/ Contributing threads: - `beta1 coming real soon <http://mail.python.org/pipermail/python-dev/2006-June/065729.html>`__ - `2.5 issues need resolving in a few days <http://mail.python.org/pipermail/python-dev/2006-June/065730.html>`__ ----------------------------------------------- Request for Bug Trackers to replace SourceForge ----------------------------------------------- The Python Software Foundation's Infrastructure committee asked for suggestions for tracker systems that could replace SourceForge. The minimum requirements are: * Can import SourceForge data * Can export data * Has an email interface and if you'd like to suggest a particular tracker system all you need to do is: * Install a test tracker * Import the `SourceForge data dump`_ * Make the `Infrastructure committee members`_ administrators of the tracker * Add your tracker to the `wiki page`_ * Email `the Infrastructure committee`_ Be sure to check the `wiki page`_ for additional information. .. _SourceForge data dump: http://effbot.org/zone/sandbox-sourceforge.htm .. _Infrastructure committee members: http://wiki.python.org/moin/PythonSoftwareFoundationCommittees#infrastructu… .. _wiki page: http://wiki.python.org/moin/CallForTrackers .. _the Infrastructure committee: infrastructure(a)python.org Contributing thread: - `Request for trackers to evaluate as SF replacement for Python development <http://mail.python.org/pipermail/python-dev/2006-June/065597.html>`__ ========= Summaries ========= -------------------------------------------- Getting more comparable results from pybench -------------------------------------------- Skip Montanaro mentioned that the NeedForSpeed_ folks had some trouble with the pybench_ string and unicode tests. In some discussions both on the checkins list and off-list, Fredrik Lundh had concluded that stringbench more reliably reported performance than pybench. There was then a long discussion about how to improve pybench including: * Using time.clock() on Windows and time.time() on Linux. This was accompanied by a long debate about whether to use wall-time or process time. Both wall time and process time can see interference from other programs running at the same time; wall time because the time consumed by other programs running at the same time is also counted, and process time because it is sampled so that other processes can charge their time to the running process by using less than a full time slice. In general, the answer was to use the timer with the best resolution. * Using the minimum time rather than the average. Andrew Dalke explained that timing results do not have a Gaussian distribution (they have more of a gamma distribution) and provided some graphs generated on his machine to demonstrate this. Since the slower runs are typically caused by other things running at the same time (which is pretty much unpredictable), it's much better to report the fastest run, which should more consistently approximate the best possible time. * Making sure to use an appropriate warp factor. Marc-Andre Lemburg explained that each testing round of pybench is expected to take around 20-50 seconds. If rounds are much shorter than this, pybench's warp factor should be adjusted until they are long enough. At the end of the thread, Marc-Andre checked in pybench_ 2.0, which included the improvements suggested above. .. _NeedForSpeed: http://wiki.python.org/moin/NeedForSpeed .. _pybench: http://svn.python.org/view/python/trunk/Tools/pybench/ .. _stringbench: http://svn.python.org/view/sandbox/trunk/stringbench/ Contributing threads: - `Python Benchmarks <http://mail.python.org/pipermail/python-dev/2006-May/065480.html>`__ - `Python Benchmarks <http://mail.python.org/pipermail/python-dev/2006-June/065525.html>`__ --------------------------------------- PEP 360: Externally Maintained Packages --------------------------------------- After checking wsgiref into the Python repository, Phillip J. Eby requested in `PEP 360`_ that patches to wsgiref be passed to him before being committed on the trunk. After a number of changes were committed to the trunk and he had to go through a complicated two-way merge, he complained that people were not following the posted procedures. Guido suggested that `PEP 360`_ was a mistake, and that whenever possible, development for any module in the stdlib should be done in the Python trunk, not externally. He also requested that the PEP indicate that even for externally maintained modules, bugfixes and ordinary maintenance should be allowed on the trunk so that bugs in external modules don't hold up Python core development. A number of solutions were discussed for authors of code that is also distributed standalone. Using svn:externals is mostly undesirable because svn is much slower at checking whether or not an svn:externals directory is updated, and because upgrading to a newer version would require making sure that no changes made by Python developers were lost in the new version. Phillip suggested adding an "Externals" directory and modifying Python's setup to invoke all the ``Externals/*/setup.py`` scripts, though this would mean having some Python code that lives outside of the Lib/ subtree. Barry Warsaw explained that for the email package, he maintains a directory in the sandbox with all the distutils and documentation stuff needed for the standalone releases as well as the email package from the Python repository through svn:externals. This means having to create some extra directories (since svn:externals doesn't work with individual files) and having one checkout per version of Python supported, but seemed to work pretty well for Barry. People seemed to like Phillip's Externals idea (possibly renamed to Packages), but work on that was postponed for Python 2.6. One of the side benefits of these discussions was that Thomas Heller generously offered to move ctypes development fully into the Python repository. .. _PEP 360: http://www.python.org/dev/peps/pep-0360/ Contributing threads: - `wsgiref documentation <http://mail.python.org/pipermail/python-dev/2006-June/065576.html>`__ - `wsgiref doc draft; reviews/patches wanted <http://mail.python.org/pipermail/python-dev/2006-June/065647.html>`__ - `[Web-SIG] wsgiref doc draft; reviews/patches wanted <http://mail.python.org/pipermail/python-dev/2006-June/065701.html>`__ - `FYI: wsgiref is now checked in <http://mail.python.org/pipermail/python-dev/2006-June/065767.html>`__ - `Please stop changing wsgiref on the trunk <http://mail.python.org/pipermail/python-dev/2006-June/065908.html>`__ - `Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk) <http://mail.python.org/pipermail/python-dev/2006-June/065919.html>`__ - `External Package Maintenance (was Re: Please stop changing wsgiref on the trunk) <http://mail.python.org/pipermail/python-dev/2006-June/065920.html>`__ - `External Package Maintenance <http://mail.python.org/pipermail/python-dev/2006-June/065937.html>`__ - `rewording PEP 360 <http://mail.python.org/pipermail/python-dev/2006-June/066001.html>`__ - `Updating packages from external ? <http://mail.python.org/pipermail/python-dev/2006-June/066035.html>`__ -------------------------------------- Universally unique identifiers (UUIDs) -------------------------------------- Ka-Ping Yee was looking to put his `uuid module`_ into Python 2.5. He addressed a number of requests from the last round of discussions, including making UUIDs immutable, removing curly braces from the UUID string and adding the necessary tests to the test suite. Then he asked about how best to address the fact that ``uuid1()`` required looking up a MAC address, a potentially slow procedure. At the suggestion of Fredrik Lundh, he changed the API to allow a MAC address to be passed in if it was already known. If a MAC address is not passed in to ``uuid1()``, the ``getnode()`` utility function is called, which searches for the MAC address through a variety of routes, including some quicker paths through ctypes that Thomas Heller and others helped Ka-Ping with. The code was checked into the Python trunk. .. _uuid module: http://zesty.ca/python/uuid.py Contributing thread: - `UUID module <http://mail.python.org/pipermail/python-dev/2006-June/065733.html>`__ ------------------------------------- PEP 275: Switching on Multiple Values ------------------------------------- Thomas Lee offered up a `patch implementing the switch statement`_ from `PEP 275`_. People brought up a number of concerns with the implementation (and the switch statement in general). The implementation didn't allow for any way of allowing multiple values to be mapped to the same case (without repeating the code in the case). The implementation also made the switch statement essentially syntactic sugar for a series of if/elif/else statements, and people were concerned that just adding another way to write if/elif/else was not much of a gain for Python. The discussion continued on into the next fortnight. .. _patch implementing the switch statement: http://bugs.python.org/1504199 .. _PEP 275: http://www.python.org/dev/peps/pep-0275/ Contributing thread: - `Switch statement <http://mail.python.org/pipermail/python-dev/2006-June/065827.html>`__ --------------------------------------------------------- The period of the random module's random number generator --------------------------------------------------------- Alex Martelli noticed a note in random.shuffle.__doc__ which said that most permutations of a long sequence would never be generated due to the short period of the random number generator. This turned out to be an artifact from back when Python used the Whichman-Hill generator instead of the Mersenne Twister generator it uses currently. There was some discussion as to whether the comment should be removed or updated, and Robert Kern pointed out that at sequence lengths of 2081 or greater, the comment was still true. Tim Peters decided it was best to just remove the comment, explaining that "anyone sophisticated enough to *understand* an accurate warning correctly would have no need to be warned". Contributing thread: - `a note in random.shuffle.__doc__ ... <http://mail.python.org/pipermail/python-dev/2006-June/065815.html>`__ ------------------------------------------------------- Pre-PEP: Allow Empty Subscript List Without Parentheses ------------------------------------------------------- Noam Raphael presented a `pre-PEP for empty subscript lists`_ in getitem-style access to objects. This would allow zero-dimensional arrays to work in a similar manner to all other N dimensional arrays, and make all of the following equivalences hold:: x[i, j] <--> x[(i, j)] x[i,] <--> x[(i,)] x[i] <--> x[(i)] x[] <--> x[()] Most people felt that zero-dimensional arrays were uncommon enough that either they could be replaced with simple names, e.g. ``x``, or could use the currently available syntax, i.e. ``x[()]``. Zero-dimensional arrays are even uncommon in numpy_ where, after `rehashing the issue`_ innumerable times, zero-dimensional arrays have been almost entirely replaced with scalars. .. _pre-PEP for empty subscript lists: http://wiki.python.org/moin/EmptySubscriptListPEP .. _numpy: http://numeric.scipy.org/ .. _rehashing the issue: http://projects.scipy.org/scipy/numpy/wiki/ZeroRankArray Contributing thread: - `Pre-PEP: Allow Empty Subscript List Without Parentheses <http://mail.python.org/pipermail/python-dev/2006-June/065762.html>`__ ---------------------------------------------- PEP 337: Logging Usage in the Standard Library ---------------------------------------------- For the `Google Summer of Code`_, Jackilyn Hoxworth has been working on implementing parts of `PEP 337`_ to use the logging module in parts of the stdlib. When Jim Jewett, who is mentoring her, brought up a few issues, people got concerned that this work was being done at all, being that `PEP 337`_ has not been approved. Jim and A.M. Kuchling clarified that the goal of Jackilyn's work is to both clarify the PEP (e.g. determine exactly which modules would benefit from logging) and to provide an implementation that can be tweaked as necessary if the PEP is accepted. For the first draft at least, it looked like Jackilyn would keep things simple -- using "py." + __name__ for the logger name, not adding any new logging messages, not changing any message formats, and generally aiming only to give stderr and stdout messages across different modules a common choke point. .. _Google Summer of Code: http://code.google.com/soc/ .. _PEP 337: http://www.python.org/dev/peps/pep-0337/ Contributing thread: - `Stdlib Logging questions (PEP 337 SoC) <http://mail.python.org/pipermail/python-dev/2006-June/065601.html>`__ ------------------- inspect.isgenerator ------------------- Michele Simionato asked for a new function in the inspect module that would identify a function as being a generator function. Phillip J. Eby pointed out that any function can return a generator-iterator (though generator functions are of course guaranteed to do so) and suggested that the perceived need for this inspect function was misguided. Michele agreed and withdrew the proposal. Contributing threads: - `feature request: inspect.isgenerator <http://mail.python.org/pipermail/python-dev/2006-May/065334.html>`__ - `feature request: inspect.isgenerator <http://mail.python.org/pipermail/python-dev/2006-June/065508.html>`__ -------------------------------- Unescaping entities with sgmllib -------------------------------- Sam Ruby asked why sgmllib unescapes entities selectively, not all or nothing (which would be easier to work around), and Fred L. Drake, Jr. explained that sgmllib is really only intended as support for htmllib. Sam suggested isolating the code that attempts to resolve character references into a single method so that subclasses could override this behavior as needed. Martin v. Löwis agreed that this seemed reasonable, though he suggested two functions, one for character references and one for entity references. Sam implemented the suggested behavior and provided a `patch to sgmllib`_. .. _patch to sgmllib: http://bugs.python.org/1504676 Contributing thread: - `sgmllib Comments <http://mail.python.org/pipermail/python-dev/2006-June/065861.html>`__ ------------------------------------------------------------------------- Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5) ------------------------------------------------------------------------- A bug in Python 2.5 that did not detect augmented assignment as creating a local name allowed code like the following to work:: >>> g = 1 >>> def f1(): ... g += 1 ... >>> f1() >>> g 2 This of course started the usual discussion about giving Python a way to rebind names in enclosing scopes. Boris Borcic in particular was hoping that the bug could be considered a feature, but Terry Reedy explained that Python was not willing to give up the near equivalence between ``x = x + 1`` and ``x += 1``. Since the former creates a local name, the latter ought to do the same thing. The thread seemed like it might drift on further until Guido cut it off, pronouncing that the behavior of augmented assignments creating local names was not going to change. Contributing threads: - `'fast locals' in Python 2.5 <http://mail.python.org/pipermail/python-dev/2006-June/065648.html>`__ - `Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5) <http://mail.python.org/pipermail/python-dev/2006-June/065902.html>`__ - `Comparing closures and arguments (was Re: Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5) <http://mail.python.org/pipermail/python-dev/2006-June/066064.html>`__ - `The baby and the bathwater (Re: Scoping, augmented assignment, 'fast locals' - conclusion) <http://mail.python.org/pipermail/python-dev/2006-June/066080.html>`__ --------------------------------------- Checking out an older version of Python --------------------------------------- Skip Montanaro asked about checking out a particular version of Python. Oleg Broytmann and Tim Peters explained that tags are just directories in Subversion, and you can view all the existing ones and their corresponding revision numbers at http://svn.python.org/projects/python/tags/. Oleg also explained that the difference between:: svn switch svn+ssh://pythondev@svn.python.org/python/tags/r242 and noting that the r242 tag corresponds to revision 39619 and doing:: svn up -r 39619 is that with the latter, commits will go to the trunk (assuming the update was performed on a trunk checkout), while with the former, updates will go to the appropriate tag or branch. Giovanni Bajo provided a nice explanation of this, describing Subversion's 2D coordinate system of [url, revision] and Skip added the explanation to the `Development FAQ`_. .. _Development FAQ: http://www.python.org/dev/faq/ Contributing thread: - `Subversion repository question - back up to older versions <http://mail.python.org/pipermail/python-dev/2006-June/065709.html>`__ -------------------- Source control tools -------------------- In the externally maintained packages discussion, Guido suggested offhand that some other version control project might make it easier to resolve some of the issues. Thomas Wouters put forward a number of considerations. On the negative side of changing to one of the newer version control systems: * Workflow would have to change somewhat to use most of the new branch-oriented systems. * Everyone would have to download the whole repository (at least once) since with the newer systems everyone usually has their own repository. But on the positive side: * History can be preserved for merges of branches (unlike Subversion), which is a big gain for when the trunk is switched to 3.0. Thomas tried importing the Python repository into a number of different systems, and after playing around with them, concluded that in the short term, none of the other version control systems were quite ready yet, though he seemed optimistic for them in the next few years. He also promised to publish imports of the Python repository into Git, Darcs, Mercurial, Bazaar-NG and Monotone somewhere once he was able to successfully import them all. Contributing thread: - `Source control tools <http://mail.python.org/pipermail/python-dev/2006-June/065971.html>`__ ---------------------------------------------------- Underscore assignment in the interactive interpreter ---------------------------------------------------- Raymond Hettinger noted that in the interactive interpreter, an expression that returns None not only suppresses the printing of that None, but also suppresses the assignment to ``_``. Raymond asked if this was intentional as it makes code like the following break:: >>> import re, string >>> re.search('lmnop', string.letters) <_sre.SRE_Match object at 0xb6f2c480> >>> re.search('pycon', string.letters) >>> if _ is not None: ... print _.group() lmnop Fredrik Lundh pointed out that users just need to recognize that the ``_`` holds the most recently *printed* result. Guido pronounced that this would not change. Terry Reedy suggested adding some documentation for this behavior to either Language Reference 2.3.2 Reserved Classes of Identifiers and/or to Tutorial 2.1.2 Interactive Mode, but it was unclear if any doc changes were committed. Contributing thread: - `Is implicit underscore assignment buggy? <http://mail.python.org/pipermail/python-dev/2006-June/065679.html>`__ ----------------------- Removing MAC OS 9 cruft ----------------------- A number of old MAC OS 9 bits and pieces that are no longer used were removed: * IDE scripts * MPW * Tools/IDE * Tools/macfreeze * Unsupported/mactcp/dnrglue.c * Wastemods This should solve some problems for Windows checkouts where files with trailing dots are not supported. Contributing threads: - `Removing Mac OS 9 cruft <http://mail.python.org/pipermail/python-dev/2006-June/065526.html>`__ - `Mac/wastemodule build failing <http://mail.python.org/pipermail/python-dev/2006-June/065588.html>`__ ------------------------------------------ Fixing buffer object's char buffer support ------------------------------------------ Brett Cannon found that ``import array; int(buffer(array.array('c')))`` caused the interpreter to segfault because buffer objects were redirecting tp_as_buffer->bf_getcharbuffer to the wrong tp_as_buffer slot. Brett fixed the bug and updated the docs a bit to clarify what was intended for the implementation, but kept changes pretty minimal as Python 3.0 will ditch buffer for the bytes type anyway. Contributing threads: - `How to fix the buffer object's broken char buffer support <http://mail.python.org/pipermail/python-dev/2006-June/065646.html>`__ - `Is "t#" argument format meant to be char buffer, or just read-only? <http://mail.python.org/pipermail/python-dev/2006-June/065678.html>`__ ------------------------------- Importing subpackages in Jython ------------------------------- In Jython 2.1, importing a module makes all subpackages beneath it available, unlike in regular Python, where subpackages must be imported separately. Samuele Pedroni explained that this was intentional so that imports in Jython would work like imports in Java do. Guido suggested that having imports work this way in Jython was fine as long as a Java package was being imported, but when a Python package was being imported, Jython should use the Python semantics. Contributing thread: - `Import semantics <http://mail.python.org/pipermail/python-dev/2006-June/065864.html>`__ --------------------------------------------- RFC 3986: Uniform Resource Identifiers (URIs) --------------------------------------------- There was some continued discussion of Paul Jimenez's proposed `uriparse module`_ which more faithfully implements `RFC 3986`_ than the current urlparse module. Nick Coghlan submitted an `alternate implementation`_ that kept all parsed URIs as (scheme, authority, path, query, fragment) tuples by allowing some of these elements to be non-strings, e.g. authority could be a (user, password, host, port) tuple, and path could be a (user, host) tuple. People seemed to like Nick's implementation, but no final decision on the module was made. .. _uriparse module: http://bugs.python.org/1462525 .. _RFC 3986: http://www.ietf.org/rfc/rfc3986.txt .. _alternate implementation: http://bugs.python.org/1500504 Contributing thread: - `Some more comments re new uriparse module, patch 1462525 <http://mail.python.org/pipermail/python-dev/2006-June/065552.html>`__ ----------------------------------------------------- False instead of TypeError for frozenset.__contains__ ----------------------------------------------------- Collin Winter suggested that code like ``{} in frozenset([1, 2, 3])`` should return False instead of raising a TypeError. Guido didn't like the idea because he thought it would mask bugs where, say, a user-defined __hash__() method accidentally raised a TypeError. Contributing thread: - `Unhashable objects and __contains__() <http://mail.python.org/pipermail/python-dev/2006-June/065577.html>`__ -------------------------------------------- IOError or ValueError for invalid file modes -------------------------------------------- Kristján V. Jónsson asked why open()/file() throws an IOError for an invalid mode string instead of a ValueError. Georg Brandl explained that either an IOError or a ValueError can be raised depending on whether the invalid mode was detected in Python's code or in the OS's fopen call. Guido suggested that this couldn't really be fixed until Python gets rid of its stdio-based implementation in Python 3.0. Contributing thread: - `file() <http://mail.python.org/pipermail/python-dev/2006-June/065903.html>`__ ----------------------------- Testing, unittest and py.test ----------------------------- Martin Blais checked in un-unittestification of test_struct, and a number of people questioned whether that was a wise thing to do. Thomas Wouters suggested that unittest should merge as many features from py.test_ as possible. This would reduce some of the class-based boilerplate currently required, and also allow some nice additional features like test cases generated on the fly. He didn't get much of a response though, so it was unclear what the plans for Python 2.6 were. .. _py.test: http://codespeak.net/py/current/doc/test.html Contributing thread: - `[Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py <http://mail.python.org/pipermail/python-dev/2006-June/065584.html>`__ ------------------------------------------------ hex(), oct() and the 'L' suffix for long numbers ------------------------------------------------ Ka-Ping Yee asked why hex() and oct() still produced an 'L' suffix for long numbers even now that ints and longs have basically been unified. `PEP 237`_ had mentioned the removal of this suffix, but not given it a specific release for removal, so people decided it was best to wait until Python 3.0 when the 'L' suffix will also be removed from repr(). .. _PEP 237: http://www.python.org/dev/peps/pep-0237/ Contributing thread: - `Should hex() yield 'L' suffix for long numbers? <http://mail.python.org/pipermail/python-dev/2006-June/065870.html>`__ --------------------------------- Adding an index of Python symbols --------------------------------- Terry Reedy suggested adding a page to the Python Language Reference index that would list each symbol in Python (e.g. ``()``, ``[]`` and ``@``) along with the places in the documentation where it was discussed. Terry promised to submit a plain-text version in time for the Python 2.5 release, so that someone could convert it to LaTeX and merge it into the docs. Contributing thread: - `Symbol page for Language Reference Manual Index <http://mail.python.org/pipermail/python-dev/2006-June/065681.html>`__ ------------------------------------------ Behavior of searching for empty substrings ------------------------------------------ Fredrik Lundh resolved the issues discussed previously with searching for an empty substring at a position past the end of the string. The current behavior looks like:: >>> "ab".find("") 0 >>> "ab".find("", 1) 1 >>> "ab".find("", 2) 2 >>> "ab".find("", 3) -1 Both Tim Peters and Guido applauded the final resolution. Contributing thread: - `Search for empty substrings (was Re: Let's stop eating exceptions in dict lookup) <http://mail.python.org/pipermail/python-dev/2006-June/065500.html>`__ ----------------- subprocess.IGNORE ----------------- Martin Blais asked about adding subprocess.IGNORE along the lines of subprocess.PIPE which would ignore the child's output without being susceptible to buffer deadlock problems. Under Unix, IGNORE could be implemented as ``open('/dev/null', 'w')``, and on Windows, ``open('nul:', 'w')``. People seemed to think this was a useful feature, but at the time of this summary, no patch had yet been provided. Contributing thread: - `subprocess.Popen(.... stdout=IGNORE, ...) <http://mail.python.org/pipermail/python-dev/2006-June/065868.html>`__ ================ Deferred Threads ================ - `Improve error msgs? <http://mail.python.org/pipermail/python-dev/2006-June/066048.html>`__ - `Keeping interned strings in a set <http://mail.python.org/pipermail/python-dev/2006-June/066084.html>`__ - `Documentation enhancement: "MS free compiler"? <http://mail.python.org/pipermail/python-dev/2006-June/066182.html>`__ - `Code coverage reporting. <http://mail.python.org/pipermail/python-dev/2006-June/066184.html>`__ - `Numerical robustness, IEEE etc. <http://mail.python.org/pipermail/python-dev/2006-June/066186.html>`__ ================== Previous Summaries ================== - `Let's stop eating exceptions in dict lookup <http://mail.python.org/pipermail/python-dev/2006-June/065499.html>`__ - `ssize_t question: longs in header files <http://mail.python.org/pipermail/python-dev/2006-June/065574.html>`__ - `ssize_t: ints in header files <http://mail.python.org/pipermail/python-dev/2006-June/065624.html>`__ - `zlib module doesn't build - inflateCopy() not found <http://mail.python.org/pipermail/python-dev/2006-June/065706.html>`__ =============== Skipped Threads =============== - `Segmentation fault of Python if build on Solaris 9 or10 with Sun Studio 11 <http://mail.python.org/pipermail/python-dev/2006-June/065495.html>`__ - `Possible bug in complexobject.c (still in Python 2.5) <http://mail.python.org/pipermail/python-dev/2006-June/065496.html>`__ - `[Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c <http://mail.python.org/pipermail/python-dev/2006-June/065501.html>`__ - `test_struct failure on 64 bit platforms <http://mail.python.org/pipermail/python-dev/2006-June/065506.html>`__ - `string inconsistency <http://mail.python.org/pipermail/python-dev/2006-June/065507.html>`__ - `S/390 buildbot URLs problematic <http://mail.python.org/pipermail/python-dev/2006-June/065517.html>`__ - `SF patch #1473257: "Add a gi_code attr to generators" <http://mail.python.org/pipermail/python-dev/2006-June/065524.html>`__ - `test_unicode failure on MIPS <http://mail.python.org/pipermail/python-dev/2006-June/065529.html>`__ - `valgrind report <http://mail.python.org/pipermail/python-dev/2006-June/065532.html>`__ - `test_ctypes failures on ppc64 debian <http://mail.python.org/pipermail/python-dev/2006-June/065544.html>`__ - `Request for patch review <http://mail.python.org/pipermail/python-dev/2006-June/065581.html>`__ - `patch #1454481 vs buildbot <http://mail.python.org/pipermail/python-dev/2006-June/065592.html>`__ - `Seeking Core Developers for Vancouver Python Workshop <http://mail.python.org/pipermail/python-dev/2006-June/065600.html>`__ - `[Python-checkins] Python Regression Test Failures refleak (1) <http://mail.python.org/pipermail/python-dev/2006-June/065613.html>`__ - `Include/structmember.h, Py_ssize_t <http://mail.python.org/pipermail/python-dev/2006-June/065619.html>`__ - `DC Python sprint on July 29th <http://mail.python.org/pipermail/python-dev/2006-June/065625.html>`__ - `tarfile and unicode filenames in windows <http://mail.python.org/pipermail/python-dev/2006-June/065710.html>`__ - `[Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk <http://mail.python.org/pipermail/python-dev/2006-June/065719.html>`__ - `-Wi working for anyone else? <http://mail.python.org/pipermail/python-dev/2006-June/065779.html>`__ - `Inject some tracing ... <http://mail.python.org/pipermail/python-dev/2006-June/065781.html>`__ - `Segmentation fault in collections.defaultdict <http://mail.python.org/pipermail/python-dev/2006-June/065828.html>`__ - `Add pure python PNG writer module to stdlib? <http://mail.python.org/pipermail/python-dev/2006-June/065834.html>`__ - `crash in dict on gc collect <http://mail.python.org/pipermail/python-dev/2006-June/065855.html>`__ - `"can't unpack IEEE 754 special value on non-IEEE platform" <http://mail.python.org/pipermail/python-dev/2006-June/065957.html>`__ - `socket._socketobject.close() doesn't really close sockets <http://mail.python.org/pipermail/python-dev/2006-June/065991.html>`__ - `DRAFT: python-dev summary for 2006-04-16 to 2006-04-30 <http://mail.python.org/pipermail/python-dev/2006-June/066011.html>`__ - `[Python-checkins] r46795 - in python/trunk: Doc/lib/libstdtypes.tex Lib/test/string_tests.py Misc/NEWS Objects/stringobject.c Objects/unicodeobject.c <http://mail.python.org/pipermail/python-dev/2006-June/066013.html>`__ - `xrange vs. int.__getslice__ <http://mail.python.org/pipermail/python-dev/2006-June/066014.html>`__ - `request for review: patch 1446489 (zip64 extensions in zipfile) <http://mail.python.org/pipermail/python-dev/2006-June/066018.html>`__ - `DRAFT: python-dev summary for 2006-05-01 to 2006-05-15 <http://mail.python.org/pipermail/python-dev/2006-June/066020.html>`__ - `pychecker warnings in Lib/encodings <http://mail.python.org/pipermail/python-dev/2006-June/066021.html>`__ - `Moving PEP 343 to Final <http://mail.python.org/pipermail/python-dev/2006-June/066027.html>`__ - `Python sprint at Google Aug. 21-24 <http://mail.python.org/pipermail/python-dev/2006-June/066043.html>`__ - `Long options support <http://mail.python.org/pipermail/python-dev/2006-June/066049.html>`__ - `High Level Virtual Machine <http://mail.python.org/pipermail/python-dev/2006-June/066053.html>`__ - `sqlite3 test errors - was : Re: [Python-checkins] r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/connection.c Modules/_sqlite/cursor.c Modules/_sqlite/module.c Modules/_sqlite/module.h <http://mail.python.org/pipermail/python-dev/2006-June/066055.html>`__ - `[Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/connection.c Modules/_sqlite/cursor.c Modules/_sqlite/module.c Modules/_sqlite/module.h <http://mail.python.org/pipermail/python-dev/2006-June/066056.html>`__ - `[Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/connection.c Modules/_sqlite/cursor.c Modules/_sqlite/module.c <http://mail.python.org/pipermail/python-dev/2006-June/066060.html>`__ - `[Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/connection.c Modules/_sqlite/cursor.c Modules/_sql <http://mail.python.org/pipermail/python-dev/2006-June/066068.html>`__ - `Last-minute curses patch <http://mail.python.org/pipermail/python-dev/2006-June/066076.html>`__ - `DRAFT: python-dev summary for 2006-05-16 to 2006-05-31 <http://mail.python.org/pipermail/python-dev/2006-June/066078.html>`__ - `Bug: xml.dom.pulldom never gives you END_DOCUMENT events with an Expat parser <http://mail.python.org/pipermail/python-dev/2006-June/066179.html>`__ - `Misleading error message from PyObject_GenericSetAttr <http://mail.python.org/pipermail/python-dev/2006-June/066183.html>`__ - `About dynamic module loading <http://mail.python.org/pipermail/python-dev/2006-June/066185.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from June 01, 2006 through June 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 6th written by Steve Bethard. (Please, ma, don't make me do the switch statement summary!) 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 ------------------------- 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. .. _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/ .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

Dallas Ft. Worth Pythoneers Meeting THIS Saturday
by Jeff Rush 06 Jul '06

06 Jul '06

The Dallas chapter of the Dallas Ft. Worth Pythoneers meets on the 2nd and 4th Saturday of each month, in a hands-on (so bring your laptops!) programming session. Topic: Last meeting our new format was a success! We covered the creational type of design patterns, showing Python code for each one, and then Brad walked us through his custom Object-Relational-Manager (ORM) in the areas of enforcing object security derived from the underlying relational security rules. This time we'll continue by going over the structural type of design patterns and then trying out lightning talks. Lightning talks are 5-minute rapid-fire presentations by members on any topic related to Python. The format is casual (slides unnecessary) and not intended to cover a topic but to introduce it to the attendees. They are a lot of fun and stimulate ideas for future talks. Everyone please think about a topic and come prepared. It could be an simple as just announcing this cool Python library you found on some website one day. Look thru your bookmarks for ideas. When: Saturday, July 8, 2006, 1:30 PM Where: NerdBooks.com 1681 Firman Drive Richardson , TX 75081 (972) 470-9600 Website: http://www.python.org/dfw http://python.meetup.com/10 Notes: We run until 5 pm and then go out for dinner. We start gathering at 1:30 pm, getting tables, projector and network equipment set up and organized, and then start any formal portion of the meeting at 2 pm. So if you can't make it until 2 pm, that's fine you won't miss any presentation. Jeff Rush <jeff(a)taupro.com> DFW Pythoneers Coordinator P.S. The DFW Pythoneers are _also_ meeting _this_ evening (1st Thursday of July) at Denny's Restaurant in Addison, on Beltline just east of Midway. We meet at 7 pm and run until midnight, usually. This meeting is a social get-together over dinner.

1 0

ANN: Python Enthought Edition Version 1.0.0.beta3 Released
by Bryce Hendrix 05 Jul '06

05 Jul '06

Enthought is pleased to announce the release of Python Enthought Edition Version 1.0.0.beta3 (http://code.enthought.com/enthon/) -- a python distribution for Windows. 1.0.0.beta3 Release Notes: -------------------- Version 1.0.0.beta3 of Python Enthought Edition is the first version based on Python 2.4.3 and includes updates to nearly every package. This is the third and (hopefully) last beta release. This release includes version 1.0.8 of the Enthought Tool Suite (ETS) Package and bug fixes-- you can look at the release notes for this ETS version here: http://svn.enthought.com/downloads/enthought/changelog-release.1.0.8.html About Python Enthought Edition: ------------------------------- Python 2.4.3, Enthought Edition is a kitchen-sink-included Python distribution for Windows including the following packages out of the box: Numeric SciPy IPython Enthought Tool Suite wxPython PIL mingw f2py MayaVi Scientific Python VTK and many more... More information is available about all Open Source code written and released by Enthought, Inc. at http://code.enthought.com

1 0

About a month until PSF call for test trackers closes!
by Brett Cannon 05 Jul '06

05 Jul '06

Back at the beginning of June, the Python Software Foundation's Infrastructure committee sent out an email requesting people to help us find a replacement tracker for SourceForge (the original announcement can be found at http://wiki.python.org/moin/CallForTrackers ). We asked that people put test trackers loaded with a data dump of Python's SourceForge tracker data online for us to play with. We said that we would close acceptance of test trackers as of August 7. That close date is a little over a month away! If you want to help get your favorite tracker up and going for the Infrastructure committee to evaluate, please visit http://wiki.python.org/moin/CallForTrackers and see if you can help out! We already have a tracker for JIRA up and loaded with the SF data to poke around with. There are also Trac and Roundup trackers in the planning stages that could use some help in getting the SF data imported and getting the servers up. In order for a tracker to be considered it *must* have the SF data loaded up. This will be a necessary step if the tracker is accepted, plus it lets us see how well the tracker lets us manage a large number of bugs. If you have questions or concerns, please email infrastructure at python.org(it is subscription-protected, but your email will be accepted; the subscription page is at http://mail.python.org/mailman/listinfo/infrastructure ). Thank you to those that have helped so far and those that do in the future. -Brett Cannon Chairman, PSF Infrastructure Committee

1 0

ANN: M2Crypto 0.16
by Heikki Toivonen 05 Jul '06

05 Jul '06

I am happy to announce the M2Crypto 0.16 release. Highlights: - All known memory leaks fixed - All known regressions fixed - Added --openssl option to setup.py which can be used to specify where OpenSSL is installed, by Matt Rodriguez - ECDSA signatures and ECDH key agreement, requires OpenSSL 0.9.8+, by Arno Bakker - Added sha224, sha256, sha384 and sha512, by Larry Bugbee - Added serialNumber, SN, surname, GN and givenName fields to X509_Name, by Martin Paljak - And various other improvements and bugfixes, see CHANGES file Requirements: * Python 2.3 or newer * OpenSSL 0.9.7 or newer o Some optional new features will require OpenSSL 0.9.8 or newer * SWIG 1.3.24 or newer Get it while it's hot from M2Crypto homepage: http://wiki.osafoundation.org/bin/view/Projects/MeTooCrypto -- Heikki Toivonen

1 0

ANN: Porupine 0.0.7 released
by t.koutsovassilis＠gmail.com 05 Jul '06

05 Jul '06

Porcupine is a Python based Web application server that features an embedded object database, the Porcupine Object Query Language, XMLRPC support, and QuiX, an integrated AJAX powered XUL motor. On the server side, this release includes support for WSGI and HTTP cookies. The session ID is stored in a cookie, instead of being injected into the URL. This new feature, along with the "max-age" attribute added to Porcupine registrations, results in better utilization of the HTTP cache. On the client side, QuiX has a new box layout widget and a unified XMLRPC module. Additionally, QuiX windows support a new "onclose" event, triggered just before the window is closed. Finally, each user can select the desired application to be launched automatically immediately after successful login. Resources ========= Porcupine online demo: http://www.innoscript.org/content/view/21/43/ Porcupine tutorial: http://wiki.innoscript.org/index.php/Developers/Tutorials Developer resources: http://www.innoscript.org/component/option,com_remository/Itemid,33/func,se…

1 0

ANN: Intro to Python course, Aug 16-18, San Francisco
by w chun 05 Jul '06

05 Jul '06

What: (Intense) Intro to Python When: August 16-18, 2006 Where: San Francisco (SFO/San Bruno), CA, USA Web: http://cyberwebconsulting.com (click "Python Training" link) Need to get up-to-speed with Python as quickly as possible? Come join us in beautiful Northern California for another one of our rigorous Python training events! This is an intense introduction to Python programming geared towards those who have some proficiency in another high-level language. Topics include: * Syntax, Data Types, Operators, and Methods * Python's Objects and Memory Model * Errors and Exception Handling * Flow Control (Loops and Conditionals) * Writing Optimized Python * Files and Input/Output * Functions and Functional Programming Aspects * Modules and Packages * OOP: Classes, Methods, Instances, Class Customization, Inheritance * Execution Environment * Operating System Interface * Advanced Topics and Python Updates This course will take place in San Bruno right near the San Francisco International Airport at the: Staybridge Suites San Francisco Airport 1350 Huntington Ave San Bruno, CA 94066 USA +1-650-588-0770 LOCALS: easy freeway (101/280/380) and public transit (BART and CalTrain) access: San Bruno stations VISITORS: free shuttle to/from the airport, free high-speed internet cxn, free breakfast and evening reception daily The cost is $1095 per attendee. Discounts are available for multiple registrations as well as teachers/students and those with financial hardship. For more information and registration, go to the website above. Registration is also now open for our next Advanced Python course, taking place at the same location in November 2006. See website for more details. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Core Python Programming", Prentice Hall, (c)2007,2001 http://corepython.com wesley.j.chun :: wescpy-at-gmail.com python training and technical consulting cyberweb.consulting : silicon valley, ca http://cyberwebconsulting.com

1 0

IMDbPY 2.6
by alberanid＠libero.it 05 Jul '06

05 Jul '06

IMDbPY 2.6 is available (tgz, deb, rpm, exe) from: http://imdbpy.sourceforge.net/ IMDbPY is a Python package useful to retrieve and manage the data of the IMDb movie database about both movies and people. With this release, huge improvements and bug fixes for the "http" and the "sql" data access systems: the imdbpy2sql.py script has acceptable performances and the new format of the "DVD details" page is handled. Platform-independent and written in pure Python (and few C lines), it can retrieve data from both the IMDb's web server and a local copy of the whole database. IMDbPY package can be very easily used by programmers and developers to provide access to the IMDb's data to their programs. Some simple example scripts are included in the package; other IMDbPY-based programs are available from the home page. -- Davide Alberani <alberanid(a)libero.it> [PGP KeyID: 0x465BFD47] http://erlug.linux.it/~da/

1 0

CSpace - call for developers!
by K.S.Sreeram 04 Jul '06

04 Jul '06

Hi All CSpace aims to be the next generation in realtime communication. It is an opensource python application, which provides a platform for secure, decentralized, user-to-user communication. The platform provides a connect(user,service) primitive, similar to the sockets API connect(ip,port). Applications built on top of this platform can simply invoke connect(user,service) to establish a secure, nat/firewall friendly connection. Currently TextChat, FileTransfer and RemoteDesktop applications are available on CSpace. CSpace is still a work in progress, and I would like to invite everybody who's interested, to help in improving this product! CSpace Website: http://cspace.in Regards Sreeram PS: My CSpace KeyID is 20. Feel free to add me to your contact list and message me!

1 0

itools 0.13.7 released
by "J. David Ibáñez" 04 Jul '06

04 Jul '06

itools is a Python library, it groups a number of packages into a single meta-package for easier development and deployment: itools.catalog itools.i18n itools.uri itools.cms itools.ical itools.web itools.csv itools.resources itools.workflow itools.datatypes itools.rss itools.xhtml itools.gettext itools.schemas itools.xliff itools.handlers itools.stl itools.xml itools.html itools.tmx Changes: Catalog - Fix the "prof.py" script. CSV - Improved Index & Search API, by Hervé Cauwelier [#339]. Web - Fix the access log, flush the buffer on every line. - Support a non-standard HTTP Date format used by some browsers: '%A, %d %b %Y %H:%M:%S GMT'. CMS - Internationalize Epoz, by Hervé Cauwelier [#345]. - Fix Epoz for IE, by Hervé Cauwelier [#390]. Resources --------- Download http://download.ikaaro.org/itools/itools-0.13.7.tar.gz Home http://www.ikaaro.org/itools Mailing list http://mail.ikaaro.org/mailman/listinfo/itools Bug Tracker http://bugs.ikaaro.org -- J. David Ibáñez Itaapy <http://www.itaapy.com> Tel +33 (0)1 42 23 67 45 9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88

1 0

ANN: pycairo release 1.2.0 now available
by Steven Chaplin 02 Jul '06

02 Jul '06

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.0 is now available from: http://cairographics.org/releases/pycairo-1.2.0.tar.gz http://cairographics.org/releases/pycairo-1.2.0.tar.gz.md5 ab531e02fda56a9d6b2b65153fda65f6 pycairo-1.2.0.tar.gz Overview of changes from pycairo 1.1.6 to pycairo 1.2.0 ======================================================= General changes: Pycairo has been updated to work with cairo 1.2.0. New methods: Surface.set_fallback_resolution Surface_get_content ImageSurface_get_format Image_surface_get_stride Deleted methods: PDFSurface.set_dpi, PSSurface.set_dpi, SVGSurface.set_dpi - replaced by Surface.set_fallback_resolution Other changes: cairo.FORMAT_RGB16_565 added Overview of changes from pycairo 1.0.2 to pycairo 1.1.6 ======================================================= General changes: Pycairo has been updated to work with cairo 1.1.6. New objects: SVGSurface New methods: Context.get_group_target Context.new_sub_path Context.pop_group Context.pop_group_to_source Context.push_group Context.push_group_with_content FontOptions.get_antialias FontOptions.get_hint_metrics FontOptions.get_hint_style FontOptions.get_subpixel_order FontOptions.set_antialias FontOptions.set_hint_metrics FontOptions.set_hint_style FontOptions.set_subpixel_order PDFSurface.set_size PSSurface.dsc_begin_page_setup PSSurface.dsc_begin_setup PSSurface.dsc_comment PSSurface.set_size ScaledFont.get_font_face ScaledFont.text_extents Surface.get_device_offset XlibSurface.get_depth Updated methods: PDFSurface()/PSSurface() - can now write to file-like objects (like StringIO). surface.write_to_png() and ImageSurface.create_from_png() can now write to file-like objects (like StringIO). select_font_face, show_text, text_extents and text_path now accept unicode objects. Other changes: misc bug fixes. New examples: examples/cairo_snippets/snippets_svg.py examples/cairo_snippets/snippets/ellipse.py examples/cairo_snippets/snippets/group.py examples/svg/svgconvert.py Send instant messages to your online friends http://au.messenger.yahoo.com

1 0

python-dev Summary for 2006-05-16 through 2006-05-31
by Steven Bethard 01 Jul '06

01 Jul '06

python-dev Summary for 2006-05-16 through 2006-05-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-05-16_2006-05-31] ============= Announcements ============= ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Martin v. Löwis on what kind of questions are appropriate for python-dev: ... [python-dev] is the list where you say "I want to help", not so much "I need your help". Contributing thread: - `Segmentation fault of Python if build on Solaris 9 or 10 with Sun Studio 11 <http://mail.python.org/pipermail/python-dev/2006-May/065493.html>`__ ------------------- Python 2.5 schedule ------------------- Python 2.5 is moving steadily towards its next release. See `PEP 356`_ for more details and the full schedule. You may start to see a few warnings at import time if you've named non-package directories with the same names as your modules/packages. Python-dev suggests renaming these directories -- though the warnings won't give you any real trouble in Python 2.5, there's a chance that a future version of Python will drop the need for __init__.py. .. _PEP 356: http://www.python.org/dev/peps/pep-0356/ Contributing thread: - `2.5 schedule <http://mail.python.org/pipermail/python-dev/2006-May/065058.html>`__ - `warnings about missing __init__.py in toplevel directories <http://mail.python.org/pipermail/python-dev/2006-May/065270.html>`__ ------------------------------ Restructured library reference ------------------------------ Thanks to work by A.M. Kuchling and Michael Spencer, the organization of the `development Library Reference documentation`_ structure is much improved over the `old one`_. Thanks for your hard work guys! .. _development Library Reference documentation: http://docs.python.org/dev/lib/lib.html .. _old one: http://docs.python.org/lib/lib.html Contributing thread: - `[Python-3000] stdlib reorganization <http://mail.python.org/pipermail/python-dev/2006-May/065441.html>`__ ----------------------------- Need for Speed Sprint results ----------------------------- The results of the `Need for Speed Sprint`_ are all posted on the wiki. In particular, you should check a number of `successes`_ they had in speeding up various parts of Python including function calls, string and Unicode operations, and string<->integer conversions. .. _Need for Speed Sprint: http://wiki.python.org/moin/NeedForSpeed/ .. _successes: http://wiki.python.org/moin/NeedForSpeed/Successes Contributing threads: - `[Python-checkins] r46043 - peps/trunk/pep-0356.txt <http://mail.python.org/pipermail/python-dev/2006-May/065061.html>`__ - `Need for Speed Sprint status <http://mail.python.org/pipermail/python-dev/2006-May/065279.html>`__ ------------------------- Python old-timer memories ------------------------- Guido's been collecting `memories of old-timers`_ who have been using Python for 10 years or more. Be sure to check 'em out and add your own! .. _memories of old-timers: http://www.artima.com/weblogs/viewpost.jsp?thread=161207 Contributing thread: - `Looking for Memories of Python Old-Timers <http://mail.python.org/pipermail/python-dev/2006-May/065121.html>`__ ========= Summaries ========= ----------------------------- Struct module inconsistencies ----------------------------- Changes to the struct module to do proper range checking resulted in a few bugs showing up where the stdlib depended on the old, undocumented behavior. As a compromise, Bob Ippolito added code to do the proper range checking and issue DeprecationWarnings, and then made sure that the all struct results were calculated with appropriate bit masking. The warnings are expected to become errors in Python 2.6 or 2.7. Bob also updated the struct module to return ints instead of longs whenever possible, even for the format codes that had previously guaranteed longs (I, L, q and Q). Contributing threads: - `Returning int instead of long from struct when possible for performance <http://mail.python.org/pipermail/python-dev/2006-May/065199.html>`__ - `test_gzip/test_tarfile failure om AMD64 <http://mail.python.org/pipermail/python-dev/2006-May/065311.html>`__ - `Converting crc32 functions to use unsigned <http://mail.python.org/pipermail/python-dev/2006-May/065430.html>`__ - `test_struct failure on 64 bit platforms <http://mail.python.org/pipermail/python-dev/2006-May/065463.html>`__ --------------------------------- Using epoll for the select module --------------------------------- Ross Cohen implemented a `drop-in replacement for select.poll`_ using Linux's epoll (a more efficient io notifcation system than poll). The select interface is already much closer to the the epoll API than the poll API, and people liked the idea of using epoll silently when available. Ross promised to look into merging his code with the current select module (though it wasn't clear whether or not he would do this using ctypes isntead of an extension module as some people had suggested). .. _drop-in replacement for select.poll: http://sourceforge.net/projects/pyepoll Contributing thread: - `epoll implementation <http://mail.python.org/pipermail/python-dev/2006-May/065277.html>`__ ----------------------- Negatives and sequences ----------------------- Fredrik Lundh pointed out that using a negative sign and multiplying by -1 do not always produce the same behavior, e.g.:: >>> -1 * (1, 2, 3) () >>> -(1, 2, 3) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for unary - Though no one seemed particularly concerned about the discrepancy, the thread did spend some time discussing the behavior of sequences multiplied by negatives. A number of folks were pushing for this to become an error until Uncle Timmy showed some use-cases like:: # right-justify to 80 columns, padding with spaces s = " " * (80 - len(s)) + s The rest of the thread turned into a (mostly humorous) competition for the best way to incomprehensibly alter sequence multiplication semantics. Contributing thread: - `A Horrible Inconsistency <http://mail.python.org/pipermail/python-dev/2006-May/065176.html>`__ --------------------- Removing METH_OLDARGS --------------------- Georg Brandl asked about removing METH_OLDARGS which has been deprecated since 2.2. Unfortunately, there are still a bunch of uses of it in Modules, and it's still the default if no flag is specified. Georg promised to work on removing the ones in Python core, and there was some discussion of trying to mark the API as deprecated. Issuing a DeprecationWarning seemeed too heavy-handed, so Georg looked into generating C compile time warnings by marking PyArg_Parse as Py_DEPRECATED. Contributing thread: - `Remove METH_OLDARGS? <http://mail.python.org/pipermail/python-dev/2006-May/065306.html>`__ ------------------------------------- Propogating exceptions in dict lookup ------------------------------------- Armin Rigo offered up `a patch to stop dict lookup from hiding exceptions`_ in user-defined __eq__ methods. The PyDict_GetItem() API gives no way of propogating such an exception, so previously the exceptions were just swallowed. Armin moved the exception-swallowing part out of lookdict() and into PyDict_GetItem() so that even though PyDict_GetItem() will still swallow the exceptions, all other ways of invoking dict lookup (e.g. ``value = d[key]`` in Python code) will now propogate the exception properly. Scott Dial brought up an odd corner case where the old behavior would cause insertion of a value into the dict because the exception was assumed to indicate a new key, but people didn't seem to worried about breaking this behavior. .. _a patch to stop dict lookup from hiding exceptions: http://bugs.python.org/1497053 Contributing thread: - `Let's stop eating exceptions in dict lookup <http://mail.python.org/pipermail/python-dev/2006-May/065346.html>`__ ------------------------------ String/unicode inconsistencies ------------------------------ After the Need for Speed Sprint unified some of the string and unicode code, some tests started failing where string and unicode objects had different behavior, e.g. ``'abc'.find('', 100)`` used to return -1 but started returning 100. There was some discussion about what was the right behavior here and Fredrik Lundh promised to implement whatever was decided. Contributing thread: - `replace on empty strings <http://mail.python.org/pipermail/python-dev/2006-May/065153.html>`__ - `Let's stop eating exceptions in dict lookup <http://mail.python.org/pipermail/python-dev/2006-May/065346.html>`__ ----------------------------------- Allowing inline "if" with for-loops ----------------------------------- Heiko Wundram presented a brief PEP suggesting that if-statements in the first line of a for-loop could be optionally inlined, so for example instead of:: for node in tree: if node.haschildren(): <do something with node> you could write:: for node in tree if node.haschildren(): <do something with node> Most people seemed to feel that saving a colon character and a few indents was not a huge gain. Some also worried that this change would encourage code that was harder to read, particularly if the for-clause or if-clause got long. Guido rejected it, and Heiko promised to submit it as a full PEP so that the rejection would be properly recorded. Contributing thread: - `PEP-xxx: Unification of for statement and list-comp syntax <http://mail.python.org/pipermail/python-dev/2006-May/065088.html>`__ ---------------------------------------------- Splitting strings with embedded quoted strings ---------------------------------------------- Dave Cinege proposed augmenting str.split to allow a non-split delimiter to be specified so that splits would not happen within particular substrings, e.g.:: >>> 'Here is "a phrase that should not get split"'.split(None,-1,'"') ['Here', 'is', 'a phrase that should not get split'] Most people were opposed to complicating the API of str.split, but even as a separate method, people didn't seem to think that the need was that great, particularly since the most common needs for such functionality were already covered by ``shlex.split()`` and the csv module. Contributing thread: - `New string method - splitquoted <http://mail.python.org/pipermail/python-dev/2006-May/065037.html>`__ ---------------------------------------- Deadlocks with fork() and multithreading ---------------------------------------- Rotem Yaari ran into some deadlocks using the subprocess module in a multithreaded environment. If a thread other than the thread calling fork is holding the import lock, then since posix only replicates the calling thread, the new child process ends up with an import lock that is locked by a no longer existing thread. Ronald Oussoren offered up a repeatable test case, and a number of strategies for solving the problem were discussed, including releasing the import lock during a fork and throwing away the old import lock after a fork. Contributing threads: - `pthreads, fork, import, and execvp <http://mail.python.org/pipermail/python-dev/2006-May/064983.html>`__ - `pthreads, fork, import, and execvp <http://mail.python.org/pipermail/python-dev/2006-May/065023.html>`__ ---------------- string.partition ---------------- Fredrik Lundh asked about the status of string.partition, and there was a brief discussion about whether or not to return real string objects or lazy objects that would only make a copy if the original string disappeared. Guido opted for the simpler approach using real string objects, and Fredrik implemented it. Contributing threads: - `whatever happened to string.partition ? <http://mail.python.org/pipermail/python-dev/2006-May/065191.html>`__ - `[Python-checkins] whatever happened to string.partition ? <http://mail.python.org/pipermail/python-dev/2006-May/065195.html>`__ - `partition() variants <http://mail.python.org/pipermail/python-dev/2006-May/065216.html>`__ ---------------------------- Speeding up parsing of longs ---------------------------- Runar Petursson asked about speeding up parsing of longs from a slice of a string, e.g. ``long(mystring[x:y])``. He initially proposed adding start= and end= keyword arguments to the long constructor, but that seemed like a slippery slope where every function that took a string would eventually need the same arguments. Tim Peters pointed out that a buffer object would solve the problem if ``PyLong_FromString()`` supported buffer's "offset & length" view or the world instead of only seeing the start index. While adding a ``PyLong_FromStringAndSize()`` would solve this particular problem, all the internal parsing routines have a similar problem -- none of them support a slice-based API. As an alternate approach, Martin Blais was working on a "hot" buffer class, based on the design of the Java NIO ByteBuffer class, which would work without an intermediate string creation or memory copy. Contributing thread: - `Cost-Free Slice into FromString constructors--Long <http://mail.python.org/pipermail/python-dev/2006-May/065163.html>`__ ---------------------- Speeding up try/except ---------------------- After Steve Holden noticed a ~60% slowdown between Python 2.4.3 and the Python trunk on the pybench try/except test, Sean Reifschneider and Richard Jones looked into the problem and found that the slowdown was due to creation of Exception objects. Exceptions had been converted to new-style objects by using PyType_New() as the constructor and then adding magic methods with PyMethodDef(). By changing BaseException to use a PyType_Type definition and the proper C struct to associate methods with the class, Georg Brandl and Richard Jones were able to speed up try/except to 30% faster than it was in Python 2.4.3. Contributing thread: - `2.5a2 try/except slow-down: Convert to type? <http://mail.python.org/pipermail/python-dev/2006-May/065147.html>`__ ----------------------------- Supporting zlib's inflateCopy ----------------------------- Guido noticed that the zlib module was failing with libz 1.1.4. Even though Python has its own copy of libz 1.2.3, it tries to use the system libraries on Unix, so when the zlib module's compress and decompress objects were updated with a copy() method (using libz's inflateCopy() function), this broke compatibility for any system that used a zlib older than 1.2.0. Chris AtLee provided a `patch conditionalizing the addition of the copy() method`_ on the version of libz available. .. _patch conditionalizing the addition of the copy() method: http://bugs.python.org/1503046 Contributing thread: - `zlib module doesn't build - inflateCopy() not found <http://mail.python.org/pipermail/python-dev/2006-May/065068.html>`__ ------------------------ Potential ssize_t values ------------------------ Neal Norwitz looked through the Python codebase for longs that should potentially be declared as ssize_t instead. There was a brief discussion about changing int's ob_ival to ssize_t, but this would have been an enormous change this late in the release cycle and would have slowed down operations on short ints. Hash values were also discussed, but since there's no natural correlation between a hash value and the size of a collection, most people thought it was unnecessary for the moment. Martin v. Löwis suggested upping the recursion limit to ssize_t, and formalizing a 16-bit and 31-bit limit on line and column numbers, respectively. Contributing threads: - `ssize_t question: longs in header files <http://mail.python.org/pipermail/python-dev/2006-May/065332.html>`__ - `ssize_t: ints in header files <http://mail.python.org/pipermail/python-dev/2006-May/065333.html>`__ ----------------- itertools.iwindow ----------------- Torsten Marek proposed adding a windowing function to itertools like:: >>> list(iwindow(range(0,5), 3)) [[0, 1, 2], [1, 2, 3], [2, 3, 4]] Raymond Hettinger pointed him to a `previous discussion`_ on comp.lang.python where he had explained that ``collections.deque()`` was usually a better solution. Nick Coghlan suggested putting the deque example in the collections module docs, but the thread trailed off after that. .. _previous discussion: http://mail.python.org/pipermail/python-list/2005-March/270757.html Contributing thread: - `Proposal for a new itertools function: iwindow <http://mail.python.org/pipermail/python-dev/2006-May/065276.html>`__ --------------------------------------------- Problems with buildbots and files left around --------------------------------------------- Neal Norwitz discovered some problems with the buildbots after finding a few tests that didn't properly clean up, leaving a few files around afterwards. Martin v. Löwis explained that forcing a build on a non-existing branch will remove the build tree (which should clean up a lot of the files) and also that "make distclean" could be added to the clean step of Makefile.pre.in and master.cfg. Contributing thread: - `fixing buildbots <http://mail.python.org/pipermail/python-dev/2006-May/065416.html>`__ ------------------------------------ PEP 3101: Advanced String Formatting ------------------------------------ The discussion of `PEP 3101`_'s string formatting continued again this fortnight. Guido generally liked the proposal, though he suggested following .NET's quoting syntax of doubling the braces, and maybe allowing all formatting errors to pass silently so that rarely raised exceptions don't hide themselves if their format string has an error. The discussion was then moved to the `python-3000 list`_. .. _PEP 3101: http://www.python.org/dev/peps/pep-3101/ .. _python-3000 list: http://mail.python.org/mailman/listinfo/python-3000 Contributing thread: - `PEP 3101 Update <http://mail.python.org/pipermail/python-dev/2006-May/065059.html>`__ ----------------------------- DONT_HAVE_* vs. HAVE_* macros ----------------------------- Neal Norwitz asked whether some recently checked-in DONT_HAVE_* macros should be replaced with HAVE_* macros instead. Martin v. Löwis indicated that these were probably written this way because Luke Dunstan (the contributor) didn't want to modify configure.in and run autoconf. Luke noted that the configure.in and autoconf effort is greater for Windows developers, but also agreed to convert things to autoconf anyway. Contributing thread: - `[Python-checkins] r46064 - in python/trunk: Include/Python.h Include/pyport.h Misc/ACKS Misc/NEWS Modules/_localemodule.c Modules/main.c Modules/posixmodule.c Modules/sha512module.c PC/pyconfig.h Python/thread_nt.h <http://mail.python.org/pipermail/python-dev/2006-May/065124.html>`__ -------------------------------- Changing python int to long long -------------------------------- Sean Reifschneider looked into converting the Python int type to long long. Though for simple math he saw speedups of around 25%, for ints that fit entirely within 32-bits, the slowdown was around 11%. Sean was considering changing the int->long automatic conversion so that ints would first be up-converted to long longs and then to Python longs. Guido said that it would be okay to standardize all ints as 64-bits everywhere, but only for Python 2.6. Contributing thread: - `Changing python int to "long long". <http://mail.python.org/pipermail/python-dev/2006-May/065133.html>`__ ---------------------------- C-level exception invariants ---------------------------- Tim Peters was looking at what kind of invariants could be promised for C-level exceptions. In particular, he was hoping to promise that for PyFrameObject's f_exc_type, f_exc_value, and f_exc_traceback, either all are NULL or none are NULL. In his investigation, he found a number of errors, including that _PyExc_Init() tries to raise an AttributeError before the exception pointers have been initialized. Contributing thread: - `Low-level exception invariants? <http://mail.python.org/pipermail/python-dev/2006-May/065231.html>`__ ------------ C-code style ------------ Martin Blais asked about the policy for C code in Python core. `PEP 7`_ explains that for old code, the most important thing is to be consistent with the surrounding style. For new C files (and for Python 3000 code) indentation should be 4 spaces per indent, all spaces (no tabs in any file). There was a short discussion about reformatting the current C code, but that would unnecessarily break svn blame and make merging more difficult. .. _PEP 7: http://www.python.org/dev/peps/pep-0007/ Contributing thread: - `A can of worms... (does Python C code have a new C style?) <http://mail.python.org/pipermail/python-dev/2006-May/065469.html>`__ ================ Deferred Threads ================ - `feature request: inspect.isgenerator <http://mail.python.org/pipermail/python-dev/2006-May/065334.html>`__ - `Python Benchmarks <http://mail.python.org/pipermail/python-dev/2006-May/065480.html>`__ ================== Previous Summaries ================== - `[Python-checkins] r45925 - in python/trunk: Lib/tempfile.py Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c <http://mail.python.org/pipermail/python-dev/2006-May/065022.html>`__ - `[Web-SIG] Adding wsgiref to stdlib <http://mail.python.org/pipermail/python-dev/2006-May/065116.html>`__ =============== Skipped Threads =============== - `FYI: building on OS X <http://mail.python.org/pipermail/python-dev/2006-May/065020.html>`__ - `MSVC 6.0 patch <http://mail.python.org/pipermail/python-dev/2006-May/065027.html>`__ - `total ordering. <http://mail.python.org/pipermail/python-dev/2006-May/065028.html>`__ - `[Python-checkins] r46002 - in python/branches/release24-maint: Misc/ACKS Misc/NEWS Objects/unicodeobject.c <http://mail.python.org/pipermail/python-dev/2006-May/065030.html>`__ - `Reminder: call for proposals "Python Language and Libraries Track" for Europython 2006 <http://mail.python.org/pipermail/python-dev/2006-May/065057.html>`__ - `Decimal and Exponentiation <http://mail.python.org/pipermail/python-dev/2006-May/065067.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-May/065071.html>`__ - `New string method - splitquoted - New EmailAddress <http://mail.python.org/pipermail/python-dev/2006-May/065078.html>`__ - `Iterating generator from C (PostgreSQL's pl/python RETUN SETOF/RECORD iterator support broken on RedHat buggy libs) <http://mail.python.org/pipermail/python-dev/2006-May/065111.html>`__ - `Charles Waldman? <http://mail.python.org/pipermail/python-dev/2006-May/065120.html>`__ - `SSH key for work computer <http://mail.python.org/pipermail/python-dev/2006-May/065138.html>`__ - `PySequence_Fast_GET_ITEM in string join <http://mail.python.org/pipermail/python-dev/2006-May/065145.html>`__ - `Socket regression <http://mail.python.org/pipermail/python-dev/2006-May/065160.html>`__ - `extensions and multiple source files with the same basename <http://mail.python.org/pipermail/python-dev/2006-May/065162.html>`__ - `Import hooks falling back on built-in import machinery? <http://mail.python.org/pipermail/python-dev/2006-May/065173.html>`__ - `This <http://mail.python.org/pipermail/python-dev/2006-May/065192.html>`__ - `SQLite header scan order <http://mail.python.org/pipermail/python-dev/2006-May/065206.html>`__ - `[Python-checkins] r46247 - in python/branches/sreifschneider-newnewexcept: Makefile.pre.in Objects/exceptions.c Python/exceptions.c <http://mail.python.org/pipermail/python-dev/2006-May/065211.html>`__ - `SQLite status? <http://mail.python.org/pipermail/python-dev/2006-May/065214.html>`__ - `Request for patch review <http://mail.python.org/pipermail/python-dev/2006-May/065215.html>`__ - `patch for mbcs codecs <http://mail.python.org/pipermail/python-dev/2006-May/065268.html>`__ - `[Python-checkins] This <http://mail.python.org/pipermail/python-dev/2006-May/065291.html>`__ - `[Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c <http://mail.python.org/pipermail/python-dev/2006-May/065296.html>`__ - `getting rid of confusing "expected a character buffer object" messages <http://mail.python.org/pipermail/python-dev/2006-May/065298.html>`__ - `[Python-checkins] Python Regression Test Failures refleak (101) <http://mail.python.org/pipermail/python-dev/2006-May/065310.html>`__ - `PEP 42 - New kind of Temporary file <http://mail.python.org/pipermail/python-dev/2006-May/065315.html>`__ - `DRAFT: python-dev summary for 2006-03-16 to 2006-03-31 <http://mail.python.org/pipermail/python-dev/2006-May/065321.html>`__ - `dictionary order <http://mail.python.org/pipermail/python-dev/2006-May/065322.html>`__ - `Syntax errors on continuation lines <http://mail.python.org/pipermail/python-dev/2006-May/065327.html>`__ - `DRAFT: python-dev summary for 2006-04-01 to 2006-04-15 <http://mail.python.org/pipermail/python-dev/2006-May/065344.html>`__ - `Contributor agreements (was Re: DRAFT: python-dev summary for 2006-04-01 to 2006-04-15) <http://mail.python.org/pipermail/python-dev/2006-May/065368.html>`__ - `Integer representation (Was: ssize_t question: longs in header files) <http://mail.python.org/pipermail/python-dev/2006-May/065391.html>`__ - `problem with compilation flags used by distutils <http://mail.python.org/pipermail/python-dev/2006-May/065418.html>`__ - `bug in PEP 318 <http://mail.python.org/pipermail/python-dev/2006-May/065440.html>`__ - `Socket module corner cases <http://mail.python.org/pipermail/python-dev/2006-May/065443.html>`__ - `uriparsing library (Patch #1462525) <http://mail.python.org/pipermail/python-dev/2006-May/065446.html>`__ - `optparse and unicode <http://mail.python.org/pipermail/python-dev/2006-May/065458.html>`__ - `Reporting unexpected import failures as test failures in regrtest.py <http://mail.python.org/pipermail/python-dev/2006-May/065468.html>`__ - `Add new PyErr_WarnEx() to 2.5? <http://mail.python.org/pipermail/python-dev/2006-May/065478.html>`__ - `Arguments and PyInt_AsLong <http://mail.python.org/pipermail/python-dev/2006-May/065485.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from May 16, 2006 through May 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 5th written by the python-dev summary solo, Steve Bethard. (The fun never ends!) 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 ------------------------- 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. .. _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/ .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0