On 01/17/2014 10:15 AM, Mark Lawrence wrote: > On 17/01/2014 14:50, Eric V. Smith wrote: >> On 01/17/2014 07:34 AM, Eric V. Smith wrote: >>> On 1/17/2014 6:42 AM, Nick Coghlan wrote: >>>> >>>> On 17 Jan 2014 18:03, "Eric Snow" <ericsnowcurren...@gmail.com >>>> <mailto:ericsnowcurren...@gmail.com>> wrote: >>>>> >>>>> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith <e...@trueblade.com >>>> <mailto:e...@trueblade.com>> wrote: >>>>>> For the first iteration of bytes.format(), I think we should just >>>>>> support the exact types of int, float, and bytes. It will call the >>>>>> type's__format__ (with the object as "self") and encode the result to >>>>>> ASCII. For the stated use case of 2.x compatibility, I suspect >>>>>> this will >>>>>> cover > 90% of the uses in real code. If we find there are cases >>>>>> where >>>>>> real code needs additional types supported, we can consider adding >>>>>> __format_ascii__ (or whatever name we cook up). >>>>> >>>>> +1 >>>> >>>> Please don't make me learn the limitations of a new mini language >>>> without a really good reason. >>>> >>>> For the sake of argument, assume we have a Python 3.5 with >>>> bytes.__mod__ >>>> restored roughly as described in PEP 461. *Given* that feature set, >>>> what >>>> is the rationale for *adding* bytes.format? What new capabilities will >>>> it provide that aren't already covered by printf-style interpolation >>>> directly to bytes or text formatting followed by encoding the result? >>> >>> The only reason to add any of this, in my mind, is to ease porting of >>> 2.x code. If my proposal covers most of the cases of b''.format() that >>> exist in 2.x code that wants to move to 3.5, then I think it's worth >>> doing. Is there any such code that's blocked from porting by the lack of >>> b''.format() that supports bytes, int, and float? I don't know. I >>> concede that it's unlikely. >>> >>> IF this were a feature that we were going to add to 3.5 on its own >>> merits, I think we add __format_ascii__ and make the whole thing >>> extensible. Is there any new code that's blocked from being written by >>> missing b"".format()? I don't know that, either. >> >> Following up, I think this leaves us with 3 choices: >> >> 1. Do not implement bytes.format(). We tell any 2.x code that's written >> to use str.format() to switch to %-formatting for their common code base. >> >> 2. Add the simplistic version of bytes.format() that I describe above, >> restricted to accepting bytes, int, and float (and no subclasses). Some >> 2.x code will work, some will need to change to %-formatting. >> >> 3. Add bytes.format() and the __format_ascii__ protocol. We might want >> to also add a format_ascii() builtin, to match __format__ and format(). >> This would require the least change to 2.x code that uses str.format() >> and wants to move to bytes.format(), but would require some work on the >> 3.x side. >> >> I'd advocate 1 or 2. >> >> Eric. >> > > For both options 1 and 2 surely you cannot be suggesting that after > people have written 2.x code to use format() as %f formatting is to be > deprecated, they now have to change the code back to the way they may > well have written it in the first place? >
That would be part of it, yes. Otherwise you need #3. This is all assuming we've ruled out an option 4, because of the exceptions raised depending on what __format__ does: 4. Add bytes.format(), have it convert the format specifier to str (unicode), call __format__ and encode the result back to ASCII. Accept that there will be data-driven exceptions depending on the result of the __format__ call. I'm open to other ideas. Eric. _______________________________________________ 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
