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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
