|| ||"Guido van Rossum" <guido-AT-python.org>|
|| ||"Python 3000" <python-3000-AT-python.org>|
|| ||PEP Parade|
|| ||Tue, 1 May 2007 11:31:00 -0700|
So the PEP submissions are in, and a few late ones will be submitted
ASAP. Let me write up a capsule review of what we've got. Please let
me know if I missed anything (e.g. a PEP that someone has committed to
write but hasn't submitted yet).
First the PEPs that have numbers as of this writing (I'm pasting the
section heads right out of PEP 0, so apoligies for the formatting):
S 3101 Advanced String Formatting Talin
While we're still tweaking details, I expect this will be ready for
acceptance soon. We also have an implementation in the sandbox!
S 3108 Standard Library Reorganization Cannon
I expect this to happen after 3.0a1 is released.
S 3116 New I/O Stutzbach, Verdone, GvR
A prototype is in the py3k branch. There are details to work through
(like how to seek on text files with non-trivial encodings) but I feel
that the basis is solid. I could use help coding!
S 3117 Postfix Type Declarations Brandl
I forgot to reject this -- it was my favorite April Fool's post of the
year though. :-)
S 3118 Revising the buffer protocol Oliphant, Banks
Where's this standing? I'm assuming that it's pretty much ready to be
implemented. I haven't had the time to participate in the discussion.
S 3119 Introducing Abstract Base Classes GvR, Talin
This is clearly still controversial. It is also awaiting a rewrite. I
am still in favor of something this (or I wouldn't bother with the
S 3120 Using UTF-8 as the default source encoding von Löwis
The basic idea seems very reasonable. I expect that the changes to the
parser may be quite significant though. Also, the parser ought to be
weened of C stdio in favor of Python's own I/O library. I wonder if
it's really possible to let the parser read the raw bytes though --
this would seem to rule out supporting encodings like UTF-16. Somehow
I wonder if it wouldn't be easier if the parser operated on Unicode
input? That way parsing unicode strings (which we must support as all
strings will become unicode) will be simpler.
S 3121 Module Initialization and finalization von Löwis
I like it. I wish the title were changed to "Extension Module ..." though.
S 3123 Making PyObject_HEAD conform to standard C von Löwis
I like it, but who's going to make the changes? Once those chnges have
been made, will it still be reasonable to expect to merge C code from
the (2.6) trunk into the 3.0 branch?
S 3124 Overloading, Generic Functions, Interfaces Eby
I haven't had the time to read this in detail, but in general I'm
feeling favorable about this idea. I'd rather see it decoupled from
sys._getframe() and modifying func_code (actually __code__ nowadays,
see PEP 3100).
S 3125 Remove Backslash Continuation Jewett
Sounds reasonable. I think we should still support \ inside string
literals though; the PEP isn't clear on this. I hope this falls within
the scope of the refactoring tool (sandbox/2to3).
S 3126 Remove Implicit String Concatenation Jewett
Sounds reasonable as well. A fixer for this would be trivial to add to
the refactoring tool.
S 3127 Integer Literal Support and Syntax Maupin
Fully in favor.
S 3128 BList: A Faster List-like Type Stutzbach
I still have misgivings about having too many options for developers.
While wizards will have no problem deciding between regular lists and
BLists, I worry that a meme might spread among junior coders that the
built-in list type is slow, causing overuse of BLists for no good
reason. But I am deferring to Raymond Hettinger in this matter.
S 3141 A Type Hierarchy for Numbers Yasskin
Jeffrey has promised to rewrite this, removing most of the references
to algebra. I expect I'll like his rewrite, once it happens.
Now on to the PEPs that don't have numbers yet.
PEP: Supporting Non-ASCII identifiers (Martin von Loewis)
I'm on record as not liking this; my worry is that it will become a
barrier to the free exchange of code. It's not just languages I can't
read (Russian transliterated to the latin alphabet would be just as
bad and we don't stop that now); many text editors have no or limited
support for other scripts (not to mention mixing right-to-left script
with Python's left-to-right identifiers). But if this receives a lot
of popular support I'm willing to give it a try. The One Laptop Per
Child project for example would like to enable students to code in
their own language (of course they'd rather see the language keywords
and standard library translated too...).
PEP: Adding class decorators (???)
I'm in favor of this. I'm just writing for someone to write it up.
PEP: Eliminate __del__ (Raymond Hettinger)
I would be in favor of this or one of the alternative ideas for fixing
the can't-GC-a-cycle-with-__del__ issue if there was a clear recipe
and (if necessary) stdlib support for what to do instead. There are
real use cases for automatic finalization for which the atexit module
isn't the right solution and try/finally or with statements don't cut
PEP: Information Attributes (Raymond Hettinger)
This would be better served by a continued discussion about the merits
and flaws of ABCs (PEP 3119 and 3141).
PEP: Traits/roles instead of ABCs (Collin Winter)
This could serve as an interesting alternative to PEP 3119. However, I
believe that it doesn't really solve the distinction between
abstractions that can be implemented as "classic" ABCs and
abstractions that require a metaclass (like TotalOrder or Ring).
--Guido van Rossum (home page: http://www.python.org/~guido/)
to post comments)