[Python-3000] PEP 3108: Standard Library Reorganization

[Brett Cannon]

On 1/1/07, Giovanni Bajo <rasky at develer.com> wrote:
>
> 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.


Fair enough.  If more people say it should stay it can stay.

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


The Python version is the reference implementation because all
implementations of Python can use it.  The C implementation is just for
speed.  Besides the Python version almost always comes first and is what
people use as a design reference.  No one is saying the C version goes away,
just that the Python version stays as a backup and is used to define the
semantics.

And Guido has already decided this whole thing anyway.

> * 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?


It's a typo.

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


Yeah, but DeprecationWarnngs are loud as well.  It is up to the developer to
change the code still.

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


PendingDeprecationWarning could work.  I will wait and see what other people
have to say.

>     + 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...


I think some people use them for mixin purposes.  But I don't know since I
never use them.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070101/a29a8f8b/attachment-0001.htm