[Python-3000] PEP 3108: Standard Library Reorganization

[Anthony Baxter]

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]

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

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. For base64, the relevant answers are "quite 
heavily used"[1] and "not at all"[2]. 

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.

[1] google for 'filetype:py base64'
[2] I don't recall it ever being discussed before now

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.