After a short holiday and clearing up some personal things I worked a bit on cssutils. Mostly adding testcases which revealed quite a few bugs. I did not plan to implement the CSSValue interfaces but due to a request I probably will do that when I am finished with the basic stuff.
An new alpha will probably be posted this week (maybe after another short holiday and should then contain basic tests for all interfaces currently done, let’s see…
I put a pre-alpha release of cssutils on my website this week. After doing some tests and extending the unittests I realized that v0.9a1 does probably not work in most cases anyway. I wanted to put up a new version but FTP to my host was down so it had to wait till today. So 0.9a2 is online, still pre-alpha quality with lots of bugs and not working features but I wanted to put something online anyway as the last release is more than a year old…
The most important todos are
- improving distribution, currenty I work my way through the setuptools docs which I meant to do for quite some time now but never found the time
- @charset is working but is not to the spec, I found some more docs (which are quite wide spread so it is a bit of a hassle really). I guess most people will not use this feature anyway but I’ll try to bring this to work properly soon
- tests for the main CSSStyleSheet and CSSStyleRule and related classes like CSSStyleDeclaration and so on are needed and I guess I guess I will find tons of bugs Strange how many bugs I put in so few code which I did while doing more tests for the much simpler @import rule.
That is quite a task by itself but I hope it will be done this month. Then I can concentrate on doing even more bug squishing (unittests and I think I put support the @namespace from CSS 3 in too. Should not be too difficult…
Ned Batchelder who quite often has very interesting things in his blog (about all kinds of stuff really) wrote about doing tests and in particular about handling exceptions there. Very interesting and I guess adding a bit more metadata to exceptions would be quite good in general.
Quite useful right now as I am about to rewrite cssutils (which comes along very nicely, at least much nicer than the last 2 tries
I noticed that all lt and gt characters in my last post are missing in the generated feeds from WordPress, both the RSS and Atom feeds. Normally these should just be escaped as AMPERSAND-gt-SEMICOLON (> – does this go through?). I have not looked deeply into RSS or Atom yet but this should simply work, at least in Atom which definitely has facilities for using markup (or in this case just XML special characters inside post texts.
From experience I know a lot of developers using XML have problems with this stuff maybe by simply forgetting these things; maybe this is simply a security “feature”. But a bit strange and in a software as widely deployed and used as WordPress this should not happen…
I just noticed that WordPress outputs the gt sign between the above parentheses as a sign and not as the escape sequence which I types. Funny thing is that the included WYSIWYG HTML editor in wordpress actually outputs the escape sequence, the actual output does not… So the feed generator is not the only quirky thing here
While looking at the Atom feed in more detail I noticed that the headline and text of the post are indeed escaped with mode=”escaped” and simply put in a CDATA section. But a combination of ltgt is handled the same as an actual HTML element and not as characters of text as the WordPress HTML Editor used them and also outputs them. It seems this is a bit of a mess…
In Reqiem for an operator Barry Warsaw farewells the <> operator which will be removed in Python 3000. I have no real opinion on the topic itself although I think <> and != are one of the few not TOOWTDI things in Python and so a reasonable decision to remove one. But the followoing question in the same blog entry got me thinking:
“How often do you type semicolons at the end of your Python statements? How often do you type colons at the end of your C conditionals? Yeah, me neither.”
So I guess getting rid of <> in Python in favor of != makes language hopping at least a bit easier.
About the only thing I sometimes wish for Python would be the removal of mandatory colons at the end of if, for, class, def etc. I guess this would make parsing of Python sourcecode impossible or at least “indeterminable” (is that an english word?). But the colon is one of the few places where a special character makes the code not more readable but a bit convoluted. Not a big problem as the parser complains about missing colons (which I see frequently .
BTW, this post is somehow related. It makes me like the language even more as there still seems to be space for a bit of fun.