On Sun, 2012-02-26 at 16:06 -0500, Barry Warsaw wrote: > On Feb 26, 2012, at 09:20 PM, Nick Coghlan wrote: > > >It reduces the problem (compared to omitting the import and using a > >u() function), but it's still ugly and still involves the "action at a > >distance" of the unicode literals import. > > Frankly, that doesn't bother me at all. I've been using the future import in > all my code pretty successfully for a long while now. It's much more > important for a project to use or not use the future import consistently, and > then there really should be no confusion when looking at the code for that > project.
That's completely reasonable in a highly controlled project with relatively few highly-bought-in contributors. In projects with lots of hit-and-run contributors, though, it's more desirable to have things meet a rule of least surprise. Much of the software I work on is Python 3 compatible, but it's still used primarily on Python 2. Because most people still care primarily about Python 2, and most don't have a lot of Python 3 experience, it's extremely common to see folks submitting patches with u'' literals in them. > I'm not necessarily saying I'm opposed to the purpose of the PEP. I do think > it's unnecessary for most Python problem domains, but can appreciate that WSGI > apps are feeling a special pain here that should be addressed somehow. It > would be nice however if the solution were in the form of a separate module > that could be used in earlier Python versions. If we use the unicode_literals future import, or some other exernal module strategy, it doesn't help much with the hitnrun contributor thing, I fear. - C _______________________________________________ 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
