Re: Martijn Faassen: The Call of Python 2.8
On Wed, Apr 16, 2014 at 12:51 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Converting print spam to print(spam) is the trivial part of it. The biggest change between Python 2.x and 3.x is the bytes to Unicode shift, and that is *not trivial*. Python 2.x tries very hard to make bytes and strings interoperate even when doing so is the wrong thing to do. So there is a lot of Python 2 code that is *broken* with respect to strings, but *seems okay* so long as you only test it using pure ASCII. Python 3 no longer tries to hide the difference, it forces you to confront the fact that bytes and strings are not the same. To people raised on ASCII- only programming standards, that's a huge paradigm shift, and a confusing one. There's a lot to learn, a lot of pain if you don't learn it, and there can be a lot of effort needed to migrate string code to Python 3. Has anyone ever had the same oh great, now I have to push everyone through a paradigm shift feeling about anything else? The only one I can think of is shifting my whole family off Windows file sharing (just accessing files everywhere) onto wholesale use of source control (have a local copy, and push your changes). (Depending on what your code actually does. It is remarkable just how much string code you can write that works identically in 2.x and 3.x. Basic string handling remains basic in both.) With PEP 461 (slated for 3.5), that's going to get even easier. Not only will a simple double-quoted string do the right thing on both platforms, but both bbinary and uunicode will support the same percent-formatting as well. But you do have to limit your definition of 2.x; a lot of that commonality is the result of deliberate design, and NOT just oh hey look it works, which means that 2.4 and 3.4 are very different. I respect and do not envy those who have to support both RHEL and Arch... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Wed, Apr 16, 2014 at 12:52 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I'm actually asking a serious question. How does a distro actively hide something publicly available on the Internet? Note that, on Linux (when you talk about distributions, you probably don't mean OS X or Windows) all the compiler tools needed to install from source are readily available, so anyone who wants to install a Python version not supported by their distro can do so. Many people don't wish to install anything outside of their distro's supported packages, but that's their choice, not the distro imposing anything on them. I'd say it's not so much actively hide as just abandon people to their own devices. It's all very well to say well hey, just go and compile it from source; this assumes two things: 1) The available source code will compile on your platform 2) The user knows how to compile code. The first is true of the platforms supported by python.org, but that's not the OS/distribution helping you to get Python - that's Python helping you to get Python. The second... that's where things like apt-get build-dep come in, but mainly there's a general understanding among end users that compiling code is haaard. Some cultures have this more strongly than others... sometimes for good reason. (I had stupid amounts of trouble trying to get a C compiler going on OS X. A non-programmer, doing the same job, might well give up, and I wouldn't argue.) Compiling from source without a package manager fetching all the appropriate libraries means an iterative process of compile or build, see what the error is, figure out what's missing, fetch it, GOTO 10. For me, that's life; that's something I've done on a number of different systems, and I know lots of the clues and/or the tools for figuring things out. For many non-programmers, though, if there's no binary package, they won't use the software. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
It is more than clear to me, Python did and does not understand the unicode case. jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 2014.04.15 20:21, Steven D'Aprano wrote: On Tue, 15 Apr 2014 17:32:57 -0500, Andrew Berg wrote: On 2014.04.15 17:18, Ned Batchelder wrote: Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. Or maybe explicit is better than implicit: # python zsh: command not found: python # which python2.7 /usr/local/bin/python2.7 # which python3.4 /usr/local/bin/python3.4 If you really meant that, you would have typed /usr/bin/which2.16 python (or whatever the location and version of which on your system). Are you sure about that? # which which which: shell built-in command Unless I'm forgetting some more explicit way of calling a command built into the shell. -- CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0 -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Wed, Apr 16, 2014 at 5:32 PM, Andrew Berg aberg...@my.hennepintech.edu wrote: If you really meant that, you would have typed /usr/bin/which2.16 python (or whatever the location and version of which on your system). Are you sure about that? # which which which: shell built-in command Unless I'm forgetting some more explicit way of calling a command built into the shell. Hmm, interesting. That's not the case for me: rosuav@sikorsky:~$ which which /usr/bin/which Debian Wheezy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Wednesday, April 16, 2014 1:02:00 PM UTC+5:30, Andrew Berg wrote: On 2014.04.15 20:21, Steven D'Aprano wrote: On Tue, 15 Apr 2014 17:32:57 -0500, Andrew Berg wrote: On 2014.04.15 17:18, Ned Batchelder wrote: Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. Or maybe explicit is better than implicit: # python zsh: command not found: python # which python2.7 /usr/local/bin/python2.7 # which python3.4 /usr/local/bin/python3.4 If you really meant that, you would have typed /usr/bin/which2.16 python (or whatever the location and version of which on your system). Are you sure about that? # which which which: shell built-in command Unless I'm forgetting some more explicit way of calling a command built into the shell. Not out here: $ which which /usr/bin/which $ ls -l /usr/bin/which lrwxrwxrwx 1 root root 10 Jul 28 2013 /usr/bin/which - /bin/which Though there is no evidence of which-versionitis which is what Steven is implying?? -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Wed, 16 Apr 2014 02:32:00 -0500, Andrew Berg wrote: On 2014.04.15 20:21, Steven D'Aprano wrote: On Tue, 15 Apr 2014 17:32:57 -0500, Andrew Berg wrote: On 2014.04.15 17:18, Ned Batchelder wrote: Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. Or maybe explicit is better than implicit: # python zsh: command not found: python # which python2.7 /usr/local/bin/python2.7 # which python3.4 /usr/local/bin/python3.4 If you really meant that, you would have typed /usr/bin/which2.16 python (or whatever the location and version of which on your system). Are you sure about that? # which which which: shell built-in command Unless I'm forgetting some more explicit way of calling a command built into the shell. I've tried it on two different systems: steve@runes:~$ which which /usr/bin/which although I see you are running as root: steve@runes:~$ su - Password: root@runes:~# which which /usr/bin/which Nope, that makes no difference. In any case, you're missing my point, which is not *where* the which binary lives, but the fact that you're calling some specific version, located in some specific place (even if that place is a virtual place inside the shell) implicitly rather than explicitly. Which is usually (but not always!) what we want for an interactive shell. Who wants to be typing out explicit paths to versioned binaries *all the time*? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 2014.04.16 03:02, Chris Angelico wrote: Hmm, interesting. That's not the case for me: rosuav@sikorsky:~$ which which /usr/bin/which That's because bash either does not have a builtin which or it is not enabled by default. I switched to zsh a while ago. I do still, of course, have a system which, which is at /usr/bin/which, and which is the which that a shell which does not have a builtin which will use. -- CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0 -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
Terry Reedy tjre...@udel.edu writes: The 'mistake' is your OS, whatever it is, not providing 3.3. It is already so old that it is off bugfix maintenance. Any decent system should have 3.4 available now. I think you mean “… should have Python 3.3 available now”, yes? -- \ “I wish there was a knob on the TV to turn up the intelligence. | `\ There's a knob called ‘brightness’ but it doesn't work.” | _o__) —Eugene P. Gallagher | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
Le lundi 14 avril 2014 20:59:37 UTC+2, Ian a écrit : On Apr 14, 2014 11:46 AM, wxjm...@gmail.com wrote: Point of curiosity: if the first 256 codepoints of Unicode happened to correspond to cp1252 instead of Latin-1, would you still object to the FSR? Yes. --- cp1252: I'm perfectly understanding, plenty of people are very happy with that coding scheme. -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/2014 1:03 AM, Marko Rauhamaa wrote: Terry Reedy tjre...@udel.edu: Any decent system should have 3.4 available now. Really, now? Which system is that? 3.4.0 was released a month ago with Windows and Mac installers and source for everything else. I know Ubuntu was testing the release candidate so I presume it is or will very soon have 3.4 officially available. Since there was a six month series of alpha, beta, and candidate releases, with an approximate final release data, any distribution that wanted to be up to date also could be. This is all quite aside from the fact that one should be able to unpack a tarball and 'make xxx'. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/2014 2:08 AM, Ben Finney wrote: Terry Reedy tjre...@udel.edu writes: The 'mistake' is your OS, whatever it is, not providing 3.3. It is already so old that it is off bugfix maintenance. Any decent system should have 3.4 available now. I think you mean “… should have Python 3.3 available now”, yes? ??? why would you think that??? My installed 3.4.0 for Windows is dated March 16. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tue, Apr 15, 2014 at 6:33 PM, Terry Reedy tjre...@udel.edu wrote: On 4/15/2014 2:08 AM, Ben Finney wrote: Terry Reedy tjre...@udel.edu writes: The 'mistake' is your OS, whatever it is, not providing 3.3. It is already so old that it is off bugfix maintenance. Any decent system should have 3.4 available now. I think you mean “… should have Python 3.3 available now”, yes? ??? why would you think that??? My installed 3.4.0 for Windows is dated March 16. Debian's current stable (Wheezy) was released 2013/05/04, and the latest version release of it (7.4) was 2014/02/08. Both those dates precede 2014/03/16, so you don't get 3.4 in Wheezy. (Actually, you don't even get 3.3, presumably because its launch date of 2012/09/29 missed the Wheezy feature freeze in mid-2012.) Debian Jessie (current testing) ships 3.3 and 3.4, with the 'python3' package giving you 3.3. Stable OSes won't necessarily be jumping onto 3.4 instantly upon availability. Debian Squeeze (oldstable, still supported) doesn't even ship 3.2, all you get is 3.1.3. If you want Arch Linux, you know where to find it :) And of course, that very stability is what makes it easy to just apt-get build-dep python3 and spin up one from source, possibly even a 3.5-with-except-expressions for the purpose of testing :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tue, 15 Apr 2014 04:33:24 -0400, Terry Reedy wrote: On 4/15/2014 2:08 AM, Ben Finney wrote: Terry Reedy tjre...@udel.edu writes: The 'mistake' is your OS, whatever it is, not providing 3.3. It is already so old that it is off bugfix maintenance. Any decent system should have 3.4 available now. I think you mean “… should have Python 3.3 available now”, yes? ??? why would you think that??? My installed 3.4.0 for Windows is dated March 16. Was it provided by Microsoft as part of the OS? Terry, while enthusiasm for the latest and greatest version of Python is a good thing, stability is also a good thing. Not everyone has the luxury of being able to jump on the upgrade treadmill and stay on it. If I recall correctly, Python 2.6 has just received its last security update from Python, but it will continue to receive them from Red Hat for a few more years. (Python 2.4 is still receiving security updates from Red Hat, and 2.7 will be receiving them until 2024.) That stability is very valuable to some people -- that's why people use (e.g.) Debian, with its promises of multi-year stability, instead of Ubuntu, which goes through major version changes three times a week (or so sometimes it seems...) That failure to support 3.4 in the OS-provided system is not a mistake, it is a feature. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
Terry Reedy tjre...@udel.edu writes: 3.4.0 was released a month ago with Windows and Mac installers and source for everything else. I know Ubuntu was testing the release candidate so I presume it is or will very soon have 3.4 officially available. Since there was a six month series of alpha, beta, and candidate releases, with an approximate final release data, any distribution that wanted to be up to date also could be. Those assertions assume that: * operating systems have stable releases every few months; and * they have a zero-length process to get a stable release of Python into the stable OS release; and * the user is always running the latest stable OS version immediately after its release. When, in reality, the OS team will need quite a long time to ensure the stable Python release works smoothly with all of the rest of the OS; the stable release will come some number of months after that assurance process is complete; and the user will upgrade some wildly varying time after the stable OS release is complete. That reality means “any decent OS will have Python 3.4 today” rather bold, only a month after its release, and eliminates just about all OSen from “decent” category. On the other hand, you might have meant “Python 3.4 is available *for* any decent OS today”; this is a very different thing from the OS having that version of Python. -- \ “We can't depend for the long run on distinguishing one | `\ bitstream from another in order to figure out which rules | _o__) apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
- Original Message - From: Terry Reedy tjre...@udel.edu To: python-list@python.org Cc: Sent: Tuesday, April 15, 2014 10:32 AM Subject: Re: Martijn Faassen: The Call of Python 2.8 On 4/15/2014 1:03 AM, Marko Rauhamaa wrote: Terry Reedy tjre...@udel.edu: Any decent system should have 3.4 available now. Really, now? Which system is that? 3.4.0 was released a month ago with Windows and Mac installers and source for everything else. I know Ubuntu was testing the release candidate so I presume it is or will very soon have 3.4 officially available. Since there was a six month series of alpha, beta, and candidate releases, with an approximate final release data, any distribution that wanted to be up to date also could be. This is all quite aside from the fact that one should be able to unpack a tarball and 'make xxx'. True, but in Debian Linux (so probably also Linux) one needs to install some zlib packages and some other stuff (https related IIRC) before compiling Python (at least with 3.3). So glad that pip (and setuptools too?) is part of the standard library in Python 3.4 (the zlib error became apparent when installing pip) Albert-Jan -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/14/14 2:32 PM, Phil Dobbin wrote: On a related note, Guido announced today that there will be no 2.8 that the eol for 2.7 will be 2020. Can you site the announcement? Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/2014 1:21 PM, Albert-Jan Roskam wrote: This is all quite aside from the fact that one should be able to unpack a tarball and 'make xxx'. True, but in Debian Linux (so probably also Linux) one needs to install some zlib packages and some other stuff (https related IIRC) before compiling Python (at least with 3.3). On windows, I can compile Python without the 3rd party dependencies installed. (They are also mostly installed by one .bat file.) The compiler will report errors for what is missing, and the corresponding imports (like 'import zlib') from the missing dlls will fail, but python.exe is built and otherwise runs fine. Are things different on *nix -- all or nothing? In any case, once the dependencies are installed, they should still be there if one upgrades with patch release. So glad that pip (and setuptools too?) is part of the standard library in Python 3.4 (the zlib error became apparent when installing pip) -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/2014 7:33 AM, Ben Finney wrote: Terry Reedy tjre...@udel.edu writes: 3.4.0 was released a month ago with Windows and Mac installers and source for everything else. I know Ubuntu was testing the release candidate so I presume it is or will very soon have 3.4 officially available. Since there was a six month series of alpha, beta, and candidate releases, with an approximate final release data, any distribution that wanted to be up to date also could be. Those assertions assume that: * operating systems have stable releases every few months; and * they have a zero-length process to get a stable release of Python into the stable OS release; and * the user is always running the latest stable OS version immediately after its release. No, I was not talking about replacing the system python. Only about having a .rpm or .deb or whatever available to make an alternate install. My comments are a response to someone saying he could not use Python3 because his system only had ancient 3.2 available and he needed to use a module that requires 3.3. If he was telling the truth, this strikes me as ridiculous. When, in reality, the OS team will need quite a long time to ensure the stable Python release works smoothly with all of the rest of the OS; For a standalone non-system install, I cannot imagine what you are talking about. CPython is primarily developed on Linux. It is continuous tested on multiple buildbots that include several *nix and in particular linux distributions (https://www.python.org/dev/buildbot/). I believe it more stable on linux than anything else, certainly more than on Windows. CPython x.y.0 is released after a month of candidate testing. When it is released, it definitely works on multiple linux distributions, or it would not be released. I believe distutils has options to create some package manager bundles (.rpm, .deb?, ???) and that we once hosted such on the site on day 1, along with a windows binary. I believe we no longer do because linux distributions proliferated and said that they would rather host python bundles in their own package manager systems. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/2014 2:32 PM, Mark H Harris wrote: On 4/14/14 2:32 PM, Phil Dobbin wrote: On a related note, Guido announced today that there will be no 2.8 that the eol for 2.7 will be 2020. Can you site the announcement? It is part of a thread on pydev list. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tuesday, April 15, 2014 12:32:14 PM UTC-6, Mark H. Harris wrote: On 4/14/14 2:32 PM, Phil Dobbin wrote: On a related note, Guido announced today that there will be no 2.8 that the eol for 2.7 will be 2020. Can you site the announcement? Thanks http://hg.python.org/peps/rev/76d43e52d978?utm_content=buffer55d59utm_medium=socialutm_source=facebook.comutm_campaign=buffer -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/14 2:37 PM, Novocastrian_Nomad wrote: On Tuesday, April 15, 2014 12:32:14 PM UTC-6, Mark H. Harris wrote: Can you site the announcement? Thanks http://hg.python.org/peps/rev/76d43e52d978?utm_content=buffer55d59utm_medium=socialutm_source=facebook.comutm_campaign=buffer Thanks, guys. I am noticing the call to 2.8 from time to time (blogs). All along I have been seeing the reluctance to migrate to 3.x as either stubborn or lazy; or both. I don't think so any longer. Seems like the reluctance to migrate stems from dependencies. Is there a list of primary dependencies ? As an example: Is 'twisted' a dependency? ie., twisted does not support 3.x consequently 'I' can't port my stuff to 3.x because 'twisted' isn't there yer. There are others, gevent, maybe. Has anyone taken an inventory of dependencies that must support 3.x before other code(s) can be ported? Maybe there could be an on-line questionnaire regarding perceived dependencies? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/2014 5:05 AM, Chris Angelico wrote: On Tue, Apr 15, 2014 at 6:33 PM, Terry Reedy tjre...@udel.edu wrote: On 4/15/2014 2:08 AM, Ben Finney wrote: Terry Reedy tjre...@udel.edu writes: The 'mistake' is your OS, whatever it is, not providing 3.3. It is already so old that it is off bugfix maintenance. Any decent system should have 3.4 available now. I think you mean “… should have Python 3.3 available now”, yes? ??? why would you think that??? My installed 3.4.0 for Windows is dated March 16. Debian's current stable (Wheezy) was released 2013/05/04, and the latest version release of it (7.4) was 2014/02/08. Both those dates precede 2014/03/16, so you don't get 3.4 in Wheezy. (Actually, you don't even get 3.3, presumably because its launch date of 2012/09/29 missed the Wheezy feature freeze in mid-2012.) Debian Jessie (current testing) ships 3.3 and 3.4, with the 'python3' package giving you 3.3. There are three things a distribution can do with a new Python version: 1. Push it on people. 2. Allow people who need it to easily get it. 3. Actively hide it and discourage its use. I happen to think 2) is generally the right answer. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/2014 3:54 PM, Mark H Harris wrote: I don't think so any longer. Seems like the reluctance to migrate stems from dependencies. Is there a list of primary dependencies ? https://python3wos.appspot.com/ -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/14 3:54 PM, Mark H Harris wrote: On 4/15/14 2:37 PM, Novocastrian_Nomad wrote: On Tuesday, April 15, 2014 12:32:14 PM UTC-6, Mark H. Harris wrote: Can you site the announcement? Thanks http://hg.python.org/peps/rev/76d43e52d978?utm_content=buffer55d59utm_medium=socialutm_source=facebook.comutm_campaign=buffer Thanks, guys. I am noticing the call to 2.8 from time to time (blogs). All along I have been seeing the reluctance to migrate to 3.x as either stubborn or lazy; or both. I don't think so any longer. Seems like the reluctance to migrate stems from dependencies. Is there a list of primary dependencies ? As an example: Is 'twisted' a dependency? ie., twisted does not support 3.x consequently 'I' can't port my stuff to 3.x because 'twisted' isn't there yer. There are others, gevent, maybe. Has anyone taken an inventory of dependencies that must support 3.x before other code(s) can be ported? Maybe there could be an on-line questionnaire regarding perceived dependencies? The Python Wall-Of-Shame/Wall-Of-Superpowers shows popular packages, and their Python 3 status: http://python3wos.appspot.com/ marcus -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 15 April 2014 06:03, Marko Rauhamaa ma...@pacujo.net wrote: Terry Reedy tjre...@udel.edu: Any decent system should have 3.4 available now. Really, now? Which system is that? Arch is on 3.4 *default*. $ python Python 3.4.0 (default, Mar 17 2014, 23:20:09) [...] -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/14 5:34 PM, Joshua Landau wrote: On 15 April 2014 06:03, Marko Rauhamaa ma...@pacujo.net wrote: Terry Reedy tjre...@udel.edu: Any decent system should have 3.4 available now. Really, now? Which system is that? Arch is on 3.4 *default*. $ python Python 3.4.0 (default, Mar 17 2014, 23:20:09) [...] Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/14 4:02 PM, Terry Reedy wrote: https://python3wos.appspot.com/ That's what I thought. Its really about getting the super-power wall fixed up; everything else will fall in place. I do think that Guido might be positioning himself as an enabler, of sorts. I can see extending through 2015... I think extending support for 2.7 through 2020 is ridiculous. The trouble with the super-power wall is that if Guido extends t much, the super-powers will slack off because the dead-line appears further out than it really is. All I'm saying is a little pressure might be a good thing. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 2014.04.15 16:02, Terry Reedy wrote: https://python3wos.appspot.com/ There seems to be a difference of opinion between this page and the Twisted devs on what the Python 2 only classifier for PyPI means. -- CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0 -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 2014.04.15 17:18, Ned Batchelder wrote: Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. Or maybe explicit is better than implicit: # python zsh: command not found: python # which python2.7 /usr/local/bin/python2.7 # which python3.4 /usr/local/bin/python3.4 -- CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0 -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 15 April 2014 23:18, Ned Batchelder n...@nedbatchelder.com wrote: On 4/15/14 5:34 PM, Joshua Landau wrote: Arch is on 3.4 *default*. $ python Python 3.4.0 (default, Mar 17 2014, 23:20:09) [...] Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. Why? The only things that break are things outside of the official repos, and the vast majority of the user repository works flawlessly. If I get something from the source, I normally run it explicitly (python the_thing) and on the very rare occasion it breaks (when it's 2.x and uses python to mean python2) I can trivially patch or wrap it, and file a bug report. The python = python3 choice of Arch is not what takes up maintenance time, and it's good to prepare developers ahead of time. That's what rolling release is all about: getting the best and preparing the rest. -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/14 7:11 PM, Joshua Landau wrote: On 15 April 2014 23:18, Ned Batchelder n...@nedbatchelder.com wrote: On 4/15/14 5:34 PM, Joshua Landau wrote: Arch is on 3.4 *default*. $ python Python 3.4.0 (default, Mar 17 2014, 23:20:09) [...] Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. Why? The only things that break are things outside of the official repos, and the vast majority of the user repository works flawlessly. If I get something from the source, I normally run it explicitly (python the_thing) and on the very rare occasion it breaks (when it's 2.x and uses python to mean python2) I can trivially patch or wrap it, and file a bug report. The python = python3 choice of Arch is not what takes up maintenance time, and it's good to prepare developers ahead of time. That's what rolling release is all about: getting the best and preparing the rest. The problem is files that use shebang lines: #!/usr/bin/python or: #!/usr/bin/env python If these are Python 2 files, they now don't work. Keep in mind, these might not be files that you have written, they may have been installed as part of another package, or written long ago. For the official statement on python meaning Python 2, and more on why, see PEP 394: 'The python Command on Unix-Like Systems': http://legacy.python.org/dev/peps/pep-0394/ -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tue, Apr 15, 2014 at 4:11 PM, Joshua Landau jos...@landau.ws wrote: On 15 April 2014 23:18, Ned Batchelder n...@nedbatchelder.com wrote: On 4/15/14 5:34 PM, Joshua Landau wrote: Arch is on 3.4 *default*. $ python Python 3.4.0 (default, Mar 17 2014, 23:20:09) [...] Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. Why? The only things that break are things outside of the official repos, Yes. Software included in Arch, and programs installed via distutils, will both work correctly under Arch. However, it breaks any 2.x code that is expected to run without being installed via distutils and doesn't use the python2 executable. Which used to be any 2.x program, since python2 originally didn't even exist in many OSes. It also, at the time of introduction, broke all installed software that wasn't part of Arch itself. I have a few problems with what they did. I don't like how Arch created a situation where it was impossible to support Arch and Debian at the same time with standalone Python 2.x programs (due to a missing python2 and differing python in Debian). I don't like how the migration was not communicated sufficiently clearly to users[*], so that when they saw weird Python errors, they came to the Python community instead of to Arch, overwhelming #python (if not other places) with support requests. (We had to temporarily ban Arch questions to stop people from asking.) I don't like how their new and unusual executable naming scheme forced into existence a PEP [1] to figure out how to bring Python and Debian into line, and I don't like how Debian was forced to do extra work to make life easier for Python 2.x developers and resolve problems that only existed because of what Arch did. They caused a lot of grief, and for what? As far as I can tell, it's was a marketing gimmick -- Arch gets to look cool by being bleeding edge, and everyone else pays the price. It's worth stating clearly: there is actually no technical benefit to changing what the python symlink points to. If we want to do such a thing, it is for cultural reasons, and there is no urgency to it. It can be done over an extremely long period of time. [*] One might also ask why they didn't do a phase where python2 was python 2.x, python3 was python 3.x, and python was 2.x but also gave a warning to upgrade your stuff because the meaning of the symlink was changing. There is no good reason. The stated reason was that warnings are annoying -- so they broke everything instead of giving warnings. [2] [1] http://legacy.python.org/dev/peps/pep-0394/ [2] https://mail.python.org/pipermail/python-dev/2010-November/105299.html -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tue, 15 Apr 2014 18:18:16 -0400, Ned Batchelder wrote: On 4/15/14 5:34 PM, Joshua Landau wrote: On 15 April 2014 06:03, Marko Rauhamaa ma...@pacujo.net wrote: Terry Reedy tjre...@udel.edu: Any decent system should have 3.4 available now. Really, now? Which system is that? Arch is on 3.4 *default*. $ python Python 3.4.0 (default, Mar 17 2014, 23:20:09) [...] Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. That's a matter of opinion :-) But Arch is considered pretty gung-ho in this matter, even by people (like me) who want python to mean the latest version rather than something old and decrepit. I recall jokes back when Arch first moved to Python 3 as their system Python, that Arch was the bleeding-edge Linux distro for those who found Slackware too tame and unadventurous. For the avoidance of doubt: Python 2.7 is not old and decripit. Yet. But some day it will be. When that time comes, I want python to mean Python 3.6 or 3.7 or 4.2, or whatever is the most recent version, not 2.7 or 1.5. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tue, 15 Apr 2014 17:32:57 -0500, Andrew Berg wrote: On 2014.04.15 17:18, Ned Batchelder wrote: Yeah, that's the wrong way to do it, and they shouldn't have done that. python needs to mean Python 2.x for a long time. Or maybe explicit is better than implicit: # python zsh: command not found: python # which python2.7 /usr/local/bin/python2.7 # which python3.4 /usr/local/bin/python3.4 If you really meant that, you would have typed /usr/bin/which2.16 python (or whatever the location and version of which on your system). -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 16 April 2014 01:42, Devin Jeanpierre jeanpierr...@gmail.com wrote: Yes. Software included in Arch, and programs installed via distutils, will both work correctly under Arch. [...] I don't like how Arch created a situation where it was impossible to support Arch and Debian at the same time with standalone Python 2.x programs (due to a missing python2 and differing python in Debian). Let the developers aim at Debian and other mainstream distros and Arch will clean it up for its own use. Isn't that how it normally works? This did, however, quickly result in python2 symlinks, which I think is extremely good in the long run to have ingrained in people's habits. I don't like how the migration was not communicated sufficiently clearly to users[*], so that when they saw weird Python errors, they came to the Python community instead of to Arch That's not expected Arch user behaviour ;). I don't like how their new and unusual executable naming scheme forced into existence a PEP [1] to figure out how to bring Python and Debian into line, and I don't like how Debian was forced to do extra work to make life easier for Python 2.x developers and resolve problems that only existed because of what Arch did. I don't agree entirely. Arch was early, perhaps earlier than reasonable, but python2 was going to be needed soon anyway, especially since it significantly aids adoption of the version-prepended names. It's worth stating clearly: there is actually no technical benefit to changing what the python symlink points to. If we want to do such a thing, it is for cultural reasons, and there is no urgency to it. It can be done over an extremely long period of time. This is Arch. The fact that it *can* be done over a long period of time falls far behind the cultural reasons in level of importance. [*] One might also ask why they didn't do a phase where python2 was python 2.x, python3 was python 3.x, and python was 2.x but also gave a warning to upgrade your stuff because the meaning of the symlink was changing. There is no good reason. The stated reason was that warnings are annoying -- so they broke everything instead of giving warnings. [2] [2] https://mail.python.org/pipermail/python-dev/2010-November/105299.html Thanks for the read; I found it rather entertaining. Apologies about the #python grief. I disagree with you about the warnings. Arch is made to move fast and this is made abundantly clear: @https://wiki.archlinux.org/index.php/The_Arch_Way This user-centric design necessarily implies a certain do-it-yourself approach to using the Arch distribution. Rather than pursuing assistance or requesting a new feature to be implemented by developers, Arch Linux users have a tendency to solve problems themselves and generously share the results with the community and development team – a do first, then ask philosophy. This is especially true for user-contributed packages found in the Arch User Repository – the official Arch Linux repository for community-maintained packages. If people want to run Arch but don't want the Arch way, then there's not much we can do about it. Arch isn't going to compromise its demographic because a different demographic is also using it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tue, 15 Apr 2014 15:48:06 -0400, Terry Reedy wrote: On 4/15/2014 5:05 AM, Chris Angelico wrote: On Tue, Apr 15, 2014 at 6:33 PM, Terry Reedy tjre...@udel.edu wrote: On 4/15/2014 2:08 AM, Ben Finney wrote: Terry Reedy tjre...@udel.edu writes: The 'mistake' is your OS, whatever it is, not providing 3.3. It is already so old that it is off bugfix maintenance. Any decent system should have 3.4 available now. I think you mean “… should have Python 3.3 available now”, yes? ??? why would you think that??? My installed 3.4.0 for Windows is dated March 16. Debian's current stable (Wheezy) was released 2013/05/04, and the latest version release of it (7.4) was 2014/02/08. Both those dates precede 2014/03/16, so you don't get 3.4 in Wheezy. (Actually, you don't even get 3.3, presumably because its launch date of 2012/09/29 missed the Wheezy feature freeze in mid-2012.) Debian Jessie (current testing) ships 3.3 and 3.4, with the 'python3' package giving you 3.3. There are three things a distribution can do with a new Python version: 1. Push it on people. 2. Allow people who need it to easily get it. 3. Actively hide it and discourage its use. I happen to think 2) is generally the right answer. How would they do #3? Patch all the web browsers to fake a 404 Not Found when you go to the Python website and try to download it? I'm actually asking a serious question. How does a distro actively hide something publicly available on the Internet? Note that, on Linux (when you talk about distributions, you probably don't mean OS X or Windows) all the compiler tools needed to install from source are readily available, so anyone who wants to install a Python version not supported by their distro can do so. Many people don't wish to install anything outside of their distro's supported packages, but that's their choice, not the distro imposing anything on them. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tue, 15 Apr 2014 14:54:53 -0500, Mark H Harris wrote: I am noticing the call to 2.8 from time to time (blogs). All along I have been seeing the reluctance to migrate to 3.x as either stubborn or lazy; or both. Migrating to 3.x can be a fair amount of work. Not as much work as migrating to a new language, you get to keep probably 90-99% of the code, but it's not always easy either. Converting print spam to print(spam) is the trivial part of it. The biggest change between Python 2.x and 3.x is the bytes to Unicode shift, and that is *not trivial*. Python 2.x tries very hard to make bytes and strings interoperate even when doing so is the wrong thing to do. So there is a lot of Python 2 code that is *broken* with respect to strings, but *seems okay* so long as you only test it using pure ASCII. Python 3 no longer tries to hide the difference, it forces you to confront the fact that bytes and strings are not the same. To people raised on ASCII- only programming standards, that's a huge paradigm shift, and a confusing one. There's a lot to learn, a lot of pain if you don't learn it, and there can be a lot of effort needed to migrate string code to Python 3. (Depending on what your code actually does. It is remarkable just how much string code you can write that works identically in 2.x and 3.x. Basic string handling remains basic in both.) The Python ecosystem is a lot bigger than ASCII users, and everyone else had to suffer with Python 2's string handling so ASCII users don't have to do anything special. With Python 3, everyone is in the same boat. If all your data is ASCII, you might be resentful of the need to go to all this trouble for no apparent benefit, and resentful of Python 3 forcing you to deal it. But whether you are glad of the changes or wish it was 1959 and you could forget all about the non-ASCII world[1], there is no doubt that the effort required can be painful. So migrating costs time, and effort, and money. If you have a 100-line script, your experience is likely to be very different from somebody having to migrate a 100,000 line application. People are reluctant to spend that sort of time and money without clear benefit, and for many people, Python 2 is good enough. Apart from Unicode, which many people do not need, appreciate or even want[2], the benefits of Python 3 are incremental, not revolutionary, and the cost/benefit ratio is on the wrong side to justify migration. This is why Python 2.7 has got such extended support, and why the core developers are spending so much effort trying to decrease the cost of migration and increase the benefit. But, ultimately, some people will decide to never migrate their application to 3.x, because the cost will always exceed the benefit. That's okay. That's the great thing about software. So long as you can find hardware that will run Python 2.7, you can keep running 2.7 for ever. Or 2.3, or 1.5. I don't think so any longer. Seems like the reluctance to migrate stems from dependencies. Not anymore. Most -- not all, but the majority -- now support 3.x. Now the reluctance stems from cost/benefit. If it takes four people a month to migrate your application, and you pay them $40 an hour (a relatively low price for software developers, I know some who make in the vicinity of $200 an hour), that's a direct cost of $25K. Plus the indirect cost of stuff that they could have been working on in that time but aren't. Would you pay twenty-five thousand dollars for an upgrade that runs a bit slower but otherwise has no new functionality that you care about? This is why Alex Gaynor calls Python 2.7 the new Cobol. I expect that most, but not all, small and medium sized Python applications will eventually be migrated to 3.x, and new applications of any size will be written in 3.x, but many existing big Python apps will stay on 2.7 forever. [1] The non-ASCII world includes the USA. Even in the US, there are common American-English symbols which cannot be written using pure ASCII, the most obvious being ¢ the cent symbol. [2] Sadly, there are still people who consider Unicode to be unnecessary. Why can't everyone just learn to write in English? Or if they won't, why can't I just ignore them and hope they go away? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Martijn Faassen: The Call of Python 2.8
http://blog.startifact.com/posts/the-call-of-python-28.html so in response to the last line, who *IS* going to do all of the required work? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Mon, Apr 14, 2014 at 10:56 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: http://blog.startifact.com/posts/the-call-of-python-28.html so in response to the last line, who *IS* going to do all of the required work? Only someone for whom it's less work to build Python 2.8 than it is to port their code to Python 3. In other words, some organization with a megantic (that's one step below gigantic, you know [1]) Python codebase, and some (but not heaps of) resources to put into it. Personally, I don't see it happening; very little of the code required will be backportable from Python 3 (in contrast to PEP 466 security patches), so every bit of that work will be for the 2.x line only; and any features added in 2.8 can't be used until you're prepared to drop 2.7 support. That means a fair amount of work *and* you have to drop 2.7 support. If you're going to do that, why not just port your code to 3.x and be done with it? Who has the resources to put hours and hours of dev time into a 2.8? ChrisA [1] Megantic is only +3/+3, but gigantic is 8/8. Look! :) http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=370794 http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=195627 -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
Chris Angelico ros...@gmail.com: If you're going to do that, why not just port your code to 3.x and be done with it? Who has the resources to put hours and hours of dev time into a 2.8? Somewhat related. Only yesterday I ported/reimplemented a software package to python3. On the finish line, I ran into a problem: xlwt only supports 2.6, 2.7 and 3.3. My system has python3.2. So I backtracked to python2.7. So not only do we have a schism between python2 and python3 but there's one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a mistake. Serves me right for being an early adopter. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Mon, Apr 14, 2014 at 11:51 PM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: If you're going to do that, why not just port your code to 3.x and be done with it? Who has the resources to put hours and hours of dev time into a 2.8? Somewhat related. Only yesterday I ported/reimplemented a software package to python3. On the finish line, I ran into a problem: xlwt only supports 2.6, 2.7 and 3.3. My system has python3.2. So I backtracked to python2.7. So not only do we have a schism between python2 and python3 but there's one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a mistake. Serves me right for being an early adopter. So get Python 3.3 for your system, then. It's not that hard. You might need to build it from source (not hard at all), or grab packages from a newer version of Debian/RHEL/etc (also not hard, although there might be additional consequential package requirements). The two should happily coexist. Also, the EOL for Python 3.2 is way *way* nearer than EOL of the 2.x line. If you declare that your package requires 2.6/2.7/3.3 (preferably also support 3.4), so be it. It won't be long before all supported systems can get 3.3+, so that won't be a problem. PEP 414 was useful because we can confidently target a newer 3.3 and expect that people will be able to get there before long. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
Chris Angelico ros...@gmail.com: So get Python 3.3 for your system, then. That'll have to wait till it's time for an OS overhaul. I don't do those every year. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 14/04/2014 14:51, Marko Rauhamaa wrote: Chris Angelico ros...@gmail.com: If you're going to do that, why not just port your code to 3.x and be done with it? Who has the resources to put hours and hours of dev time into a 2.8? The people who haven't had enough time over the last eight years to plan their upgrade path to 3.x. Eight years comes from the date of the first message here https://mail.python.org/pipermail/python-3000/ which was 21/03/2006, so feel free to come up with a different answer for the time span. Somewhat related. Only yesterday I ported/reimplemented a software package to python3. On the finish line, I ran into a problem: xlwt only supports 2.6, 2.7 and 3.3. My system has python3.2. So I backtracked to python2.7. So not only do we have a schism between python2 and python3 but there's one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a mistake. I still believe that PEP 404 was the correct thing to do. PEP 414 was a no brainer :) Serves me right for being an early adopter. No, serves the community right for not providing enough support to authors in getting their packages updated. Marko -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tue, Apr 15, 2014 at 12:40 AM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: So get Python 3.3 for your system, then. That'll have to wait till it's time for an OS overhaul. I don't do those every year. What OS? Since getting 3.3 isn't just a matter of grab the .msi/.dmg file from python.org, I'm guessing it's neither Windows nor OS X, so I'd guess you're most likely talking about Linux. On Linux, it's pretty easy to build Python from source. Debian Wheezy ships Python 3.2, so with that distro you should be able to do this: # apt-get build-dep python3 and it'll install everything you need to build Python 3.2 (and 3.3 needs the same packages). Then you just grab the source code and do the classic configure and make. Or if you don't want to build from source, you could get a package of 3.3 from somewhere. In the case of Debian, that would mean grabbing the Python package from Jessie: https://packages.debian.org/jessie/python3.3 I haven't tested, but that package will most likely install happily on a Debian Wheezy. Chances are you can find an equivalent for other Linuxes (I don't have much experience with rpm-based distros, but I'm sure there's some equivalent of apt-get build-dep). For non-Linux systems, I don't know how hard it is to get a newer Python, but it seems highly unlikely that you're forced to wait for an OS upgrade. Remember, there's nothing wrong with having lots of versions of Python installed. The package manager might provide a couple (maybe 3.1 and 3.2), but having 3.3 installed won't break scripts that depend on 3.2 being there, unless you actually switch over what 'python3' does - and even that's unlikely to break much, since most Linux distros are going to be depending more on the 2.x version than the 3.x... and those that depend on 3.x are sufficiently forward-looking to be shipping 3.3 or even 3.4, so the point is moot. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Tue, Apr 15, 2014 at 12:46 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: So not only do we have a schism between python2 and python3 but there's one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a mistake. I still believe that PEP 404 was the correct thing to do. PEP 414 was a no brainer :) I'm pretty sure the 414 there wasn't a typo, since he's talking about the schism between 3.0 and 3.3. But let's face it, there's a *lot* of schism between there, and it's all the same sort of thing: code written for 3.0 will usually run happily on 3.3, and code written to take advantage of 3.3's features won't work on 3.0. That's kinda how new versions work, yaknow... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
I will most probably backport two quite large applications to Py27 (scientific data processing apps). It's more a question of willingness, than a technical difficulty. Then basta. Note: cp1252 is good enough. (latin1/iso8859-1 not!). jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
Mark Lawrence breamore...@yahoo.co.uk writes: On 14/04/2014 14:51, Marko Rauhamaa wrote: Chris Angelico ros...@gmail.com: If you're going to do that, why not just port your code to 3.x and be done with it? Who has the resources to put hours and hours of dev time into a 2.8? The people who haven't had enough time over the last eight years to plan their upgrade path to 3.x. Eight years comes from the date of the first message here https://mail.python.org/pipermail/python-3000/ which was 21/03/2006, so feel free to come up with a different answer for the time span. Would it help if we adopted a non-numeric name for this product to support eXisting Python for those who were notified some years ago that Python 2 would be superseded? How about Python XP? I thought not ;-) -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On Apr 14, 2014 11:46 AM, wxjmfa...@gmail.com wrote: I will most probably backport two quite large applications to Py27 (scientific data processing apps). These applications are already on Python 3? Why do you want them on Python 2? Even the people talking about a 2.8 are only seeing it as an upgrade path to Python 3. It's more a question of willingness, than a technical difficulty. Then basta. Note: cp1252 is good enough. (latin1/iso8859-1 not!). Because cp1252 includes that holiest of holies, the Euro sign, I assume. Point of curiosity: if the first 256 codepoints of Unicode happened to correspond to cp1252 instead of Latin-1, would you still object to the FSR? -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/14/14 2:59 PM, Ian Kelly wrote: Point of curiosity: if the first 256 codepoints of Unicode happened to correspond to cp1252 instead of Latin-1, would you still object to the FSR? Many of us on the list would appreciate it if you didn't open that particular can of worms. You are of course always welcome to write to JMF privately, although he has never responded to me over that channel. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 14/04/2014 13:56, Mark Lawrence wrote: http://blog.startifact.com/posts/the-call-of-python-28.html so in response to the last line, who *IS* going to do all of the required work? On a related note, Guido announced today that there will be no 2.8 that the eol for 2.7 will be 2020. Cheers, Phil... -- currently (ab)using CentOS 6.5, Debian Squeeze Wheezy, Fedora 19 20, OS X Snow Leopard, RHEL 7, Ubuntu Precise Saucy GnuGPG Key : http://phildobbin.org/publickey.asc Based in London, UK -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/14/2014 9:51 AM, Marko Rauhamaa wrote: Chris Angelico ros...@gmail.com: If you're going to do that, why not just port your code to 3.x and be done with it? Who has the resources to put hours and hours of dev time into a 2.8? Somewhat related. Only yesterday I ported/reimplemented a software package to python3. On the finish line, I ran into a problem: xlwt only supports 2.6, 2.7 and 3.3. My system has python3.2. So I backtracked to python2.7. So not only do we have a schism between python2 and python3 but there's one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a mistake. The 'mistake' is your OS, whatever it is, not providing 3.3. It is already so old that it is off bugfix maintenance. Any decent system should have 3.4 available now. In any case, I think PEP 393 (new unicode implementation) is reason enough to jump to 3.3. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/14/2014 8:56 AM, Mark Lawrence wrote: http://blog.startifact.com/posts/the-call-of-python-28.html so in response to the last line, who *IS* going to do all of the required work? Steve Dower of Microsoft proposed a similar idea of a migration version of 2.7 after talking with people from businesses that use Python. His proposal engenders the same question. I don't really care. I just know that I am not volunteering my time to help billion-dollar corporations with 1000s of employees. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
Terry Reedy tjre...@udel.edu: Any decent system should have 3.4 available now. Really, now? Which system is that? Marko -- https://mail.python.org/mailman/listinfo/python-list
