On Tue, Dec 16, 2014 at 01:06:19PM -0500, D. Hugh Redelmeier wrote:
| From: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> | | On Tue, Dec 16, 2014 at 10:31:04AM -0500, William Muriithi wrote: | | Please no HTML crap. Major demangling done by hand below:
Thanks.
I do not intend to make a habit of it, but the question actually seemed interesting enough to bother.
| > Last week on Monday, Hugh listed a list of talks that were to take place | > following Tuesday though that didn't happen.
"were to take place" is too strong. I put forward some ideas to try to make an empty spot more interesting (in no official capacity!). It turned out that the spot wasn't empty. That's a good thing.
What was empty was the meeting announcement on the web page. Not so good.
It was a bit confusing.
| > I did note though he raised the issue of how entrenched python 2 is. I | > am on python list and boy, that debate has been in the second week now.
I'm not much of a Python user. I'm certainly not too aware of things in its ecosystem.
I think that it is good that language powers-that-be consider incompatible updates. Otherwise mistakes are with us forever. They should be infrequent and probably batched.
Well that does seem to be mostly the case with python 3. I am still very very very disappointed that they did NOT remove the broken and essentially useless lambda support so that they could some day replace it with a working one. Python likes to make it seem like you can do functional (rather than procedural) code in it, and then when you try it goes "ha ha, fooled you".
It helps a lot if the incompatibility can be mechanically cleansed. Second best: mechanically detected statically. Third best: mechanically detected dynamically. Horrible: just behaving different at runtime.
At some point, the community has to go cold turkey. No new work on libraries etc. for the old thing. It's like taking off a bandaid: net pain is less if the transition is quick. Of course some kind of synchronization would be useful. What better use of a BDFL.
Well as long as they make it easy to keep around an older version for handling old code.
| > What I find odd is how some of the devs there misjudge the need of | > distribution support. In most companies, installing two versions of | > python is none starter, so don't see python 3 being widespread until | > after two release of Redhat with python 3 native support. Two releases | > as most people are still on RHEL5 and RHEL6 for example. | > That may be around 2020 and hence a little early to invest in python | > 3 scripts.
RHEL5 and RHEL6 have very long support cycles. It is unreasonable to claim those as requirements. In fact, they are designed to be stable. Doing new development on and for them is kind of a contradiction. OK, I admit that until 7.1 is out, maybe 6 can be defended.
It is rather unreasonable how some people insist on stability above all else, which means not changing things, and then at the same time complain that new features are missing.
Fedora 20 seems to have Python 2.7.5 and 3.3.2. Centos 6.6 only has python 2.6.6 Centos 5.11 only has Python 2.4.3
This speaks to how much RHEL values stability.
Perhaps Python routinely and frequently breaks compatibility and that's why these old versions hang around.
BTW I consider the stability of RHEL (or Windows) a bit of a problem. Perhaps our way out is virtual machines or containerization. They change coupling. I don't really like that.
| It is rather annoying when languages stop supporting existing working | code. To me that pretty much means the language is immature and perhaps | even badly managed. Not that that has ever stopped a language from | becoming popular.
There are so many language mistakes frozen in amber.
How long did C keep "int" is the default type if you neglect to mention a type in a declaration? This should have been a compile-time diagnosed error decades ago.
But you saved 4 bytes of code each time you didn't specify. Think of the bytes saved.
How long did FORTRAN allow undeclared variables?
I don't understand what's so hard about the Python 2 => 3 transition. Is it too big a step? Are there not enough attractions? Is the first step a lulu[1]?
I think a lot of people rely on libraries for python, and until those are converted to work with the new version, people can't move their own code to the new version.
[1] phrase is perhaps out of date but you can see it at the end of <http://www.dailymotion.com/video/x48aud_merrie-melodies-jack-wabbit-and-the_shortfilms>
-- Len Sorensen