Just curious

Posted Feb 25, 2013 22:30 UTC (Mon) by man_ls (guest, #15091)
In reply to: Ruby 2.0.0 released by tnoo
Parent article: Ruby 2.0.0 released

I am glad we also/still have Python.

What series, Python 2.x or Python 3.x?

Speaking of which, I have heard that Ruby is even worse in that respect than Python, breaking backwards compatibility in point releases (1.7 vs 1.8). Does this Ruby 2.0 break too many things, or has sanity prevailed?

to post comments

Just curious

Posted Feb 25, 2013 23:04 UTC (Mon) by sml (subscriber, #75391) [Link] (1 responses)

I've worked quite a bit with python 2/3 and ruby 1.8/1.9 and python is certainly far worse with regards to maintaining backwards compatibility.

While there are some incompatible changes in ruby 2, the majority are added features and optimisations, and unlikely to cause major breakage.

Just curious

Posted Feb 25, 2013 23:20 UTC (Mon) by cortana (subscriber, #24596) [Link]

> python is certainly far worse with regards to maintaining backwards compatibility

The language, the standard library, or third party modules?

Not that it matters if Python sucks for what you're doing--I would just like a little more detail.

Just curious

Posted Feb 25, 2013 23:28 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

I'd be more interested in what it takes to support all the major versions with one code base. For example, the only way to get exceptions which works from Python 2.4 (RHEL 5) to Python 3.3 (Fedora 18) is to use sys.exc_info(); "except X as e" doesn't work in 2.4 and "except X, e" is no longer accepted in 3.x. I have no real experience with Ruby to know how hard such support is in it.

I'd be happier if one of Python 2.x and 3.x just went away, but that's not going to happen any time soon and short of splitting the codebase, supporting both can be a pain. Plus, 3.3 now supports namespace modules (which is emulated by straight.plugin[1] for now), so there's another version break I have to be aware of.

[1]https://github.com/ironfroggy/straight.plugin

Just curious

Posted Feb 26, 2013 0:27 UTC (Tue) by cjwatson (subscriber, #7322) [Link]

OTOH, if you can afford not to care about pre-2.6 (Debian squeeze; Ubuntu 9.04) then supporting both 2 and 3 is rather easy in most new code provided all your library dependencies are available - you can mostly write in Python 3 style with a bit of extra boilerplate - and for old code the main difficulty is getting bytes vs. text straight which is no bad thing anyway. I've written a few thousand lines of bilingual 2/3 code in the last week alone.

Just curious

Posted Feb 27, 2013 3:29 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

Can't you just bundle Python 3 with your application and be done with it? I find it unbearable to support a version as old as 2.4. And shame on Red Hat for not adding a Py3 package to RHEL 5.

Just curious

Posted Feb 27, 2013 3:44 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

The project has Python bindings, not an embedded Python, so shipping our own isn't really an option[1]. To be fair, there is a 2.6 package for RHEL5, so that is a possible path. Also, the chance of the RHEL5-targeting project using the Python support is low, but I'd rather keep compatibility incrementally than as an all-at-once change. The test suite is where most of the code which hits this problem lives, and it's nice for code that doesn't ship to raise a lower version bound on something. Doesn't make it less painful.

[1]I suppose, technically, it is, but we also try to play nice with Python world by converting between NumPy and C++ data structures instead of forcing Python to use a C-like API. Losing that by trying to get an embedded Python to work with a non-embedded Python isn't worth it (or we ship NumPy too...). Unless I've missed some docs on that...