6 ms·

From my perspective (mostly scientific computing), Python has been killed after 2.7 by its creators. Python 3 might as well be Perl 6. I know this is just the

From my perspective (mostly scientific computing), Python has been killed after 2.7 by its creators. Python 3 might as well be Perl 6. I know this is just the situation in my corner, and that it looks rosier for other users - e.g. for web development, system administration, etc.. The thing is, we have decades worth of legacy code - large libraries and small config scripts - that no one is going to rewrite. All python versions up till 2.7 were mostly backwards-compatible, and we came to depend on that. That the changes towards 3.x were breaking seems totally unneccessary (except for the string/unicode thing), which also gives it a psychological component in my opinion. Give us back the stupid print statement, and I bet this alone will massively increase adoption. And if someone makes a patch to Python to import a Python 2 module in Python 3 (old syntax, old str/unicode, and a copy of the old stdlib - and it doesn't matter if it is 10% slower or never gets merged upstream), I'd be willing to pay $$ for it.

ant6n 12y ago
is there any PEP that makes parens around function call params optional? Tried to find it, no luck.
- hueving 12y ago
  That wouldn't be adequate at this point because the signature for print is different as well.
- actsasbuffoon 12y ago
  That would be tricky. Ruby has optional parens for function calls, but it makes it tricky to get a reference to a method without calling it. We have to write "foo.method(:some_method_name)", while the Python equivalent is simply "foo.some_method_name". You might be able to require parens for methods with no arguments, but optional parens with arguments. It might require some clever hacks in the parser, but I suspect it's possible. The bigger question is whether or not the result would be Pythonic.
  - ant6n 12y ago
    Maybe they could just re-introduce print x as syntactic sugar for galling a print function. Like in Matlab, where the operators (+, *, ..) are just syntactic sugar for calling functions add, mul, ..
    - DrJosiah 12y ago
      The Python 3.x print function and 2.x print statement automatically called the __str__ method on an object to get a representation to print to screen. The result is then sent to the appropriate file handle for actual printing (which can be overridden).
- tripzilch 12y ago
  IPython has this as a configuration option. I only use it in the interactive interpreter (not sure if it works in scripts, but I don't think that's a good idea anyhow). I like being able to type len flurp to quickly get the length of an array.
orf 12y ago
It's unlikely that print statements are the only thing that won't work in older Python 2 code, the standard lib has changed (for the better) and there are lots of other smaller changes that could stop a script from running.
- captainmuon 12y ago
  Sure, that's why I say it's in part psychological. It feels like that change was made just to spite users. "It's my language and I can do what I want." Of course, that's nonsense. Still, I believe that adding back a print statement would make the transition easier for some people. For the people that are stuck with Python 2 legacy code, we'd need something else. Python-future [1] seems to be able to import some Python 2 modules, but I'm not sure how far it goes. [1] http://python-future.org/translation.html#translation http://python-future.org/translation.html#translation
  - actsasbuffoon 12y ago
    Making print a statement again would mean you can't print in a lambda. That'll break a bunch of Python 3 code, which puts us right back where we started; people being upset about a new release of Python breaking their code.
    - alextgordon 12y ago
      You don't need to jettison print-as-a-function in order to have print-as-a-statement. >>> print "hello" SyntaxError: Missing parentheses in call to 'print' If it can print a SyntaxError explaining the problem then it can print "hello". The only snag is that a tuple would be printed slightly differently, but that is harmless. People should be upset that a new release of Python breaks their code, because the Python developers acted unprofessionally in expecting all python code in existence to be rewritten to suit their aesthetic fetishes.
      - scrollaway 12y ago
        So instead of code breaking explicitly, you'd rather it breaks implicitly? You're really foolish if you believe that's better. The print keyword isn't what is preventing 3k adoption.
urschrei 12y ago
Considering that Numpy and Scipy are now Py3 compatible, and that there's no actual time constraint, I don't think the idea that it's rosier for others is particularly convincing. And, though neither are perfect, both 2to3 and Six exist to smooth the transition (particularly for smaller scripts and libraries).
eeZi 12y ago
There's python-bond as well: https://pypi.python.org/pypi/python-bond https://pypi.python.org/pypi/python-bond > You can freely mix Python versions between hosts/interpreters (that is: you can run Python 3 code from a Python 2 host and vice-versa).
bayesianhorse 12y ago
Sounds more like a problem with technical debt than with py3k. If you have that much code and are completely unable to port it, then your engineering staff is thoroughly underpowered. And that will get in you in trouble soon, even if you stay with Python 2.
- rcthompson 12y ago
  Considering most academic labs that write scientific computing code have no engineering staff and most of the code is written by academics analyzing data, yes, I'd have to agree that "no engineering staff" constitutes an underpowered engineering staff. But more importantly, keep in mind that many academics move on to a new institution every couple of years (after finishing undergrad/Ph.D./post-doc, etc.), so any code written more than 5 years ago likely has no maintainer and no one in the lab knows how it works.
  - akshatpradhan 12y ago
    That's a problem that needs to be addressed by hiring a full-time maintainer for all legacy code. For example, Clark University has an endowment of $355 Million. That's three times the size a company like Veracode. Why are universities unable to hire maintainers for all this legacy code and bring this legacy code up-to-date with current standards and best practices?
    - hobarrera 12y ago
      Because it's really really hard to justify. My dad is a chemist, and I recently learnt that some Fortran code he wrote in the nineties is till being used in academia. Try to explain to his colleagues that you need an on-site engineer to maintain python code just a decade old. Anyhow, while I disagree with the need of a dedicated engineer to port code to python3, porting isn't much of a big deal. If your dependencies work (eg: your libraries are python3-compatible), most of you work is done by 2to3. Very little effort is needed after that. The problem up to now, has been waiting for you dependencies/libraries to achieve python3-compatibility (recursively, of course). But we've already moved past that.

ant6n 12y ago

is there any PEP that makes parens around function call params optional? Tried to find it, no luck.

hueving 12y ago
That wouldn't be adequate at this point because the signature for print is different as well.
actsasbuffoon 12y ago
That would be tricky. Ruby has optional parens for function calls, but it makes it tricky to get a reference to a method without calling it. We have to write "foo.method(:some_method_name)", while the Python equivalent is simply "foo.some_method_name". You might be able to require parens for methods with no arguments, but optional parens with arguments. It might require some clever hacks in the parser, but I suspect it's possible. The bigger question is whether or not the result would be Pythonic.
- ant6n 12y ago
  Maybe they could just re-introduce print x as syntactic sugar for galling a print function. Like in Matlab, where the operators (+, *, ..) are just syntactic sugar for calling functions add, mul, ..
  - DrJosiah 12y ago
    The Python 3.x print function and 2.x print statement automatically called the __str__ method on an object to get a representation to print to screen. The result is then sent to the appropriate file handle for actual printing (which can be overridden).
tripzilch 12y ago
IPython has this as a configuration option. I only use it in the interactive interpreter (not sure if it works in scripts, but I don't think that's a good idea anyhow). I like being able to type len flurp to quickly get the length of an array.

orf 12y ago

It's unlikely that print statements are the only thing that won't work in older Python 2 code, the standard lib has changed (for the better) and there are lots of other smaller changes that could stop a script from running.

captainmuon 12y ago
Sure, that's why I say it's in part psychological. It feels like that change was made just to spite users. "It's my language and I can do what I want." Of course, that's nonsense. Still, I believe that adding back a print statement would make the transition easier for some people. For the people that are stuck with Python 2 legacy code, we'd need something else. Python-future [1] seems to be able to import some Python 2 modules, but I'm not sure how far it goes. [1] http://python-future.org/translation.html#translation http://python-future.org/translation.html#translation
- actsasbuffoon 12y ago
  Making print a statement again would mean you can't print in a lambda. That'll break a bunch of Python 3 code, which puts us right back where we started; people being upset about a new release of Python breaking their code.
  - alextgordon 12y ago
    You don't need to jettison print-as-a-function in order to have print-as-a-statement. >>> print "hello" SyntaxError: Missing parentheses in call to 'print' If it can print a SyntaxError explaining the problem then it can print "hello". The only snag is that a tuple would be printed slightly differently, but that is harmless. People should be upset that a new release of Python breaks their code, because the Python developers acted unprofessionally in expecting all python code in existence to be rewritten to suit their aesthetic fetishes.
    - scrollaway 12y ago
      So instead of code breaking explicitly, you'd rather it breaks implicitly? You're really foolish if you believe that's better. The print keyword isn't what is preventing 3k adoption.

urschrei 12y ago

Considering that Numpy and Scipy are now Py3 compatible, and that there's no actual time constraint, I don't think the idea that it's rosier for others is particularly convincing. And, though neither are perfect, both 2to3 and Six exist to smooth the transition (particularly for smaller scripts and libraries).

eeZi 12y ago

There's python-bond as well: https://pypi.python.org/pypi/python-bond https://pypi.python.org/pypi/python-bond > You can freely mix Python versions between hosts/interpreters (that is: you can run Python 3 code from a Python 2 host and vice-versa).

bayesianhorse 12y ago

Sounds more like a problem with technical debt than with py3k. If you have that much code and are completely unable to port it, then your engineering staff is thoroughly underpowered. And that will get in you in trouble soon, even if you stay with Python 2.

rcthompson 12y ago
Considering most academic labs that write scientific computing code have no engineering staff and most of the code is written by academics analyzing data, yes, I'd have to agree that "no engineering staff" constitutes an underpowered engineering staff. But more importantly, keep in mind that many academics move on to a new institution every couple of years (after finishing undergrad/Ph.D./post-doc, etc.), so any code written more than 5 years ago likely has no maintainer and no one in the lab knows how it works.
- akshatpradhan 12y ago
  That's a problem that needs to be addressed by hiring a full-time maintainer for all legacy code. For example, Clark University has an endowment of $355 Million. That's three times the size a company like Veracode. Why are universities unable to hire maintainers for all this legacy code and bring this legacy code up-to-date with current standards and best practices?
  - hobarrera 12y ago
    Because it's really really hard to justify. My dad is a chemist, and I recently learnt that some Fortran code he wrote in the nineties is till being used in academia. Try to explain to his colleagues that you need an on-site engineer to maintain python code just a decade old. Anyhow, while I disagree with the need of a dedicated engineer to port code to python3, porting isn't much of a big deal. If your dependencies work (eg: your libraries are python3-compatible), most of you work is done by 2to3. Very little effort is needed after that. The problem up to now, has been waiting for you dependencies/libraries to achieve python3-compatibility (recursively, of course). But we've already moved past that.