Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Jan 3, 2007, at 9:23 AM, Michael Urman wrote:
> > On 1/2/07, Anthony Baxter <[EMAIL PROTECTED]> 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
_______________________________________________
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
