[Python-3000] PEP 3108: Standard Library Reorganization

[Giovanni Bajo]

Brett Cannon wrote:

> * fileinput
>     + Basic functionality handled by ``itertools.chain``.
>     + Using ``enumerate`` (for the line number in the file),
>       ``itertools.repeat`` (for returning the filename with each
>       line), and ``zip`` (for connecting the ``enumerate`` object and
>       ``itertools.repeat`` object)  provides 95% of other unique
>       abilities of fileinput.

How would you rewrite this without fileinput:

====== cat.py ======
import sys
import fileinput

for L in fileinput.input():
     sys.stdout.write(L)
====================

The very concise call to input() lets you handle many different issues at once 
and implement a natural interface for a text-mungling program (accepts one or 
more file names, default to stdin, if "-" is specified it means stdin, and so on).

I think this module should stay. Its most important feature is that it lets 
you implement a de-facto standard interface with a single call.


> The C module is to be given a leading underscore to delineate the fact
> that it is not the reference implementation (the Python implementation
> is).  This means that any semantic difference between the C and Python
> versions must be dealt with before Python 3.0 or else the C
> implementation will be removed until it can be fixed.

Why should always the Python implementation be the reference one? Of the three 
examples you did, in two cases (cPickle and cStringIO) the C implementation is 
much faster. In fact, I would suggest to remove the Python implementation if 
any...

> * profile/cProfile
>     + Rename cProfile to profile.
>     + Semantic completeness of C implementation *not* verified.

Is this an editor mistake? Where does the current "profile" go? Are you 
suggesting to remove it?

> Modules will be renamed in Python 2.6 .  The original names of the
> modules will still work but will raise ImportWarning upon import.  The
> refactoring tool for transitioning to Python 3.0 will refactor imports
> that use the original names to the new names.

Does that mean that a very large amount of existing Python code will raise an 
ImportWarning under Python 2.6? I don't think this is acceptable. Why should 
the users be bothered with deprectation warnings related to Python 3.0? Surely 
the *developers* are the only ones interested in this.

A PendingDeprecationWarning is fine in this case too I guess. Or you could 
introduce a specific Py3kDeprecationWarning, turned on with a mystical -3 
command line option (in which we can join all the features to help porting 
source code to Py3k).


>     + UserDist
>     + UserList
>     + What to do with UserString?

BTW, aren't the User* modules a relic of when builtin types weren't 
subclassable? Are they still useful now? Really a genuine question...
-- 
Giovanni Bajo