I have added support for coverage analysis using coverage.py from Gareth Rees and Ned Batchelder, as well as support for profiling using either the profile or hotshot modules from the Python standard library, to Zope 2's test runner test.py.

See the attached file.

Just thought it out while discussing with Ruslan:

Every project is 80% finished 80% of the time

Proof: just apply twice the 80/20 principle (also known as Pareto's principle). Details are left as an exercise to the reader.

Rails est un framework web MVC pour le langage Ruby qui connait une certaine popularité en ce moment.

Django est son plus proche équivalent dans le monde Python.

Les deux projets sont issus de projets spécifiques (Basecamp pour Rails, Lawrence Journal World pour Django) et ont été générisés ensuite.

Sam Newman vient d'écrire A comparison of Django with Rails, et conclut sa comparaison assez équilibrée des deux frameworks par:

I said at the start that the two frameworks were developed as a result of two very different applications - and most of the differences between the two are a result of this. If you are developing a simple (in a domain model sense) application where you want to use Ajax to deliver a great UI, Rails is probably for you. If however you want to develop an entire site with different types of applications within it - then Django’s plugable applications and general approach might be what you’re after. Equally, the better user and administration side of Django favours portal style applications – this is something you’ll have to do yourself if you want to use Rails.

There is scope for both frameworks to learn from each other, and I still have a question around how well Rails will scale (in terms of the size of the site, not number of hits) - Django has already proved it is capable of this with LjWorld.com. Likewise it will be interesting to see if Django can or even wants to make the use of Ajax as simple as it is with Rails (although work is already progressing along these lines), or if the more powerful language features of Ruby will prove the deciding factor.

Ce qu'il manque à présent, c'est une comparaison avec Zope3...

[Ajouté à 9h44] A lire aussi, une comparaison entre Python et Ruby par Ian Bicking.

We have updated the site (lighter design + some updated functionalities).

We're still working on how to handle trackback spam.

Philip Eby has some comments on the Chandler development team recent decision to drop its XML-based "parcel" (parcels are components in Chandler) description format in favor of a pure-Python solution.

There are two interesting lessons in his post:

Of course, the real sin here was not so much XML per se, as overengineering in advance of requirements. If you're not developing the feature now, it's best not to make a bunch of other design decisions based on what you think the feature will need. A little thing like choosing to put data in XML form can result in a wide variety of additional costs like:

• Designing the XML format
• Implementing a parser
• Documenting the format
• Developing a bunch of stuff in the format
• Evolving and fixing the parser to handle more and more complex use cases that weren't thought of previously
• Productivity losses versus what it would've been with Python
  
• Converting all the data once you decide it was a bad idea, or else paying the ongoing marketing and education costs to get third-party developers over the hump, or the cost of not getting those developers on board

And:

I've certainly worked for organizations where the reverse is true, though, including one that threw away tens of millions of dollars trying to replace a small, well-designed Python application with an expensive piece of "enterprise" crapware. Ah, the things I could've done with that budget! Well, probably I just would've given everybody raises and maybe hired a few more people. Or maybe spun off my group as a company that would sell the software to other companies. Heck, we could've used it to buy free sodas for life for everybody working in the company and got more value for the investors than what was actually done with the money!

Fabio Tranchitella wrote me this morning that Debian packages for CPS were available at his experimental Debian Zope packages web site.

More information in this message I sent this afternoon to the cps-devel mailing list.

The press release says it:

Major Linux vendors and non-profit organizations today officially launched the DCC Alliance. The Alliance plans to assemble a common, standards-based Debian core for Debian-based Linux distributions, accelerate worldwide commercial adoption of Debian, promote compatibility among the growing community of Debian derivatives, and work with Debian on features important to commercial adoption such as a predictable release cycle and Linux Standard Base (LSB) compliance.

Interestingly, Ubuntu is not part of the founding members.