[Python-3000] PEP 3108: Standard Library Reorganization

[Brett Cannon]

On 1/2/07, Anthony Baxter <anthony at interlink.com.au> wrote:
>
> On Wednesday 03 January 2007 10:47, Brett Cannon wrote:
> > > > > * 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.
> > > > >
> > Are you at least okay with base64, quopri, and uu going?  You are
> > just arguing for the saving of binascii, right?
> >
> > Does anyone else care to try to save binascii?
>
> I am deeply uncomfortable with base64 going. This is used by a _lot_
> of code, and the alternative (using the codecs module) is not at
> all well publicised. For instance, the docs for the base64 module
> don't even mention that you can use the codecs module as an
> alternative. I just looked up how to do it, and it provides a
> different, and to my eyes, less pleasant API. For instance these
> two:
>
> base64.encodestring('hello world')
> or
> base64.b64encode('hello world')
>
> become
> codecs.getencoder('base64')('hello')[0]


It is starting to sound like the codecs module needs a little work.

Additionally, base32 and base16 are not supported by codecs,
> according to the docs, and neither is the ability to specify
> alternate character mappings (I don't know how heavily used the
> last is, though).


Yeah, I noticed the base32 and base16 codecs were missing.

I think any removal should take into account how heavily the module
> is used, as well as how aggressively we've previously pushed people
> to an alternative.


Fine with me, but I need help figuring out which modules are used heavily
(which, luckily, people are doing).

base64 seems to have quite the following, so I will take it off the list.  I
assume then that means quopri and uu should be saved as well?  And I am
assuming binascii comes along with the package (although alternative idea is
below).

For base64, the relevant answers are "quite
> heavily used"[1] and "not at all"[2].


It seems that the codecs module might need a cleanup in terms of API or
something.  Or at least have people be more aware of it.

For those reasons, I'm a strong -1 on removing base64. I don't have
> a problem with it being reimplemented on top of the codecs module,
> so long as that doesn't lead to any serious performance slowdowns.
> A couple of quick tests with timeit seems to show that the two are
> approximately equal in performance, but more testing is needed.


That's an idea if someone is up for doing that.  Could also hide binascii as
_binascii and have base64, quopri, and uu use it then to follow what we are
doing with cStringIO/StringIO et. al.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070102/64b0456b/attachment.htm