On 1/1/07, Giovanni Bajo <[EMAIL PROTECTED]> 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
_______________________________________________
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
