5 ms·

this is great news, but will it be backported? i had to jump through hoops to support 2+3 in a single code base because of this (in case people don't understan

this is great news, but will it be backported? i had to jump through hoops to support 2+3 in a single code base because of this (in case people don't understand u"abc" is a syntax error in python 3.0-2, which makes writing portable code that uses unicode tricky, since that's what it a unicode literal looks like in python 2). if it's not backported to 3.0-2 then we'll have the strange state of libraries that run on 2 and 3.3, but not inbetween.

kibwen 15y ago
Won't be backported (which would be sort of weird in any case... if you were going to actually go to the trouble of upgrading your copy of 3.2 by a minor version, you might as well just upgrade to 3.3), but they do address this in the PEP: There are many existing Python communities that are prepared to put up with the constraints imposed by the existing suite of porting tools, or to update their Python 2 code bases sufficiently that the problems are minimised. This PEP is not for those communities. Instead, it is designed specifically to help people that don't want to put up with those difficulties. However, since the proposal is for a comparatively small tweak to the language syntax with no semantic changes, it is feasible to support it as a third party import hook. While such an import hook imposes some import time overhead, and requires additional steps from each application that needs it to get the hook in place, it allows applications that target Python 3.2 to use libraries and frameworks that would otherwise only run on Python 3.3+ due to their use of unicode literal prefixes. One such import hook project is Vinay Sajip's uprefix [4]. For those that prefer to translate their code in advance rather than converting on the fly at import time, Armin Ronacher is working on a hook that runs at install time rather than during import [5]. Combining the two approaches is of course also possible. For example, the import hook could be used for rapid edit-test cycles during local development, but the install hook for continuous integration tasks and deployment on Python 3.2. The approaches described in this section may prove useful, for example, for applications that wish to target Python 3 on the Ubuntu 12.04 LTS release, which will ship with Python 2.7 and 3.2 as officially supported Python versions.
- maaku 15y ago
  It's not so simple. As mentioned in the last paragraph, for example, Ubuntu LTS will release with Python 3.2. Backporting this feature to 3.2 will make it available to (updated and patched) Ubuntu LTS installs. NOT backporting this PEP could result in further delays in Python 3 adoption as people wait for Ubuntu 14.04 LTS.
  - kibwen 15y ago
    A good point. I do wonder what proportion of Ubuntu users take advantage of the LTS releases rather than, say, just outright using Debian. I also intuitively want to say that anyone deciding to go with a LTS release would, if given the choice between a 2.7 library and a 3.2 library, choose the more "mature" option anyway. I agree that it would have been smart to backport such a seemingly small and unobtrusive change to 3.2 (and who knows, maybe they still will).
    - kibwen 15y ago
      Actually, no, after contemplation I realize that it would be much worse to split the compatibility of 3.2 and force library authors to qualify their compatibility targets by the minor version. After all, if the hypothetical 3.2.new didn't require any porting effort to support 3.3-style unicode literals, then library authors would have even less incentive to port their libraries to 3.2.old for all the people who can't upgrade, or won't upgrade, or who don't realize that their version doesn't feature a critical language addition.
      - deleted 15y ago
        [deleted]
      - andrewcooke 15y ago
        in my experience, people (and distros) will update minor versions in mid-life patches/updates. so backporting gets this fix to "legacy" installs, where a new python version is not acceptable (i have clients with python 2.5 - 5 years from now the same kinds of people will be stuck on 3.1). and i'm not sure why comparing three digits rather than two is so much more difficult. can you expand on your logic there?

kibwen 15y ago

Won't be backported (which would be sort of weird in any case... if you were going to actually go to the trouble of upgrading your copy of 3.2 by a minor version, you might as well just upgrade to 3.3), but they do address this in the PEP: There are many existing Python communities that are prepared to put up with the constraints imposed by the existing suite of porting tools, or to update their Python 2 code bases sufficiently that the problems are minimised. This PEP is not for those communities. Instead, it is designed specifically to help people that don't want to put up with those difficulties. However, since the proposal is for a comparatively small tweak to the language syntax with no semantic changes, it is feasible to support it as a third party import hook. While such an import hook imposes some import time overhead, and requires additional steps from each application that needs it to get the hook in place, it allows applications that target Python 3.2 to use libraries and frameworks that would otherwise only run on Python 3.3+ due to their use of unicode literal prefixes. One such import hook project is Vinay Sajip's uprefix [4]. For those that prefer to translate their code in advance rather than converting on the fly at import time, Armin Ronacher is working on a hook that runs at install time rather than during import [5]. Combining the two approaches is of course also possible. For example, the import hook could be used for rapid edit-test cycles during local development, but the install hook for continuous integration tasks and deployment on Python 3.2. The approaches described in this section may prove useful, for example, for applications that wish to target Python 3 on the Ubuntu 12.04 LTS release, which will ship with Python 2.7 and 3.2 as officially supported Python versions.

maaku 15y ago
It's not so simple. As mentioned in the last paragraph, for example, Ubuntu LTS will release with Python 3.2. Backporting this feature to 3.2 will make it available to (updated and patched) Ubuntu LTS installs. NOT backporting this PEP could result in further delays in Python 3 adoption as people wait for Ubuntu 14.04 LTS.
- kibwen 15y ago
  A good point. I do wonder what proportion of Ubuntu users take advantage of the LTS releases rather than, say, just outright using Debian. I also intuitively want to say that anyone deciding to go with a LTS release would, if given the choice between a 2.7 library and a 3.2 library, choose the more "mature" option anyway. I agree that it would have been smart to backport such a seemingly small and unobtrusive change to 3.2 (and who knows, maybe they still will).
  - kibwen 15y ago
    Actually, no, after contemplation I realize that it would be much worse to split the compatibility of 3.2 and force library authors to qualify their compatibility targets by the minor version. After all, if the hypothetical 3.2.new didn't require any porting effort to support 3.3-style unicode literals, then library authors would have even less incentive to port their libraries to 3.2.old for all the people who can't upgrade, or won't upgrade, or who don't realize that their version doesn't feature a critical language addition.
    - deleted 15y ago
      [deleted]
    - andrewcooke 15y ago
      in my experience, people (and distros) will update minor versions in mid-life patches/updates. so backporting gets this fix to "legacy" installs, where a new python version is not acceptable (i have clients with python 2.5 - 5 years from now the same kinds of people will be stuck on 3.1). and i'm not sure why comparing three digits rather than two is so much more difficult. can you expand on your logic there?