I just had Guido van Rossum’s blog pointed out to me, and on it, he’s just made an announcement about the next “major” version of Python, for which they’re going to do some massive internal changes, and (god forbid), break backward compatability. So, firstly, you may want to read the post, which you can get here and then take a look at some of my thoughts.

  • Firstly, removing “print” as a keyword (and rebirthing it as a function, a la C) is something that should have been done years ago — truly it is an abomination and deserves to die a slow and painful death.
  • Many functions useful to the building of for loops have had their entire internal structure revamped; instead of building lists and iterating over these lists, they simply use an iteration function — from an algorithmist’s point of view, this is truly wonderful (technical details follow). The current python model implies that to initiate a for loop, you would need to go through an O(n)-time process of constructing a list, and then use that list to get an iteration variable (which has an O(n) space overhead) — clearly not very efficient. The new version of range acts like Python’s xrange(), which simply uses an iteration function. The time and memory increase will be enourmous.
  • Division (where necessary) is now floating-point by default; so 1/2 will now equal 0.5 instead of 0. From a teaching point of view, it’s going to be wonderful.
  • A Java-like Class hierarchy now exists, which, despite my great hatred of Java, is one of its OO-related strong points.
  • So, all in all, I think Python 3K is going to be very interesting, indeed, and am looking forward to trying out some of the alphas when they’re out (August)

    2 thoughts on “Py3K

    1. Well, it looks like it’s going to be an interesting language. Almost glad I didn’t finish learning Python 2.

      I’m not sure I agree with you on the print thing. When you have a purely interpreted language, you print out things a lot (well, Python does at least). Thus, it makes sense to have a print function built-in. Not sure how this will change in Py3K though.

      And why the random K, anyway? (this is rhetorical, the answer is on Wikipedia)

    2. Well, in relation to what you said, I expect that most implementations of the language will implement it as a built-in anyway, but with far more consistent syntax.  It would also mean that you can do the same things as you can do with function pointers in C.  For example, if you had a logging function, you could change its behaviour by passing a function




      This is very much like how Scheme would accomplish similar things (which is definitely a good thing).

    Leave a Reply

    Your email address will not be published. Required fields are marked *