This might just work. That's really the best I can come up with to describe an odd little library that I've secretly been working on. It's called curry, because it's both cooking and currying.
Also referred to as partial application, currying is the transformation of a function of n variables into a chain of n functions of a single variable. That seemed a bit too mathematical for me to be of any practical use in Python, so my starting point is a bound method. The idea then is to apply partial application to this method to shift off the class instance pointer, partially evaluating the function body (recursively). This is actually a means of optimization and the motivation is to try and use it instead of code generation in libraries like chameleon. Rather than generating code, the idea is to reduce existing, working, tested code to obtain the exact same result.
There are more technical details available on the project page, while examples are included in the test suite.
2009-06-02
2009-05-16
Activist appears on a tortilla in mexico god
Yesterday, while attending a poetry slam session in a Nairobi suburb, it dawned upon me that a central theme in the Christian belief goes against my morality. I find it interesting, because non-believers are often lead to believe that their morals are inherited from Christian doctrine. Appearently, not so. I suppose it's a relief to me, which is why I feel like sharing. An apology for posting this here is due being wanton off-topic, but rest assured that the word "science" does appear. For the record, the title of this piece was inspired by a friend who said, "I honestly don't even think I believe in God more than like some levelling force of good in the universe, I don't believe in this activist appears on a tortilla in mexico god". I'm not personally seeing much of this levelling force and not very compelled to spirituality in general, but the rest of the remark does make for a good title.
Spirituality is strong in Kenya and most of the poems recited in the session carried religious messages. I took note of one piece in particular, which had a female poet ask her would-be suitor if "He was your king, your leader" (he would then ask her the same). This lead me to think about the concept of judgment, e.g. the notion that after we pass away, divine judgment awaits (protecting the kingdom of heaven). Another poet introduced his piece by reminding the audience that "scientists should stick to formulas". While a fair proposition, I hope it does not exclude me from employing logic, because I will need it in the following.
You'll recall that in Christian doctrine, Purgatory is the station just before Heaven and Hell (there's a notion of being in "limbo" as well, but that's irrelevant here). I've always thought that eternal damnation was an odd concept, but I've been lead to believe that it's a scarecrow idea that will never materialize (surely if it did, it would undermine the entire foundation of Christian morality, being such as cruel punishment). As such, we all go to Heaven eventually. What's important is that we don't know this while down here and so there's still this judgment awaiting us which could prove detrimental.
I call this morality of Purgatory "The Carrot or the Chariot", inspired by Malcolm X's speech "The Ballot or The Bullet", which in 1964 warns the United States government that if African-Americans are not given full equality, armed struggle will ensue. Mine is a pun on the obvious flaw of using Heaven as a carrot, while Hell is the actual destination should anything go wrong. The opposite of a carrot must be neutral, else it's no carrot.
We must believe in reform and morality while down here and we cannot instill this using fear for divine judgment. The carrot is the joy of living a moral life with all in which entails of honesty, modesty, humility, and so forth. With the morality of divine judgment comes reasoning that leads us to such cruelties as capital punishment (the secular counterpart to eternal damnation).
Further, if Purgatory is merely a scarecrow institution, we must question whether Heaven is even possible. Can such a state of being truly be different from that which we experience here below? The same petty thiefs, thugs and defilers will dwell there, too, demanding justice.
To observe this belief of happiness in living a life in morality and accepting happiness as a carrot is thus to reject the existance of Purgatory, Heaven and Hell, all of which are central to Christian morality.
Spirituality is strong in Kenya and most of the poems recited in the session carried religious messages. I took note of one piece in particular, which had a female poet ask her would-be suitor if "He was your king, your leader" (he would then ask her the same). This lead me to think about the concept of judgment, e.g. the notion that after we pass away, divine judgment awaits (protecting the kingdom of heaven). Another poet introduced his piece by reminding the audience that "scientists should stick to formulas". While a fair proposition, I hope it does not exclude me from employing logic, because I will need it in the following.
You'll recall that in Christian doctrine, Purgatory is the station just before Heaven and Hell (there's a notion of being in "limbo" as well, but that's irrelevant here). I've always thought that eternal damnation was an odd concept, but I've been lead to believe that it's a scarecrow idea that will never materialize (surely if it did, it would undermine the entire foundation of Christian morality, being such as cruel punishment). As such, we all go to Heaven eventually. What's important is that we don't know this while down here and so there's still this judgment awaiting us which could prove detrimental.
I call this morality of Purgatory "The Carrot or the Chariot", inspired by Malcolm X's speech "The Ballot or The Bullet", which in 1964 warns the United States government that if African-Americans are not given full equality, armed struggle will ensue. Mine is a pun on the obvious flaw of using Heaven as a carrot, while Hell is the actual destination should anything go wrong. The opposite of a carrot must be neutral, else it's no carrot.
We must believe in reform and morality while down here and we cannot instill this using fear for divine judgment. The carrot is the joy of living a moral life with all in which entails of honesty, modesty, humility, and so forth. With the morality of divine judgment comes reasoning that leads us to such cruelties as capital punishment (the secular counterpart to eternal damnation).
Further, if Purgatory is merely a scarecrow institution, we must question whether Heaven is even possible. Can such a state of being truly be different from that which we experience here below? The same petty thiefs, thugs and defilers will dwell there, too, demanding justice.
To observe this belief of happiness in living a life in morality and accepting happiness as a carrot is thus to reject the existance of Purgatory, Heaven and Hell, all of which are central to Christian morality.
2009-05-11
Pesky operands
Unlike ZPT, Chameleon relies on the venerable expat parser. It's not forgiving in the slightest and won't parse a "<" character that isn't part of a tag (as often used in an inline Javascript for-loop). Often times we can't make assumptions on the document mode, which rules out CDATA. We're not spoilt for choice. Then I stumbled upon a clever workaround: Reverse the operands and invert the operator, then it just works.
2009-05-07
Forms that don't make you tense and nervous
Forms are tedious. I used to think that some five thousand lines of code was the remedy [1]. All the pesky details are abstracted away and in their stead is a very reasonable model based on schemas, widgets, converters, add forms, edit forms, display forms, page forms, subforms–rest assured, there's an option that fits you.
Invariably, with any framework you'll need to adjust things a bit. As it happens, this is where it gets tedious with the framework that is supposed to remedy tediousness. Endless abstraction and delegation makes it difficult to plug in custom behavior, let alone come to terms with what needs to be plugged out and how to write the code to replace it.
Typesetting documents in Latex is similar; you'll spend hours trying to align four graphs on a page, because "letting the system do it for you" doesn't get you where you want. The better you're acquainted with the system, headaches will come fewer and farther between–the learning curve pays off. Yet, arguably not all documents are best typeset in Latex.
Where's the restructured text of forms? There's Ian Bicking's FormEncode. It does some of the things I want and it does a lot of things I don't want. It also does the things I do want in a way I don't quite like.
Sanctioned by the "scratch your own itch" approach to software development (if it works for you, chances are it'll work for others), Stefan Eletzhofer and I decided to write a minimalistic form library called repoze.formapi. Part of the library was actually written with Ian present, while Jeroen Vloothuis wrote most of the error handling and validation logic. The result is a very usable library which intentionally does very little. It provides powerful field marshalling, flexible validation and a minimalistic form class framework. You write your own HTML.
Note: Narrative documentation for the library is now available.
[1] z3c.form
Invariably, with any framework you'll need to adjust things a bit. As it happens, this is where it gets tedious with the framework that is supposed to remedy tediousness. Endless abstraction and delegation makes it difficult to plug in custom behavior, let alone come to terms with what needs to be plugged out and how to write the code to replace it.
Typesetting documents in Latex is similar; you'll spend hours trying to align four graphs on a page, because "letting the system do it for you" doesn't get you where you want. The better you're acquainted with the system, headaches will come fewer and farther between–the learning curve pays off. Yet, arguably not all documents are best typeset in Latex.
Where's the restructured text of forms? There's Ian Bicking's FormEncode. It does some of the things I want and it does a lot of things I don't want. It also does the things I do want in a way I don't quite like.
Sanctioned by the "scratch your own itch" approach to software development (if it works for you, chances are it'll work for others), Stefan Eletzhofer and I decided to write a minimalistic form library called repoze.formapi. Part of the library was actually written with Ian present, while Jeroen Vloothuis wrote most of the error handling and validation logic. The result is a very usable library which intentionally does very little. It provides powerful field marshalling, flexible validation and a minimalistic form class framework. You write your own HTML.
Note: Narrative documentation for the library is now available.
[1] z3c.form
2009-04-15
Book review: Practical Plone 3
Let me first make the observation that printed books are here to stay; I received an electronic copy of the latest Plone book from the publisher asking for a review and it's been looking at me from its place on the desktop for about two months now. Today I received an e-mail from the publisher asking for the location of the review, so I'd better get on with it.
I haven't bought or read a technical book for about five years. The last one was Philipp's book on developing Zope applications using the component architecture. I thought that was quite a good book and certainly one that I'll revisit from time to time (okay, less and less so, but it's had a very decent life span). Why is it a good book? I think the primary reason is that it knows its audience and stays with it throughout the book. There's a learning curve, but not an audience curve.
I think the average reader will take one year to read this book (sic).
When I read through the initial chapters, I got the odd feeling that it's got an audience curve instead of a learning curve. In the first few chapters we learn what Plone looks like and we're introduced to some new vocabulary like breadcrumbs and colophon. That doesn't seem very practical; it seems introductory. To spend some fifty pages going through the main user interface may not seem like an issue (you can easily skip them), but skipping pages is something you do on Google, not when reading. In other words, skip the extended introduction–it's too likely that it will be anyway.
Parts 2 and 3 (starting on page 55) make up the rest of the book. Part 2 is essentially a user's guide (how to use Plone) while part 3 is an integrator's guide (how to extend and customize Plone). It's good writing and the material matches expectations. However, we can't get around the fact that this book addresses three different audience in three different parts. It'll take a year to read the book and by then we'll have Plone 4.
Perhaps 500+ pages isn't always the right balance for a technical book; in the case of Plone, it seems that 50/250/250 would be better, distributed in three separate volumes, like a trilogy. Perhaps 50/250/500/500, where the missing part 4 would deal with how to develop enterprise Plone apps, but luckily, this is what Martin's book is all about.
Is there a conclusion to these ramblings? I'm not sure, but knowing your audience, staying with them and appreciating the quick read are valuable points I think. As for a recommendation, I'll say that this book belongs in any office where Plone is being used, but perhaps not in every home. I look forward to the revised second edition, coming out in three separate volumes.
I haven't bought or read a technical book for about five years. The last one was Philipp's book on developing Zope applications using the component architecture. I thought that was quite a good book and certainly one that I'll revisit from time to time (okay, less and less so, but it's had a very decent life span). Why is it a good book? I think the primary reason is that it knows its audience and stays with it throughout the book. There's a learning curve, but not an audience curve.
I think the average reader will take one year to read this book (sic).
When I read through the initial chapters, I got the odd feeling that it's got an audience curve instead of a learning curve. In the first few chapters we learn what Plone looks like and we're introduced to some new vocabulary like breadcrumbs and colophon. That doesn't seem very practical; it seems introductory. To spend some fifty pages going through the main user interface may not seem like an issue (you can easily skip them), but skipping pages is something you do on Google, not when reading. In other words, skip the extended introduction–it's too likely that it will be anyway.
Parts 2 and 3 (starting on page 55) make up the rest of the book. Part 2 is essentially a user's guide (how to use Plone) while part 3 is an integrator's guide (how to extend and customize Plone). It's good writing and the material matches expectations. However, we can't get around the fact that this book addresses three different audience in three different parts. It'll take a year to read the book and by then we'll have Plone 4.
Perhaps 500+ pages isn't always the right balance for a technical book; in the case of Plone, it seems that 50/250/250 would be better, distributed in three separate volumes, like a trilogy. Perhaps 50/250/500/500, where the missing part 4 would deal with how to develop enterprise Plone apps, but luckily, this is what Martin's book is all about.
Is there a conclusion to these ramblings? I'm not sure, but knowing your audience, staying with them and appreciating the quick read are valuable points I think. As for a recommendation, I'll say that this book belongs in any office where Plone is being used, but perhaps not in every home. I look forward to the revised second edition, coming out in three separate volumes.
2009-03-27
Time-out in Africa
Yesterday, while listening to "White Car in Germany" by The Associates, I kept getting an error while running buildout:
The documentation suggests that it will raise an exception, but perhaps the clue is that if no time-out value has been set, it's really not a time-out (so why raise an exception). At least, setting it (at a reasonable location in the buildout-script) resolves the issue:
Error: MD5 validation failed for plone.app.locales-3.2.0.zip;"What the hell", I thought and went step-debugging into the code. First an observation: I would not expect a ``check_md5`` method to actually go ahead and unlink the downloaded file if validation fails. That aside, the error persisted and it turns out that ``urllib2`` silently times out a request if the socket does not receive data within some period of time (this happens quite often here).
The documentation suggests that it will raise an exception, but perhaps the clue is that if no time-out value has been set, it's really not a time-out (so why raise an exception). At least, setting it (at a reasonable location in the buildout-script) resolves the issue:
import socket
socket.setdefaulttimeout(3600)
2009-01-29
Wire it up
While trying to wire up an interface for managing composited content on a page, it occurred to me that it's very similar to using something like Interface Builder (IB) on the Mac and pulling the wires with XCode. The wire problem is fundamentally difficult, but with JavaScript and HTML, it's plain awkward.
Essentially there are two ways to go about creating user interfaces and this goes for both desktop applications and browser-based applications. It's either done programatically or graphically. Certain tasks can only be accomplished programatically, so there nothing's new under that sun.
Both HTML and IB are essentially based on containment. Buttons inside panes inside dialog windows aren't much different than buttons inside divs inside a document body. However, IB is object-oriented and each object corresponds to a class in Objective-C. The linker is actually tying the knots of the wires at compile-time.
It's hard to express abstract objects with HTML, because you're typically only afforded a class name, the exception being form elements and anchors, but even they carry only a minimal set of attributes. It's common to simply put binary decorators in elements in the form of multiple class names, e.g. "selected", "enabled", "current".
An alternative wiring scheme is to use invisible anchors to signal some interaction using the "href", "rel" and "name" attributes to carry information. It's not a good solution, because there's no "value" attribute (which would facilitate an RDF-like structure) and none of these attributes are indexed, making queries slow.
A third strategy is to use hidden definition lists. This can be coupled with containment to express attribute name/value pairs. The disadvantage is that it's an inappropriate container. Definition lists are part of the document content, while element attributes typically aren't. But the structure is near-perfect.
Meanwhile, XML namespace attributes may qualify as a fourth option even though browser-support is still disappointing. There's fundamental support, but no high-level API. To change this situation, I decided to put together a jQuery plugin which provides XML attribute access using James Clark's namespace notation "{ns}name" which will be familiar to most people who've been parsing XML.
By combining the HTML attributes "id" and "class" (which all elements may carry) and XML attributes, we can model the state of a class instance. In a complex situation, one could use the prototyping features of JavaScript, but in many cases it will be good enough to simply use this as a data storage.
Update: I've successfully tested the plugin in Safari, Firefox and IE7.
Essentially there are two ways to go about creating user interfaces and this goes for both desktop applications and browser-based applications. It's either done programatically or graphically. Certain tasks can only be accomplished programatically, so there nothing's new under that sun.
Both HTML and IB are essentially based on containment. Buttons inside panes inside dialog windows aren't much different than buttons inside divs inside a document body. However, IB is object-oriented and each object corresponds to a class in Objective-C. The linker is actually tying the knots of the wires at compile-time.
It's hard to express abstract objects with HTML, because you're typically only afforded a class name, the exception being form elements and anchors, but even they carry only a minimal set of attributes. It's common to simply put binary decorators in elements in the form of multiple class names, e.g. "selected", "enabled", "current".
An alternative wiring scheme is to use invisible anchors to signal some interaction using the "href", "rel" and "name" attributes to carry information. It's not a good solution, because there's no "value" attribute (which would facilitate an RDF-like structure) and none of these attributes are indexed, making queries slow.
A third strategy is to use hidden definition lists. This can be coupled with containment to express attribute name/value pairs. The disadvantage is that it's an inappropriate container. Definition lists are part of the document content, while element attributes typically aren't. But the structure is near-perfect.
Meanwhile, XML namespace attributes may qualify as a fourth option even though browser-support is still disappointing. There's fundamental support, but no high-level API. To change this situation, I decided to put together a jQuery plugin which provides XML attribute access using James Clark's namespace notation "{ns}name" which will be familiar to most people who've been parsing XML.
By combining the HTML attributes "id" and "class" (which all elements may carry) and XML attributes, we can model the state of a class instance. In a complex situation, one could use the prototyping features of JavaScript, but in many cases it will be good enough to simply use this as a data storage.
Update: I've successfully tested the plugin in Safari, Firefox and IE7.
Subscribe to:
Posts (Atom)
