On 12/01/14 16:52, Kristján Valur Jónsson wrote:
Now you're just splitting hairs, Nick.
An explicit operator, %s, _defined_ to be "encode a string object using
strict ascii",
I don't like this because '%s' reads to me as "insert *string* here".
I think '%a' which reads as "encode as ASCII and insert here" would be
better.
how is that any less explicit than the .encode('ascii', 'strict') spelt
out in full? The language is full of constructs that are shorthands for
others, more lengthy but equivalent things.
I mean, basically what I am suggesting is that in addition to %b with
def helper(o):
return str(o).encode('ascii', 'strict')
b'foo*%b*bar'%(helper(myobj), )
you have
b'foo*%s*bar'%(myobj, )
There is no "data driven change in assumptions." Just an interpolation
operator with a clearly defined meaning.
I don't think anyone is trying to compromise the text model. All people
are asking for is that the _boundary_ is made a little easier to deal with.
K
------------------------------------------------------------------------
*From:* Nick Coghlan [ncogh...@gmail.com]
*Sent:* Sunday, January 12, 2014 16:09
*To:* Kristján Valur Jónsson
*Cc:* python-dev@python.org; Georg Brandl
*Subject:* Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
It is not explicit, it is implicit - whether or not the resulting string
assumes ASCII compatibility or not depends on whether you pass a binary
value (no assumption) or a string value (assumes ASCII compatibility).
This kind of data driven change in assumptions about correctness is
utterly unacceptable in the core text and binary types in Python 3.
_______________________________________________
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/mark%40hotpy.org
_______________________________________________
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
