On 1/1/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
"Brett Cannon" <[EMAIL PROTECTED]> 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. I agree with Giovanni on the above.
OK. Starting to sound like fileinput should stay.
* telnetlib > + Telnet is not used very much anymore. > - Telnet is unsafe. > - Most people use SSH instead. I don't know how common telnet lib use is currently, but I have found it useful in writing plaintext line-based clients (like SMTP, POP, HTTP, IMAP, etc.), before moving on to writing async* derived clients.
Fair enough. If more people step up it can stay.
* base64/quopri/uu > + Support exists in the codecs module. > + If removed (along with binhex), also remove binascii. > - C implementation of base64, binhex, and uu modules. The binascii module has become a catch all module for various plaintext <-> binary conversions.
Right, but is it necessarily the best thing that it has become a catch-all? I'm not sure if using .encode()/.decode() are
necessarily desireable, especially in the case of certain binascii conversions that involve long/int <-> binary (that didn't make it into Python 2.5).
Anyone else want to weigh in to save binascii?
* asynchat/asyncore > + Third-party libraries provide better solutions. > - twisted [#twisted]_ > + Deprecation previously supported [#py-dev-summary-2004-11-01]_ There is quite a bit of user code that depends on asynchat/asyncore modules. While there are many people who end up using twisted, forcing all asynchronous socket users to "drink the twisted kool-aid" would set a bad precident for any commonly used stdlib Python library with a more fully-featured 3rd party module.
Well, I just remember the thread that led to the suggestion the two modules go. It can be saved from the chopping block but I remember part of the issue was no one was wanting to maintain the modules anymore and they were starting to collect dust.
* stat > + ``os.stat`` now returns a tuple with attributes. The stat module also offers useful functions like stat.IS_DIR() for determining if an object is a directory.
Perhaps the functions should move to os or be part of the object returned by os.stat.
* thread > + People should use 'threading' instead. > - Rename 'thread' to _thread. > - Deprecate dummy_thread. > * Rename to _mockthread. > * Change of name better reflects modules purpose. > + Guido has previously supported the deprecation > [#thread-deprecation]_. Sounds good. Can we get this particular change into the 2.x series? I've seen too much code that mixes and matches threading and thread use.
Probably if people want it.
* SocketServer > socketserver SocketServer and its derivatives (*HTTPServer) are tricky (I've been seeing them used quite a bit)...
Well, I am not proposing to remove them although I would not cry if the HTTPServer children disappeared, but that's just me. We will have to see if anyone else is up for letting them go.
* Servers > + BaseHTTPServer > + CGIHTTPServer > + DocXMLRPCServer > + SimpleHTTPServer > + SimpleXMLRPCServer > + SocketServer Would it be a reasonable semantic to say that 'no top level modules or packages can violate PEP 8 module/package naming guidelines', but sub-modules or packages may use CamelCase by historical precident or when doing so would make understanding the purpose of the module/package easier?
Could. The renaming as of right now only enforces it on the package name stringently. But the style guide is not my call. -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
