Comment by captainmuon | Hacker News Reader

Comment by captainmuon | Hacker News Reader

Parent Full thread

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.

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).

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.

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.

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?

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.

There's no reason why you can't use "closed" Python 2 code, or even Fortran for that matter, from Python 3. It's just a matter of interfacing.

I highly doubt that "End of life" means you can't get it to run anymore.

> code written more than 5 years ago likely has no maintainer and no one in the lab knows how it works.

Very true, but this happens regardless of whether it was Python2.x, Python3 or MATLAB code.

The problem is that many academics writing scientific code rarely have the training/education/experience to write maintainable code (if you feel this does not apply to you, you are probably the exception, and if you ever shared code with colleagues, you are aware how rare your skill is in academia). Also most of it is or started out as, quick experiments, try-outs, for that, and some other (even political) reasons, there is not a lot of incentive to write beautiful maintainable code.

At least in my opinion, using Code of which nobody knows what it does is a much bigger problem than just having to port it to Python 3.

But then again, a lack of reproducibility sometimes seems to be what it takes to succeed in Academia...

There's python-bond as well:

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).

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.

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

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.

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.

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.

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

That wouldn't be adequate at this point because the signature for print is different as well.

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.

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, ..

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).

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.

Reply on news.ycombinator.com