[Python-3000] PEP Parade

[Guido van Rossum]

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
rewrite).

 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
it either.

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/)