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

New features you can't use unless you are in Python 3

asmeurer.com

Post reply on HN
Print view View original

11–20 of 264 posts

Re: New features you can't use unless you are in Python 3

#11

Post by coldtea »

SloopJon wrote: post #6
xutopia wrote: post #4

I'm impressed how much Python seems stuck on older versions. What went wrong?

One of the chapters added in the second edition of Peopleware quotes from a presentation by Steve McMenamin: "People hate change ... and that’s because people hate change ... I want to be sure that you get my point. People really hate change. They really, really do."

And still tons of projects managed to get people on board.

Change has to be compelling. Python 3 wasn't until at least recently (3.5 and on).

Change has to be backwards compatible as possible. Python 3 wasn't, often for BS reasons.

Change better has some major selling feature. Python 3 has nothing that special over 2.

Change must come with nice conversion tools. 2to3 wasn't that.

etc...

Re: New features you can't use unless you are in Python 3

#12

Post by coldtea »

web007 wrote: post #8
edoceo wrote: post #3

Earlier quoted context omitted.

The buttons are on your keyboard. Swipe on touch interface

I don't expect to have to use my keyboard to navigate a webpage. It's also not discoverable or prompted in any way.

Using the arrows keys for the slides has been a standard since the dawn of web presentations, a decade or so ago.

Doesn't have to be more discoverable imho. As soon one finds it out, they can use the knowledge for any other presentation they chance upon -- and presentations remain clutter free, without prompts and extra navigational buttons for the rest.

Re: New features you can't use unless you are in Python 3

#13

Post by problems »

xutopia wrote: post #4

I'm impressed how much Python seems stuck on older versions. What went wrong?

It was source-level incompatible with older code so it couldn't be used as a smooth transition like... almost any other language upgrade I've ever seen.

Breaking code like this was a big mistake in my opinion - it resulted in many people sticking on the old version for code and library compatibility. There are still libraries which don't work on Python 3, though now fairly few of them.

In addition to that, the unicode changes were in my opinion another mistake - they made it far more complicated to deal with strings and byte arrays as now even for the simplest of applications you have to put thought into character encodings. Another annoyance for me personally is that I often use python to do things like hex and base64 encoding, the removal of .encode("hex") really wrecked this one for me. Now I have to remember weird import libraries like "binascii" with weird function names like "hexlify".

Ultimately Python 2 works. And it works well, there just aren't that many compelling reasons to move to 3 given that it often is more complicated and breaks existing code. They have a few cool things now, so I sometimes use it for new code but there's still nothing that's making me want to delve into a port of my older codebases.

Re: New features you can't use unless you are in Python 3

#15

Post by gshulegaard »

Quite a nice presentation!

But I just wanted to point out that the title is a bit presumptuous. I don't refuse to upgrade to Python 3, it's that the default Python for most distributions is 2 (sometimes as far back as 2.6). If you want to write a user-space tool with Python you can either require additional dependency setup, bundle a full interpreter with your package, or just write Python 2.7/6 code that is forward compatible with Python 3...in which case I still can't use the new features of 3.

At the end of the day, the continued slow adoption of Python 3 today is because ecosystems move slowly. Not to mention the original releases of Python 3 were really rough around the edges (such as being slower than Python 2.7 until ~3.4) which definitely contributed to the slow adoption in the early years.

Re: New features you can't use unless you are in Python 3

#16

Post by gh02t »

xutopia wrote: post #4

I'm impressed how much Python seems stuck on older versions. What went wrong?

A combination of Unicode strings breaking a lot of libraries and Py3K not having a lot of user-visible improvements early in its lifetime. It built up a base of people who said "they broke all my code and I don't see any reason to fix it". A lot of people recommended (legitimately) that you stick with Python 2 until Py3K was more widely supported. The momentum from this group persisted even after the point where it made sense to switch to 3.

And so we are stuck, especially in enterprise where it could cost a lot of time and money to port because the transition wasn't managed well, both by users and the Python team.

Re: New features you can't use unless you are in Python 3

#18

Post by mattnewton »

matthewmacleod wrote: post #14

Ruby's 1.8 to 1.9 transition seemed to go much smoother - I'm curious what the difference is. Just down to what is essentially better source comparability I guess.

My guess is it could also have to do with the communities. Anecdotally, the limited sample of ruby-istas I have interacted with tend to have more tolerance of churn for improvement's sake whereas the people attracted to python are more interested in stability because they are focused on some other need that the code is mearly an ends to.

Re: New features you can't use unless you are in Python 3

#19

Post by vapemaster »

rjgonza wrote: post #5
xutopia wrote: post #4

I'm impressed how much Python seems stuck on older versions. What went wrong?

Python 3 came about with a split in the community.

what is the split that has to do with 2vs3? Really it just seems like some devs are still griping about fairly minor backwards compatibility issues. the whole print vs print() is obviously a straw man. but the major one, strings, unicode, and bytes, changes for the good in py3. the fact that people have to go back and "un-hack" their code is time, effort, and more commits but it's for the best.

i think the real split is between CPython + C-Extensions and the JIT (PyPy,Numba) gang for heavy lifting in python. I for one wish Guido would embrace the effort of integrating the GILectomy into CPython and make python thread parrallism real for CPU bound work as opposed to the high overhead multiprocessing approach.

Also, including mypy in the stdlib to make genuine optional static typing would make python a defacto standard for much of what it does now without the "we love python but...." production code pain points.

Post reply on HN