[Python-3000] PEP 3108: Standard Library Reorganization

[Brett Cannon]

On 1/2/07, Josiah Carlson <jcarlson at uci.edu> wrote:
>
>
> "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.


I don't remember the whole bytes discussion in terms of encoding and
decoding.

> > 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 can't add you myself; someone else will need to do it (they will need your
SF ID).

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


I will probably do a separate email to get support or not for package
suggestions once the list of modules to  remove is settled upon.

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


Not really because if they move to a package they will most likely have to
go from ``import BaseHTTPServer`` to ``from web import BaseHTTPServer``, at
which point we can do ``from web import base_http_server as BaseHTTPServer``
just as easily in the refactoring tool.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070102/09eb9b38/attachment.html