[hackerboos]

That's what happens when you maintain two versions, one of which has fundamental breaking changes.

When the Ruby team makes changes the attitude is generally 'deal with it'. Sure they still do point releases on older versions but only for security issues AFAIK.

Python moves forward it just does a poor job of dragging everyone with it.

[dagw]

When the Ruby team makes changes the attitude is generally 'deal with it'

However they complement this attitude by being a lot better at working with big 3rd party library developers and making sure they are on board. To the best of knowledge there has never been a Ruby release that was incompatible with RoR for any period of time. Compare to Python that jumped to python 3 without either numpy or Django on board.

[yxhuvud]

Well, on the other hand I definitely remember a point release of 1.8.7 that broke Rails :)

[wycats]

Momentarily, and Matz appeared to feel so bad about it that they have been far more aggressive about tiny-version changes ever since.

[reledi]

Sounds about right. Coming from a Python background to Ruby, I think there's more to it though. For example, Ruby version managers such as rvm and rbenv help a lot with keeping the community moving forward. Python has virtualenv but it always felt awkward to me compared to what Ruby has.

[jrochkind1]

Interesting, I haven't worked in python, but I was always jealous of python having a single 'official' solution in virtualenv, instead of ruby, where it's confusing for newcomers to figure out which one they should be using (rvm? rbenv? chruby?), and each solution has it's annoyances and problems. I always thought it would be better if the community unified it's efforts behind one solution and made sure it was bug-free, and where the language's binaries or behaviors might actually be changed when needed to support that solution.

Maybe it's just the grass is always greener.

[weaksauce]

Since you haven't used it you don't know how awkward it is compared to the Ruby iterations. Let's just say virtualenv and the packaging ecosystem is what drew me away from Python.

[nileshtrivedi]

Ideally, the operating system's package manager is supposed to solve this. User-installable alternative versions shouldn't be that hard.

[berdario]

You have a plethora of similar tools in the python world as well:

- Pythonz

- Conda

- Pew (disclaimer: I'm the author)

- Virtualenvwrapper

- Pyenv

Etc.

If you argue that people might not move to the latest and greatest as soon as possible due to the fact that people don't build their own interpreter, I can definitely agree with it: python users seem to truly prefer the python version that already comes pre-installed with their linux distribution

[reledi]

> python users seem to truly prefer the python version that already comes pre-installed with their linux distribution

Definitely. It's not that Python doesn't have the tools to switch between versions, but it's not as prevalent as is in the Ruby community. Most Python users will start their program with shebangs like

    #!/usr/bin/env python

or if they want Python 3+

    #!/usr/bin/env python3

while not necessarily using tools like virtualenv and virtualenvwrapper.

I feel like shebangs are not as commonly used in Ruby, instead you use tools and your Gemfile to specify Ruby version.

[alxndr]

Unfortunately that's lead me to need to specify my intended ruby version in several places on a ruby project (.ruby-version, Gemfile, CI config file...)

[weaksauce]

Well, Ruby version and the versions of all your dependencies and the versions of gems for different environments.

[kennyledet]

pythonz looks great, thanks