On Oct 7, 2015, at 2:01 PM, Eric V. Smith <eric@trueblade.com> wrote:
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.
Make that "!p". Eric.
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>)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/