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@trueblade.com <mailto:eric@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@yahoo.com <mailto:abarnert@yahoo.com> > <mailto:abarnert@yahoo.com <mailto:abarnert@yahoo.com>>> wrote: > > On Oct 7, 2015, at 04:35, Nick Coghlan <ncoghlan@gmail.com <mailto:ncoghlan@gmail.com> > <mailto:ncoghlan@gmail.com <mailto:ncoghlan@gmail.com>>> wrote: > > > >> On 4 October 2015 at 08:25, Andrew Barnert <abarnert@yahoo.com <mailto:abarnert@yahoo.com> <mailto:abarnert@yahoo.com <mailto:abarnert@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@python.org <mailto:Python-ideas@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>)