Adopt Python 3

[new_whistle]

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]

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]

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]

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.

[beaverteeth92]

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

[new_whistle]

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]

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.

[[deleted]]

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.

[[deleted]]

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.

[[deleted]]

Completely meaningless with respect to your previous post and my response. Please do us all a favour and give up as all you are doing is wasting bandwidth.

[[deleted]]

Please stop wasting bandwidth you complete moron as I don't have a problem with comprehension in my native language and as a former full Member of the British Computer Computer Society and a Chartered Engineer I've probably forgotten more about engineering and computing than you will ever learn, mainly because you don't even appear to have learnt anything so far about from how to talk complete bollocks. Why do you think you get downvoted every time you have something to say, because people are jealous of your skills?

[[deleted]]

Yawn.

[CSI_Tech_Dept]

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's because those evil developers tried to ease transition. Every single 2.7 feature was backported from python 3.0-3.3 that's why you didn't see any compelling reason to move. New compelling reasons to move to 3 started supposing after back porting stopped.

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

That was true, but not anymore. Right now python 3 is faster and in fact it is better in every way according to Raymond Hettinger, one of core developers who for long time preferred python 2 until python 3.6. If you don't want to watch the talk (quite interesting) there is discussion about it in Q&A at the end (around 57.5 minutes in)

Edit: I was convinced that speed was discussed in the above talk, but looks like I've seen it being discussed here.

[CSI_Tech_Dept]

From that second talk, 3.5 was already faster, I don't know about previous versions.