[Python-3000] PEP 3108: Standard Library Reorganization

[Josiah Carlson]

Barry Warsaw <barry at python.org> wrote:
> On Jan 3, 2007, at 9:23 AM, Michael Urman wrote:
> > On 1/2/07, Anthony Baxter <anthony at interlink.com.au> wrote:
> >> base64.encodestring('hello world')
> >> or
> >> base64.b64encode('hello world')
> >>
> >> become
> >> codecs.getencoder('base64')('hello')[0]
> >
> > Isn't this a lot more idiomatically translated as
> >     'hello world'.encode('base64')
> > or is there still too much worry that this will require
> > encoding/decoding ascii bytestrings?
> >
> > Your additional points about base32 and base16 still apply to
> > .encode(), as they each result in an unknown encoding LookupError.
> 
> And don't forget that options can be passed to the encoders.
> 
> But fundamentally, I really dislike having to specify the encoder as  
> a string rather than as a POFC (plain ol' function call).

What about:

    'hello world'.encode.base64()

Then incorrectly named encodings can raise an attribute error.  Users
can discover what they can encode/decode their objects to via dir(obj.encode),
etc.

It may take some name mangling on the part of the iso-* codecs (iso_*?),
and it may even make sense for modules in the encodings package to
specify if they can take optional arguments (for the alternate alphabet
for base64, etc.).


 - Josiah