Hacker News new | past | comments | ask | show | jobs | submit login

There is no Python 4 planned for now.

Python broke compat once in 25 years and gave 13 years to migrate.

It's a very conservative language.




Python breaks compatibility often on minor point releases. Only once as big as 3.0.0 but it happens regularly.

I argued on the list that these should be kept for major releases for planning reasons but they appear to be convinced it is too hard.


Can you provide an example of where Python has broken backwards compatibility recently between 3.x version? I'll admit (despite googling for 5 or so minutes) that i don't actually know if it does. It obviously breaks forward compatibility continuously all the time - new language features are landing, and they just aren't present in previous versions - but I don't know if I've ever run into people being tripped up by that.

I know some Python Libraries break backwards compatibility (Pandas being a big one) - but, for the most part, hasn't the language been backwards compatible since at least Python 3.4? (And possibly further back, for all I know).


On this page you'll see them. Check the "Porting to X.X" items under each release:

https://docs.python.org/3/whatsnew/index.html

Keep in mind they have deferred a number of them because of the impending EOL of Python 2.7. There are fewer breaking changes during the latter 3.X series, which should resume in 3.9 or 3.10 now that Python2 has passed on.

Here's a commonly mentioned one:

Changes in Python Behavior: async and await names are now reserved keywords. Code using these names as identifiers will now raise a SyntaxError. (Contributed by Jelle Zijlstra in bpo-30406.)

Note: I think this is a bad idea, I'd rather all these small breaking changes and parser be deferred to 4.X. But they need to be small breaking changes, of course, not a new language.


async keyword 3.5


If we look back in python history, the rolling breaking changes have been handled mostly fine, and the actual Python 3 caused a lot of pain in the ecosystem. So I hope they stay away from major versions and keep up the other things they are doing.


That was due to the scope of the breakage, not number format. A good way to handle that and maintain predictability is to constrain breaking changes, yet defer them to 4.X.


I'm struggling to think of any other language that has done something like this.

It might seem like a quibble, but it seems better to describe Python 3 as a different language versus Python 2. Newbies seem to get that.

(Or, alternatively, "How many Python 2 scripts will run on a Python 3 interpreter?" Answer: "None of them.")


First, there are not a lot of interpretted (not compiled, that's another matter entirely) languages that are as old as Python.

And there are really few that are even near Python popularity, or used with such diversity as Python.

I mean, you can get away with keeping AWK the way it was 2 decades ago, nobody is going to use it for for machine learning or to teach computing in all universities in the world on 3 operating systems, utilizing C extensions, or processing Web API.

Among the few that would even compare, there are the ones that have accumulated so much cruft that they became unusable from today's standard (E.G: bash). Then you have those who have done like Python (E.G: perl 6). The ones that just tried and failed (PHP 6). The ones that broke compat and told everybody move or die (Ruby in a point release, gave basically 2 years). And the ones that created a huge pile of horror they called full stack to keep going (E.G: JS). Also those that got hijacked by vendors and just exploded in miriads of proprietary syntaxes (E.G: SQL) or completely new concepts (E.G: lisp).

At least, in Python you CAN write Python 2/3 compatible code, and you have a LOT of tooling to help you with that, or migrating.

So, yes, the Python 2 -> 3 transition could have been better. Insight is 20/20.

But I'm struggling to think of any other language in a similar situation that has done better.


Hindsight 20/20, not insight.


Thanks. French here. Can't edit anymore though


Ruby did something like this around the same time Python did. Ruby's was a bit smaller, but overall a roughly similar amount of breaking changes. They forced you to think about encodings more with Strings, they changed the signatures of several operators, they changed some of the syntax for case statements, they drastically changed the scope rules for block variables, they restructured the base object hierarchy, etc. In both cases, it was a deliberate decision to make a clean break. I think Ruby's big break didn't make as big a schism mainly because Rails was very supportive, and Rails holds an enormous amount of influence in the Ruby world.

If Python 3 had been introduced as a separate language, I'm pretty sure everyone would have said "Why isn't this just called Python 3? It's 99.9% the same as Python and it's by the same people and they're deprecating Python in favor of it."


> Or, alternatively, "How many Python 2 scripts will run on a Python 3 interpreter?" Answer: "None of them."

That's obviously untrue. For example, consider the following Python 2 script:

    with open('a.txt', 'r') as a, open('b.txt', 'w') as b:
        for line in a:
            b.write(line)
It works identically on a Python 3 interpreter, and it doesn't even use "from __future__ import ...".


Not quite. If your a.txt contains utf-8 byte blocks you are screwed in Python 2.


Yes, I should have said, "a vanishingly small proportion, and even then mostly by accident".

My guess is that if you sweep GitHub for Python2 code and push it into Python3, that proportion would be under one percent.


how will that number look when you first autoconvert via 2to3?

I did two migrations of >500k loc projects in an afternoon each, and admittedly some days of testing to gain confidence since there where few unit test. But i found it to be very smooth sailing.

I was very familiar with both projects, so that helped a lot.

EDIT: I also want to add that i did this using python3.5, when to ecosystem seemed to be at a sweet spot of dependencies supporting both 2 and 3 mostly. I guess if one has been waiting until now, the divide between library versions will be a lot bigger.


As a big user of logging and little to do with character coding, all of my admin/daemon stuff moved over with almost no changes necessary for 3.0 (actually ~3.3).

For some projects I did bigger refactors for 2.6/7 (exceptions) and 3.6 (fstrings).


Fair point, but:

  int main(int c,char** v)
    {
    printf("Hello, World!\n");
    return 0;
    }
doesn't make C++ the same language as C.


> Or, alternatively, "How many Python 2 scripts will run on a Python 3 interpreter?" Answer: "None of them."

That is completely false. So many libraries have support both for 2 and 3. That's code that run just as well under both interpreter.


Really? The same .py file runs under python2 and python3?

Googling quickly, I find this, which does a bit better than 2to3. I suppose one could write to a somewhat constrained intersection of Python2 and Python3, if one is willing to make at least some boilerplate changes to the original Python2 code.

https://python-future.org/overview.html

That said, if you bring a Python2 script and feed it to a Python3 interpreter, no, in general that will not work. They simply aren't the same language. Even a simple "print x" will do you in.


> The same .py file runs under python2 and python3?

Sure, as long as it doesn't contain any syntax or spellings which are incompatible between the two. That's a fairly large subset of the language.

> if you bring a Python2 script and feed it to a Python3 interpreter, no, in general that will not work. They simply aren't the same language. Even a simple "print x" will do you in.

But this will work:

    from __future__ import print_function
    print(x)
This is valid under both Python 2 and Python 3.

Also, as I said above, there is a pretty large subset of the Python language that has the same syntax and spellings in both Python 2 and Python 3, and any script or module or package that only uses that subset will run just fine under both interpreters. You are drastically underestimating both the size and the usage of this subset of the language.


Say Django 1.11, a massive amount of .py files, works completely fine under both 2 and 3. As do many other libraries.

Yes you often need some precautions like "from __future__ import" statements and sometimes libraries like `six`, but it's been perfectly normal practice for most of the last decade.


No, but it is possible to write Python 2 code than runs in Python 3.

In fact, the vast majority of popular libs had a 2/3 compatible code base for a few years.

The hard part was not the syntax in fact. It's pretty trivial: the language are not that different.

The hard part is the I/O stack, because the stdlib is very different, espacially for this part.


A lot of projects write in that style e.g. compatible with both python2 and python3, it's really common because there's so much py2 deployed (was default on centOS until very recently, still default on osx, etc.)

Nearly every py3 feature was backported to 2 you just need to write it in a compatible way. I'm seeing some drop py2 support now though. Which I'm fine with, I haven't written python2 code in maybe 6 or 7 years now.


PHP which tried to address unicode in version 6, but then abandoned it and went straight to 7. Perl, which amusingly also at version 6 decided on a huge re-write, but then just decided to rename the version as an actual new language "Raku".


Re Raku, in hindsight, this was the right call. Give a new language a new name, and the story stays simple.


Yep. Also people are not shamed and ridiculed online because they did not upgraded to new language.


It if was such a righ call, why did it die ?


Why do you think it is dead?


> Or, alternatively, "How many Python 2 scripts will run on a Python 3 interpreter?" Answer: "None of them."

That is not true though, a lot of 2 scripts will run no problem, especially if import future is used


Swift has had 3 backwards incompatible versions of larger scope in less time.


> I'm struggling to think of any other language that has done something like this.

Perl 6 (now Raku), of course, but they at least had the decency to admit it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: