[Jonathan Ellis]
[Michael Bayer]
you know, back when I first got into Python and wrote Myghty, I got
exposed to this whole "oh no theres TOO MANY WEB FRAMEWORKS" thing
that was going on, which I suppose is still going on, and my casual,
largely uninformed impression of it was that it seemed to be a notion
spearheaded primarily by young, possibly novice developers who were
having a hard time making a decision on how to build their first
dynamic website.
"Suck it up an evaluate them all yourself" is an appealing answer, but
not a realistic one. Not when there are, as someone famously pointed
out, more web frameworks than there are keywords! If you spent just
half an hour evaluating each framework on the python.org
<http://python.org> wiki, that's a serious time investment.
Actually, it *is* realistic because it's easier for the developer, which is a shame. I
would amend your statement to say "'...evaluate them all yourself' is an appealing
answer, but not a _smart_ one".
And experienced developers come from novice developers, so putting up a
"novices go away" sign is suicide, from a community POV.
Well said.
[Jonathan Ellis]
As I've posted before, the ORM space seems to be another area where
people seem inclined to create Yet Another Half-assed Project instead of
putting forth the effort to contribute to somebody else's project. And
that's a shame. Probably because understanding someone else's code _is_
an effort, and perhaps a less-common skill than just starting in coding
something solo.
Am I advocating never creating new projects? Of course not. But do I
think the bar for "are my requirements really so different that I need
to start a new project for them" should be set a lot higher than where
most people seem to have theirs calibrated.
If Ian wants to spend his time creating new ORM that's totally his choice. He
does write good code, so it would probably be useful.
On the other hand, SQLAlchemy has an excellent SQL/mapping layer, and SQLObject
has the best API of any ORM I've ever used. I don't think it's a stretch to
imagine implementing SQLObject on top of SQLAlchemy. That would give us the
best of both worlds, which would be even more useful than another new ORM.
As Michael already pointed out, there are many Python ORM's. But it's not like
there will only be one choice if SA and SO combine. There may be value in
diversity, but that doesn't mean two similar projects should never join forces.
I think what we are trying to say in this thread is it would make more sense to
combine efforts and build something better together than to have each camp
reinvent its own wheel. If efforts were combined both projects could come out
stronger--possibly becoming the defacto standard Python ORM. That would not
only be useful, but good for the community.
The key issue is how people work together. If there's too much head butting and
discouragement then it won't work. Working together is hard--it could even be a
deal breaker in this case.
~ Daniel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
