Does it work with SQLAlchemy yet? I see no changelog anywhere, so it's hard to tell why I should reconsider my perception that web2py cares only about reinventing the wheel.
Well, Django can be made to do so. I don't use Django, though Django at least has a valid excuse for ignoring the best-of-breed components (it predates them).
Who determines what the best of breed is? Is SQLAlchemy the best of breed because it predates web2py? Then SQLObjects is the best of breed ORM. Kudos to SQLAlchemy because I learned a lot from it and it is a good product. It is just too verbose for my taste.
No, date of origin doesn't determine best-of-breed. Features, usability, and power determine best-of-breed. Michael Bayer is one of the smartest programmers I know and both his major projects (SQLAlchemy and Mako) are best-of-breed in their categories.
I do not know him personally and judging from his programs I agree that he is one of the smartest programmers out there.
Yet, who determines what the best of breed is? How much time have you spent evaluated the web2py DAL vs SQLAlchemy to reach this conclusion? Or are you basing your judgement solely on the fact that SQLAlchemy has been out there longer and therefore it is more popular?
If you have pros/cons about web2py vs SQLAlchemy I would like to hear some concrete examples. They could help us improve it.
By the way... I think you cannot even define "best of breed" since requirements are subjective. You can only list specific issues where one system is better than another.
By the way... I think you cannot even define "best of breed" since requirements are subjective. You can only list specific issues where one system is better than another.
replying 3 times to a comment is a bit annoying, can you try to put everything in one comment in the future (especially when responding multiple times within minutes of one another)?
You can use SQLAlchemy with it as you can use any Python package you like but...
1) The web2py DAL is designed to work with SQLFORM. SQLAlchemy is not. By using SQLAlchemy you would be using web2py more or less like you would use Pylons, thus missing a lot of the extra stuff that web2py does for you (and that you do not see because you think SQLAlchemy).
2) It is internal DAL is comparable and in some cases better than SQLAlchemy because is smaller, faster, and it works on the Google App Engine. By using SQLAlchemy your web2py programs would not run on GAE.
3) web2py users like the web2py DAL better than SQLAlchemy. That is why hey use web2py.
We are not reinventing the wheel. We are just building a better wheel that runs faster and is easier to spin. We are not reinventing the wheel any more or less than any other framework did.
Mostly:
- Group Based Access Control: login, logout, registration, etc.
- CRUD
- Built portable CRON capability
- More powerful DAL
- Read only forms
- runs on Jython and IronPython (except for web server, lack of csv module, and third party database adaptors)
14 comments
[ 2.7 ms ] story [ 45.2 ms ] threadYet, who determines what the best of breed is? How much time have you spent evaluated the web2py DAL vs SQLAlchemy to reach this conclusion? Or are you basing your judgement solely on the fact that SQLAlchemy has been out there longer and therefore it is more popular?
If you have pros/cons about web2py vs SQLAlchemy I would like to hear some concrete examples. They could help us improve it.
1) The web2py DAL is designed to work with SQLFORM. SQLAlchemy is not. By using SQLAlchemy you would be using web2py more or less like you would use Pylons, thus missing a lot of the extra stuff that web2py does for you (and that you do not see because you think SQLAlchemy).
2) It is internal DAL is comparable and in some cases better than SQLAlchemy because is smaller, faster, and it works on the Google App Engine. By using SQLAlchemy your web2py programs would not run on GAE.
3) web2py users like the web2py DAL better than SQLAlchemy. That is why hey use web2py.
We are not reinventing the wheel. We are just building a better wheel that runs faster and is easier to spin. We are not reinventing the wheel any more or less than any other framework did.
It can read SQLAlchemy models (has a compatibility module)
It can read Django models, including validators (has a compatibility module)
It can use Jinja2 and Genshi and any any other template language.
Although I do not really see why anybody would want to do such things.