[Python-Dev] release plan for 2.5 ?
Phillip J. Eby
pje at telecommunity.com
Fri Feb 10 22:07:50 CET 2006
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.
More information about the Python-Dev