[Python-Dev] PEP 460: allowing %d and %f and mojibake

Mark Shannon mark at hotpy.org
Sun Jan 12 18:06:46 CET 2014


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 [ncoghlan at gmail.com]
> *Sent:* Sunday, January 12, 2014 16:09
> *To:* Kristján Valur Jónsson
> *Cc:* python-dev at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mark%40hotpy.org
>



More information about the Python-Dev mailing list