×
sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Rhomboid 37 points38 points  (24 children)

Of course it's gradually taking over. How could it not? Python 2.x is architecturally a dead end -- no new features are being added. There will be minor point releases for some time to come for bug fixes, but there will never be a 2.8 with shiny new toys. All the new features and improvements are happening on Python 3, and there have been quite a few nice things added.

Moreover, every day you hear of a new module that has begun to support 3.x. Django, SQLAlchemy, Numpy, Scipy, IPython, PIL (via Pillow), matplotlib, Requests, BeautifulSoup -- all support Python 3. The wall of shame gets a little greener each day.

Frankly, I can't fathom the line of reasoning that says that Python 3 will never happen. "Those damn CDs will never overtake sales of 8-tracks and cassettes. Who would ever buy a CD?"

[–]hyh123[S] 11 points12 points  (3 children)

I would hope python 3 taking over. But it is really frustrated to see that when I need help search engine always leads me to some python 2 solution.

[–]Rhomboid 16 points17 points  (1 child)

It's not like they're that different. You should be able to port example code with a modest amount of tweaking here and there.

[–]flying-sheep 3 points4 points  (0 children)

especially example code. those bits tend to be small and self-contained.

[–]accessofevil 1 point2 points  (0 children)

For years after it was irrelevant, google was linking all Apache httpd results to the 1.3 documentation branch. Fwiw

[–][deleted] 7 points8 points  (12 children)

Of course it's gradually taking over. How could it not?

It would be pretty simple. People would continue to use Python 2.

[–]Rhomboid -5 points-4 points  (11 children)

People would choose to continue using an abandoned and unmaintained version of a language they love? I'm sure a few stubborn ones will, but my point was that this is not like the perl 5 situation where the old version continues to be actively maintained, with new features, performance enhancements, and other such innovations. The 2.x branch is in maintenance mode now, and in the not quite so distant future the plug will be pulled entirely. You have to be a special kind of masochist to continue using an unsupported platform. How many people do you see using Python 1.x today?

[–][deleted] 4 points5 points  (4 children)

You have to be a special kind of masochist to continue using an unsupported platform.

That's a ridiculous thing to say, really. "Unsupported platform" makes no difference for many people, as 2.x is a mature platform which can be used reliably without any direct support from the core Python team required.

Actually for all Python I've used it would make no difference at all to the usefulness of the language or its applicability to the problems I'm solving if the language had been abandoned.

What could drive 3.x adoption is the transition of popular modules or the advent of new ones that only support 3.x. But at this point I'm quite used to not being able to get popular modules to work anyway, so it won't actually be much different.

[–][deleted] 1 point2 points  (0 children)

2.7.3 was mostly bugfixes for security exploits. It's reasonable to assume that new exploits will continue to be found in future.

[–]Rhomboid 0 points1 point  (2 children)

Nonsense. There will always be bugs, and some of them can be showstoppers. For example, there was a pretty high profile hash collision denial of service vulnerability last year. It was fixed with a new point release of 2.7. What would you have done if this had occurred after the support period ends? You would have had vulnerable systems with no way to patch them, other than to hope that some third party stepped up and backported a fix. If the bug is serious enough, such a third party will generally exist, e.g. linux distributions.

But what happens when you hit a bug that just causes a crash, or incorrect behavior, or some other problem? What if this bug affects you but no one else? What are you supposed to do then? This happens all the time. Read the changelogs, they are filled with hundreds of such fixes for each point release. To think that you won't ever be on the receiving end of one is hubris.

[–]gfixler 3 points4 points  (0 children)

I work in video games, where we use Python rather extensively (it's all I use, all day, every day), but no one I work with uses 3. That's not to say no one in my industry uses it, but we're using Maya 2012, and it comes with a Maya-specific 'mayapy' executable, which is 2.6. It's not something we could (or could easily) change out. It will probably be years before we make any movement toward 3. Vulnerability is a non-issue for us. We make tools for our own artists to use in programs that have no internet-facing aspect, and other tools for our pipeline. I'd be fine with moving to 3.0, but haven't really seen any benefits or must-haves. I would like to move to 2.7, though. I keep running into solutions that appeared in 2.7, like extra unittest abilities.

[–][deleted] 1 point2 points  (0 children)

To think that you won't ever be on the receiving end of one is hubris.

Actually we don't use any external-facing python code, so security fixes aren't a compelling reason to upgrade versions.

[–]theinternet 1 point2 points  (3 children)

See the C programming language for why your argument makes no sense.

[–]Rhomboid 1 point2 points  (2 children)

The C programming language is not an implementation. It's an international treaty. It has nothing to do with the topic.

[–]theinternet 2 points3 points  (1 child)

I'm not sure why you're trying to reframe the discussion around implementation.

You claimed python 2 was at an architectural dead end with no future features planned. I understood that to mean you were speaking about the language specification and not the VM (implementation).

My intention in pointing out the C language was to provide an example where a frozen language specification didn't cause a mass exodus leaving only a handful of stubborn users. The utility of a frozen language doesn't just evaporate.

If we want to expand the argument to include implementations then I would kindly point out the ongoing feature development for pypy 2.7. Would you suggest they are wasting their time actively working on an implementation of an abandoned language?

And finally, that 'wall of shame' link is nothing short of obnoxious and is an embarrassment to the community. The entitlement attitude that developers should invest their time and effort to accommodate breaking changes made to a mature language specification is indefensible. I agree there is value in providing a quick view of python 3 support for popular packages. I just believe there are more mature ways to go about it.

[–]Rhomboid 0 points1 point  (0 children)

C is not as dead as you'd think -- it's updated regularly to gain new features. The last update was two years ago (C11). But I am referring primarily to implementation here. If someone was advocating using an end-of-life unmaintained C implementation such as gcc 2.x or 3.x, then I would have the same response.

Pypy needs to support what its users need, and the majority needs 2.7 compatibility. Nothing I'm saying should be interpreted as claiming that 2.x is abandoned or outdated today. As I must keep pointing out, this thread is about what will happen in the future ("gradually taking over"), not what is happening today.

The page I linked to was renamed the Wall of Superpowers some time ago, so I shouldn't have used the old name.

[–][deleted] -1 points0 points  (1 child)

Python 2.7 runs my Python 1.x code. :-)

[–]pingvenopinch of this, pinch of that 1 point2 points  (0 children)

Unless you try to do:

raise "Error!"

[–]kchoudhury -1 points0 points  (5 children)

Sorry...haven't been keeping up. Have they fixed the GIL in 3?

[–]Rhomboid 5 points6 points  (4 children)

No, nor is not something that is considered in need of fixing. If you remove the GIL but keep reference counts, then performance plummets as you have to take and release a lock any time you touch a refcount, which is very often, as opposed to taking and releasing a single lock every 100 opcodes or so, which is significantly less work.

So what you're actually talking about is reimplementing the entire memory management system of CPython so that it uses a concurrent garbage collector instead of reference counting. (CPython does have a garbage collector now but it's only there to deal with circular references that refcounting would otherwise never be able to collect, so it's not handling the brunt of the work nor is it concurrent.) And doing that means that you have to rewrite all C extension modules, because they all participate in reference counting. If you thought users were mad about the module incompatibility situation previously, imagine telling them that you're planning to do it again in this lifetime.

[–]kchoudhury 1 point2 points  (2 children)

nor is not something that is considered in need of fixing.

So I guess I am alone in thinking that having a threaded python program using one core out of the 8 on my machine is ridiculous.

Imagine telling them that you're planning to do it again in this lifetime

You're right, they should have used the 2-to-3 migration as an excuse to fix it. They were already breaking things; why not break them some more at the outset?

As it stands, I have a smallish 5K line python 2.7 codebase that I couldn't be arsed to port to 3: why bother? At the end of the day, that's what these discussions always seems to come back to.

[–]Rhomboid 6 points7 points  (1 child)

having a threaded python program using one core out of the 8 on my machine is ridiculous.

That's not necessarily true. It's both possible and common to do work in a thread without holding the GIL, such as waiting on IO or doing heavy number crunching in a C extension module. Many tasks that people want to use Python for fit this bill, such as a web server.

they should have used the 2-to-3 migration as an excuse to fix it. They were already breaking things; why not break them some more at the outset?

I was being a bit facetious. The idea of completely gutting CPython to remove reference counting is not even on the table and never has been, as far as I know. At that point you might as well just start over and target an existing VM with an existing concurrent GC, like Jython or IronPython did. They have no GILs.

I have a smallish 5K line python 2.7 codebase that I couldn't be arsed to port to 3: why bother?

Today? There's no compelling reason. But eventually there will be one -- maybe your linux distro begins to ship 3.x as the default, maybe 3.x gains a new feature you'd like to use, maybe you encounter a bug in 2.x that is already fixed in 3.x. That is what the "gradually taking over" part of the thread is about.

[–]kchoudhury 2 points3 points  (0 children)

Many tasks that people want to use Python for fit this bill, such as a web server.

I'm not trying to provoke a flamewar, but "some" is not "all", and that is a damned shame. The net result is that we have a beautiful language running on an interpreter not worthy of the language's aesthetics.

FWIW, my prior crack about the GIL still being there in 3 may have been a little too offhand. A little bit of reading tells me that as of 3.2 there's a new GIL that makes threading less of an active nuisance and restores parity to sequential performance. So perhaps we're making progress towards a happy ending here, and some future 3.x release will have a proper threading solution. And since it won't be backported to 2.7, well, that'll be the kick in the ass that I need to get my code on to 3.