Hacker News Reader

Comment by bayesianhorse | Hacker News Reader

I am detecting a high level of "Py3K denial syndrome" in this discussion.

The greatness of Python would have been impossible without rejecting virtually all feature requests. To move the vision of Python forward, it was necessary to depart with old syntax.

Python 3 is happening. Deal with it.

View on HN

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.

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.

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.

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

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

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

I always found this Python 2 vs Python 3 discussion very interesting.

One does not see such amount of discussions regarding other languages that suffer even bigger transitions problems.

Java is now version 8, still there are lots of places having to deal with versions 4 and 5.

.NET is getting 4.6/5 version in the upcoming months, still many enterprises still have version 3.5 code bases.

Everyone is discussing the benefits of C++14, while many corporations still use pre-C++98 like code.

Yet in the Python community it is such a big deal.

Code for older Java versions still compiles in Java 8. Code written for python 2.x will not run on python 3.x.

Breaking changes in Java 8

http://www.oracle.com/technetwork/java/javase/8-compatibilit...

Breaking changes in Java 7

http://www.oracle.com/technetwork/java/javase/compatibility-...

Breaking changes in Java 6

http://www.oracle.com/technetwork/java/javase/compatibility-...

Breaking changes in Java 5

http://www.oracle.com/technetwork/java/javase/compatibility-...

Breaking changes in all Java versions up to 1.4

http://www.oracle.com/technetwork/java/javase/compatibility-...

I no longer remember which version it was and don't feel like going through those lists now, but I remember one of those versions changed some JDBC interfaces which would break any application using JDBC.

Well, it kinda depends on exactly what the breaking changes are and how much code they break, don't you think? Certainly none of the languages you mention in the grandparent comment broke Hello, world. It's also a question of what share of issues can be automatically flagged and when (build, run?)

Python had its share of breaking changes as well over the years and there wasn't much fuss about them. Who refused to upgrade over class name(object) or say hex(-1) producing '-0x1' instead of '0xffffffff'?

> but I remember one of those versions changed some JDBC interfaces which would break any application using JDBC

lol wut? How exactly does adding a method to a JDBC interface "break any application using JDBC"?

The code will fail to compile because the implementation no longer matches the interface? Duh.

Maybe I should have written extending the JDBC classes instead.

Yeah, you should have. An application is not supposed to implement JDBC. The database driver is supposed to implemented JDBC. If your application implements JDBC you're doing it wrong.

Just like nobody walks around and complains that new versions of the servlet API break any Java web application because web applications are not supposed to implement the servlet API. That's the job of the server.

Someone needs to implement those drivers...

Yeah, but not your application. If the driver specification gets updated it's not really surprising that the drivers will need to be updated. But the same is true for every specification. However your application doesn't need to be changed.

Those drivers can be application specific, as it was the case in the application I had to fix. Why it was made so, will be kept under the covers of the NDA agreement.

Another use case, many developers mock JDBC by creating their own dummy drivers, specially in large companies where mocking libraries are frown upon.

> Those drivers can be application specific,

Nope, they are database specific.

So we went from "would break any application using JDBC" to large company rolling their own database drivers for reasons that can't be disclosed (probably to protect the guilty).

> as it was the case in the application I had to fix. Why it was made so, will be kept under the covers of the NDA agreement.

Standard case of a large company doing it wrong and blaming somebody else when it comes back to bite them rather than fixing it. And hiding behind an NDA. Seriously what was the expectation? That JDBC never changes? Because at that time JDBC was already at version 3.0 which is obviously the final version after which no features would ever be added again.

> Another use case, many developers mock JDBC by creating their own dummy drivers, specially in large companies where mocking libraries are frown upon.

If you're doing it wrong then you're doing it wrong. Nobody to blame but yourself. Just because you're a large company doesn't make it right. Part of why it's wrong is that it will come back and bite you later on. And that's the problem in this case? The compiler tells you where you need to implement which methods.

Two give you two other examples. Interfaces for HTTP likely need to be updated when something in HTTP changes (WebSockets, HTTP/2). Servers implementing this will need to be updated to implement this. You don't accuse the language of the web server to make a breaking change. That's just how these things work. Same for SSL/TLS features like SNI. Sure it could be that you absolutely have to run your own web server or SSL/TLS implementations for reasons that you can't disclose because you're under an NDA. But then you expect that you'll have to maintain them and add additional features, don't you?

With Perl 6 we saw even bigger fuss and ultimately failure.

Ruby 2.0 had similar levels of incompatibility; I think people simply didn't have those large enterprise codebases in Ruby to make a fuss about.

Java, .net and C++ go to extreme efforts for backwards compatibility, compromising their current/future versions as a result.

> Java, .net and C++ go to extreme efforts for backwards compatibility, compromising their current/future versions as a result.

True, but they still introduce breaking changes as well.

I just posted all the Java release notes in a sibling post, and could do the same for .NET and C++.

Maybe the amount of breakage isn't as big as Python 2 -> 3, but it does happen.

The breaking changes really are tiny though. You can take a random Java 7 app and build/run it with Java 8 and be >99% confident that it will work, whereas with Python 2 -> 3 I'd be 99% confident it would fail (quite possibly even a syntax error).

Afaik Ruby 1.9.3 -> 2.0 was less painful than getting from 1.8.7 to 1.9.3. See http://nerds.airbnb.com/upgrading-from-ree-187-to-ruby-193/

I wish installation was easy and having it as a default language on an OS. Scientific Python distributions are generally with 2. Trying to get all scientific packages with 3 is still tough.

Try Continuum's Anaconda, then that's not tough at all. The most important libraries have been ported to 3 already.

C++ is getting nicer and nicer. The issue is mostly that compilers aren't implementing all the nice features yet. I'm looking forward to C++14 etc. etc., I'm not looking forward to finally having to port to python3.

> Python 3 is happening. Deal with it.

Moving a large codebase to v3 is expensive for almost no benefits? Some parts of the community already moves on to Go, etc. Many third party libraries are v2 only and unmaintained. Many languages that broke backwards compatibility ultimately failed (their community moved on) or split their community. Examples: Modula 2/3/Oberon4, Perl 4/5/6, Lua 5.1(LuaJIT)/5.2, Visual Basic 6/.Net, QBasic/Visual Basic 1, VBA/VBA.Net, J++/J.Net/C#, etc.

Fibers and coroutines are key features of certain language and API's for decades. WinAPI16 had already Fibers (MS Word), Lua's coroutines, Go's goroutines, etc.

Modula-2 and Modula-3 don't have the same authors, even if the name implies otherwise.

Also Oberon had a different purpose than Modula-2.

What's your point? It's what I meant with split the community. And I meant Oberon 2 (not 4 which doesn't exist) - two different Oberon 2 versions exist. My point was introducing incompatible language changes that splits the community usually isn't that good, in the long run.

Those languages are not related other than sharing the Mesa and Cedar language design ideas.

In Oberon's case, you have actually Oberon, Oberon-2, Component Pascal, Active Oberon, Zonnon and Oberon-07.

It is not the same as the next version of a given language, rather different approaches how to design memory safe languages for systems programming.

If you think you don't need to port, then don't port. If you don't like Python, don't use Python.

Python is the future my brother, and python 3 is the future of python.

disclaimer.. i understand the strengths of 2.x, but i use and prefer 3

my standing question in the debate has always been what is the big deal with having built a robust 2to3 preprocessor?

i figure if you make a change to the spec migrating existing code to the new syntax should be a pretty straight forward ifttt, something that should be a necessary addition to the change, a la tests

knowing full well 'pretty straight forward' is the bane of all software endeavors could anyone explain to me what is going on within the scope of 2to3 preprocessors?

and why such preprocessors seem an impossible boon very few, except a handful of seeming independants, endeavor

It's pretty clear with support until 2020, that python3 isn't happening...

Shame on the community for not learning the lessons of Perl. Fragmentation is far worse than an imperfect language.

I'm not feeling this fragmentation. Many people are already using both versions, and the community doesn't seem to have suffered one bit.

Unlikely, python 2 doesn't seem to go anywhere and the two languages can coexist.

In five years it won't be maintained anymore.

So they claim. My experience says that somebody will not make the deadline and will have to keep maintaining it.

Reply on news.ycombinator.com