On 1/2/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
"Brett Cannon" <[EMAIL PROTECTED]> wrote:
> On 1/1/07, Josiah Carlson <[EMAIL PROTECTED]> 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
_______________________________________________
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
