151–160 of 392 posts
Shoot the 2.8 messenger all you want for choosing to call it Python 2.8, but don't dismiss the issue that drives thoughtful people to get value out of this strategy.
> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writ…
> What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about…
However, at a certain point it is worth your time to move forward instead of doing nothing, you gain a little time savings now and you run into few moments of "Oh @#$%^!!" later. Real world example: You don't bother updating ssl to deal with weak DHE and suddenly chrome users can't see your payment site.
My approach has always been to try to front load the work instead of doing it in crisis mode later. It sorta sucks but that's just how software is right now.
I think the problem for me is that they did these changes and made a big song and dance about Python 3. If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate. PHP has been successfully deprecating features for decades now and cleaned up their code base; they have never had a schism in the way Python has so you can argue all you want about legacy, or people preferring 2.7.…
Massive breakage of backwards compatibility in a minor release is bad form. They absolutely did the right thing by naming it Python 3.0.
I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.
> Please, do not put obsolete software on life support. Regarding adoption, it's 3.0 that's obsolete, and 2.7 that's vibrant. Even for new code (they conveniently only count totally greenfield projects, but most new code is written in fact to work with established 2.x codebases under Python 2, not as a totally greenfield project).
I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.
> Please, do not put obsolete software on life support. Regarding adoption, it's 3.0 that's obsolete, and 2.7 that's vibrant. Even for new code (they conveniently only count totally greenfield projects, but most new code is written in fact to work with established 2.x codebases under Python 2, not as a totally greenfield project).
Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.
> Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. S…
You mean print functions. I love the new change because you can pass "print" around like any other function now, letting you write code like:
def my_map(data, func):
for item in data:
func(item)
my_map(dataset, insert_into_database)
# For testing
my_map(dataset, print)I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.
If you have several large software products rolled out and churning away at hundreds of customer sites, moving from Python 2.x all the way to 2.7 alone is a slow and tedious process of tests and deliberations. And we're still not talking about going all the way to 3.x which breaks things in even more new and exciting ways. So scoff all you want, but Python 2.x isn't going away that soon.
In the Java world (conservative and slow-moving) JRE 7 (2011) is considered the absolute minimum, and if you're not targeting JRE 8 (2014) you have to have a very good reason.
Theres a module called __future__ for exactly this purpose
> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writ…
> What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about…
Would you also call the RHEL life cycle a blackmail? I'm using version 5 now and the normal support ends in March 2017. My options now are "port or pay extra for extended life cycle or else my RHEL will be without security fixes". And like Python, major RHEL versions break backwards compatibility.