[Python-ideas] Adding 'bytes' as alias for 'latin_1' codec.

[Nick Coghlan]

On Fri, May 27, 2011 at 9:07 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Nick Coghlan writes:
>
>  > To me, the defining feature of str.format() over str.__mod__() is the
>  > ability for types to provide their own __format__ methods,
>
> Ah, so you object to the _spelling_, not the requested functionality.
> (At least, not all of it.)  All is clear now!
>
> OK, I retract my suggestion, but I'll let you beat up on anybody who
> dredges it up in the future.  Specifically, I think that calling it
> "bytes.format" (a) is discoverable and (b) it is not obvious to me
> that __format_bytes__ functionality for arbitrary types is a bad
> thing, although I personally have no use case and am unlikely to catch
> one for a while (thus at most I'm now -0, and could easily be
> persuaded to lower that).

In the specific case of adding bytes.format(), it's the weight of the
backing machinery that bothers me - the PEP 3101 implementation isn't
small, and providing a parallel API for bytes without slowing down the
existing string implementation would be problematic (code re-use would
likely slow down the common case even further, while avoiding re-use
would likely end up duplicating a lot of code). However, *if* a solid
set of use cases for direct bytes interpolation can be identified (and
that's a big if), then it may be possible to devise a narrower, more
focused API that doesn't require such a heavy back end to support it.

But the use cases have to come first, and ones that are better
expressed via techniques such as ASCII decoding with the
surrogateescape error handler to support round-tripping don't count.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia