8 ms·

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 fe

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.

frik 11y ago
> 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.
- pjmlp 11y ago
  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.
  - frik 11y ago
    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.
    - pjmlp 11y ago
      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.
- bayesianhorse 11y ago
  If you think you don't need to port, then don't port. If you don't like Python, don't use Python.
tomjen3 11y ago
Unlikely, python 2 doesn't seem to go anywhere and the two languages can coexist.
- nailer 11y ago
  In five years it won't be maintained anymore.
  - tomjen3 11y ago
    So they claim. My experience says that somebody will not make the deadline and will have to keep maintaining it.
cmdrfred 11y ago
Python is the future my brother, and python 3 is the future of python.
pjmlp 11y ago
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.
- Proleps 11y ago
  Code for older Java versions still compiles in Java 8. Code written for python 2.x will not run on python 3.x.
  - pjmlp 11y ago
    Breaking changes in Java 8 http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198 http://www.oracle.com/technetwork/java/javase/8-compatibilit... Breaking changes in Java 7 http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities http://www.oracle.com/technetwork/java/javase/compatibility-... Breaking changes in Java 6 http://www.oracle.com/technetwork/java/javase/compatibility-137541.html#incompatibilities http://www.oracle.com/technetwork/java/javase/compatibility-... Breaking changes in Java 5 http://www.oracle.com/technetwork/java/javase/compatibility-137462.html 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-142878.html 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.
    - _yosefk 11y ago
      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'?
mattbillenstein 11y ago
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.
- bayesianhorse 11y ago
  I'm not feeling this fragmentation. Many people are already using both versions, and the community doesn't seem to have suffered one bit.
captainmuon 11y ago
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 11y ago
  is there any PEP that makes parens around function call params optional? Tried to find it, no luck.
  - hueving 11y ago
    That wouldn't be adequate at this point because the signature for print is different as well.
  - actsasbuffoon 11y 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 11y 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, ..
justifier 11y ago
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

frik 11y ago

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

pjmlp 11y ago
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.
- frik 11y ago
  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.
  - pjmlp 11y ago
    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.
bayesianhorse 11y ago
If you think you don't need to port, then don't port. If you don't like Python, don't use Python.

tomjen3 11y ago

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

nailer 11y ago
In five years it won't be maintained anymore.
- tomjen3 11y ago
  So they claim. My experience says that somebody will not make the deadline and will have to keep maintaining it.

cmdrfred 11y ago

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

pjmlp 11y ago

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.

Proleps 11y ago
Code for older Java versions still compiles in Java 8. Code written for python 2.x will not run on python 3.x.
- pjmlp 11y ago
  Breaking changes in Java 8 http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198 http://www.oracle.com/technetwork/java/javase/8-compatibilit... Breaking changes in Java 7 http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities http://www.oracle.com/technetwork/java/javase/compatibility-... Breaking changes in Java 6 http://www.oracle.com/technetwork/java/javase/compatibility-137541.html#incompatibilities http://www.oracle.com/technetwork/java/javase/compatibility-... Breaking changes in Java 5 http://www.oracle.com/technetwork/java/javase/compatibility-137462.html 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-142878.html 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.
  - _yosefk 11y ago
    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'?

mattbillenstein 11y ago

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.

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

captainmuon 11y ago

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 11y ago
is there any PEP that makes parens around function call params optional? Tried to find it, no luck.
- hueving 11y ago
  That wouldn't be adequate at this point because the signature for print is different as well.
- actsasbuffoon 11y 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 11y 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, ..

justifier 11y ago

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