Add to that the fact that to maintain the Python 3 text model, we either have to gut it to the point where it has very few of the benefits the text version offers printf-style formatting, or else we introduce a whole new protocol for a feature that we consider so borderline that it took us six Python 3 releases to add it back to the language.

">

(original) (raw)


On 18 Jan 2014 02:08, "Paul Moore" <p.f.moore@gmail.com> wrote:
\>
\> On 17 January 2014 15:50, Eric V. Smith <eric@trueblade.com> wrote:
\> > For #3, hopefully this "additional work" on the 3.x side would just be
\> > to add, to each class where you already have a custom \_\_format\_\_ used
\> > for b''.format(), code like:
\> >
\> > � � def \_\_format\_ascii\_\_(self, fmt):
\> > � � � � return self.\_\_format\_\_(fmt.decode()).encode('ascii')
\>
\> For me, the big cost would seem to be in the necessary documentation,
\> explaining the new special method in the language reference,
\> explaining the 2 different forms of format() in the built in types
\> docs. And the conceptual overhead of another special method for people
\> to be aware of. If I implement my own number subclass, do I need to
\> implement \_\_format\_ascii\_\_?
\>
\> My gut feeling is that we simply don't implement format() for bytes. I
\> don't see sufficient benefit, if %-formatting is available.

Exactly, it's the documentation problem to explain "when would I recommend using this over the alternatives?"� that turns me off the idea of general purpose bytes formatting. printf style covers the use cases we have identified, and the code bases of immediate interest support 2.5 or earlier and thus \*must\* be using printf-style formatting.

Add to that the fact that to maintain the Python 3 text model, we either have to gut it to the point where it has very few of the benefits the text version offers printf-style formatting, or else we introduce a whole new protocol for a feature that we consider so borderline that it took us six Python 3 releases to add it back to the language.

By contrast, the following model is relatively easy to document:

\* printf-style is low level and relatively inflexible, but available for both text and for ASCII compatible segments in binary data. The %s formatting code accepts arbitrary objects (using str) in text mode, but only buffer exporters and objects with a \_\_bytes\_\_ method in binary mode.

\* the format is high level and very flexible, but available only for text - the result must be explicitly encoded to binary if that is needed.

Cheers,
Nick.

>
\> Paul.
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> Python-Dev mailing list
\> Python-Dev@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com