Hacker News Reader

Comment by crusso | Hacker News Reader

I just got back into some Python programming after a 2+ year hiatus from the language.

I'm stunned that this 2.x vs 3.x debate is still happening and that 99% of all libraries in use* haven't been converted to 3.x. I like the language, but ... damn... If it weren't for the scikit/numpy stuff, I'd stick with Ruby. The Ruby community seems much less fragmented and wants to see the language move forward. It helps a lot that the 800 pound gorilla, Rails, keeps up with Ruby releases.

edit: * By that, I mean that the conversion rate for commonly used libraries hasn't hit 99%.

View on HN

> The Ruby community seems much less fragmented and wants to see the language move forward. It helps a lot that the 800 pound gorilla, Rails, keeps up with Ruby releases.

You kind of answer your question you know, the reason why Python is so fragmented wrt Ruby is precisely because it has a much larger number of uses case: scientific (numpy/scipy/panda), sysadmin, web (django, bottle, ...), games (Ren'Py, ...), etc. Ruby on the other hand is pretty much just Rails[1]. It doesn't make Ruby a bad language, but then it's a lot easier to handle the migration.

[1] Yes, Ruby can also do games and statistics, but AFAIK, it's nowhere near as much used as numpy is to Python.

Thats wrong, Ruby is also used in a lot of devopsy stuff and I've seen quite a few uses of Ruby in other fields. Also, even the web community is rather fragmented now.

Also don't ignore that Ruby has a _huge_ subcommunity in asia that you rarely get any news from, using the language for many other things.

Still, an aggressive push towards the future is part of the Ruby mindset. If your lib doesn't work with Ruby 2.1, it is not considered maintained. That helped _a lot_ during the 1.8->1.9 transition, which was basically Rubys Python 3 moment. The Ruby community managed to cross that bridge.

> Ruby on the other hand is pretty much just Rails[1]

Puppet and chef say hi.

Well there is a HN front page story just now about Puppet moving to Clojure ;).

(And Chef is part Erlang...)

That being said, my point wasn't that there are no software outside of Rails, that would have been quite a claim, but rather than Ruby is much more defined by Rails than Python is defined by Django, which is why migration which alway be much more difficult on this side of the animal kingdom.

This is completely not true, on PyPi there are more libraries supporting 3.x than 2.x. The only major 2.x packages that I can think of that haven't been ported are twisted and gevent(?).

http://python3wos.appspot.com/

And in Python 3.4+, much of the async functionality of Twisted will also be available in the Python standard lib itself (asyncio, Tulip, http://legacy.python.org/dev/peps/pep-3156/).

You are reading that wrong. Having 3.x support does not imply lacking 2.x support. In fact, I believe all those libraries support both 2.x and 3.x.

"I'm stunned that this 2.x vs 3.x debate is still happening"

The worst thing to me about this transition is what it says about updating existing languages. Python 2 to 3 wasn't that large, really, and look at the resulting screwup, still ongoing. I was on the pro-Python 3.0 side (though I had 0 influence on the decision) and honesty compels me to admit that I never dreamed that it would go down like this. I never would have been pro-3000 if I'd known.

Anyhow, to anyone who has ever read about Go or Clojure or Nimrod or Rust coming out and asked "Why do we need another languge?", the answer is: "Look at Python 3." If you want to tweak anything about an established language, it's almost easier to "just" bring up an entire new language and stack than to fix the old one. And unless our existing languages are Practically Perfect in Every Way... and they're not... we need fixes, which means we need new languages.

The deprecate-warn-remove pattern seems to work well enough for smaller changes.

So maybe it's only when you want to do something as invasive as switching the default string type that things go so sideways, if that is even the right description for Python 3 (which I think you could argue was really about having a better language available in 2015 or 2016 or so, not just being the Python after 2.7).

Where do you get that many libraries that aren't converted? Most, at least the ones still under development, are.

He is not saying that 99% are not converted, he is saying the conversion rate is not 99%. E.g., the conversion rate could be 90%, or 80%, and his statement would be correct.

Ah. What a very poor way to phrase that, though.

You guys can downvote me all you want for bringing up an uncomfortable truth, but the fact is that from the outside, it looks like there's still a huge schism in the Python community and that it's not at all obvious that users should be jumping into the 3.x tree to get miscellaneous work done.

As far as specifics, one of the first tasks I wanted to perform was to survey some of the NoSQL databases with some test cases that I would build in Python.

Mongo had a good 3.x driver and I worked with it. Great... but then these drivers all put me into a brick wall trying to use 3.x: couchdb, pycassa, happybase, and cql. There were numerous others that I tried along the way, but I don't have notes on all the failures.

Now, rather than trying to be 3.x pure, I don't even bother checking. I'm just using 2.7 for this project.

Personally, I think the larger problem is package management. Most of my python projects use lots external libraries that often conflicting binaries. I find that difficult to manage as it is.

Python is the least special component in the mix and I would be very reluctant to have to upgrade everything just for 3.x.

I'm not that familiar with Ruby, but fix any of its version updates fundamentally break backwards compatibility the way Python did with the Unicode string changes in 3.0?

My organisation has a massive internal platform, with hundreds of applications all developed in Python 2.6. We are in the process of upgrading the base platform to 2.7 but I believe we will never be able to upgrade to 3.x. We have hundreds of thousands, perhaps millions of lines of Python code and it's growing all the time. When we started the project version 3 wasn't really a practical option.

> I'm not that familiar with Ruby, but fix any of its version updates fundamentally break backwards compatibility the way Python did with the Unicode string changes in 3.0?

Yes, the Ruby 1.9 release broke backward compatibility and there was quite a time when lots of Ruby stuff was stuck on Ruby 1.8 and you saw much the same stuff as Python 2 to Python 3.

Indeed, one of the big issues was a major change in string handling (to encoding-aware strings), just as with Python.

It resolved more quickly, but I think that's largely due to the fact that Ruby had less diversity of libraries that were critical in one domain or another than Python, and thus less holding it back from changing over. Python has been something of a victim of its own success here.

Reply on news.ycombinator.com