Responding to two posts at once, as I consider them
On 1/17/2014 11:00 AM, Brett Cannon wrote:
I would rephrase it to "switch to %-formatting for bytes usage for their
common code base". If they are working with actual text then using
str.format() still works (and is actually nicer to use IMO). It actually
might make the str/bytes relationship even clearer, especially if we
start to promote that str.format() is for text and %-formatting is for
bytes.
Good idea, I think: printf % formatting was invented for formatting
ascii text in bytestrings as it was being output (although sprintf
allowed not-output). In retrospect, I think we should have introduced
unicode.format when unicode was introduced in 2.0 and perhap never have
had unicode % formatting. Or we should have dropped str % instead of
bytes % in 3.0.
On 1/17/2014 12:13 PM, Eric V. Smith wrote:
> But if we think that %-formatting is neanderthal and will get dropped
> in the Python 4000 timeframe (that is, someday in the far future),
Some people, such as Martin Loewis, have a different opinion of
%-formatting and will fight deprecating it *ever*. (I suspect that
%-format opinions are influenced by one's current relation to C.)
> then I think we should have some advice to give to people who are
> writing new 3.x code for the non-porting use-cases addressed by the
> PEP. I'm specifically thinking of new code that wants to format some
> bytes for an on-the-wire ascii-like protocol.
If we add %-formatting back in 3.5 for its original purpose, formatting
ascii in bytes for output, I think we should drop the idea of later
deprecating it (a few releases later) for that purpose. I think the PEP
should even say so, that bytes % will remain indefinitely even if str %
were to be dropped in favor of str.format.
I would consider dropping unicode(now string).__mod__ in favor of
.format to still be an eventual option, especially if someone were to
write a converter.
--
Terry Jan Reedy
_______________________________________________
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
