I’ve been pushing the conversion of arachadmin over to Pyramid pretty hard the past few weeks. I started with the SQLAlchemy tutorial and then started with the project template, tried setting up the database (in Postgresql) in both Core and ORMS and chose the later (mostly for the more complete transaction support). I rewrote the initdb script in the template to load and copy every (used) table in the current MySQL database and stuff it in the postgreSQL database defined by the schema. Lots of problems with ordering of transactions due to primary keys that were also foreign keys points to a table of identifiers (goodbye mandatory integer indexes). Just of note – I used a master table of URIs that were used as primary keys for records that persist objects (pubs, terms, properties, claims, individuals, taxa) as a straightforward way to guarantee uniqueness. This is an issue because most of these classes of objects can have generated ids and this is an easy way to backup the id generation system.
Once I had the database, I picked up enough of Chameleon and Deform to implement (very) basic listing and browsing pages for publications, taxa, and claim (still in progress). I haven’t done enough with Deform past the default display to have much to say, but the Chameleon templating system is working well – the basic templating and the macro system just work and I haven’t had any nasty surprises in each. As long as I remember what belongs in the template and what needs to get passed in from the view function, everything is fine.
I’ve been trying to figure out why I feel more comfortable tinkering with the guts in this code than I was with web2py. I think the difference is that a lot more is exposed in the process of getting started, especially moving beyond the basic ‘hello world’ app. Web2py hides a lot more and it seems less transparent about the documentation examples are doing. For example, specifying widths of strings in database columns vs. forms: because the packages for database and forms are separate in pyramid (and there are options) it is clearer what specifying a width in a particular place means. In web2py it wasn’t clear whether a string length was specifying a database column width, a form display width, or a form validation constraint. In summary, there is a lot of functionality packed into web2py, but I had trouble building a mental model of what was going on with a lot of the functionality (especially views).
The lack of serious support for unit-testing (beyond doc tests) didn’t encourage experimentation either. I’m also happy that pylint, despite some complaints, seems a lot happier with the pyramid code I’ve feed it than when I tried web2py code. With web2py I had to limit myself mostly to pep8 formatting if I didn’t want to drown in lists of problems due to the mismatch between pylint and web2py. There is a pylint init file that claims to work with web2py code but I never saw any effect of including it (it said it loaded, then reported the same problems).
A new entry in the world of python code-checkers (or linters if you prefer) is the online tool from QuantifiedCode. I haven’t tried this tool (or their new code ‘corrector’) on the new arachadmin code because I’m waiting for Pylons to officially release Pyramid 1.6 before I commit everything to github (just simpler that way). The beta has been out for two weeks and no problems reported (I am actually using an older, alpha release of 1.6, no problems to report).
Enough rambling. Wayne Maddison published a taxonomic revision of the Salticidae last month and at the same time released a large collection of his specimen photos. So, since I have nothing new, have a northern Phidippus (not audex, which I didn’t find any pictures of).
An Arachnolingua Blog 