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" <ericsnowcurrently at gmail.com >>> <mailto:ericsnowcurrently at gmail.com>> wrote: >>>> >>>> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith <eric at trueblade.com >>> <mailto:eric at 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? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4