[Python-Dev] release plan for 2.5 ?

[Phillip J. Eby]

At 12:21 PM 2/10/2006 -0800, Guido van Rossum wrote:
> >    PEP 343: The "with" Statement
>
>Didn't Michael Hudson have a patch?

PEP 343's "Accepted" status was reverted to "Draft" in October, and then 
changed back to "Accepted".  I believe the latter change is an error, since 
you haven't pronounced on the changes.  Have you reviewed the __context__ 
stuff that was added?

In any case Michael's patch was pre-AST branch merge, and no longer 
reflects the current spec.


>PEP 332 - byte vectors. Looks incomplete. Put off until 2.6?

Wasn't the plan to just make this a builtin version of array.array for 
bytes, plus a .decode method and maybe a few other tweaks?  We presumably 
won't be able to .encode() to bytes or get bytes from sockets and files 
until 3.0, but having the type and being able to write it to files and 
sockets would be nice.  I'm not sure about the b"" syntax, ISTR it was 
controversial but I don't remember if there was a resolution.


>PEP 314 (metadata v1.1): this is marked as completed, but there's a
>newer PEP available: PEP 334 (metadata v1.2). That PEP has 2.5 as its
>target date. Shouldn't we implement it? (This is a topic that I
>haven't followed closely.) There's also the question whether 314
>should be marked final. Andrew or Richard?

I'm concerned that both metadata PEPs push to define syntax for things that 
have undefined semantics.  And worse, to define incompatible syntax in some 
cases.  PEP 345 for example, dictates the use of StrictVersion syntax for 
the required version of Python and the version of external requirements, 
but Python's own version numbers don't conform to strict version 
syntax.  ISTM that the metadata standard needs more work, especially since 
PyPI doesn't actually support using all of the metadata provided by the 
implemented version of the standard.  There's no way to search for 
requires/provides, for example (which is one reason why I went with 
distribution names for dependency resolution in setuptools).  Also, the 
specs don't allow for a Maintainer distinct from the package Author, even 
though the distutils themselves allow this.  IMO, 345 needs to go back to 
the drawing board, and I'm not really thrilled with the currently-useless 
"requires/provides" stuff in PEP 314.

If we do anything with the package metadata in Python 2.5, I'd like it to 
be *installing* PKG-INFO files alongside the packages, using a filename of 
the form "distributionname-version-py2.5.someext".  Setuptools supports 
such files currently under the ".egg-info" extension, but I'd be just as 
happy with '.pkg-info' if it becomes a Python standard addition to the 
installation.  Having this gives most of the benefits of PEP 262 (database 
of installed packages), although I wouldn't mind extending the PKG-INFO 
file format to include some of the PEP 262 additional data.

These are probably distutils-sig and/or catalog-sig topics; I just mainly 
wanted to point out that 314, 245, and 262 need at least some tweaking and 
possibly rethinking before any push to implementation.