[Python-ideas] Binary f-strings
Eric V. Smith
eric at trueblade.com
Wed Oct 7 20:01:36 CEST 2015
On 10/07/2015 01:58 PM, Guido van Rossum wrote:
> Of course that would still leave the door open for struct.pack support
> (maybe recognized by having the string start with <,=, > or @). Pro:
> everybody who currently uses struct.pack will love it. Con: the
> struct.pack mini-language is pretty inscrutable if you don't already
> know it. (And no, I don't propose to invent a different mini-language --
> it's just easier to figure out where to find docs for this when the code
> explicitly imports the struct module.)
Right. I think Steve Dower's idea of :p switching to struct.pack mode is
reasonable. But as Nick says, we don't need to add it on day 1.
Eric.
>
> On Wed, Oct 7, 2015 at 10:53 AM, Eric V. Smith <eric at trueblade.com
> <mailto:eric at trueblade.com>> wrote:
>
> On 10/07/2015 12:25 PM, Guido van Rossum wrote:
> > I think bf'...' should be compared to b'...' % rather than to f'...'.
> > IOW bf'...' is to f'...' as b'...'% is to '...'%.
>
> I'm leaning this way, at least in the sense of "there's a fixed number
> of known types supported, and there's no extensible protocol involved.
>
> Eric.
>
> >
> > On Wed, Oct 7, 2015 at 5:34 AM, Andrew Barnert <abarnert at yahoo.com <mailto:abarnert at yahoo.com>
> > <mailto:abarnert at yahoo.com <mailto:abarnert at yahoo.com>>> wrote:
> >
> > On Oct 7, 2015, at 04:35, Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>
> > <mailto:ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>>> wrote:
> > >
> > >> On 4 October 2015 at 08:25, Andrew Barnert
> <abarnert at yahoo.com <mailto:abarnert at yahoo.com>
> <mailto:abarnert at yahoo.com <mailto:abarnert at yahoo.com>>> wrote:
> > >> Nick's suggestion of having it do %-formatting makes sense.
> Yes, it means
> > >> that {count:03} is an error and you need '{count:03d}',
> which is
> > >> inconsistent with f-strings. But that seems like a much
> less serious problem
> > >> than bytes formatting not being able to handle bytes.
> > >
> > > Exactly, if someone is mistakenly thinking
> > > bf"{header}{content}{footer}" is equivalent to
> > > f"{header}{content}{footer}".encode(), they're likely to get
> immediate
> > > noisy errors when they start trying to format fields.
> >
> > Except that multiple people in this thread are saying that'd
> exactly
> > what it should mean (which I think is a very bad idea).
> >
> > > The parallel I'd attempt to draw is that:
> > >
> > > f"{header}{content}{footer}" is to
> "{}{}{}".format(header, content, footer)
> > >
> > > as:
> > >
> > > bf"{header:b}{content:b}{footer:b}" would be to b"%b%b%b" %
> > > (header, content, footer)
> > >
> > > To make the behaviour clearer in the latter case, it may be
> reasonable
> > > to *require* an explicit field format code, since that
> corresponds
> > > more closely to the mandatory field format codes in
> mod-formatting.
> >
> > Are you suggestive that if a format specifier is given, it must
> > include the format code (which seems perfectly reasonable to
> > me--guessing that :3 means %3b is likely to be wrong more
> often than
> > it's right…), or that a format specifier must always be given,
> with
> > no default to :b (which seems more obtrusive and solves less of a
> > problem).
> >
> >
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido <http://python.org/~guido>
> <http://python.org/~guido>)
> >
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org <mailto:Python-ideas at python.org>
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
More information about the Python-ideas
mailing list