Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 2.7 Retirement Countdown

pythonclock.org

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Python 2.7 Retirement Countdown

#71

Post by neokya »

kinkdr wrote: post #57
Grokzen wrote: post #28

Earlier quoted context omitted.

The tool they use to determine py3 support is the following: https://github.com/brettcannon/caniusepython3 They have overridden mysql-python with mysqlclient https://github.com/PyMySQL/mysqlclient-python

> They have overridden mysql-python with mysqlclient I am aware of this, but the fact that the tool is reporting MySQL-python as 3.0 compatible, when it is not, is worrying.

Overrides are mostly for drop in replacement. So you could use mysqlclient but chance very little in existing code.

Re: Python 2.7 Retirement Countdown

#72

Post by Retra »

asdfologist wrote: post #49
shadowmint wrote: post #44

Earlier quoted context omitted.

A lot of people really dont care about the future of python, they just want to write code. ...and honestly, whats wrong with that? really, what difference does it make if people use old python versions? Other than the core python team, which get to be embarrased that many people have zero interest in the work theyre doing? Does it affect you? nope. Does it break the ecosystem? nope. Does it make library authors suffe…

I think you missed the whole point of this thread. People want ongoing official support of Python 2.7, which involves resources that could be used elsewhere. Supporting stuff is not free, you know?

The "ongoing official support of Python 2.7" is what resulted in the creation of Python 3. Python 3 contains the enhancements that are meant to fix the (very real) problems that exist in Python 2.

I really don't know where else you think those resources could have been used that wouldn't have resulted in Python 3. Unless you consider "doing nothing meaningful" to be a form of support.

Re: Python 2.7 Retirement Countdown

#73

Post by Retra »

netheril96 wrote: post #48
asdfologist wrote: post #43

People here keep bemoaning the golang designers' decision to not upgrade their language with things like generics, but suddenly their panties get twisted in a bunch when the Python community actually decides to fix problems in their language. Get off your high horse and upgrade your code. So many people did it before you, and so can you.

If Go upgrades itself with support with generics but break backwards compatibility in a horrible way and the breaks cannot be caught at compile time, people will be complaining and resisting upgrade just the same.

And what should the Go team do if the only reasonable way to add generics is to break backward compatibility? Just rip the bandage off? Stagnate? Abandon the language and start a new one?

Re: Python 2.7 Retirement Countdown

#74

Post by zzzcpan »

Retra wrote: post #73
netheril96 wrote: post #48

Earlier quoted context omitted.

If Go upgrades itself with support with generics but break backwards compatibility in a horrible way and the breaks cannot be caught at compile time, people will be complaining and resisting upgrade just the same.

And what should the Go team do if the only reasonable way to add generics is to break backward compatibility? Just rip the bandage off? Stagnate? Abandon the language and start a new one?

Programming languages are not like that. There is an unlimited amount of ways to implement a feature without breaking backward compatibility. Perl, for example, at some point kept compatibility even with bugs, because many people were relying on them.

Re: Python 2.7 Retirement Countdown

#75

Post by Retra »

zzzcpan wrote: post #74
Retra wrote: post #73

Earlier quoted context omitted.

And what should the Go team do if the only reasonable way to add generics is to break backward compatibility? Just rip the bandage off? Stagnate? Abandon the language and start a new one?

Programming languages are not like that. There is an unlimited amount of ways to implement a feature without breaking backward compatibility. Perl, for example, at some point kept compatibility even with bugs, because many people were relying on them.

I don't understand this at all. Yes, you can add features, but if they are not ergonomic, then why bother? For instance, you can't just add features that introduce syntactic ambiguity or change your parser to become context sensitive without making the language significantly more complex all around.

Yes, you can add anything without breaking backward compatibility. That's why I qualified it with "reasonable" -- there are very good reasons to break backward compatibility, and being a slave to it will pile up technical debt in very unpleasant and potentially avoidable ways.

It's like trying to make a skyscraper taller without rebuilding the foundation. Sure, you can add giant ugly supports on the side, but once you've done that a few times, nobody is going to feel safe near your building. And no self-respecting architect would do it.

Re: Python 2.7 Retirement Countdown

#76

Post by takeda »

wink wrote: post #66
underyx wrote: post #60

Earlier quoted context omitted.

Actually, it seems to me that everyone who is active in the community is already on Python 3 and is heavily in favor of upgrading. The people who are still using Python 2 are the 'lazy' ones, who don't really care about the community at all; the ones who keep making comments like 'I just use whatever the `python` command starts.' I'm pretty sure these people couldn't maintain Python 2 by themselves.

I have a reasonably large project that was started in late 2013 (so only 2.5 years ago) when 2.7 was already long "to be deprecated" but some of the key libraries used were not yet python 3 compatible. I haven't actually checked, it could probably be ported now - but why would you do that now - everything can change in the next 3 years.

We're over the hump if something would change and still was python it would most likely be compatible with python 3.

There two things that might help you port things:

1. You can use Cython to mix python 2 and python 3 code together. You compile python2 code as a module and then reference it from the python3.

2. MyPy (http://mypy-lang.org/) - This might not seem like related, but if you provide information about types refactoring the code becomes much easier (like in statically typed languages) so when you change something it's easier to find all other places that also need to be changed. Some IDEs (for example PyCharm) also understand typing which helps when using their refactoring functionality.

Re: Python 2.7 Retirement Countdown

#77

Post by zzzcpan »

Retra wrote: post #75
zzzcpan wrote: post #74

Earlier quoted context omitted.

Programming languages are not like that. There is an unlimited amount of ways to implement a feature without breaking backward compatibility. Perl, for example, at some point kept compatibility even with bugs, because many people were relying on them.

I don't understand this at all. Yes, you can add features, but if they are not ergonomic, then why bother? For instance, you can't just add features that introduce syntactic ambiguity or change your parser to become context sensitive without making the language significantly more complex all around. Yes, you can add anything without breaking backward compatibility. That's why I qualified it with "reasonable" -- there…

There is nothing stopping you from implementing a feature in a reasonable and ergonomic way without breaking backward compatibility. Programming languages are fun like that. Anything can be done, your imagination is your only limit. And on this level technical debt is not a concern, not even a little. But having good rationale for a feature is, and a huge one. Most of the time the authors themselves don't know why they need it, they just feel like having it.

Re: Python 2.7 Retirement Countdown

#78

Post by scrollaway »

Avernar wrote: post #68
scrollaway wrote: post #42

Earlier quoted context omitted.

Most everything good? Like high quality unicode support and async def?

High quality unicode? Where every string with even a single emoji takes 4 times the memory. They should have used UTF-8 for their internal representation. Putting that aside, my issue with 3.X is that I have to use the unicode type even when I'm manipulating byte strings.

> even when I'm manipulating byte strings

What? No you don't. The `bytes` object is what you want when you deal with byte strings.

Re: Python 2.7 Retirement Countdown

#79

Post by Avernar »

scrollaway wrote: post #78
Avernar wrote: post #68

Earlier quoted context omitted.

High quality unicode? Where every string with even a single emoji takes 4 times the memory. They should have used UTF-8 for their internal representation. Putting that aside, my issue with 3.X is that I have to use the unicode type even when I'm manipulating byte strings.

> even when I'm manipulating byte strings What? No you don't. The `bytes` object is what you want when you deal with byte strings.

The bytes object is not a string type. It's treated more like a list of integers. It has very little string operations. Only in 3.5 did they add back the ability to % format.

Not to mention all the b prefixes it just becomes painful.

Re: Python 2.7 Retirement Countdown

#80

Post by CJefferson »

Svenstaro wrote: post #27
CJefferson wrote: post #4

No, I'm getting sick of my code being broken. My C code from 15 years ago works fine, but code in other languages can end up breaking within a year. I've moved much of my development back to C++ just so I can have reasonable confidence my code will work when I come back to it in a couple of years. I don't care if Python 2.7 never gains another feature, as long as my code will still work in Windows 13 and Mac OS X 10.…

Your C code might still work but are you not relying on any libraries which might have been updated in 15 years in a non-backwards compatible way and thus broken your build?

It's not perfect, I'll admit.

I'm probably in a special area -- algorithms research. I tend not to use many libraries, and I'm often taking code written 10-20 years ago and wanting to get it working. The code is often VERY complicated, and I don't really want to reimplement it.

Finally (and probably most importantly) I don't care about security holes, I'm not going to run this code on malicious input.

Post reply on HN