The main problem with Python 3’s lack of backwards compatibility is not that you need to change the code. That’s pretty easy. No, the main problem is that you need to wait for all the libraries you use to be ported first. And when you use a whole framework that can be a lot. Zope + Plone involves some 170 packages or so.

And amongst the absolutely most popular packages out there has been Setuptools. So when I wanted to look into using the Zope Component Architecture on Python 3, I realized I needed Buildout, and to use Buildout I needed Setuptools. And many others, I’m sure, has had the same experience. Setuptools has become a block to Python 3.

But no longer! As mentioned earlier, Distribute now has Python 3 support, and 0.6.3 of Distribute has been out for some weeks now and seems reasonably stable. And that means, that Yes! It is finally time for You to port your library to Python 3!

Install Python 3.1 (forget 3.0, it’s too buggy) and Distribute and  read the documentation on Python 3 support. Then subscribe to the python-porting mailing list, and off you go!

I just read Jarret Hardies article in Python Magazine on How to Survive Sorting in Python 3. There it is claimed that sort() and sorted() takes both cmp and key as parameters (which is correct) but that cmp is easier to understand and more popular.

But is it easier to understand? cmp requires you to compare two objects. It requires you to first extract a value from the two objects that can be compared, then compare these values and then return -1 if the first object is smaller than the object passed in, 0 if they are equal, and +1 if the first object passed in to the comparison function is larger than the second. Or, if it’s multiple values that should be compared, you typically compare them one by one.

OK, admittedly, that is not very hard to understand. But what about using key? Well, for key you pass in a method that takes only one parameter, the object. The method then extracts a value that is used by the sorting. Done. It honestly doesn’t get simpler or easier to understand than that. It’s also faster, as the sorting methods will call the key function on each object only once.

The reason Python programmers are still using cmp instead of key (and also list.sort() instead of sorted()) is that these didn’t exist before Python 2.4, and therefore people use the old methods out of habit. No other reason. I didn’t even know about key until a year ago when I started looking into Python 3.

There is one usecase where key has one minor issue of “uhm…”, and that is if there is no obvious way of extracting one value. Maybe you should sort fruit so you want it sorted by type of fruit, and then size. So that’s two values, but key requires you to generate just one value. Well, you can simply return a tuple of the values, in the order they should be sorted. So for the fruit case (hehe), you simply do “return fruit.type, fruit.size”. It’s that simple, again.

Jarret also mentions a use case that key doesn’t cover, namely if you want to sort one value ascending and another descending. Well, it is possible to do, by generating some sort of hash that takes this into consideration, but that’s silly. Instead Jarret recommends doing tow consecutive sorts. He also demonstrates this to be faster than a cmp based comparison, so there you go.

Key is easier to implement and faster to run. You should already now use key instead of cmp. And you should buy Python Magazine, it’s getting really good.

(Also, most of the time you should use sorted() instead of sort. Because sorted can sort anything, while list.sort() of course only works on lists. That way people can pass in generators to your methods where you expected lists, and use the dynamicism of Python even more!)

At DZUG-Tagungs last weekend it turned out that Martin v Löwis had a bunch of patches for my Python 3 port of setuptools. I merged them in, and Martin then proceeded to look through all my change sets and try to actually make sure they wouldn’t break edge cases (which I never bothered with). And then who ported my changes, change for change, to Distribute, the new fork of Setuptools. He wasn’t the only one working on this during the sprint, but he did the main body of the work, and embarassingly I’ve forgotten the names of the others. Shame on me.

This means, that amazingly enough, Distrubute now has Python 3 support! The next version 0.6.2, hasn’t been released yet, but it works fine for me for Python 3. And that’s really nice! If you need setuptools for Python 3, please try out the trunk version of Distribute. Martin put in support for automatically running 2to3 on code so you can support both Python 2 and Python 3 from the same source code easily, and I put in support so that the test command also does this conversion.

So thanks to Martin and the others! Also thanks to Alex Grönholm who has fixed some bugsin the Python 3 port, and thanks to Tarek for managing the Distribute project!

Recommendation 1: xrandr

At OSCON I had problems with getting my Ubuntu MacBook to talk to the overhead projects. Yes, MacBooks are notorious for this. At the excellent DZUG-Tagungs I had the same troubles, but time to look for a fix. (At PyCon everything worked fine though, so it’s only certain projectors).

Basically, the monitor configuration tool will present me with three screens if I connect the VGA dongle. One being the LCD screen, another the VGA and a third screen seems to be the DVI screen, even though I connect the VGA dongle. Crazy stuff. The problem is that whatever you do with the VGA screen, nothing actually happens. Resolution makes no difference, mirroring makes no difference. Pressing Apply will make the screen blink and you get asked if you want to save the settings, but the external monitor never turns on.

Aftersome serious Googling I found xrandr. This saved my life. Well, OK it didn’t, but it saved the presentation. xrandr does the same thing as the screen tool, but on the command like, and unlike it, it works. Possibly it’s way more stupid, and maybe doens’t ask the monitor if it can handle the resolution or something, it just sets it. Just typing xrandr will tell you what screens you have and the modes that they support.

I’ll give you a couple of handy typical settings. For other stuff, read the manual:

Single-screen presentation setting; Mirror the LCD and the VGA in 1024×768:

xrandr --output LVDS --mode 1024x768 --output VGA --mode 1024x768

Dual screen presentation; Separate screen for the LCD and the VGA, VGA to the right of the LCD:

xrandr --output LVDS --mode 1280x800 --output VGA --mode 1024x768 \
       --right-of LVDS

As you see it’s pretty straight forward to use.

Recommendation 2: Presenter view plugin for Impress

Open Office Impress is not the worlds best presentation software. In many ways it’s pain in the ass, and I did a lightning talk at Pycon using the normal image viewer in fullscreen mode and just pictures I Googled. That was actually quite nice and much easier to do.

But that’s not always enough, and then you do need a presentation software, and for Linux the choices are limited. Now that I have discovered xrandr and know how to get separate screens in a reliable way when I’m at conferenses, I would like to have a separate presenter view, where you see not only the current slide, but the next slidem the notes and the time.

And whaddayounkow, there is one for Impress. Now, stupdly it’s not included, you need to download it as a separate plugin. Silly really. But it seems to work fine, and I’m totally using it for my next presentations. No more forgetting what the next slide is, no more looking at the clock worringly, no more forgetting to say stuff. It’s going to make me a better presenter!

So why did I tell you guys this? I should have kept the secret to myself, right? No, I shouldn’t, and with some luck I’ll tell you why not at the Plone conference!

I see Ruby people bashing Python a lot on Stackoverflow. It’s a bit sad, Python and Ruby are usually bestest friends forevah. So I started a question on Stackoverflow, not about which of them is best, but just what the differences are, objectively.

It was more difficult to make that objective than I thought, but I sure learnt a lot. And, as suspected, many of the differences are just semantic, like Ruby using @attribute and Python using self.attribute. And of course it’s objectively it’s impossible to say what language is better, which we of course knew from the beginning. That’s no surprise. The surprise is that there are so few differences that can be cast as better or worse at all. Even such things that sound like an objective good or bad, such as a language having a certain feature, turns out to mostly be a matter of taste.

I could just find these differences that in any way can be called objectively better:

1. Ruby has a reference to the class in the class body

This means that code like this is possible:

class MyClass
    initialize_magick()
end

While in Python, you would have to write:

class MyClass:
    pass
initialize_macgick(MyClass)

As you see the practical difference is very small. But Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class. And indeed, the Zope component architecture uses some heavy magic with metaclasses to make the same thing happen in Python:

def MyClass:
    implements(IMyInterface)

So it’s possible (In Python 2) by some clever tricks to get the same effect. In Python 3 it isn’t because the metaclass syntax is different, so in Python 3 you instead need to use class decorators. And what you think is cleaner of

@magickly_initialized
def MyClass:
    pass

or

def MyClass
    initialize_magick()
end

is again a matter of taste. So, a small plus for Ruby there, without a doubt. But it’s really not a big deal, because calling the initialize method after the class or as a decorator is really not a major drawback.

2. Ruby has continuations

Continuations are heavy magic. And Ruby has them, and Python has not. You can “fake” them, and it seems that many of the usecases can instead be done with passing variables into .next() which you can do in Python 3.1. The use of continuations seem rather limited, and hard to understand, but it’s there in Ruby, and not in Python. So another plus for Ruby.

3. Python has generators

You can fake them in Ruby by using blocks, or use continuations. So no big deal again, but a small plus for Python anyway, as Pythons generators are both easy and clean.

4. Python has multiple inheritance

Some people claim multiple inheritance is evil. But having it means that if you think it’s evil, you can simply not use it. I have used it a lot, never found it a problem, but I think adaptation is a better pattern. Still, it’s clearly a plus for Python.

5. Python has docstrings

Docstrings makes it possible to attach documentation directly to the classes and methods. That’sa nice documentation plus, and makes things like the Python interpreters help() function really useful. Another plus.

Aaaaannnd, that’s it!

These five small differences are the only things that I can see are objective improvements over the other language. And as you see, none of them are really major. It’s just small things that are more convenient or not. So, am I gonna switch to Ruby now, when it’s almost just as good? Nope. Because there are lot of other differences, that are differences in attitudes and semantics. And there I really like Python better. Here are three major features of Ruby that in my opinion either are misfeatures or just not of value:

1. Ruby has built-in regexp and line input looping

This is inspired by Perl, and means you can easily make a script that looks through a text file and munges each line separately and prints out another text line. This is extremely useful’in many cases. Also Ruby is said to be better to make glue.scripts, so it can more readily be used for a shell script replacement than Python. Plus for Ruby? Well, no, not in my book. I do these things sometimes, mostly in awk. If they get more complex than that, I prefer to use the clarity of Python than the obscure machinations of regexps. And having a small open(filename).readlines() isn’t that much trouble. So this is a feature I think only adds clutterm and I’m happy Python doesn’t have it. Wow! That turned out to be a subjective issue! That surprised me.

2. Ruby protects class attributes etc

Ruby treats variable names that has the first letter in capitals like a constant, so you can’t modify it. You also can’t access attributes of objects from outside the class. Python doesn’t protect your code from other programmers. If they want to shoot themselves in the foot they are allowed to. I like that. I remember when using Delphi, and I needed to subclass an object in the standard library, but some attributes or methods were protected, so I couldn’t. I ended up having to duplicate almost the whole (rather big) component class in my subclass, just because the developer of the base class hadn’t forseen my type or requirement. So these sorts of protections are generally just a problem. OK, it’s less of a problem in Ruby, as it allows you to monkey-patch the class but this still is a big plus for Python in my book. I’m sure Ruby people do not agree. It’s subjective again.

3. Ruby has blocks

But some differences are more differences in attitudes than anything else. And sometimes these different attitudes seem to in the end be the same attitude but from different angles. Ruby has for example the concept of blocks. Blocks seems to pretty much be Rubys name for closures, and it’s an abstract concept basically meaning a piece of code that gets variables from somewhere else and can have local variables that doesn’t pollute the surrounding name space.

Rubys blocks are widely hailed (by Ruby people) as something fantastic compared to Python. But it turned out to be very difficult to find actual cases where Ruby really did something in a cleaner way than Python thanks to blocks. Well, it turns out that Python also has blocks. But they are called “functions”. What’s the difference? Functions need a name, while blocks don’t. At this point a Python programmer says “Aha, so blocks are lambdas!” Yes, except that blocks can be multiline code and do anything, while Pythons lambdas are restricted to being expressions.

OK, so plus one to Ruby then? Well, no. Because what use is a block if you don’t attach it to a variable name so you can call it? In Ruby you create blocks and use them directly like this:

amethod do |variable|
    print variable
end

This is principally equivalent to Pythons

def theblock(variable)
    print variable
amethod(theblock)

Which of course is doable in Ruby as well. Which way is neater? Matter of taste again. And it becomes even harder to decide when considering that Ruby has a special statement to call the block with parameters. It’s called yield. Yield exists in Python as well, but there it’s used for generators. But the we get this code examples:

def themethod
    for a in [1,2,3,4,5]
        yield a
    end
end

themethod do |b|
   puts b
end

Which is almost suspisciously similar to

def themethod():
    for a in [1,2,3,4,5]:
        yield a

for b in themethod():
    print b

So in the end, this much touted principle of block seem to very rarely actually lead to any significantly different code than in Python. So here are widely discussed differences in principals that in the end…end up as the same thing (almost)!

4. Python has list comprehensions

It’s worth mentioning here that Python has some big features that Ruby doesn’t, like for example list comprehensions.

[foo(x) for x in alist if bar(x) != 'frotz']

But although I use them all the time because they are practical I don’t know what I think about them. Well, it’s shorter than:

foo = []
for x in alist:
   if bar(x) != 'frotz':
      foo.append(x)

But is it really neater and more readable? I’m not sure. It becomes a matter of taste again. I did not like list comprehensions when they first arrived in Python, but of course now I’ve gotten used to them. So that is not a good argument for Python. It’s subjective again.

5. Python has decorators

Decorators are prettier than the other ways of doing the same in Python, for example the above initialize_magick(class). But again it can be argued that the @decorator syntax just makes Python ugly, and that you don’t need them as much in Ruby. Again, matters of taste.

So why Python?

So, in the end, why do I, subjectively prefer Python over Ruby in almost everything? Because of Pythons clarity and simplicity, and it’s attitudes and principles. In Ruby, you have open classes, so you can extend any class. In Python, you can monkey patch in extensions into any class. The difference? That in Python it’s an ugly attitude that is frowned upon. In Ruby, many people tutorials and examples of blocks extend the Array class, like brutally monkey patching the standard types is a normal thing to do. (A hint guys: That does NOT help in explaining blocks, it’s just confusing).

In Ruby, there are no functions, but there are methods, blocks and lambdas. All of them seem to have subtle differences, and sometimes you need to not just call them, but use .call(). In Python, there are only functions. Lambdas are functions whose __name__ is <lambda>. Methods are functions that are wrapped to you don’t have to pass self. Simple and clear.

Python is more explicit. In Ruby you can skip the () when calling a method. Rubyists like that because it makes calls look like statements they say. Pythonists like me think it’s a bad idea to make a call look like a statement. If it’s a call it should bloody well look like one.

And Pythons packages and modules are just so much better for namespaces than Rubys modules. Again, subjectively. And you can choose if you want to import * in Python or not. In Ruby that’s all you can do

And all of these things, the things that makes me go “Eww…” about Ruby and “Yeah!” about Python turns out not to be features, but just subjective options of the different languages semantics and attitudes. It is truly so that none of the Languages are better than the other.

Except, of course, that Ruby sucks.

Update: Emencia has graciously offered to lend me desk space at their office. Thanks!

Working from home is losing it’s attractiveness, so therefore I’m starting to look for a place to rent here in Paris. And of course, I’d like to share it with people who also work with Python or Plone. So if you have a desk over and like to rent it out to me, contact me. Or, if you are a Python programmer or Plone person, and you also are looking to share an office, contact me. If we get some people together, we can maybe share a small office.

Requirements:

• A desk
• Internet connection
• A coffee machine, or a place to put one
• Nice easy going people that doesn’t mind my crappy French.

Bonuses:

• Good espresso
• Biking distance from my place (11e)
• Access to a meeting room
• A view

Well, that’s it, really. Send me a mail at regebro@gmail.com!

Edit: The reception was less than overwhelmingly enthusiastic, and for me to push a community project that is not absolutely necessary for me, I need overwhelmingly enthusiastic. So I’m not going to push this. I still think i could be a good solution, though.

There are two problems that can be killed with one piece of software in the world.

One of the problems is that the Python Package Index (aka the Cheese Shop) is a single point of failure when distributing python software. Well, in fact, because some packages doesn’t reside there, but are only indexed there, it’s multipole single points of failure. There is a whole bunch of servers that currently needs tobe running for you to install Plone from a buildout, for example.

A second problem is that bittorent, although being a great idea and useful for all sorts of distribution of data, is currently used pretty much only for file sharing of copyrighted materials. This means that this great protocol often gets filtered by ISPs and similar. We need a legitimate use for bittorrent.

And as you of course quickly realize, bittorent is in fact a solution to the first problem! And not only that, it also provides an answer to some other problems. Like setting up a local egg cache for a company.

So, I will start a project to do this. But before I start, I want to check if more people have had this idea. Good ideas are typically somebody elses ideas, and in this case I know that Matthew Wilkes already started on this earlier. So if you already have some half-finished code for this, or know somebody that has, give us a shout, and lets merge the projects! Also, if you want to help, give us a shout too.

Plone4ArtistsCalendar 2.0a3 has just been released on the Cheese Shop.
New in this version is various bugfixes, and support for uninstall.

Thanks to all that helped with bugfixes for the various parts of Plone4ArtistsCalendar! It’s been a real community effort with loads of people contributing! Thanks, thanks thanks to all of you!!

So, if this is so bugfree and stable, why is it still an alpha? Well, because we still need migration from Version 1.1, a new iCal implementation that supports recurring events,  and a better UI for recurring events.

I’m looking for a Windows (or Linux) video editing software or combination of grabbing and editing softwares that

• doesn’t cost hundreds of dollars/euros and
• can grab video from a web cam,
• audio from any audio input,
• keeps the synchronization well and
• has at leat two sound tracks (so I can have background musc) and
• has good frame-by-frame editing and
• doesn’t require the use of abscure file formats

Python 2.6 and 3.0 compatibility

I think it doens’t work very well without the slides though.