PyMET: a simple api client for Trimet data

I've been hacking on and off this Trimet data wrapper for about a year now and I recently decided to give it a big push. My biggest point of contention with the project has been dealing with irregular XML api data and modeling that in python objects. It's an annoying and frustrating task in any circumstance. You must deal with parsing the xml, and then figure out how you'd like to shove it into your object properties for every single property. This means you spend more time figuring out how to map the data than actually using it.

I am really tired of this situation, it flat out sucks. That's why I've gotten lazy and tried to make it better. My new Trimet classes are based on a lazy xml api class which handles this mapping for you based on introspection of the returning data. Thanks to the BeautifulSoup project, discovering attributes, text values and children of XML objects is a very simple task. My only task was to provide the mapping. For this, I recursively loop over the elements and make a few important choices:

1. choose to either add attributes and descend if any element has children
2. put all elements which have identical tagname siblings into a list

With these goals for the algorithm, implementation was not too difficult. The main things to keep track of is when to append data vs. when to just add a new dict object (I am converting the entire xml tree into a dict/list object). I'm also doing so fun stuff with __getattr__ so you can acces properties of the object returned based on your schema and the data itself.

Now that I have the obvious bugs worked out, adding new XML apis based on this should be trivial. I think civic apps has some which I might try out.

* Warning, this code is still pretty rough and needs some cleanup, but if you know what you're doing it should be easy to follow the examples in arrivals.py

Recent Presentations

I've decided to start publishing all my presentations and their source to github. Most recently, I spoke at the pdxpython user group about my uses of PLY in Cockerel. The talk went well and I think everyone enjoyed it. I'll also be talkng on Sunday at PGDay about the PORTAL project. Should be a good time.

2 Packages for Flask

I've released 2 extensions for Flask today; Flask-Markdown and Flask-Jinja2Extender. Both are very simple, but handy when you're doing a lot of templating and working with Markdown. Also, it's import to note that both will be going under heavy development and should be considered unstable, blah, blah, blah. Otherwise enjoy!

Edit:
One more thing, you can also grab cockerel from pypi.

Developing a DSL for logical reasoning

DSLs are a great way to extend a program's accessibility to non-programmer domain experts. Generally, the approach is to reconstruct the operations needed for a given task, but using language and semantics that the end users are familiar with, not the programmers. It is the programmers job to design and implement the language. Here in the Cockerel project, I have been undertaking a similar exercise. The goal is to provide a language which can be used by novice logicians and students to form proofs. So far, I've developed a basic syntax:

Lemma ex_6_19 P : (~~P) <-> P. 
Universal_Intros.
Split_Eq.
  P_with_CP.
  For P Use IP.
  For False Use (Contr H1 H2).
  P_with_CP.
  P_with_CP.
  For False Use (Contr H1 H2).
Qed.

Hopefully this proof is easily read, but I'll walk through it anyway. We begin by introducing our universally quantified variable [P]. (Its good to note that even though I am doing Propositional logic, there is an implicit [forall] in the goal state.) After the introduction, we divide the bi-conditional, [<->], into two implications and begin the main body of the proof. For [~~P -> P], we'll need to use a conditional proof technique. The matching tactical is [P_with_CP]. From there the [For Use] syntax allows use to write a new hypotheses [~P] for [P] using the Indirect Proof [IP] tactical. Finally we'll show [False] using a contradiction between our two hypotheses, [~~P, ~P]. The other direction is immediate from the implication.

Ideally, a new student will be able to understand this language since it is very close to the language in their books. One area I am not a fan of is the lack of explication for some of the tacticals, [Univeral_Intros, Split_Eq, P_with_CP]. It might be a worthwhile addition to have the student also write out what those tactics are producing; this would be a similar behavior to the other tactics.

Well that's it for now, happy proving!

Building out a webpp using Flask

Flask is a new micro-framework by the folks at Pocoo. I have to say I'm super impressed. The build-out is really flexible which I find as refreshing compared to Django. You can organize the application in any fashion you like; I've chosen to do a standard layout for a wsgi application. I've got a module for models, and a webapp which has submodules for my views. A nice feature of Flask is being able to register these modules on boot and instantiate all the routing; I am also initializing and managing the db connection when starting the app using the Flask-SQLAlchemy extension. Finally, I've got Flatland taking care of my forms. This overall architecture seems to his the sweet spot for my application needs. I'm knocking out tasks and taking names! Naturally all my code is on github by now...