Today and yesterday we have been six people at the Bubblenet offices in Louvain-la-Neuve, Brussels, where we have been working on five.grok. The main work has been implementing views. During this my intuition proved incorrect and Godefroids correct: Most of the classes and grokkers from Grok turned out to be directly useable under five.grok with no modifications.I thought we would need much more differences between Grok and five.grok than has so far been the case. (Although security will certainly be a big issue).

As a result of this a new module has been started to keep everything related to views and layers and such, and it will probably be called grokcore.browser (although it’s currently called grokcore.view). Just as grokcore.component extracts the parts from grok that has to do with the component architechture, grokcore.[browser|view] has all the parts with Zope views. We hope to get this accepted into Grok itself, so that both Grok and five.grok ends up using it, because there is a lot of code, and a massive amount of tests to handle views, and it would be silly to have two implementations of everything.

As a result of this, five.grok now has both adapters and utilities and views, and is therefore right now starting to become useful. Some have today been sprinting on an example application of how to extend a Zope2 object with five.grok views. We hope this example application will show us what is missing and what the next parts to be added to five.grok is.

In this years summer of code, there are two related projects, Martin Lundwalls Component Registry Introspector, which I mentor, and Ulrich Fouquets Grok Introspector, which Martijn Faassen mentors. We have since the start of this planned to get together all four and work on this for some time, and the result of this is a two day mini-sprint on introspection for the Zope component architecture and various Zope variants, including Grok and Plone. The sprint is graciously hosted by Pilot Systems here in Paris, the 21st and 22nd of July.

If you are interested in coming and helping in the tasks, you are welcome! I can’t promise that the weather will be as perfect as it is today, but the cafés will still be here next week as well, so I can promise a great time! Mail me at regebro@gmail.com for more information.

MaxM’s icalendar module is a python module that reads and writes data according to RFC2445, commonly known as iCalendar. I have been using it since the fall of 2005, and only discovered a small set of bugs in it. In fact, after the release of version 1.2 in November 2006, only two (and a half) bugs have been found and reported to icalendar-dev@codespeak.net as far as I can see. Today I fixed those and released a new version. Well, in fact, I didn’t see one of the bug reports until I had made one release already, so I released two new versions today, 2.0 and 2.0.1.

Two and a half bugs normally doesn’t give you an increase in the major version number, but one of the bugs changes the API, so 2.0 is not compatible with 1.x if you use EXDATE or RDATE in your application.

I haven’t updated icalendars homepage, because I don’t remember how to do it, but they are available at pypi, and installable as eggs, so it shouldn’t matter much. So, go ahead and use this fine piece of software, and I’ll look forward to making a new release in 2010.

Changes in 2.0.1 compared to 1.2

• EXDATE and RDATE now returns a vDDDLists object, which contains a list of vDDDTypes objects. This is do that EXDATE and RDATE can contain lists of dates, as per RFC.
  ***Note!***: This change is incompatible with earlier behavior, so if you handle EXDATE and RDATE you will need to update your code.
• When creating a vDuration of -5 hours (which in itself is nonsensical nothing can last for a negative time period), the ical output of that was -P1DT19H, which is correct, but ugly. Now it’s ‘-PT5H’, which is prettier, and compatible with Korganizer that for some reason seems to think things can last less than no time.
• Renamed the UTC class to Utc, so it would not clash with the UTC object, since that rendered the UTC object unpicklable.
• Made the tests run under Python 2.5 and 2.6.

I just released Dateable 0.3, the project that aims to be the future mega project of Plone calendaring. I also released Plone4ArtistsCalendar 2.0a1, and the reason for that is that these projects now are pretty much one and the same. Before the final release of Plone4ArtistsCalendar 2.0 it is quite likely that we’ll use only the name Dateable, as it’s shorter and cuter, but that renaming hasn’t happened yet.

So, what is new in this alpha release: Well, main anticipated news is recurring events. Yes, you heard me right: Recurring events. The mechanism to have recurring events is there now, although the user interface is quite rough and missed some features. That’s the first main reason this is an alpha release and not a beta. The second main reason is that the iCalendar support doesn’t handle recurring events yet.

The other main news, which is less hotly anticipated except by me, is that Plone4ArtistsCalendar now uses dateable.chronos as it’s main views. Dateable.chronos has week and day views in addition to the month, list and past views of p4a.calendar. And thanks to much work from several people, these views look awesome!

And the third main new feature of this is that this is an egg-only release. It means it’s very easy to install. In your Plone 3 buildout add p4a.plonecalendar to the list of eggs, and to the list of zcml packages. Run buildout, restart. Install the Plone4Artists PloneCalendar and Plone4Artists PloneEvent products in Quickinstaller. Done! Events now have a recurrence tab, and Folders have a Calendar subtype.

So, please go ahead and test! Yes, this is an alpha release, don’t install it on production systems, please. If you like it, please come and help at p4a-users@googlegroups.com. Main things that needs to be fixed: Recurring event support for iCalendar. Recurring event support for the Plone event portlet. A nice useable, Ajaxified UI for Events.

18-19th October there will be a PyCon in Rybnik, Poland. I will here hold a talk about the python-incompatibility project and how to write code that runs under both 2.6 and 3.0 for a smooth transition to 3.0. The rest of the talks are in Polish, of course, so I won’t understand them, but I’ll hang around and mingle anyway.

See you there!

My vacation plans stopped me from going to the Blackforest sprint in the end of August. Too bad I had wanted to work on five.grok there. But as compensation I’m going to Brussels the 17th and 18th for a mini-sprint on Grok and Zope 2. If you are interested, be there, or B²! Contact Godefroid for more info: gotcha@bubblenet.be.

Or have servers there. Why? Well, the Swedish parlament look set to vote through a law that gives FRA (Swedens NSA, basically) the right to do surveillance on all electronic traffic crossing Swedish borders. Yes. All. Really. They do really intend to survey ALL electronic traffic, looking for what is called “external threats” (i.e. terrorists and such).

So, if you send email to a Swedish server, this email will be read by a machine to see if it matches certain criteria, and if so, it might be read by somebody at FRA in the end. This is the rights that are being given to an organisation that has illegally done this kind of surveillance within Sweden for ten years. And this is a move supported by around 80% or the parliament. Yes, really. Of course, only 50% will actually vote for it because the social democrats, who’s law it really is, is now in opposition and votes against everything out of principle.

The law has been by Googles expert in questions like this been characterized as not having any place in a western democracy. I agree.

I am so amazingly happy that I have moved from that country.

I like the ideas of good looking word coulds like wordle. Here is the front page of my blog today, as a wordle.

Somebody should make a Plone tag cloud portlet that looks like that.

In the python-incompatibility project I’ve added loads of code that works under 2.5 but does not work under Python 3.0. I’ve also added code on how to re-write the code so that it will run under both 2.6 and 3.0.

Quite a lot of time, the rewritten code will run not only under 2.6 and 3.0, but also under 2.5! This may be surprising, but the reason is that you in 2.x is able to do a lot of bad things that you can’t do in 3.0.
One example is using the keys of a dictionary as a list. For example, this code is valid in 2.x:

d = {'key1': 'value1',
     'key2': 'value2',
     'key3': 'value3',
}
d.values()[1]

But doing that is a bad idea. The keys of a dictionary isn’t sorted, so you don’t know which one you get back. Of course, if you are going through all the keys, that’s OK, but that would mean you are doing some sort of basic newbie mistake, like

for i in len(d.keys()):
  key = d.keys()[i]

When you should be doing

for key in d.keys():

Now, in Python 3 you simply cannot slice the keys of a dictionary, because .keys() doesn’t return a list, but a view, which isn’t sliceable. So, these kinds of bad programming can’t happen in Python 3. Or, well, they can, but you need to also explicitly convert keys() to a list, so it’s unlikely you do it by mistake, which can happen under 2.5, where one person can start slicing a list without noticing that it comes from a dictionary further up in code that somebody else wrote. So in 3.0 you have to intentionally create bad code in situations where it could happen by mistake in 2.x.

I like Python 3. Python 2 rocks. Python 3 is metal!

Andy Buckley wrote a blog about why Python indentation was bad. He has two arguments, and one example. Fortunately, he is mostly wrong. He is right about his first argument: Invisible syntax isn’t really a good idea. A really good example of invisible code was old to me by a friend in Sweden many years ago. There was a programming language, I’ve forgotten the name, where any characters where allowed in variable names. For a joke, people would insert the escape codes for colours in the variable names, so you would have a green variable, named red, and a red variable named red. Highly confusing. Then somebody figured out you could call the variable <escape to red><escape to red>red<escape back>. This would of course be completely indistinguishable from the other red red variable, and make the program incomprehensible.

Yes, invisible syntax is bad, and if you mix tabs and spaces in Python, the syntax indeed becomes invisible. Andy will without a doubt be happy to know that Python 3 will no longer allow it. Try it and you get “TabError: inconsistent use of tabs and spaces in indentation”. This news was greeted at PyCon this year with loud cheers. That means that with Python 3, the syntax is no longer invisible. You will see the difference in indentation, the indentation can no longer be ambiguous. Yes, you can still mix three spaces with two spaces and one space and ten spaces. But that doesn’t matter. Inconsistent indentation might be confusing, but no more so that inconsistent variable naming, and is no fault of the language.

The second reason from Andy is that you can’t use tools to fix the indentation. But this is in fact incorrect. If the indentation is broken, that is a syntactic error. It’s a bug. You can’t use tools to fix bugs, you need a programmer. His has an example of broken indentation and asks how it should be fixed. It’s this:

def myfunction(foo, bar):
    foo.boing()
   for i in bar.fizzle(foo):
      baz = i**2
    foo.wibble(baz)
    return foo, baz

Well, but with braces, that code would look like this (or similar, the indentation errors makes the code ambiguous, so there is alternative ways of misplacing the braces.):

def myfunction(foo, bar): {
    foo.boing()}
   {
   for i in bar.fizzle(foo): { {
      baz = i**2 }
    foo.wibble(baz)
    return foo, baz }
}

How would you correct that? Which braces are incorrect? There is an error in how the blocks are created, and you can’t fix that with a tool, no matter if the blocks are created with brackets or white space.

Andy’s real world example is that he needed to cooperate with somebody whose editor liked using a mix of tabs and three-space indents. First, delete that editor, or fix the configuration. Secondly, as long as the indentation in fact is correct, you can fix it. The confusion comes if you use an editor where you have said that tabs should be shown as equal to four spaces, and you mix tabs and spaces. Then you can get things that look like this:

def foo():
      for x in range(5):
    print x

And you go “wha?” Because that print line starts with a tab, which is expanded by python to eight spaces, but shown by your editor as four. And the line before contains six spaces. So, Python will interpret this correctly, your editor will not. However, if you look at the file with “less” it will look OK. These type of problems are fixable. You can use a script that replaces all tabs with spaces, correctly. Then the file will look OK. And if the indentation after this is a mix of two, five and umpteen spaces, this is also fixable by tools. In fact WingIDE, which I use, will complain on mixes of tabs and spaces and ask if they should be fixed. It will adapt the indentation to what is already going on in the file, so when I get a file written with three spaces as indentation (this has happened), this works just fine, but I can also tell it that no, it should in fact always be 4 (or 2 or 6 or 9) spaces as indentation, consistently, and it will re-indent the whole file.

So, yes, invisible syntax is bad. Yes, Python 2 has it. Python 3 does not. That you can’t fix programmer bugs with tools is nothing unique for Python. You can fix ugly indentation in Python, as long as the code actually runs.

There is however one actual problem with the indentation: There is no do-until loop. And this is because you can’t write:

do:
  blablablabl
until x

This is a pity, because I want a do until loop. An alternate syntax is possible:

until x:
   blablablablabal

But this apparently has been decided against, because it means that the test comes before the code, and the variables used in the test gets defined after the test, which apparently is frowned upon from a syntactic point of view. I don’t care. I still want an until x statement, but it seems I won’t get one. And this is the indentations fault, and the only real problem with Pythons indentation as I see it. But the benefits still are so many more and so much bigger that the drawbacks get dropped-kicked into PHP-land.