On Thu, Jan 16, 2014 at 4:56 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>
> On 16 Jan 2014 17:53, "Ethan Furman" <et...@stoneleaf.us> wrote:
> >
> > On 01/15/2014 06:45 AM, Brett Cannon wrote:
> >>
> >>
> >> This is why I have argued that if you specify it as "if there is a
> format spec specified, then the return value from
> >> calling __format__() will have str.decode('ascii', 'strict') called on
> it" you get the support for the various
> >> number-specific format specs for free.
> >
> >
> > It may work like this under the hood, but it's an implementation detail.
> Since the numeric format codes will call int, index, or float on the
> object (to handle subclasses), we could then call __format__ on the
> resulting int or float to do the heavy lifting; but since __format__ on
> anything else would never be called I don't want to give that impression.
>
> I have a different proposal: let's *just* add mod formatting to bytes, and
> leave the extensible formatting system as a text only operation.
>
> We don't really care if bytes supports that method for version
> compatibility purposes, and the deliberate flexibility of the design makes
> it hard to translate into the binary domain.
>
> So let's just not provide that - let's accept that, for the binary domain,
> printf style formatting is just a better fit for the job :)
>
Or PEP 460 for bytes.format() and PEP 461 for %.
-Brett
> Cheers,
> Nick.
>
> >
> >
> >> It also means if you pass in a string that you just want the strict
> ASCII bytes
> >> of then you can get it with {:s}.
> >
> >
> > This isn't going to happen. If the user wants a string to be in the
> byte stream, it has to either be a bytes literal or explicitly encoded [1].
> >
> > --
> > ~Ethan~
> >
> > [1] Apologies if this has already been answered. I wanted to make sure
> I responded to all the ideas/objects, and I may have responded more than
> once to some. It's been a long few threads. ;)
> >
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> 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/brett%40python.org
>
>
_______________________________________________
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/archive%40mail-archive.com
