Vinay, Thank you for the comprehensive summary. Big +1. I really do hope that Nick and Armin will rectify the PEP. Otherwise, many of its points are moot, and we need to raise a question of rejecting it somehow.
On 2012-03-01, at 2:00 PM, Vinay Sajip wrote: > Guido van Rossum <guido <at> python.org> writes: > >> I noticed there were some complaints about unnecessarily offensive >> language in PEP 414. Have those passages been edited to everyone's >> satisfaction? > > I'm not sure if Nick has finished his updates, but I for one would like to see > some improvements in a few places: > > "Many thought that the unicode_literals future import might make a common > source > possible, but it turns out that it's doing more harm than good." > > Rather than talking about it doing more harm than good, it would be better to > say that unicode_literals is not the best solution in some scenarios > (specifically, WSGI, but any other scenarios can also be mentioned). The "more > harm than good" is not true in all scenarios, but as it's worded now, it seems > like it is always a bad approach. > > "(either by having a u function that marks things as unicode without future > imports or the inverse by having a n function that marks strings as native). > Unfortunately, this has the side effect of slowing down the runtime > performance > of Python and makes for less beautiful code." > > The use of u() and n() are not equivalent in the sense that n() only has to be > used when unicode_literals are in effect, and the incidence of n() calls in an > application would be much lower than using u() in the absence of > unicode_literals. In at least some cases, it is possible that some of the APIs > which fail unless native strings are provided may be broken (e.g. some > database > adapters expect datetimes in ISO format as native strings, where there is no > apparent reason why they couldn't accept them as text). > > As far as "less beautiful" code is concerned, it's subjective: I see nothing > especially ugly about 'xxx' for text, and certainly don't find u'xxx' "more" > beautiful - and I doubt if I'm the only person with that view. The point about > the added cognitive burden of semantic-changing __future__ imports is, > however, > quite valid. > > "As it stands, when chosing between 2.7 and Python 3.2, Python 3 is currently > not the best choice for certain long-term investments, since the ecosystem is > not yet properly developed, and libraries are still fighting with their API > decisions for Python 3." > > This looks to become a self-fulfilling prophecy, if you take it seriously. You > would expect that, if Python 3 is the future of Python, then Python 3 is > *precisely* the choice for *long*-term investments. The ecosystem is not yet > fully developed, true: but that is because some people aren't ready to grasp > the > nettle and undergo the short-term pain required to get things in order. By > "things", I mean places in existing 2.x code where no distinction was made > between bytes and text, which you could get away with because of 2.x's > forgiving > nature. Whether you're using unicode_literals and 'xxx' or u'xxx', these > things > will need to be sorted out, and the syntax element is only one possible focus. > > If that entire sentence is removed, it does the PEP no harm, and the PEP will > antagonise fewer people. > > "A valid point is that this would encourage people to become dependent on > Python > 3.3 for their ports. Fortunately that is not a big problem since that could be > fixed at installation time similar to how many projects are currently invoking > 2to3 as part of their installation process." > > Yes, but avoiding the very pain of running 2to3 is what (at least in part) > motivates the PEP in the first place. This appears to be moving the pain that > 2.x developers feel when trying to move to 3.x, to people who want to support > 3.2 and 3.3 and 2.6+ in the same codebase. > > "For Python 3.1 and Python 3.2 (even 3.0 if necessary) a simple > on-installation > hook could be provided that tokenizes all source files and strips away the > otherwise unnecessary u prefix at installation time." > > There's some confusion about this hook - The PEP calls it an on-installation > hook (like 2to3) but Nick said it was an import-time hook. I'm more > comfortable > with the latter - it has a chance of providing an acceptable performance for a > large codebase, as it will only kick in when .py files are newer than their > .pyc. A 2to3 like hook, when working with a large codebase like Django, is > likely to be about as painful as people are finding 2to3 now (when used in an > edit-test-edit-test workflow). > > "Possible Downsides" does not mention any possible adverse impact on single > codebase for 3.2/3.3, which I mention only because it's still not clear how > the > hook which is to make 3.2 development easier will work (in terms of its impact > on development workflow). > > In the section on "Modernizing code", > > "but to make strings cheap for both 2.x and 3.x it is nearly impossible. The > way > it currently works is by abusing the unicode-escape codec on Python 2.x native > strings." > > IIUC, the unicode-escape codec is only needed if you don't use > unicode_literals > - am I wrong about that? How are strings not equally cheap (near enough) on > 2.x > and 3.x if you use unicode_literals? > > In the "Runtime overhead of wrappers", the times may be valid, but a rider > should be added to the effect that in a realistic workload, the wrapper > overhead > will be somewhat diluted where wrapper calls are fairly infrequent (i.e. the > unicode_literals and n() case). > > Of course, if the PEP is targeting Python 2.5 and earlier where > unicode_literals > is not available, then it should say so. I would say that the overall > impression > given by the PEP is that "the unicode_literals approach is not worth bothering > with", and that I do not find to be true based on my own experience. > > Regards, > > Vinay Sajip > > _______________________________________________ > 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/yselivanov.ml%40gmail.com _______________________________________________ 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
