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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
