Hacker News Reader

Comment by krychu | Hacker News Reader

> The main reason for Python 2 users to not switch to Python 3 is the lack of motivation/killer features. We need to therefore be more proactive in encouraging people to switch to Python 3 by (a) making sure that any new users are always directed to the latest Python 3 version, and (b) releasing, in the near future, new major versions of packages for Python 3 only, while maintaining long term bugfix support for Python 2 versions.

That's the evil right there. Read carefully what's written.

"The main reason for Python 2 users to not switch to Python 3 is the lack of motivation/killer features". Which says that users are familiar with what Python 3 has to offer but consider it not good enough. Why would you then jump to a conclusion that you have to be more proactive in directing people to switch to Python 3. Or even better, to stop adding features to what 81% of people use.

View on HN

In my experience the main reason is actually people who just looked at 3.0, decided it didn't have anything new and required work to port over, and then never looked at 3.1, 3.2, 3.3, 3.4 or the in-progress 3.5.

Which means those people don't know about/don't get to use, among other things:

* Vastly improved unittest module, including mock objects

* Dictionary-based logging config

* The sysconfig module

* The pathlib module

* Built-in enums

* Single-dispatch generic functions

* The statistics module

* The asyncio module

* The "yield from" syntax to delegate to generators

* The lzma module

* The ipaddress module

And that's without getting into 3.5, which adds things like the matrix multiplication operator that science-y packages will care about and probably port for.

You can probably scratch the statistics module as something scientists might be interested in; as much as it's simple set of functions is useful for new users who are overwhelmed by numpy, it doesn't add any new capability to python.

With that said - I love it.

Almost none of these things are used in scientific computing though. Maybe asyncio and yield from.

I suspect enums have uses, as do the improved async code constructs (and there's more of that in the pipeline).

Yes, I do use python for scientific applications and enums are one of the things I miss - I've built around it in python 2.x by using this construct:

    def enum(*sequential, **named):
        enums = dict(zip(sequential, range(len(sequential))), **named)
        return type('Enum', (), enums)

    Init = enum("NOTHING_LOADED",
    "DEPENDANT_ENTRYNODE_ATTRIBUTES_LOADED",
    "ROUTINENODE_ATTRIBUTES_LOADED",
    "DECLARATION_LOADED"
    )

    myState = Init.NOTHING_LOADED

3.x is still a non starter for me since many clusters where I want my software to work still only come with 2.6, e.g. I can't even use dictionary comprehensions. Adoption for scientific software is heavily influenced by how many external dependencies you have - requiring users without root access to compile python 3.x for their cluster home is a no-go.

No offense meant, but if you're at a stage where you use a pre-2.7 version because that's what comes with the OS, then it's not really a case of "looked at 3.x and decided it didn't have anything".

OS vendors who will be supporting ancient Python versions until the next decade are a blight on the entire ecosystem.

> it's not really a case of "looked at 3.x and decided it didn't have anything"

I agree, this isn't the main reason why I'm not looking at 3.x.

Yup, enums I use as well, you're right. Still... like 3 trivial things that can be overlooked.

First of all, it's not evil so let's not get crazy.

"The main reason for Python 2 users to not switch to Python 3 is the lack of motivation/killer features". Which says that users are familiar with what Python 3 has to offer but consider it not good enough.

You could have lack of motivation because you're familiar and decide that you don't need it - or - you could have lack of motivation out of ignorance or misunderstanding about the benefits. Both are reasonable and if it's the second one, there would be benefit from being more proactive about directing people to switch and explaining the reasons.

Why would you then jump to a conclusion that you have to be more proactive in directing people to switch to Python 3. Or even better, to stop adding features to what 81% of people use.

Maintaining 2 lines of development does have a cost associated with it for the entire python community involved. I think overlooking this was part of the problem with choosing this python3 strategy to begin with. I personally would not have done it this way and I get what you're saying about continuing 2.7 line but I think it's too late and now 2.7 and 3.4 have improved to the point where the porting task is reasonable.

I think at this point the community should just get it over with. I say this as someone who primarily develops on python 2.7 (mainly due to library dependencies) so I get where you're coming from.

That pretty much sums it up for me. I wouldn't have done it this way, but we are too far ahead on the Python 3 line and it's probably time to let go off the debate and move on to Python 3, at least for new projects.

Needless to say that the Python web developers community was set back by couple of years due to diverted attention. When Python should have been looking at concurrency and async support, everyone had to get busy maintaining duplicate code. The biggest issue probably was for the library developers (Django, Flask, Jinja, pymongo etc) to create a new Py3 package. But now that most of the important libraries and frameworks have moved to Python 3, application developers could probably move along with the change. It's not that much work for the app developers.

> by (a) making sure that any new users are always directed to the latest Python 3 version, and (b) releasing, in the near future, new major versions of packages for Python 3 only

How about a major speedup? Even a 10% speed up would be a big motivation!

You don't need fancy JIT, just less costy function calls and modern interpreter optimizations.

Maybe for the sake of having a single version to focus maintenance efforts on?

I've never seen it happen. (having a single version to focus maintenance efforts on)

1. Waiting for other favorite libraries to be ported over.

1. Waiting for other people to work the bugs out.

1. Waiting for a new project to work on. I have work ongoing in Python3 and 2.7; and I have no plans to migrate existing work from 2.7 to 3. I would not have migrated existing projects that are working; let sleeping dogs lie, seriously, you'd have to fight a lot of scientists if you told them you wanted to change anything in their (working) DAQ, just for the hell of it.

Directing people to the newest version is unsolved. If you type "apt-get install python [or pypy]" you get 2.7. This is obviously a problem.

Basically, everything here suggests that 2.7 is the official version and 3 is some kind of risky beta.

It's anecdotal, but Arch has had Python 3 as default for over a year. I think Fedora is coming close to this too.

Almost five years[1] in fact. To correct some other common misunderstandings elsewhere, it is not correct to say that python3's "changes are extremely breaking." It is easy to write code that runs under both 2 and 3, and 2to3 can convert 99% of code I've thrown at it[2]. The last one percent is straight up bad code that does crazy things like override the list() function with a variable.

The other pain point is hybrid python-C libraries that monkey around with Python internals - but those often have trouble keeping up with mere point releases. Given everything done to make the transition easy, if a library doesn't work under python3 by now it is a code smell. Either the library does weird things under the hood or it is practically unsupported.

Regarding "lack of killer features", there are some pretty compelling ones[3]. I've been writing all my code in py3 (or at least making it support both 2 and 3) for years now.

[1] https://www.archlinux.org/news/python-is-now-python-3/

[2] About two dozen packages I maintain and a bunch of personal projects.

[3] http://asmeurer.github.io/python3-presentation/python3-prese...

So is Ubuntu.

Because Python 3 made breaking changes that make the langauge easier to use for 99% of people. But the changes are extremely breaking.

This has been my takeaway too.

Yep stick to Vax/Vms

It's not that it isn't good enough, it's that the cost of switching is larger than the value of what they believe they would gain. I believe this is very common in academic settings (consider, for instance, how many people still see no reason to switch away from Fortran).

but with Fortran, the reason is generally because there's a large highly optimised legacy codebase that few understand or want to understand. Also it's still difficult to beat Fortran in terms of performance.

Python has neither characteristic. Switching to Python 3 is really easy, and it's easy to understand both. There are only a few projects where it would take more than a week or two to move from Python 2 to non-idiomatic Python 3 (assuming that Python 2 needn't be supported afterwards). Sure for some unviersities or whatever it wouldn't be in the budget, but where active development occurs by this point it's largely due to stubbornness (or need to support python 2 due to stubbornness of others).

I worked for a physicist for a number of years who refused to give up on Fortran. It wasn't for (computer) performance reasons. It was because he could quickly get his ideas into code with Fortran. He wasn't interested in computing for the sake of computing.

Most scientists use computers as a tool to prove that something works. Since few scientists are required to make commercial tools based on these ideas, so there is no reason to use latest software engineering fads/techniques. I know a guy who writes his software in VBA+Excel, and for him it is all that he needs to get data for his scientific papers.

It's not that it isn't good enough, it's that the cost of switching is larger than the value of what they believe they would gain.

That's exactly what "not good enough" means. Getting rid of the GIL, or a 5x performance increase, or optional static typing might have been worth breaking everyone's code. Somewhat better Unicode handling wasn't.

Jython and IronPython both remove the GIL, and PyPy is often roughly 5x faster than CPython. Strangely enough, these projects don't seem to be as widely used as I'd expect.

By the way, optional static typing is available in any version of Python by using MyPy.

Because all the alternatives do not support many C-extensions, especially numpy, without which no scientists would look at Python at all.

All three of those bundled into the official release might have done it.

>I believe this is very common in academic settings

It's even more common in enterprise settings, where the cost of switching also includes real money, not just some postgraduates porting code over...

Reminds me of Mozilla and HTTPS.

just include it for default in ubuntu repositories and distributions

Reply on news.ycombinator.com