regarding SQLAlchemy, a primary motivation I had for writing it was that there were no non-active-record style ORMs available; considering that I find the active record pattern to be too simplistic and limiting, rail's active record was definitely not any kind of inspiration for SA (although many features of SQLObject were).
as far as migrations, Ive no idea where you got the impression that SA feels migrations are "dangerous"; there *is* a migration package for SA called Migrate. Its separate because i feel that schema migration is a big enough subject to warrant its own project, and i also dont think its a "theres only one way to do it" sort of thing; bundling a migrate package within the SA core would be too opinionated/monolithic for my tastes. People bug me to unbundle the SQL construction and ORM libraries all the time too, so i think the level of how much is "core" and how much is "separate" is a real subjective thing.
Michael,
Regarding Rails Conf. It is *this* year conference that will have twelve hundred attendees.
http://weblog.rubyonrails.org/20...onf-07-sold-
out
Last year, there was about 550 attendees.
Mike,
I was told by the SQLAlchemy speaker at the PyCon that Rails migrations are considered to be dangerous. "Many people lost their data..."
Concerning testing in the Python community, I'd like to back up Ian's point that automated testing is a strong part in the Python community. We have a lot of experience with it too; it has been a strong part of the Python community for a significant period; it started to pick up steam in about 2001, I'd say.
Projects like Zope 3 (which I'm personally most familiar with) have thousands of tests, many of which are *doctests*, i.e. documents with tests mixed in. From an article on doctesting in Ruby I saw a while back, I don't believe that's as well established within the Ruby community yet, and we've been doing it for years now. We even have doctests that can test web applications by emulating a browser. (zope.testbrowser)
Doctests have three advantages over plain unit tests (which are good already):
* Your tests are more readable, also later on.
* Your doctests also function as developer documentation. Not always *great* developer documentation, but at least with up to date code samples (as it's tested), and often the alternative is *no* dev documentation.
* I believe test-driven (and test-first) development is a way to create better APIs and more solid code. In my experience doctest-driven development produces even better APIs. This is because writing API documentation helps you think about the API even better than just writing tests.
It's probably accurate that:
* we don't advocate this well enough as a Python community
* we are fractured as a Python community, so Zope's use of doctests is less well-known or appreciate elsewhere. (this in part a marketing issue of Zope)
Regarding WSGI, we're about to change the situation for Ruby:
http://rack.rubyforge.org/
(Disclosure: I'm the lead developer.)
Michael -- thanks for the kind words. I agree with Martijn that automated testing is a part of many important Python projects (Twisted also has > 3,000 unit tests ). I also believe it's a question of marketing. I'd love to see some case studies on how Zope is using automated testing.
BTW, my take on RoR's popularity is that it's in a large part a question of marketing. DH is a charismatic leader, and the Pragmatic Programmers jumped early on the bandwagon.
Regarding test stylings, I also find doc tests to be more readable later on. The text can hold a narrative. When doing test driven development, you can write out your thoughts as well as writing out the tests. In theory you could do this with comments in a classically styled unit test, but you can't extract, format, and print those thoughts as easily as you could a plain restructured text document or docstring.
Having that narrative prose alongside running test code can serve as a good reminder about certain design decisions made. This, I believe, makes doctest a stupendous Python feature.
Hi, this is Mark Ramm. I did the talk on SQLAlchemy at Pycon, and I'm the one why said that the way Rails migrations work is slightly dangerous. I think I wasn't clear, certainly it's not true that lots of people loose data, but I definitely have seen people loose data.
The idea that a migrations can be fully automated is powerful, and certainly can make life easier. But at the same time it can be deceptively easy, and developers who aren't careful can loose data on production databases by not thinking things through. I haven't seen data loss from Rails Migrations caused by anything other than developer error, at least not anytime in the last year or so.
The SQLAlchemy migrations package actually asks users to think about upgrade and downgrade procedures, and I think this is a benefit rather than a drawback. But other than that it provides all the features of Rails migrations.
"""It's fair to say that SQLAlchemy and related Python projects are at least in part inspired by the success and expressiveness of ActiveRecord for Rails."""
[boggle] Have you ever even bothered to look at the most basic documentation for SQLAlchemy or DejaVu?
Regarding your footnote about attaching methods to core classes. As we discussed earlier today, it can be dangerous, but I'm certainly convinced that it's also highly useful. For example, in Ruby, Enumerable is a module that gets mixed in to about everything that can be enumerated in any way. Attaching a new method to Enumerable means all classes and objects mixing in Enumerable will have that method as well. This is extremely useful, and the Facets Core project is a big example on the _good_ ways you can extend core classes.
Commenting by HaloScan
