On Mon, 27 Feb 2012 11:21:16 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<mar...@v.loewis.de> wrote:
> I find this rationale a bit sad: it's not that there is any (IMO) good
> technical reason for the feature - only that people "hate" the many
> available alternatives for some reason.
>
> But then, practicality beats purity, so be it.
Agreed on both counts (but only reluctantly on the second :)
The PEP does not currently contain a discussion of the unicode_literals +
str() alternative and why that is not considered acceptable. That should
be added (and I'm very curious why it isn't acceptable, it seems very
elegant to me).
In fact, I'd like to see the PEP contain a bullet list of alternatives
with a discussion of why each is unacceptable or insufficient. The text
as organized now is hard to follow for that purpose.
Other comments:
I disagree that "it is clear that 2to3 as a tool is insufficient" and
that *therefore* people are attempting to use unified source. I think
the truth is that people just prefer the unified source approach,
because that is more Pythonic.
I also strongly disagree with the statement that unicode_literals is
doing more harm that good. Many people are using it very successfully.
In *certain contexts* (WSGI) it may be problematic, but that doesn't
mean it was a bad idea or that it shouldn't be used (given that a
project uses it consistently, as noted previously in this thread).
As noted above, the native string type *is* available with
unicode_literals, it is spelled "str('somestring').
I don't understand the "Who Benefits?" section at all. For example, I
think you'll agree I'm experienced working with email issues, and I don't
understand how this proposal would help at all in dealing with email.
The PEP would be strengthened by providing specific examples of the
claims made in this section.
I am -0 on this proposal. I will bow to the experience of those actually
trying to port and support web code, which I am not doing myself.
But I'd like to see the PEP improved so that the proposal is as strong
as possible.
--David
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
