On 1/2/07, Anthony Baxter <[EMAIL PROTECTED]> 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
_______________________________________________
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
