On Fri, May 27, 2011 at 9:07 PM, Stephen J. Turnbull <stephen@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@gmail.com | Brisbane, Australia