[Python-3000] PEP 3108: Standard Library Reorganization

[Josiah Carlson]

"Brett Cannon" <brett at python.org> wrote:
> On 1/1/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> > I would guess that Raymond Hettinger would have something to say about
> > this (being that he was going to add the long/int <-> binary conversion
> > to binascii). I don't know if he has been paying attention and/or
> > reading py3k.
> 
> Raymond might, but I don't think he is following Py3K.  But MAL kicked the
> PEP over to python-dev so he might notice now.
> 
> Are you at least okay with base64, quopri, and uu going?  You are just
> arguing for the saving of binascii, right?

More or less.  One concern I have about switching to a codecs-only
approach is that one will not be able to use bytes.encode('base64'), as
per previous discussions on the topic (that I may be remembering
incorrectly), only bytes.decode(...) will be available (think in terms
of unicode text encoding and decoding). One would need to perform
bytes.decode('latin1').encode('base64'). Using the base64 module
bypasses such round trip foolishness.  I believe the same holds for
quopri and uu.


> > If asyncore/asynchat/smtpd needs a maintainer, then I volunteer.  Assign
> > all bugs, patches, etc., to me and I'll handle them.
> 
> That's good enough for me.  They are saved.

Someone needs to add me to the project on SF.  Or we can wait until the
new tracker is up.  I don't see anyone rushing to patch the async
modules.


> > I'm not voting for their removal, just stating that they are trickly to
> > handle, both in a naming, and in an understanding perspective.  Honestly,
> > which is easier to read and/or understand to you: basehttpserver or
> > BaseHTTPServer?  I prefer CamelCase.
> 
> Perhaps, but consistency is more important (at least to me).  Best bet would
> be to put them in a package.

I agree.


> > xml.etree.ElementTree could be used as an example of what could/should
> > or shouldn't be done.
> 
> It is its own special open issue for that reason.  =)  I personally would
> prefer they go into a package, we ditch the CamelCase and move to
> underscores for them.

Either is fine with me.  Sticking with CamelCase makes the renaming
easier.


 - Josiah