January 30th, 2008 by Mark Ramm
Recently Guido offered up a couple of interesting recipes for cleaner monkey_patch implementations via decorators and metaclasses.
I think monkeypatching can be a very useful tool in the same way that a jackhammer or a shotgun can be useful tools. When you need them, nothing else can do the job as well. Of course, you can always smash the cement by hand with heavy iron rods — as is sometimes done in India, where labor is often cheaper than tools… Feel free to make your own analogy to using static languages and the trend towards code generation, rather than having the right tool for the job. But don’t expect me to do it, I’m trying to take the high road today ;)
Anyway, some of the responses have been along the lines of “I like my monkeypatching to look ugly, because it deters people from doing it.” And while I have a lot of respect for some of the folks saying this, I’ve never been a fan of this kind of “syntactic vinegar” argument. It seems to me that it’s better to make complex things seem easy than it is to make simple things seem hard. And it’s kind of paternalistic, and not consistent with the “we’re all consenting adults here” philosophy behind Python. Sure people could do stupid things with these tools, but I think it’s a bad idea to spend your time trying to stop hypothetical bad programmers from doing stupid things.
In other words, we shouldn’t make jackhammers more ugly and complicated just because you would smash your living room wall to pieces if you tried to hang a picture with one. ;)
And I think these patterns are useful. The first decorator syntax is particularly valuable for stubbing interface points out for testing purposes. Hey, a it’s a “mock framework” in 5 lines of code. The second looks like a nice thing to have around for testing purposes too. I’m sure there are uses beyond testing, but I know that’s where I’m likely to start applying these monkeypatching helpers.
January 30th, 2008 by Mark Ramm
And I’m looking forward to DBSprockets because it will make it even easier to create TurboGears applications very, very quickly, by making it easy to create automatic (but customizable) CRUD interfaces for your SQLAlchemy model objects.
For me it’s not the 600 lines of code goal that’s interesting, it’s the ability to try out lots of little things quickly and see what sticks.
January 30th, 2008 by Mark Ramm
Wow, somebody released a TurboGears widget to help automatically minify JS and CSS files. It certainly looks like a good idea to me, and was something that people were talking about adding to ToscaWidgets a few days ago. Unfortunately I haven not yet had a chance to look at it in any depth yet because I’m at a hotel with crappy internet connection all week so I haven’t been able to pull it down yet.
One thought I had when I saw this is that it would be extra cool if this only minified stuff when you are running a project in production mode.
January 24th, 2008 by Mark Ramm
Last year I hosted my first ever sprint at PyCon when the original TurboGears sprint leader had to work at the last minute. It was a totally intense and somewhat humbling experience. But I learned a lot and I got to work with lots of smart people on TurboGears stuff. And equally importantly, we all had a lot of fun. So, it was definitely worth it.
Well, one year later, and I’ve somehow ended up leading the TurboGears 2 effort. And I’m planning to host another sprint again this year. There’s a lot of interesting TurboGears 2 projects moving which would be fun to hack on this year. Chris has written a automatic UI generation app that works with turbogears (+pylons, and eventually others) called dbsprockets which looks really promising.
I’ve also heard some rumblings about some flex/turbogears/silverlight integration work, as well as building some TurboGears site components.
But I’d like to focus some attention on a “working together on the web” sprint. Part of being a good neighbor is in the python web framework wold is building reusable components.
People have said in the past that Python’s diversity of web-tools is a problem, and they do have a point it makes it harder to choose a framework, but even more importantly — as long as frameworks are isolated, it means lots of duplication of effort.
But, I think our diversity can actually be a huge advantage if we learn how to work it better.
We are all exploring various solutions to a complex set of problems. Diversity brings creativity by bringing wide ranges of experience to the community pool. But that only works when there is a community pool, so we all need to be committed to living and working together and learning from one another.
And fortunately TurboGears and Pylons and Zope 3 have all been traveling down the same path. We are all, in our own ways in trying to explode our respective “frameworks” various components into reusable libraries. And with the help of WSGI, Paste, WebOb, and other defacto standards, we’ve all been bringing a lot of those components together around the same set of well defined interfaces.
The more this happens, the more we are able to turn our web framework diversity into an huge advantage. We can work together where it makes sense, innovate in our own areas, and learn from one another.
So, while we work on TurboGears stuff this year, let’s make sure that we’re doing what we can to learn from the rest of the python web framework world, and to contribute back in whatever ways we can.
I think with a little bit of creativity and effort we can find lots of new ways to work together on the web.
January 23rd, 2008 by Mark Ramm
I’ve enjoyed hanging out with Adrian at the last couple of PyCon’s, and I’ve been looking forward to his new venture EveryBlock.com for a while.
It seems like the buzzword of our times is:
think globally, and act locally.
But it sure seems to me that you can’t act effectively at the local level unless you understand what’s happening in your neighborhood. And most of the time we don’t know a thing about anything local, because it’s not a big enough market to for the increasingly corporate mass-media driven news outlets.
But, at least in theory, the web should change that. It should provide us with the ability to find truly local information. And that’s what everyblock is all about.
Earlier this summer Adrian released a very cool tool for parsing content that was likely built from some kind of template (eg, dynamically generated e-mails, or web pages). I’ve been using TemplteMaker for about a month on a little side project, I immediately saw how this fit into the EveryBlock master plan.
Anyway, congratulations Adrian! And if you live in Chicago, New York, or San Francisco, check it out.