I strongly dislike Python 3
in [Python]
|
From: Stephen Hansen on 27 Jun 2010 13:39 On 6/27/10 9:26 AM, rantingrick wrote: >> That being said, Stephen's statement was very broad, but I think it's >> true: print is primarily used in small scripts, or script-like testing >> functions/methods. > > No, Stephen's comments were NOT general in any way and they where in > fact very specific... "If you use the print statement/function you're > are a noob and your code is a toy". And i think there's and air of > "also you're beneath me" in the tone of it too. Excuse me? You do not speak for me. Do not put words into my mouth: especially words which are not at *all* what I said. I said, "P.S. Am I the only one who has never, ever, even *seen* a 'print' statement in non-toy or non-bash-script-style code in any application or even third-party library I looked at? Except, on occasion, for quick and dirty debugging. Perhaps because I'm more used to cross-platform to windows development, where a stray print can actually break the entire application (depending on contexts, if one is run under a service or sometimes even pythonw". If you actually practice your reading comprehension-- I know this is difficult for you-- then you would see there's three categories of places I have seen print statements: - Toys (do you even know what I mean by that?) - Bash-script-style code (this is /very/ broad, and I do it all the time) - Debugging (qualified as 'quick and dirty', as opposed to debugging using say, the logging module or some other framework) I then further qualified that its possible my own personal experience is the way it is, because I may be using applications and libraries which focus more on windows support then others who may be doing a great deal more in a pure-Unix environment where things are more sensible (i.e., a program always has a stdout, even if its /dev/null, as opposed to on windows, where you sometimes just have none at all, and writing to it kills your program). For you to mischaracterize that all into, "you're a noob and your code is a toy" goes far beyond simple misunderstanding and into malicious false attribution. Usually our disagreements have at least the vaguest *semblance* of an actual argument, notwithstanding your long wanderings in sophistry and substance-less rants. Now if you've decided to go down the path of rewriting what I say into something it completely isn't, instead of actually responding to it: then I have no time for you. You're *this* close to getting killfiled after all. Your usual nonsense is one thing, you usually have the barest sense of decency to actually quote me when you respond. If you're going to paraphrase me, do so accurately at least-- or do so after quoting what I actually said, if you wish to reinterpret my words. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Terry Reedy on 27 Jun 2010 15:38 On 6/27/2010 8:41 AM, David Cournapeau wrote: > I think one point which needs to be emphasized more is what does > python 3 bring to people. The" what's new in python 3 page" gives the > impression that python 3 is about removing cruft. That's a very poor > argument to push people to switch. Python3 is about finishing transitions. The last stage in a transition that replaces something old with something new is to remove the old, after showing that the new works. I am working on a separate post for this.) I presume most readers here who are not packrats have at some time discarded a working machine (perhaps reluctantly) after installing and testing a new one. For new learners, not having to also learn the old is a real benefit. People who already know the old typically do not see that. > I doubt "porting is easier than you think" will convince many people > if they don't know what the gain will be. For example, porting numpy > and scipy to py3k has been easier than I thought, but besides making > it easier for other people to switch, I can't see *any* benefit. I thank you and your group for porting numpy and scipy for the benefit of those who switch and for new Pythonistas that start with Python3. I hope and expect that they will eventually outnumber Python2 programmers. I agree that there may be not much reason to port custom proprietary apps that are working fine and which would hardly benefit from, let alone need, and new Py3 features. -- Terry Jan Reedy
From: Martin v. Loewis on 27 Jun 2010 16:09 > I agree that there may be not much reason to port custom proprietary > apps that are working fine and which would hardly benefit from, let > alone need, and new Py3 features. In the long run, there will be a benefit: at some point in the future (surely years from now), /usr/bin/python will be Python 3. So scripts that use /usr/bin/python (or "/usr/bin/env python") will stop working. As a quick fix, it might then be possible to have them run with /usr/bin/python2. Some time more into the future, this will also stop working, as Python 2.x won't be available anymore in the OS distributions. If the custom proprietary app is then still used, it better be ported. The same happened with other kinds of deprecations and removals through the life of 2.x. Some applications where tied to a specific Python release, or to a specific feature that had been deprecated. These either needed to be ported, or dropped. Regards, Martin
From: Eric_Dexter on 27 Jun 2010 19:03 On Jun 27, 2:09 pm, "Martin v. Loewis" <mar...(a)v.loewis.de> wrote: > > I agree that there may be not much reason to port custom proprietary > > apps that are working fine and which would hardly benefit from, let > > alone need, and new Py3 features. > > In the long run, there will be a benefit: at some point in the future > (surely years from now), /usr/bin/python will be Python 3. So scripts > that use /usr/bin/python (or "/usr/bin/env python") will stop working. > As a quick fix, it might then be possible to have them run with > /usr/bin/python2. Some time more into the future, this will also stop > working, as Python 2.x won't be available anymore in the OS > distributions. If the custom proprietary app is then still used, it > better be ported. > > The same happened with other kinds of deprecations and removals through > the life of 2.x. Some applications where tied to a specific Python > release, or to a specific feature that had been deprecated. These either > needed to be ported, or dropped. > > Regards, > Martin It should be easier to have a large number of python versions on one machine... I am realy fond of 2.5 so I am probily going to start compiling them or just include the python2.5 exe if I port stuff and settle it that way..
From: Benjamin Kaplan on 27 Jun 2010 19:11
On Sun, Jun 27, 2010 at 4:03 PM, Eric_Dexter(a)msn.com <Eric_Dexter(a)msn.com> wrote: > On Jun 27, 2:09 pm, "Martin v. Loewis" <mar...(a)v.loewis.de> wrote: >> > I agree that there may be not much reason to port custom proprietary >> > apps that are working fine and which would hardly benefit from, let >> > alone need, and new Py3 features. >> >> In the long run, there will be a benefit: at some point in the future >> (surely years from now), /usr/bin/python will be Python 3. So scripts >> that use /usr/bin/python (or "/usr/bin/env python") will stop working. >> As a quick fix, it might then be possible to have them run with >> /usr/bin/python2. Some time more into the future, this will also stop >> working, as Python 2.x won't be available anymore in the OS >> distributions. If the custom proprietary app is then still used, it >> better be ported. >> >> The same happened with other kinds of deprecations and removals through >> the life of 2.x. Some applications where tied to a specific Python >> release, or to a specific feature that had been deprecated. These either >> needed to be ported, or dropped. >> >> Regards, >> Martin > > It should be easier to have a large number of python versions on one > machine... I am realy fond of 2.5 so I am probily going to start > compiling them or just include the python2.5 exe if I port stuff and > settle it that way.. > -- You're on the only platform where it isn't that easy. All us *nix users have to do is compile it with the altinstall flag, and then use #!/usr/bin/env python25 Windows uses the file extension instead of the shebang line to execute stuff, so it's harder for you to have multiple versions. |