24
25

Adopt Python 3 (medium.com)

submitted by rroocckk

all 16 comments
sorted by:
best
topnewcontroversialoldq&a

[–]rroocckk[S] 4 points5 points  (3 children)

I wrote an article about Python 3 support of third party libraries few days back and submitted it to reddit. Based on the feedback I got, I have rewritten and reorganized the article so that it's more insightful. It includes more data and better visualisations. Thanks for your earlier feedback and let me know if you have any questions.

[–]spinwizard69 3 points4 points  (2 children)

I never understood the mentality of the part of the Python community that has stuck with Python 2 so foolishly. Very unprofessional in my mind.

[–]rroocckk[S] 7 points8 points  (0 children)

I wouldn't call it foolish. From what I have heard

  1. For businesses, it does not always make economic sense to move.

  2. Sometimes, a major dependency still needs to ported before some code bases can move.

I think a majority of developers who stuck to Python 2 stuck to it for a reason. There's only a minority that stuck to it because they are not open to change.

But 'times they are a-changin'. Every statistics out there points to a steady growth of Python 3 presence. There's no need to worry.

[–]is_it_fun 1 point2 points  (0 children)

My company sticks with Python 2 because other companies we work with stick with Python 2. Shitty reason but.... codes gotta work, man...

[–]toyg 3 points4 points  (1 child)

Some of those py2-only "big" packages by now will likely have some py3 experimental branch somewhere. Check them out before you commit to py2, they might work well enough for your needs or they might need just a few tweaks. In some cases it's just maintainer inertia that stops these branches from being released.

[–]vmpajares 2 points3 points  (0 children)

Not only experimental by the same team, there are forks of many 'only python2' packages by different coders. But the original version is more popular because is older.

[–]new_whistle 3 points4 points  (9 children)

The fact that Python 3 isn't seen by developers as a clearly better alternative to Python 2 is the problem. Don't blame developers and package maintainers for the blunders Python's roadmap over the past five years. Developers are naturally conservative because there is always unmeasured risk in choosing a new technology over an old one.

BUT, with all that said. There's absolutely no excuse in 95% of cases for not writing cross-compatible code. With loads of CI and testing options (web based, self-hosted, local, it's all there), it should be very easy to write libraries that target both from the start and maintain them with 100% test coverage.

[–]rroocckk[S] 1 point2 points  (0 children)

I used to recommend supporting both versions too, but with this approach it is not possible to take advantage of the new features in Python 3. On the upside, it is possible to target 100 % of packages in PyPI.

[–]billsil 0 points1 point  (4 children)

The fact that Python 3 isn't seen by developers as a clearly better alternative to Python 2 is the problem.

Raymond Hettinger (a core developer) gave a talk saying exactly this. He now thinks Python 3.6 is better than 2.7 due to the improved dictionaries.

https://www.youtube.com/watch?v=p33CVV29OG8

I maintain an 2.7.7+/3.3+ compatible open source package. The Python 2 support is a lot easier. I think I've hit every obscure Python 3 different. That lack of Python <2.7.6 is also due to a quirk is the Python struct module as well as a quirk in six that just breaks trying to support anything more than that.

It's really unfortunate that there's no killer feature of Python 3 (outside of being able to develop a unicode aware app in a sane way, but it's not actually better when running said app). MyPy is the closest there is, but the documentation on MyPy stub files isseverely lacking. It's also unfortunate that unicode documentation is so poor. It took me a month of fighting with it to figure it out.

[–]aiPh8Se 5 points6 points  (3 children)

There are lots of (in my opinion) killer features in Python 3. (Well, maybe not killer features individually.)

  • Proper scoping of iteration variable in list comprehensions
  • Print function by default
  • No implicit relative import by default
  • No new/old style class distinction
  • Sane byte/Unicode string separation
  • UTF-8 source files by default
  • yield from syntax
  • async/await syntax
  • Parameter type hints
  • pathlib module
  • venv module (solves the odd problem caused by old versions of virtualenv)
  • Lots of API improvements in the standard library
  • subprocess.run()
  • Lots of iterators by default instead of lists: no more xrange, no more iteritems(), itervalues(),
  • No more long/int separation.
  • Clear division and floor separation (/ vs //)
  • Keyword only parameters (I have seen a lot of Python 2 code that hacks around this by rolling their own).
  • nonlocal keyword for assignment in closures

Of course all of the new 3.6 features as well.

[–]new_whistle 0 points1 point  (0 children)

There are lots of (in my opinion) killer features in Python 3. (Well, maybe not killer features individually.)

That's what I mean - most projects aren't going to benefit from all of these things, and so the weight of all of them isn't felt.

[–]billsil 0 points1 point  (0 children)

Print function by default

Really? How is that a "killer" feature? It's an inconvenience.

No implicit relative import by default

I've been bit by that once in 10 years of coding. It was weird, but it wasn't that hard to fix.

No new/old style class distinction

Yeah, but I haven't used old style classes since Python 2.5. Inherit from object and your fine.

venv module (solves the odd problem caused by old versions of virtualenv)

I use Anaconda, which has a better wrapping of virtualenv. You can access them from anywhere.

Clear division and floor separation (/ vs //)

Again, Python 2 has this.

Parameter type hints

With piss poor documentation on how to use it. This is the closest to what I'd call a killer feature, but multi-type parameters (e.g., int, List[int], None, numpy (n, ) int array, sequence, generator [int]) need better support or at the very least documentation.

No more long/int separation.

For the stuff I do, I actually don't like this. A long for me is an error. I guess I'm doing isinstance(value, (int, np.int32, np.int64) anyways. I can add and value < 100_000_000. I don't want to though.

Sane byte/Unicode string separation

It took until Python 3.4 before that was really done. The struct module didn't allow unicode, so making Python 2/3 code was overly difficult. I do like unicode in Python 3, but I don't have any unicode issues in Python 2 given that I test in Python 3. What I don't like is the unicode tutorials. How do you figure out your encoding when nobody tells you? I also hate utf-8. I use latin1 for everything cause it works, where utf-8 doesn't. It took me a month to figure that out.

Proper scoping of iteration variable in list comprehensions

I actually don't like that.

I can't comment on yield from or async or nonlocals since I don't use them and don't care to.

[–]beaverteeth92Python 3 is the way to be 0 points1 point  (0 children)

Not to mention that @ is a killer feature for anyone doing numerical programming.

[–]breamoreboy 0 points1 point  (2 children)

Don't blame developers and package maintainers for the blunders Python's roadmap over the past five years.

Please list these blunders and why they are restricted to the last five years, as quite frankly the comment makes no sense to me at all.

[–]throwaway143259 0 points1 point  (1 child)

Really? Despite Python versions 3.0 -> 3.3 offering nothing compelling compared to 2.7 we responsible developers were regularly abused and cast as troglodytes for not immediately porting our code to 3.X. Since then nothing much has changed. Every 3.X release is called the "killer release that makes 2.7 obsolete" yet here we are, with the majority of code still running on 2.7

That is a complete failure of the BFDL and other senior developers. 3.0 was released waaaay to early and did irreparable damage to the perception and future of the language.

That 3.X is still slower than 2.7 and offers only a handful of features which justify breaking the ecosystem is borderline unforgivable.

[–]breamoreboy 0 points1 point  (0 children)

Do you earn your living writing fiction? To start with it was expected that it would take 10 years for Python 3 to take over the world so there's still two years to go.

Decisions about Python development are NOT restricted to the BDFL and senior developers. Anybody can comment and if you (plural) have something sensible or new to add to the debate then you'll always be listened to.

I have no interest in Python's runtime speed, programmer time is far more important to me. As for the "handful of features" that's plain nonsense, as is "breaking the ecosystem". The biggest change is the bytes vs string saga which most people welcome.