[quoting Armin from Reddit]
"Because in all honesty, because string wrappers make a codebase horrible to
work with. I will have to continue maintaining 2.x versions for at least another
four or five years. The idea if having to use string wrappers for that long
makes me puke."
Reading this led me to think the following:
* 2.5 is now available basically everywhere, and it was released
almost 5 years ago (Sep 2006);
* if it takes the same time for 3.3, it will be widespread after 4-5
years (i.e. 2016-2017) [0];
* if you want to target a Python 3 version that is widespread [1], you
will want to support 3.1/3.2 too in the meanwhile;
* therefore you will have to use the hook on 3.1/3.2;
* in 2016-2017 you'll finally be able to drop 3.1/3.2 and use only 3.3
without hooks;
* in 2016-2017 you'll also stop maintaining the 2.x version (according
to that quote);
* if you are not maintaining 2.x anymore, you won't need u'' -- right
when you could finally stop using the hook;
Now, if the hook doesn't get in the way (AFAIU you just have to
"install" it and it will do its work automatically), wouldn't it be
better to use it in 3.3 too (especially considering that you will
probably have to use it already for 3.1/3.2)?
If my reasoning is correct, by the time you will be able to use u
without problems you will have to start phasing it out because you won't
need to support 2.x anymore.
Is this hook available somewhere? How difficult is the installation?
Does it strip the u automatically or is there a further step that
developers should do before testing on 3.1/3.2?
Best Regards,
Ezio Melotti
[0]: ISTM that people think "once you decide to switch to 3.x, there's
really no reason to pick an older release, just pick the latest (3.3)".
While this might be true for single developers that install it by hand,
I don't think it's the same for distros and I expect for 3.x the same
time span between release and widespread availability that we have with
2.x (i.e. 4-5 years). However this is just an assumption, if you have
more accurate information that can show that the time span will indeed
be shorter for 3.x (e.g. 2-3 year), feel free to prove me wrong.
[1]: I think most projects still support 2.5, some support even older
versions, some support only newer ones, but 2.5 as minimum support
version seems a good average to me. Targeting the same use base seems
reasonable to me (albeit not strictly necessary).
I know that this was just a comment on Reddit and was not in the PEP, but it
smacks of you throwing all your toys out of the pram. It certainly wasn't a
reasoned response to my point. And some of that toys-pram attitude bleeds
through into the language of the PEP, leading others to make the criticisms that
they have. A PEP is supposed to be balanced, reasonable and thought through.
It's not supposed to gloss over things in a hand-wavy sort of way - there's
still uncertainty in my mind, for example, whether the 3.2 hook will be a
2to3-style tool that runs over a chunk of the whole project's codebase between
editing and running a test, or whether it's an import-time hook which only kicks
in on files that have just been edited in a development session. Which of these
it is might affect crucially the experience of someone wanting to support 3.2
and 3.3 and 2.6+ - but that clearly isn't you, and you don't seem to have much
sympathy or patience with that constituency - we're all stick-in-the-muds who
want to work with Ubuntu LTS, rather than people subject to constraints imposed
by employers, clients, projects we depend on etc.
In contrast, Nick made a more reasonable case when commenting ion my preference
for unicode_literals (on this list, not on Reddit), by reminding me about how
unicode_literals changes the semantics of string literals, and this increases
the cognitive burden on developers.
I'm not whinging about the PEP in this post - I've said elsewhere that I wasn't
opposed to it. I'm just trying to respond to your apparent bewilderment at some
of the reaction to the PEP.
I have confidence that with your continued input and Nick's input, the wording
of the PEP can be made such that it doesn't ruffle quite so many feathers. I'm
looking forward to seeing the updates.
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/ezio.melotti%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
