This post originated from an RSS feed registered with Ruby Buzz
by James Britt.
Original Post: Guido @ Google : Python 3000
Feed Title: James Britt: Ruby Development
Feed URL: http://feeds.feedburner.com/JamesBritt-Home
Feed Description: James Britt: Playing with better toys
self was fortunate enough to get a seat at Guido van Rossum’s presentation on Python 3000 at Google’s Tempe, AZ facility.
I don’t know enough Python to appreciate the significance of the details of what’s new and notable in this next major release of Python, but the talk was interesting for the chance to hear some rationale for why a language designer might opt to add, change, or discard things.
The first thing to know is that Python3K will break current code. This is the version where past mistakes get corrected and cruft and crap jettisoned. Guido made a number of references to various features and their implementation in C. As is now becoming true for Ruby, Python has multiple implementations. The C version is (I believe) the canonical one. However, there is also Jython, IronPython, and PyPy .
At the end of the presentation, I ask how the existence of alternate implementations influenced decisions for Python 3K. Guido said that these were important, and the ability for them to stay compliant as Python the language evolved was a factor. There were at least some features or behavior were rejected because a JVM or CLR implementation would be sufficiently hard or impractical. (No, I don’t have specifics, and I’m paraphrasing from memory, so consider this an impressionistic recollection of the talk rather than a detailed report.)
There were some other items that caught me eye; loosely speaking (and, again, coming from a brain a bit exhausted from a 500+ mile drive earlier in the day) they would facilitate method overloading and type checking.
Dispatching methods based on the “type” and number of parameters is not something Ruby offers out of the box. It is something that comes up, though, as part of the the ruby-talk Static Typing permathread (which, now that I think of it, seems due for an appearance). Various arguments get put forth, usually with a good deal of misunderstanding from the pro-static camp about what a “type” in Ruby actually is.
I don’t know the use cases or culture for Python coding, so I can’t say how these features would be used. From my cursory preview, though, they seem to offer the option to write code that essentially dumps duck typing in favor of more B&D behavior .
Perhaps this is something Pythonistas desire; it’s curious how the Python culture and Ruby culture have, for example, very different takes on re-opening classes. Pythonistas (as far as I’ve seen) frown on it. It’s “monkey patching”. You don’t do it unless you really, really have to; it’s a hack. Rubyists, on the other hand, consider it simply what the language does. Re-opening a class is no more scary than re-assigning to a variable. We really don’t need someone telling us “you’ll shot your eye out!” We know.
(BTW, the phrase “monkey patching” pops up here and there in Ruby discussions. Usually it says more about the speaker than about the code.)
Previous Topic
