Daniel Miller wrote:
[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".
I don't get why people complain that there are too many (web/orm/X)
frame works out there. Choice is great ! I would hate to have been
forced fed SO (which as the case before SA) or django or turbogears or
X. If people can't determine if a tool is good or not, they really
should not be in a position to be choosing tools. Novices shouldn't
pretend to be experts.
That is the problem I feel in the python community. There are too many
novices preaching to other novices (especially when it comes to web
frameworks). You can tell this is happening when features which have
been around for years are suddenly the "hype" just because some people
have just suddenly come up with it "again".
And experienced developers come from novice developers, so putting up
a "novices go away" sign is suicide, from a community POV.
Well said.
I'm not sure having a massive community of novices should be the ideal
goal of a project. You should just aim to produce the best tool "you"
(the developer/development team) can. After all, it's the brilliant
ideas from the developers which usually make a great product. The
community feedback usually just polishes the product. If a tool is
solely community driven in terms of features/development ideas, and that
community is made of mainly of novices, you could be in trouble.
[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.
I'm not sure why everyone thinks SO is so good. It's one of the worst
ORMs I have ever tried to use, because of its "you have to name your
columns like this" and "your keys have to be that". A tool like that is
very short sighted, and is aimed at average joe, who shouldn't be coding
any serious database applications in the first place. You can only hand
hold a novice so much by hiding things like database schemas/design
before you start hurting the expert users (which the novices will
hopefully become after a while). This is where SA shines. It is simple
where it needs to be, and makes complex things elegantly possible.
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.
Although it's not up to me, I wouldn't bother joining with SO at this
stage because it can't offer anything to the SA community except more users.
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.
This is exactly the problem. The big difference between the two products
speaks volumes about the people behind. SA does not compromise on the
important things in a database application, whilst SO just wants to do
easy things quickly and forget about hard things.
Huy
~ 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
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
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
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
