Mailman 3 January 2006 - Python-Dev

(no subject)
by Robert Kim Wireless Internet Advisor 01 Feb '06

01 Feb '06

anybody here? bob 2611 s highway 101 san diego, ca 92007 209 984 0880 http://evdo-coverage.com/cell-phone-antenna-booster.html -- Robert Q Kim, Wireless Internet Advisor http://evdo-coverage.com/cellular-repeater.html http://hsdpa-coverage.com 2611 S. Pacific Coast Highway 101 Suite 102 Cardiff by the Sea, CA 92007 206 984 0880

1 0

DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
by Tony Meyer 31 Jan '06

31 Jan '06

Here's the draft for the first January summary. If anyone has time to send me/Steve comments/suggestions/corrections/additions, those will be most welcome. The Py_ssize_t threads were particularly over my head. As always, many thanks :) ============= Announcements ============= ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Guido, on the crashability of Python: I'm not saying it's uncrashable. I'm saying that if you crash it, it's a bug unless proven harebrained. Contributing thread: - `Include ctypes into core Python? <http://mail.python.org/pipermail/python-dev/2006-January/059621.html>`_ [SJB] ------------------------------------ Brett Cannon looking for Ph.D. ideas ------------------------------------ Brett Cannon is looking for Python-related ideas to form the subject of his PhD dissertation, under Eric Wohlstadter at the University of British Columbia. He has three areas in which he has possible funding (XML integration, game scripting support, and AOP); he is open to grants from anyone else interested in particular Python development. If anyone has suggestions for topics, Brett is listening! So far: * Phillip J. Eby mentioned that he has been doing some research on implementing a non-traditional form of AOP in Python. * Bill Janssen suggested a system to compile Python to AJAX. * Steve Holden suggested a Python learning system. * Ian Bicking suggested Boxer_ implemented for Python. * Armin Rigo suggested PyPy related work. * Jason Orendorff suggested collecting a downloadable corpus of Python source code, and performing various analyses on it. * Dennis Allison suggested interpreter structures for Python-like languages that do not use a global interpreter lock, as well as various other topics. .. _Boxer: http://dewey.soe.berkeley.edu/boxer.html Contributing thread: - `Ph.D. dissertation ideas? <http://mail.python.org/pipermail/python-dev/2006-January/059702.html>`__ [TAM] --------------------------------- 2.4 Documentation with Commentary --------------------------------- Ian Bicking put an instance_ of his commenting system, Commentary_, up against the full 2.4 documentation. If you'd like to see how the Python docs look with user-added comments, now's your chance! .. _instance: http://pythonpaste.org/comment/python24/ .. _Commentary: http://pythonpaste.org/commentary/ Contributing thread: - `[Doc-SIG] that library reference, again <http://mail.python.org/pipermail/python-dev/2006-January/059353.html>`__ [SJB] --------------------------------------- Builds of the Development Documentation --------------------------------------- Be sure to keep yourself up to date with the newest Python documentation - Neal Norwitz has arranged it so that the current Python development documentation is now automatically generated every 12 hours and placed at http://docs.python.org/dev/. Contributing thread: - `automated builds and tests <http://mail.python.org/pipermail/python-dev/2006-January/059362.html>`__ [SJB] -------------------------------- PEPs now automatically installed -------------------------------- Martin v. Löwis has arranged for an automatic installation of PEPs_: they will now get published in the subversion post-commit. Contributing thread: - `Installing PEPs <http://mail.python.org/pipermail/python-dev/2006-January/059745.html>`__ .. _PEPs: http://www.python.org/peps [TAM] ========= Summaries ========= --------------------------------------------------- Using buildbot to automate testing of Python builds --------------------------------------------------- A buildbot_ has been setup to facilitate `automated testing of the Python SVN`_. There are currently five slaves setup: * Linux x86 (gentoo 2.6, glibc 2.3) * Linux AMD64 (gentoo 2.6, glibc 2.3) * Solaris10 sparc * OS X 10.3 G5 * OS X 10.4 G4 Ideally, all supported platforms will be added (including OS, version, hardware, and various configurations); the slaves are testing the trunk and the 2.4 branch. Note that Window buildbot slaves have to have an appropriate compiler (MS VC 7.1), otherwise it can't compile the code; the Windows Python would also like to build several other packages (like bz2 and Tcl/Tk). A periodic "clean build" may also be added; there was discussion whether this should be done via a patch to the buildbot master, via an IRC command, or with a separate scheduler. Martin v. Löwis would rather buildbot produced static pages than act as a web server (for security reasons). Brian Warner explained that it once did, but was changed to make it easier to implement features like the "Force Build" button. An explanation of the security was given, and it seems satisfactory at the moment. The buildbot testing has already produced results: a compiler warning on OS X 10.3 was noticed. A discussion took place as to whether this should be fixed (it should) and who could do it (Ronald Oussoren volunteered, with help from Skip Montanaro). Fredrik Lundh had been playing with "automatic module discovery" in an attempt to figure out how complete the library reference really is, tracking down missing reference pages and generating stubs for pages that "should exist". He suggested that the buildbot could also run this script; at the time of this summary this was in progress. .. _automated testing of the Python SVN: http://www.python.org/dev/buildbot/ .. _buildbot: http://buildbot.sourceforge.net/ Contributing threads: - `buildbot <http://mail.python.org/pipermail/python-dev/2006-January/059359.html>`__ - `Buildbot questions <http://mail.python.org/pipermail/python-dev/2006-January/059429.html>`__ - `[Buildbot-devel] Re: buildbot <http://mail.python.org/pipermail/python-dev/2006-January/059455.html>`__ - `Automated Python testing <http://mail.python.org/pipermail/python-dev/2006-January/059460.html>`__ - `building a module catalogue with buildbot <http://mail.python.org/pipermail/python-dev/2006-January/059623.html>`__ - `Buildbot: doing occasional full builds <http://mail.python.org/pipermail/python-dev/2006-January/059643.html>`__ [TAM] ---------------------- A "Rejected Ideas" PEP ---------------------- Alexander Kozlovsky submitted a pre-PEP for the oft-repeated request that Python do away with its explicit "self" parameter. Guido responded with a definitive "This won't change", but didn't want to allow the PEP to be created just to be rejected. A number of people felt that the mailing lists weren't a sufficiently visible place for this response, especially considering the huge number of times the request has been presented. Thomas Wouters proposed a "Rejected Ideas" PEP that would list some of the more commonly raised proposals that weren't really even worthy of a PEP, with references to the appropriate python-list or python-dev discussions. Tim Peters nominated the alternate title "Don't Bother: PEPs Rejected Before Being Written" which perhaps better summarizes the intent. People seemed generally in favor of the idea, and Thomas Wouters offered to write up a first draft indicating three major rejected ideas: * removing the explicit "self" parameter * upgrading the Python parser beyond a simple LL(1) * allowing parentheses to be omitted in function calls At the time of this summary, no PEP was yet available. Contributing threads: - `Draft proposal: Implicit self in Python 3.0 <http://mail.python.org/pipermail/python-dev/2006-January/059446.html>`__ - `Rejected ideas PEP (was re: Draft proposal: Implicit self in Python 3.0) <http://mail.python.org/pipermail/python-dev/2006-January/059514.html>`__ [SJB] ------------------------------- Using ssize_t as the index type ------------------------------- Continuing from `last week`_, more process was made towards `PEP 353`_. Tim Peters, Neal Norwitz, and Martin v. Löwis discussed replacing '#' as a format character, and how this could be down in a backwards compatible way; they also discussed how Py_ssize_t could be output correctly in a printf-style statement. Martin suggested using %zd, but this isn't in VC 7.1; Tim suggested that a macro be added to pyport.h, which would use "z" where possible, and define something else where not (e.g. Windows). Tim also suggested that PyErr_Format() and PyString_Format() should be taught to recognize the "z" qualifier, with the macros hidden inside the implementation of those functions. M.-A. Lemburg pointed out other changes of output parameter types which will cause problems in extensions, and worried that authors wouldn't be able to get these converted in time for Python 2.5. Martin disagreed. While code will continue to work with 32-bit systems with little work, more needs to be done for 64-bit systems. Martin suggested that users could continue to use 32-bit Python (since nothing will be gained by using 64-bit anyway) until the required changes are made. For more details, see the "Open Issues" section of the PEP. .. _last week: http://www.python.org/dev/summary/2005-12-16_2005-12-31.html#using-ssize-t-… .. _PEP 353: http://www.python.org/peps/pep-0353.html Contributing threads: - `[Python-checkins] commit of r41906 - python/branches/ssize_t/Objects/obmalloc.c <http://mail.python.org/pipermail/python-dev/2006-January/059381.html>`__ - `New PEP: Using ssize_t as the index type <http://mail.python.org/pipermail/python-dev/2006-January/059437.html>`__ - `[Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c <http://mail.python.org/pipermail/python-dev/2006-January/059516.html>`__ - `Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...) <http://mail.python.org/pipermail/python-dev/2006-January/059597.html>`__ [TAM] ------------------------------------- Adding ctypes to the standard library ------------------------------------- Thomas Heller suggested that ctypes be included in core Python (starting with 2.5). The common response was that while ctypes is a useful, popular, mature module, it does make it very easy to get a core dump, which violates the guideline that if you get a core dump it's a bug in Python or in a third party extension or you're doing something harebrained. On the other hand, it was pointed out that the dl module suffers from the same problem, and is included without any warnings (the documentation was later fixed to include warnings). Martin v. Löwis suggested making ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could opt out of installing it. Everyone seemed happy with prominent warnings in the documentation, and so this is how it was checked in. Contributing thread: - `Include ctypes into core Python? <http://mail.python.org/pipermail/python-dev/2006-January/059604.html>`__ [TAM] ----------------------------------------- Adding tests when no fix is yet available ----------------------------------------- After Georg Brandl checked in a test for the compiler module without a corresponding fix, Tim Peters reverted the change, indicating that no check-in should ever leave the repository in such a state that ``regrtest.py -uall`` fails. The ensuing thread discussed a number of ways of checking in a test for a bug when code to fix the bug was not yet available. Neal Norwitz proposed adding two files to Lib/test, outstanding_bugs.py and outstanding_crashes.py, which would include the appropriate tests, but which would not be run under ``regrtest.py -uall``. Some people were concerned about the maintainability of keeping failing tests for a module separate from the other tests of that module, so Neal Norwitz and Scott David Daniels presented a patch_ and a recipe_ for decorators that mark individual test functions as failing. No official pronouncement on how failing tests should be added to the Python test suite had been made at the time of this summary. .. _patch: http://python.org/sf/1399935 .. _recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288 Contributing thread: - `Checking in a broken test was: Re: [Python-checkins] r41940 - python/trunk/Lib/test/test_compiler.py <http://mail.python.org/pipermail/python-dev/2006-January/059481.html>`__ - `r42003 - python/trunk/Lib/test/outstanding_bugs.pypython/trunk/Lib/test/outstanding_crashes.py <http://mail.python.org/pipermail/python-dev/2006-January/059599.html>`__ [SJB] ------------------------------------------- Running the test suites in multiple locales ------------------------------------------- Georg Brandl noted that unicode format modifiers were (in SVN) incorrectly using the locale (one should always use locale.format to get locale-aware formatting). Fredrik Lundh suggested that all test should be run in a different locale than C to detect these bugs, perhaps adding a "use setlocale" flag to the test runner, to simplify this. Neal Norwitz made a patch to do this, finding a failure in test_email and two failures in test_re. Contributing thread: - `locale and LC_NUMERIC <http://mail.python.org/pipermail/python-dev/2006-January/059530.html>`__ [TAM] ----------------------------------------------------------- Replacing the docutils directory with an svn:externals link ----------------------------------------------------------- David Goodger replaced the static copy of docutils in the "peps" repository with a svn:externals link to the docutils repository. There was some concern about svn querying servers other than svn.python.org (the docutils repository is hosted on svn.berlios.de) and about linking to a potentially broken repository. David assured python-dev that the svn.berlios.de server was hardly ever unreachable, and changed the svn:externals link to select the 0.4 revision of docutils instead of the trunk. That guaranteed a non-broken copy of docutils, and made updating to a new revision just a simple propedit. Contributing thread: - `r42015 - peps/trunk <http://mail.python.org/pipermail/python-dev/2006-January/059676.html>`__ [SJB] -------------- Tkinter status -------------- A brief message from Joseph Rodrigues asking about the status of Tkinter in Python started a short thread about how Tkinter is maintained in Python. Martin v. Löwis is the primary maintainer, and he mainly focuses on integrating user contributions and making sure that Python is compatible with the latest release of Tcl/Tk. New widgets don't get wrapped automatically - if you want one supported, you should submit a patch. Contributing thread: - `Tkinter <http://mail.python.org/pipermail/python-dev/2006-January/059588.html>`__ [SJB] ------------------------------------ Roadmap for ConfigParser development ------------------------------------ Once again, the output capability of ConfigParser was brought up; this time by Facundo Bastista, who `submitted a patch`_ that orders the output so that doctest output can be easily reliable. He pointed out that there is `another open patch`_ that allows the user to specify the order through an "ordered dictionary". Guido explained that he didn't feel that it mattered, as long as the patch also allows comments to be preserved; his preference was for everything (ordering, blank lines, and comments) to be preserved. Tony Meyer point out some examples of previous_ `python-dev`_ discussion_ about how ConfigParser should be modified, and that SpamBayes_ includes a ConfigParser subclass that allows 'surgical' editing of files. .. _submitted a patch: http://python.org/sf/1399309 .. _another open patch: http://python.org/sf/1371075 .. _previous: http://mail.python.org/pipermail/python-dev/2004-October/049454.html .. _python-dev: http://mail.python.org/pipermail/python-dev/2004-October/049527.html .. _discussion: http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1483518 .. _SpamBayes: http://spambayes.org Contributing thread: - `ConfigParser to save with order <http://mail.python.org/pipermail/python-dev/2006-January/059480.html>`__ [TAM] ------------------------------- Patches for the logging package ------------------------------- Shane Hathaway asked about the process for submitting patches for the logging package. Vinay Sajip is the primary maintainer, and accepts patches (compatible with Python 1.5.2) through sourceforge as normal, though personal emails are appropriate if you are worried about spending time on a patch that is not accepted. There was a brief followup discussion about how to get the logging package to interact nicely with external log rotation tools, including the possible creation of a ``reopen()`` function for files, but the thread trailed off without any solid conclusion on this issue. Contributing thread: - `Logging enhancements <http://mail.python.org/pipermail/python-dev/2006-January/059566.html>`__ [SJB] ---------------------------------- os.path.getmtime() bugs on Windows ---------------------------------- Christian Tismer noted that if, in a single interactive session on Windows, create a file, get its os.path.getmtime(), change your time zone, and get its os.path.getmtime() again, the time stamps are different. He asked whether there was a way to circumvent the problem, or if a patch could be created. Tim Peters gave him a `reference to a CodeProject page` that discusses the problem. Martin v. Löwis has meant to work on a patch for several years; his plan is to drop usage of msvcrt's stat(3), and instead implement os.stat in terms of Windows API directly - this would also have the advantage that subsecond time-stamps can be exposed. This patch would need to be implemented twice; once for Win9X (ANSI file names) and once for NT+ (unicode file names). .. _reference to a CodeProject page: http://www.codeproject.com/datetime/dstbugs.asp Contributing thread: - `os.path.getmtime on Windows <http://mail.python.org/pipermail/python-dev/2006-January/059741.html>`__ [TAM] ---------------------------------------- Generating Python-ast.c and Python-ast.h ---------------------------------------- Python-ast.c and Python-ast.h are generated automatically from Parser/asdl_c.py and then checked into Subversion. However, a ``make distclean`` removes these files, and if you do not have a 2.2+ version of Python available, they cannot be regenerated. The best solution seemed to be to alter ``make distclean`` to not remove Python-ast.c and Python-ast.h as they only need to be regenerated when the AST definition changes, which is rather infrequent. Contributing thread: - `[Python-checkins] commit of r41880 - python/trunk/Python/Python-ast.c <http://mail.python.org/pipermail/python-dev/2006-January/059356.html>`__ [SJB] ----------------------------------------- Allowing dict subclasses for exec globals ----------------------------------------- Currently, the ``exec`` statement allows the locals expression (the second expression after ``in``) to be any mapping type. The globals expression (the first expression after ``in``) should be a dict object, but Python does not currently raise an exception if you use a dict subclass, though it will not call any overridden methods correctly. `Crutcher Dunnavant presented a patch`_ that allows the globals expression to be a dictionary subclass such that overridden methods are called properly. Because it gives Python new capabilities, if the patch is accepted, it will not become part of Python until 2.5. .. _Crutcher Dunnavant presented a patch: http://www.python.org/sf/1402289 Contributing thread: - `[PATCH] Fix dictionary subclass semantics when used as global dictionaries <http://mail.python.org/pipermail/python-dev/2006-January/059625.html>`__ [SJB] ================== Previous Summaries ================== - `When do sets shrink? <http://mail.python.org/pipermail/python-dev/2006-January/059346.html>`__ - `Including zlib... <http://mail.python.org/pipermail/python-dev/2006-January/059372.html>`__ - `a quit that actually quits <http://mail.python.org/pipermail/python-dev/2006-January/059384.html>`__ - `Real time behaviour of Pythons memory management; WAS: RE: Documentation about Python's GC,python-dev list messages referenced in Modules/gcmodule.c notreachable anymore <http://mail.python.org/pipermail/python-dev/2006-January/059408.html>`__ - `slight inconsistency in svn checkin email subject lines <http://mail.python.org/pipermail/python-dev/2006-January/059355.html>`__ - `buildno (Was: [Python-checkins] commit of r41907- python/trunk/Makefile.pre.in) <http://mail.python.org/pipermail/python-dev/2006-January/059419.html>`__ =============== Skipped Threads =============== - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-January/059352.html>`__ - `current test problems <http://mail.python.org/pipermail/python-dev/2006-January/059360.html>`__ - `mac memory leaks <http://mail.python.org/pipermail/python-dev/2006-January/059367.html>`__ - `API changes <http://mail.python.org/pipermail/python-dev/2006-January/059374.html>`__ - `file.next() vs. file.readline() <http://mail.python.org/pipermail/python-dev/2006-January/059410.html>`__ - `Sharing between multiple interpreters and restricted mode <http://mail.python.org/pipermail/python-dev/2006-January/059412.html>`__ - `TAR problems under Solaris <http://mail.python.org/pipermail/python-dev/2006-January/059415.html>`__ - `bsddb broken <http://mail.python.org/pipermail/python-dev/2006-January/059425.html>`__ - `Jython and CPython <http://mail.python.org/pipermail/python-dev/2006-January/059434.html>`__ - `Compiler warnings for 64-bit portability problems <http://mail.python.org/pipermail/python-dev/2006-January/059464.html>`__ - `some interesting readings <http://mail.python.org/pipermail/python-dev/2006-January/059482.html>`__ - `Birkenfeld's gone <http://mail.python.org/pipermail/python-dev/2006-January/059492.html>`__ - `Python-Dev Digest, Vol 29, Issue 111 <http://mail.python.org/pipermail/python-dev/2006-January/059494.html>`__ - `PyCon TX 2006: Early-bird registration ends Jan. 15! <http://mail.python.org/pipermail/python-dev/2006-January/059511.html>`__ - `test_curses <http://mail.python.org/pipermail/python-dev/2006-January/059528.html>`__ - `sudo security hole w/ potential Python connection <http://mail.python.org/pipermail/python-dev/2006-January/059586.html>`__ - `Python-Dev Digest, Vol 30, Issue 32 <http://mail.python.org/pipermail/python-dev/2006-January/059587.html>`__ - `PyThreadState_Delete vs PyThreadState_DeleteCurrent <http://mail.python.org/pipermail/python-dev/2006-January/059595.html>`__ - `Hello <http://mail.python.org/pipermail/python-dev/2006-January/059628.html>`__ - `Limiting the recursion limit <http://mail.python.org/pipermail/python-dev/2006-January/059652.html>`__ - `PEP and stdlib <http://mail.python.org/pipermail/python-dev/2006-January/059694.html>`__ - `DRAFT: python-dev Summary for 2005-12-01 through 2005-12-15 <http://mail.python.org/pipermail/python-dev/2006-January/059713.html>`__ - `Unicode print/stdoutput exceptions are not nice <http://mail.python.org/pipermail/python-dev/2006-January/059715.html>`__ - `pystate.c changes for Python 2.4.2 <http://mail.python.org/pipermail/python-dev/2006-January/059716.html>`__ - `DRAFT: python-dev Summary for 2005-12-16 through 2005-12-31 <http://mail.python.org/pipermail/python-dev/2006-January/059717.html>`__ - `DRAFT: python-dev Summary for 2005-12-16 through2005-12-31 <http://mail.python.org/pipermail/python-dev/2006-January/059726.html>`__ - `Python icon <http://mail.python.org/pipermail/python-dev/2006-January/059738.html>`__

12 30

"DOS" error codes, WindowsError, and errno
by "Martin v. Löwis" 31 Jan '06

31 Jan '06

I have a new implementation of stat/fstat/wstat which directly uses Win32 API, rather than using msvcrt. This works fine so far, except that error handling turns out to be tricky. mscvcrt maps errors (GetLastError()) into errno.h values, and also preserves the original error code in _doserrno. Currently, stat() will raise OSError, with errno set to the errno.h value. Because the Win32 error codes are much more fine-grained, this conversion loses information. Python raises WindowsError in some cases (e.g. os.listdir); WindowsError inherits from OSError, but the errno attribute now must be interpreted as a Win32 error. This is unfortunate, because the values overlap, and somebody handling OSError might confuse the error codes for errno.h (msvcrt) values. So what should I do in the new stat implementation? Try to map error codes also? Raise WindowsErrors instead? Do something else entirely? Comments appreciated. Regards, Martin

3 4

from __future__ syntax changed
by Guido van Rossum 31 Jan '06

31 Jan '06

It looks like the syntax for "from __future__ import ..." changes in Python 2.5. I was playing around with Cheetah, and it stumbled over a file with the following structure: # comments """ docstring """ __author__ = "..." __version__ = "..." from __future__ import generators Python 2.2 throug 2.4 accept this fine. Perhaps the AST tree enforces stricter syntax for what can precede a future statement? I think this should be fixed. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: [Python-Dev] [Doc-SIG] that library reference, again
by David Goodger 31 Jan '06

31 Jan '06

On 12/29/05, Fredrik Lundh <fredrik(a)pythonware.com> wrote: > however, given that the discussion that led up to this has been dead for > almost a week, You mean since Christmas? > I'm beginning to fear that I've wasted my time on a project > that nobody's interested in. Could be. I don't see HTML+PythonDoc as a significant improvement over LaTeX. Yes, I'm biased. So are you. > are we stuck with latex for the foreseeable future? Until we have something clearly and significantly better, yes. -- David Goodger <http://python.net/~goodger>

12 22

(libffi) Re: Copyright issue
by Thomas Heller 30 Jan '06

30 Jan '06

[I've added python-dev to cc:] Anthony Green <green(a)redhat.com> writes: > On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote: >> Anyway, another question is: Is aclocal.m4 needed at all for building >> (or maybe for regenerating the configure scripts), or is it optional? > > aclocal.m4 is required, but is only used as a build-time tool. The fact > that aclocal.m4 is distributed under the GPL should have no impact on > the licensing terms used for software built using aclocal.m4. If I understand correctly this means that the Python source distribution would have to be GPL licensed, while the built programs would be able to use another license. I'm pretty sure this kills the whole idea (to include libffi in python). Thanks, Thomas

11 32

SourceForge Download Page, Subversion Home Page
by Steve Holden 30 Jan '06

30 Jan '06

You may be aware that Tim Parkin's work on our "next-generation" web presence has borne fruit in the shape of beta.python.org. While there's still a lot to be done Tim has given us a great start by creating a framework that makes it rather easier to manage content. I'm just starting to work on the beta site content, and this is causing some examination of the existing web content. Is there any way to affect the target of the very prominent "Download Python" link on http://sourceforge.net/projects/python/ ? I ask because the link currently takes you to a page whose title is "Exiting with Error" and whose content is largely "No File Packages". While it's not where you arrive from a Google search for "python download" it is nevertheless a legitimate way (just now) to approach the project, and should therefore really be live. Is there any chance some SF admin could point it to http://www.python.org/download/ There's the further issue that the entire HTML body of http://svn.python.org/ currently reads  It would seem like the logical place to have pointers to Subversion software (downloads, documentation, operating instructions) together with an *annotated* summary of http://svn.python.org/projects/ and links back to the main developer site at the very least. I'm not even sure where that web content is under SVN control at the moment. The web revision is going to lead to several of these kinds of discussions. I'll try to only spill on to the python-dev list what impinges on developers. Your opinions on these specific issues are probably the most significant. [pydotorgers: let's try not to spam python-dev with any discussions] regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/

8 9

Path inherits from string
by BJörn Lindqvist 29 Jan '06

29 Jan '06

This seems to be the only really major issue with the PEP. Everything else is negotiable, IMHO. But the string inheritance seem to be such a critical issue it deserves its own thread. I have tried to address all criticism of it here: Really, it is the same arguments that have been rehashed over and over again. I also think that they have been suitably countered already - Practicality beats Purity. The fact that you can plug Path into already existing code is a major benefit. It makes it possible to use and integrate the Path class *now* and not wait until the mythical Python 3000 when every single flaw in Python have been fixed. Remember that the Path module have existed for three years in the wild and is extra-ordinarily well-liked. If the fact that Path inherits from string is such a big deal, then *why* is the path module so hugely popular?? :) The inheritance is a design trade-off. An implementation detail, an insignificant wart in an otherwise very practical design. Over the years I have used the path module this wart has never ever hurt me. Not even once. But if someone can construct a Path class that does *not* inherit from string and that works equally well as Path then ofcourse, that is preferable. However, because of this (and similar issues) I don't think it is possible: class Foo: def __str__(self): return "foo" open(Foo()) TypeError: coercing to Unicode: need string or buffer, instance found However, I might be wrong because according to [1] it should work. And having to wrap the Path object in str() (open(str(somepath))) each and every time the called function expects a string is not a practical solution. Also note that because compatibility with existing code is important, Path can not override or change any methods at all from str - Liskov Substitution Principle. As Path is, it only violates LSP once: >>> type(Path()) == type('') False And there is absolutely nothing that can be done about that. As far as I can tell, the string inheritance is either livable with or is a showstopper. If it is the latter, then: 1. Someone has to make the required modifications to the Python core. 2. Create a Path class (or adapt the existing one so) that does not inherit from string. 3. Release it and wait a few years hoping for it to gain widespread acceptance in the Python community. 4. Make a PEP (or adapt this PEP) that gets accepted. This scenario makes me sad because it basically means that there will never be a Path module in Python, atleast not during my lifetime. :( Why? Because Jason Orendorff's path module already exists and works. But I may be overestimating the problems and doing what Jason suggests in [2] may be enough. Maybe someone who knows what he is talking about can expand on it further? 1 http://mail.python.org/pipermail/python-dev/2001-August/016674.html 2 http://mail.python.org/pipermail/python-dev/2006-January/060030.html -- mvh Björn

9 12

stabilizing builds
by Neal Norwitz 28 Jan '06

28 Jan '06

I would really like to stabilize a bunch of the current rough edges in 2.5. We are likely to have enough instability with the PEP 353 changes, so it would be better to fix some of these issues sooner rather than later. There are a bunch of tests that are not stable. It would really help to get people knowledgeable about a particular subdomain to provide input into bugs/patches and produce patches too! The areas that are known to have problems are listed here: http://wiki.python.org/moin/BuildBot It would be nice to clean those issues up. Does anyone have some time to spend to resolve the issues with Berkeley DB? That's the one that annoys me most right now. I have a patch that fixes at least one of the problems, but no idea if it's the correct solution or not. http://python.org/sf/1407992 n -- PS. In case you are interested in all the problems: * BSD DB 4.1 and 3.2 fail * test_pty is brittle on solaris 10, sometimes it works, sometimes not * getaddrinfo() configure check sometimes fails on OS X 10.3

6 13

The path module (class) PEP
by Jim Jewett 27 Jan '06

27 Jan '06

(1) What is the advantage of module Path vs just turning os.path into a class? (except that people already import from os.path, so I suppose it would need to be os.Path) (2) It sounds like quite a few stdlib calls will be both deprecated and wrapped. Having a new stdlib module rely on deprecated features leaves a bad taste. Perhaps move the functionality to the Path class and then forward from the current (about to be deprecated) modules? -jJ

1 0