I looked into this for an audio app, and it looked really cool. Then I contacted him to find out what contingencies were in place because of the truck number of 1 (!!). I asked him if he had any business partner, or perhaps a dead man's agreement in place in the license by which if the company folded or he left it would revert to open source. Not only does he not, but he was a jerk about it, completely dismissive of it as a valid concern. No way would I put years of work into a project on a platform that might become stagnant because of his lack of foresight or understanding there. So I just used QT and other audio only toolkits. Pity, it's really neat looking.
Well, that's the beauty of open-source... I try to be hit as few trucks as possible, but it certainly wouldn't mean the end of the project, just perhaps a slight drop in code-quality :)
I remember you getting in touch and asking about this because I think you're the only person who ever asked me about the truck-number. Slightly surprising, really - I've sold licenses to all kinds of huge mega-corporations who I would have expected to worry about such things, but apparently not. Just you!
..actually, I should mention that although most of the library is still GPL, the core module is now under a permissive ISC license. So if you're doing non-GUI or audio stuff, you can use many of the core classes for free.
Jules I am a real fan of your work, you are an inspiration - thanks for your response! Reading iain's comment again - I think he knows it is GPL already but for commercial users he's concerned that they would have to GPL their code to get updates if something unfortunate were to happen.
As is so often the case, IMHO the poster is ignoring the business side of the equation in favour of "correct". A good ORM is fantastic for speeding up development. If you design your db around being well usable with the ORM, the potential development gains (at least in dynamic languages like Python) are HUGE. I left Django in part because of their ORM. But using SQLAlchemy, we develop far, far, faster than if we were using SQL directly. And it's flexible enough to allow me to drop into the SQLAlchemy Query language when I need to hand tune a query, or to SQL itself if I really need to get close to the metal.
Will there be downsides one day? Probably. Will they come even close to the business value of the amount of the coding time we've saved during the critical bootstrap phase? No way in hell. As they say, those are problems I'd love to have.
For me, Python is the only language that addresses the human side of programming well. You just plain make fewer mistakes with Python, and it's way easier to reload code into your brain after not looking at it for a while. The readability and obvious syntax has vastly more far reaching effects than one thinks it will when first learning it. It's amazing how much more productive one is in a language that is easy to read, easy to type, and easy to figure out what the most likely way to do something is. I reach for pdb more than a manual because most of the time I can guess what an api will be, and if not, 5 seconds of introspection reveals it. Ruby is well designed for computers, but Python is better designed for us fallible humans who have to type into computers. ;-)
Further to this, as fallible humans, we usually get the design wrong on the first try. The truly multi-paradigm nature of python has for me made it a really great language for refactoring and iteratively arriving on a good design. You can write proto-types really fast, and turn them into more formal architectures very smoothly.
I would add that the data mapper pattern gives you very fine grained control over what objects and attributes of the object are matched to which tables. So refactoring either your object layer or your table layer is easy to do independently.
I agree with that assessment with the exception of the repoze.who comment. Repoze.who is bad ass. It takes a while to get your head around it, but at the end, it is far and away the best engineered and extensible auth system for python apps. I would encourage you to take a closer look.
The way you identify a user is to pull the 'repoze.who.identity' out of environment variables. The way you detect a failed login is to check whether the login count, passed as a query string in a specially named __logins variable, is greater than zero. This especially seems like an ugly hack to me.
Oh, and I really didn't like the fact that the latest release of repoze.who (2.0a1) has a ton of undocumented, backwards incompatible API changes. It was amusing trying to get it working, only to realize that the docs only referenced a much earlier release.
I understand the goals of repoze.who and think they've written a very impressive set of plugins, and I understand how it would be useful if your app happened to have multiple types of authentication that made sense to handle at the middleware level: HTTP Basic or LDAP or whatever.
But they've done that at the expense of keeping the base case simple: having a user model with a username and password that authenticates at the application level with a login form. 99% of websites use this approach so I was surprised that it wasn't simpler to do, especially coming from Django where this feature ships by default.
I've use Django, Pylongs, TG, and repoze.bfg. It's quite different. A vastly oversimplified metaphor would be unix to OSX. Django is a monolithic all in one environment where everything 'just works' together but is not useful outside of Django, and no part really really excels at its own job, while being good enough for Django. Pylons expects you to write a lot more glue, and works better if you anticipate hitting the wall with a Django component ( ie Django's ORM is not even close to SQLAlchemy ). Pylons tends to attract people who will be writing a complex app that they will run with for a long time, or be extending in their own way. If you think there is a good chance you might need to rip out own component to replace it with a tweaked one, or different version, it's a lot easier with Pylons. Pylons is also written from the ground up around WSGI, so if building app stacks out of WSGI is your thing, that is still easier in Pylons ( though possible in Django. It still feels a bit bolted on though ).
That said, I personally prefer repoze.bfg over all of them now. Also minimal, built on wsgi, but also built on the Zope Component Architecture ( just the ZCA, does not depend on the ZODB or Zope server). For really being able to reuse and extend your code, that ZCA infrastructure is the killer feature.
To be fair, I should point out that it's much easier to get new developers going on Django, and that the monolithic approach gives people a much better out-of-box experience. Just not my thing, I like Vim better than Eclipse too. ;-)
This is totally true, with one giant caveat: how much you are worth will not sell itself. You will get referrals, but you need to make sure that you are negotiating properly or you can wind up swamped with work that you aren't charging enough for. Sooo, even if you feel like you have all the work you need, you owe it to yourself to do some sales reading. ;-)
