Re: Looking for a language/framework
Alex Martelli wrote: Jeffrey Froman [EMAIL PROTECTED] wrote: Alex Martelli wrote: I've never seen an object-relational mapping (technical term for cruft that tries to avoid people having to learn and use SQL) which doesn't drive me into a murderous, foam-at-mouth rage in a very short time -- I WANT my SQL, I LOVE SQL, it's WAY more powerful and suitable for access to data than all those simulated OO DB people lay on top of it How refreshing to discover I'm not the only person on earth who feels this way. Hey, there's two of us, if this was Italy we could found a new political party!-) Me too - I rather prefer using SQL to ORMs, *but* my basic reason is that I find it ridiculous for python ORMs to claim they lower sql/python impedance while they lead away from the python construct that's the obvious fit in the role of sql representative : I mean generator expressions. And OK, generator expressions aren't quite as powerful as SQL, but... well, maybe they can yet be perfected. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Gregor Horvath wrote: Scott David Daniels schrieb: Using a relational DBMS is most definitely _not_ premature optimization. A relational system provides a way to store data so that it is later I did not mean that using a relational DBMS is premature optimization but not using a ORM because of performance considerations is one . Whether or not to use an ORM might be a fairly big design decision, and a part of the entire approach to your data handling. For some kinds of data and some kinds of applications, it will drastically reduce your flexibility in how you can conveniently deal with the data. Object oriented design and programming, is often very helpful, but it's not the only approach you can take to solving a problem in software, and I'm not sure it's always the best approach... Using an ORM means that you are making it much more difficult to use the full expressiveness of SQL. On the other hand, using the full expressiveness of SQL might make it much more difficult to use your data in an object oriented way... You have to weigh the pros and cons depending on the situation. I'm sure different ORMs might be more or less limiting on SQL. I suspect that this depends on how well the designer of the ORM knows SQL. I guess the problem is that those who are best at SQL and most capable of writing a non-limiting ORB are fairly good at working without an ORM, so it's the guys who don't really understand and appreciate the strengths of SQL that designs the ORMs... :) If it turns out that the ORM is a performance problem you can always tune it afterwards. (probably by the DBMS setup, indexes etc.) To a large extent, use of ORMs and a proper OO design, means that you move a lot of logic from the the DB and the SQL layer up to the Python (or whatever language you use) layer, and there are efficient SQL solutions you simply can't reach in that way. As a simple example, the natural way to calculate the averages of an attribute in a set of object in an OO system is to iterate over the objects, get the value, add up a sum, count the objects as you iterate and divide the sum with the count once you were done iterating. It's very simple and straight forward, and often magnitudes slower than the corresponding obvious SQL solution. Its just a layer and therefore the endresult is SQL much the same as the one you would hand code. (and you still can use direct SQL if you like with most of them) That's a joke, right? It might be much the same as *you* would have hand coded, but perhaps very different from what *I* (and I suspect Scott) would have coded. With different approaches to your design, you solve problems in completely different ways. Different languages lend themselves to very different design approaches. The distinction between declarative and imperative languages is pretty big, as is the more concrete ways to actually work with data in Python and SQL. SQL is a really stupid language in many ways. It's pretty useless without a good partner, such as Python, and even considering its limited perspective as a language for querying and manipulating relational databases, I think it could have been designed so much better. I can't see any intelligent reason not to provide the kind of abstractions that function calls provide for instance. The amount of repetition in SQL code in large database applications is appalling. Still, there are applications where it's widely superior to any really existing alternatives, and it goes far beyond manipulating or fetching individual records in tables. In any way you have to bridge the logical gap between the relational and the object data model in your programm. Certainly. So you will end up in building a layer between your persistence code and your problem and domain specific application code, so what you are actually doing is writing an ORM. Well, I wouldn't say it's an ORM unless it tries to be generic in some way. In many cases, this mapping is fairly trivial. I once used SQLObject for a whisky tasting database web app, and I think it made life easier for me than raw SQL would have been, but that was a small system where it was more important to make development fast than to make the end product fast and robust. Not reinventing the wheel every time and using a existing one is IMHO a better approach. Well, as usual... That depends... For each project you have to decide how well different available alternatives fit your actual requirements. If there's an ORM that fit yours, fine. No such external product would be able to handle the applications I work with right now. The kind of conventional use of SQL in ORMs simply won't work for our needs for several reasons. For us, and ORM simply can't solve the problem. For others, it's overkill. As I said, ORMs have their uses, but it seems to me that a reason for many people to use ORMs is to avoid having to properly understand the way relational databases work, and that means they will never use the
Re: Looking for a language/framework
Magnus Lycka schrieb: As I said, ORMs have their uses, but it seems to me that a reason for many people to use ORMs is to avoid having to properly understand the way relational databases work, and that means they will never use the So is the reason for using Python for many people to avoid having to properly understand the way a von Neumann architecture (or Assembler) works? -- Mit freundlichen Grüßen, Ing. Gregor Horvath, Industrieberatung Softwareentwicklung http://www.gregor-horvath.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Gregor Horvath wrote: But what you overlook is SQL's strength: SQL can be translated into _very_ efficient query plans w/o changing the SQL. SQL's query optimizers (more properly, de-pessimizers) give Premature optimization is the root of all evil. On the top level of an appliciation the goal is to only have problem or domain specific code. Middelware or ORM is a way to this goal because it encapsulates and hides the technical details of persistence and helps for cleaner code. Using a relational DBMS is most definitely _not_ premature optimization. A relational system provides a way to store data so that it is later possible to go back into your DBMS setup and improve the performance of your program _without_changing_the_program's_code_. The ORM structure prevents this ability by abstracting away the meaningful structure. The database structures built are as good a DB organization as code generated by code generation programs: the meaning is obscured, and the generated (structure / code) is hard to work with. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Scott David Daniels schrieb: Using a relational DBMS is most definitely _not_ premature optimization. A relational system provides a way to store data so that it is later I did not mean that using a relational DBMS is premature optimization but not using a ORM because of performance considerations is one . If it turns out that the ORM is a performance problem you can always tune it afterwards. (probably by the DBMS setup, indexes etc.) structure. The database structures built are as good a DB organization as code generated by code generation programs: the meaning is obscured, and the generated (structure / code) is hard to work with. Its just a layer and therefore the endresult is SQL much the same as the one you would hand code. (and you still can use direct SQL if you like with most of them) In any way you have to bridge the logical gap between the relational and the object data model in your programm. So you will end up in building a layer between your persistence code and your problem and domain specific application code, so what you are actually doing is writing an ORM. Not reinventing the wheel every time and using a existing one is IMHO a better approach. -- Mit freundlichen Grüßen, Ing. Gregor Horvath, Industrieberatung Softwareentwicklung http://www.gregor-horvath.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
I am presently looking at a commercial product called dbqwiksite. I generates php code. I know that sounds lame, but the demos were impressive. If I could get the product to work like they show in the demos it would be great. It uses ODBC to connect to a mysql database; but I can't get it to work. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
I am presently looking at a commercial product called dbqwiksite. I generates php code. I know that sounds lame, but the demos were impressive. If I could get the product to work like they show in the demos it would be great. It uses ODBC to connect to a mysql database; but I can't get it to work. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
For example, I've never seen an object-relational mapping (technical term for cruft that tries to avoid people having to learn and use SQL) which doesn't drive me into a murderous, foam-at-mouth rage in a very short time -- I *WANT* my SQL, I *LOVE* SQL, it's *WAY* more powerful and suitable for access to data than all those simulated OO DB people lay on top of it (of course, that does depend on having a REAL relational DB underneath, not, say, MySQL;-). Other people disagree very, very deeply with my preferences (as proven by the existence of a begazillion ORMs, including general-purpose ones as well as ones that are part of web-application frameworks). I for one don't have any particular love for SQL. For most purposes I don't want to be bothered with its details. However, I am disillusioned with ORMs. With SQL and old school database management, I had tools such as QBEs, ERD managers to visually manage much of the details (I perform better with pictures than text) and even if others disagree, it worked well for me. Now with ORMs, I am back to code again. Granted, it appears cleaner most of the time but I want to be able to not see it at all. Java ORMs are begining to get a lot of these tools now. But I have been cautious to dip my toes in these cold (verbose, XML infested) waters so far. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Ravi Teja wrote: ... I've never seen an object-relational mapping (technical term for cruft that tries to avoid people having to learn and use SQL) which doesn't drive me into a murderous, foam-at-mouth rage in a very short time -- I *WANT* my SQL, I *LOVE* SQL, it's *WAY* more powerful and suitable for access to data than all those simulated OO DB people lay on top of it I for one don't have any particular love for SQL. For most purposes I don't want to be bothered with its details. However, I am disillusioned with ORMs. With SQL and old school database management, I had tools such as QBEs, ERD managers to visually manage much of the details (I perform better with pictures than text) and even if others disagree, it worked well for me. Now with ORMs, I am back to code again. Granted, it appears cleaner most of the time but I want to be able to not see it at all But what you overlook is SQL's strength: SQL can be translated into _very_ efficient query plans w/o changing the SQL. SQL's query optimizers (more properly, de-pessimizers) give performance which can be tuned w/o touching the SQL. SQL, a language which is truly ugly, not quite standardized, and otherwise quite clunky, does manage to let you say more of what you want without specifying how to get it. This separation of result spec from query plan is what makes makes those optimizers work. The ORMs put objects on top of the DB, but in a way that either (A) violates the object model in that everything must be of the _same_ type in a table (good-bye duck-typing), or (B) gives up on most any attempt to get optimized access -- the DB becomes a persistent store, without the normal SQL feature of our DB admin can tune this up to fly like a peregrine in full stoop. A query planner for well-insulated objects just doesn't have enough information about what it can and cannot rewrite, so it doesn't know how to estimate how much I/O one plan will cost as opposed to another. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Agreed. Mine was hardly a complete list. Another bit I lost is keeping data operations close to the database. I am more likely to use multiple languages/frameworks over the same database than change databases for the same application. I actually prefer functions and procedures within the DB (even if I have to use a non-standard language extension) than implementing them in multiple clients (No, I don't want to toss in middleware unless I have to). -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
But what you overlook is SQL's strength: SQL can be translated into _very_ efficient query plans w/o changing the SQL. SQL's query optimizers (more properly, de-pessimizers) give Premature optimization is the root of all evil. On the top level of an appliciation the goal is to only have problem or domain specific code. Middelware or ORM is a way to this goal because it encapsulates and hides the technical details of persistence and helps for cleaner code. -- Mit freundlichen Grüßen, Ing. Gregor Horvath, Industrieberatung Softwareentwicklung http://www.gregor-horvath.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Steve Juranich wrote: [EMAIL PROTECTED] wrote: As far as hosting, I also know where Zope/Plone hosting from 7.95 a month - although the host doesn't list it on their ads, they do use and host it. Which host would this be? I'm currently exploring some options for getting a Zope site hosted. Virtual servers is getting cheaper and cheaper. That's obviously a viable way to host Zope, if you don't mind being your own sysop. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Actually I recently went from a managed hosting to a virtual host via XEN, it's been great value for the cost -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
walterbyrd wrote:
You can bet it'll be plain old cgi - possibly with an outdated Pyton version.
I think you are right. In practical terms, what does that mean? Will I
not be able to use modules? Will I not be able to use frameworks?
It means that you will be limited to what can run with cgi and the
installed Python version. But instead of wondering, why don't you check
this out with your hosting company ? And if it appears that Python
support is too limited, you can also change for a more Python-friendly
host...
Which frameworks have you looked at ?
django, turbogears, cheetah, cherrypy, . . .
cheetah is a templating system, not a framework. Django needs
mod_python. Turbogears needs Cherrypy, which is itself a web server - so
it's not sure you'll be able to run it, depending on your hosting.
Anyway - I'm actually developping an app with Django, I have also played
with Turbogears (not stable and documented enough by now to be used in
production IMHO, but definitively very exciting) and Cherrypy, and I
certainly wouldn't qualify the learning curve for any of them as 'steep'.
By looked at I mean I read up on them, a little. I have not tried any
of them.
Maybe you should ?
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
ocssolutions.com offers hosting solutions and will host Zope -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Alex Martelli wrote: I've never seen an object-relational mapping (technical term for cruft that tries to avoid people having to learn and use SQL) which doesn't drive me into a murderous, foam-at-mouth rage in a very short time -- I WANT my SQL, I LOVE SQL, it's WAY more powerful and suitable for access to data than all those simulated OO DB people lay on top of it How refreshing to discover I'm not the only person on earth who feels this way. (of course, that does depend on having a REAL relational DB underneath, not, say, MySQL;-). Well, you lost me there ... I prefer MySQL to the alternatives, but I still feel validated :-) Jeffrey -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Jeffrey Froman [EMAIL PROTECTED] wrote: Alex Martelli wrote: I've never seen an object-relational mapping (technical term for cruft that tries to avoid people having to learn and use SQL) which doesn't drive me into a murderous, foam-at-mouth rage in a very short time -- I WANT my SQL, I LOVE SQL, it's WAY more powerful and suitable for access to data than all those simulated OO DB people lay on top of it How refreshing to discover I'm not the only person on earth who feels this way. Hey, there's two of us, if this was Italy we could found a new political party!-) (of course, that does depend on having a REAL relational DB underneath, not, say, MySQL;-). Well, you lost me there ... I prefer MySQL to the alternatives, but I still feel validated :-) Lots of people I respect like MySQL, I just can't see _why_ (compared, for example, to PostgreSQL). I guess our new party will have two rival currents from the start (how nostalgically Italian!-)... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
walterbyrd [EMAIL PROTECTED] wrote: ... I consider php to be an abombination, the backward compatibility issues alone are reason enough to make me hate it. Rail looks promising, but it's difficult to find inexpensive hosting that supports rails. What's your budget? DreamHost offers Rails hosting for $7.95 per month, which definitely falls within what I would call inexpensive, just for example. I'm sure you can find others in similar price ranges. I like python much better, but I'm not certain it's as well suited for web developement. I'm not sure how th e apache module thing works. I am using shared hosting, they provide python, but I'm not sure how limited I'll be. What Python server-side frameworks does your shared hosting service support? Or do they only offer Python as a CGI language? I wouldn't even mind the steep learning curves, so much, except, it seems to me that anything developed with one framework, would not work with another. So if I changed my mind about which framework, I'd have to start all over again - re-learning everything, re-writing everything. Of course, everybody says their framework is the best. But how can I know for sure? I don't have time to try them all. Nobody does, which is the main advantage of Rails -- it so dominates the scene of web frameworks for Ruby, that nobody seriously wonders what framework to pick for that language (there exist others, but their mind share is close to zero). Python frameworks may interoperate at several levels (e.g. through the WSGI middleware layer) but that's not the same as having a single framework. OTOH, different frameworks may cater for different audiences: at one extreme, the webjockey who knows and loves the underlying technologies, from HTTP to SQL, and only wants high productivity without (what he or she perceives as) cruft on top and definitely without any conceptual blockage impeding access to the underlying technologies when that access is wanted; at the other extreme, somebody who doesn't even know the difference between SQL and HTTP, doesn't want to learn anything hard, and just wants to point and grunt and make three websites a day -- and, of course, anything in-between. For example, I've never seen an object-relational mapping (technical term for cruft that tries to avoid people having to learn and use SQL) which doesn't drive me into a murderous, foam-at-mouth rage in a very short time -- I *WANT* my SQL, I *LOVE* SQL, it's *WAY* more powerful and suitable for access to data than all those simulated OO DB people lay on top of it (of course, that does depend on having a REAL relational DB underneath, not, say, MySQL;-). Other people disagree very, very deeply with my preferences (as proven by the existence of a begazillion ORMs, including general-purpose ones as well as ones that are part of web-application frameworks). How is a poor web framework to make both groups happy (me on one side, all the rest of the world on the other;-) without becoming ridiculously complex and ungainly? Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
walterbyrd wrote:
Way back when, I got a lot of training and experience in highly
structued software development. These days, I dabble with
web-development, but I may become more serious.
I consider php to be an abombination, the backward compatibility issues
alone are reason enough to make me hate it. Rail looks promising, but
it's difficult to find inexpensive hosting that supports rails.
I like python much better, but I'm not certain it's as well suited for
web developement.
It is. Much more than PHP.
The problem then is: which solution/framework. And there quite a few
Python web developpment solutions...
I'm not sure how th e apache module thing works.
It exposes most of the Apache API to Python, and provides hooks to take
control over request processing.
I am
using shared hosting, they provide python, but I'm not sure how limited
I'll be.
You can bet it'll be plain old cgi - possibly with an outdated Pyton
version.
Ideally, I would like to be able to develop a database driven web-app,
in much the same manner as I could develop an ms-access app. As much as
I dislike msft, I have to admit, an ms-access app can be put together
quickly, without any steep learning curve.
I've been looking at python web frameworks, and I'm not sure what to
think. It seems like these frameworks would allow me to do a lot of
work, with a small amount of code, but the learning curve seems very
steep.
Which frameworks have you looked at ?
I wouldn't even mind the steep learning curves, so much, except, it
seems to me that anything developed with one framework, would not work
with another.
heck, this is true of all frameworks ever (web or not, Python or not).
So if I changed my mind about which framework, I'd have
to start all over again - re-learning everything, re-writing
everything. Of course, everybody says their framework is the best. But
how can I know for sure?
Trying them ?
I don't have time to try them all.
Then only try the ones that *may* fit your needs !-)
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
You can bet it'll be plain old cgi - possibly with an outdated Pyton version. I think you are right. In practical terms, what does that mean? Will I not be able to use modules? Will I not be able to use frameworks? Which frameworks have you looked at ? django, turbogears, cheetah, cherrypy, . . . By looked at I mean I read up on them, a little. I have not tried any of them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
As far as languages go, Python seems a far better choice than php or perl based solutions. I haven't tried Ruby - so I can't comment. The Zope framework for python has been remarkably productive for me both with and wtihout plone(CMF modules and a look and feel on top of Zope). The documentation is improving, but I can's say the situation is good. In truth, Zope knowledge is zope specific (at least I haven't found it useful) and it was a bit of a transition coming from a j2ee background. I didn't find the learning curve to be very steep, but the path is covered in brambles - haha. Mostly due to the fast pace of development. btw, I am not a zope person or a plone, person - I have however used both solutions to develop some pretty nifty sites faster than anything else I have used. Even through the gettting to know you phase So I'm a pretty big fan. That being said, Zope is it's own universe of ideas, and a lot of them seem odd.As far as hosting, I also know where Zope/Plone hosting from 7.95 a month - although the host doesn't list it on their ads, they do use and host it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
[EMAIL PROTECTED] wrote: As far as hosting, I also know where Zope/Plone hosting from 7.95 a month - although the host doesn't list it on their ads, they do use and host it. Which host would this be? I'm currently exploring some options for getting a Zope site hosted. Thanks much. -- Steve Juranich Tucson, AZ USA -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
walterbyrd [EMAIL PROTECTED] wrote: Ideally, I would like to be able to develop a database driven web-app, in much the same manner as I could develop an ms-access app. As much as I dislike msft, I have to admit, an ms-access app can be put together quickly, without any steep learning curve. Look at django then. It excels (IMHO) at this interfacing to an SQL database. Its admin interface is all you'll ever need for trusted data entry, and you won't have to write any code at all for it. We're currently converting a twisty mass of perl code which we can't maintain any more into a django site, and we've been monstrously impressed! -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
