5 ms·
I'm not very familiar with the culture of the Python community so this might come across as offending, but why such an obsession with "pure" Python? On one ext
by kijin 14y ago
I'm not very familiar with the culture of the Python community so this might come across as offending, but why such an obsession with "pure" Python?
On one extreme, of course, there are spaghetti apps that mix PHP, HTML, CSS, JS, shell, and SQL in the same file. We all know and hate those apps. But is there any reason to jump to the other extreme and turn as much as possible into "pure" $LANGUAGE ?
As soon as your query gets moderately complicated, you're still littering Python with SQL keywords like order_by(), desc(), select(), and commit(). The GROUP BY section of the documentation just reads like a rough translation of SQL into Python, the only difference being the syntax. It's like watching a first-week ESL student try to construct sentences in English.
The documentation advertises that "Pony allows any programmer to write complex and effective queries against a database, even without being an expert in SQL." I don't think this is true for any ORM I've seen so far, whether in Python or in any other popular language. Beyond a certain level of complexity, you need to know SQL in order to write complex queries. But if you already know SQL, why translate long GROUP BY ... HAVING queries into Python only to have the ORM translate it back into SQL? Why are we trying so hard to avoid writing SQL? What are we going to do next? Write a library that translates pure Python into Lua scripts for your Redis server?
I like ORMs because they simplify frequent tasks, like grabbing a dozen items from the database and filtering them by a couple of columns. I also like them because they often come with caching and effective protections against SQL injection attacks. But I also think that purity is overrated. Both web apps and native apps are already a mixture of several different languages, both on the frontend and on the backend. Don't be afraid to add SQL to your belt, it's just another language.
(By the way, why is there an order_by() method and a separate orderby() method?)
- dagw 14y agowhy such an obsession with "pure" Python? One guess is that python is very popular among large non-developer communities, like GIS, Finance, and various groups doing numerical analysis. Many of these people aren't programmers and have no desire to become programs, they simply use python to automate tedious tasks and script the applications they use. If you tell them they have to learn a second language completely unrelated to the one they already know just to grab some data from a database, they'll probably push back. Tell them they can grab data from the database using the language they already know and they'll be much more interested in learning. Also the diagram editor is conceptually similar to many tools they might already be using and thus it might be easier for them to get a hang of it.
- d0ugal 14y agoI think you need to know SQL to use this. An ORM like Django's offers a higher level of abstraction and removes the need to fully understand SQL in many cases. This is closer to a direct translation. A few possible reasons I can think of; - People prefer to only work in one language - you don't need to make the full mental shift - It works better/looks better in Python editors - It should be safer and cleaner that mashing SQL strings together.
- estebank 14y agoA few other potential benefits: - syntax highlighting - autocomplete - syntax check - query linting, finding common antipatterns - no SQL injections possible
- david 14y agoRight, there's only like a million of these already in existence in every language and I have yet to find one that is comprehensive enough that I don't just fall back to regular sql queries sooner or later. And if you think about it, any library that was powerful enough for me to not write SQL anymore would basically have to rewrite the complete SQL spec using awkward hacks in a language that is totally unsuited for it. And if you're writing an application of any complexity or size using an SQL database you need the full capacities of SQL. There are a lot of little features or quirks of SQL that these languges seem to overlook that you need to make your app perform. Now I usually just write a couple functions like this: query("SELECT one, two FROM mytable", ["WHERE weight > %f AND name = '%s'", weight, name]); That gives me SQL-injection protection, lets me save subqueries as strings and re-use them, and caching to if I need it. And as a plus, I don't have continuously look up/relearn each little feature of SQL in this little language, or if I write it this way is it actually going to compile into the SQL I want? It's pretty much inevitable that you're going to need to know/control the SQL that's being written sooner or later (usually sooner), so save yourself the extra headache and just go SQL from the start.
- ralph 14y agoA "couple [of] functions"? What does the other do?
- stcredzero 14y ago[of] is optional in this case.
- ronnix 14y ago> I'm not very familiar with the culture of the Python community so this might come across as offending, but why such an obsession with "pure" Python? I think it refers to the implementation, meaning the library has no C modules and is written 100% in Python. This means it should be able to run on all Python implementations, including Jython, IronPython, PyPy, Google App Engine...
- kijin 14y agoI see. It actually makes sense to emphasize the purity in this case, since it almost looks like Pony is messing with the Python interpreter itself.
- amalashkevich 14y agoI'm Alexey Malashkevich, one of the Pony ORM authors. For now Pony ORM runs on CPython only because there is no access to frames in other implementations. "Pure Python" means that you can write queries in term of objects using Python generators.
- ronnix 14y agoOK, thanks. But isn't it the point of all ORMs? Why the emphasis on pure?
- amalashkevich 14y agoPure in this case means that you can use Python syntax in order to query a database. This way a database query looks identical to an iteration over a list of Python objects.
- mbreese 14y agoOrdinarily this is what "pure python" would mean. Since "pure python" libraries can run anywhere without compiling C code. But in this case, they are referring to the fact that you don't have to write SQL and write your queries using Python syntax generators.
- ulput 14y agoPure Python ensures that your software is as slow as possible. This minimizes the likelihood of users mistakenly continuing to use it despite its low quality, and thus maximizes global welfare.
- kozlovsky 14y agoHi, I answered about “pure Python” obsession in a separate comment ;) > you're still littering Python with SQL keywords like order_by(), desc(), select(), and commit() Well, I see them not as “SQL keywords” but as logical concepts > The GROUP BY section of the documentation just reads like a rough translation of SQL into Python Hmm, not sure I understand this. With PonyORM, GROUP BY section is generated automatically, and not present in Pony ORM queries. This eliminates the need to duplicate the same columns in SELECT and GROUP BY sections. > Beyond a certain level of complexity, you need to know SQL in order to write complex queries. I agree with this. But I hope PonyORM can lower entry barrier for new developers. Also, PonyORM allows developers to use pure SQL, if all they need from mapper is IdentityMap, caching, etc. > By the way, why is there an order_by() method and a separate orderby() method? Thanks for noticing this, it is a typo in documentation. The method was renamed from orderby() to order_by() recently.
- kijin 14y agoHere's an example from the documentation that just reads like a "rough translation of SQL into Python": select((item.order, item.order.total_price, sum(item.price * item.quantity)) for item in OrderItem if item.order.total_price < sum(item.price * item.quantity))
- kozlovsky 14y agoWell, it doesn't seems that "rough" to me, because content of GROUP BY and HAVING sections is determined automatically and there is no need to manually join tables
- saosebastiao 14y agoSQL is declarative, statically typed but with an incredible type-inference system, and does an amazing amount of optimization behind the scenes. If it weren't so domain-specific, it would be the holy grail of languages. It amazes me how many developer hours of effort has been put into this global quest to completely avoid SQL. It is starting to remind me of all the people I work with that would rather write 10k lines of VBA for some unmaintainable Excel spreadsheet than learn to write 300 lines of Python/Ruby/Lua/Whatever that can accomplish exactly the same task. I can understand some hesitation to learn something new, especially when there are so many new things to learn and the value of learning them is not always apparent...but I would assume that the benefits of knowing SQL would be readily apparent. I'm not even a developer and I would feel like a quadriplegic without it.
- romaniv 14y agoIt's not hesitance to learn something new. People avoid SQL for a variety of fairly rational reasons. For me, the biggest one is that most general-purpose programming languages encourage you to solve large problems by splitting them up into manageable chunks. SQL, on the other hand, encourages you to lump different problems together (for performance reasons). It also has remarkably poor tools for code reuse and abstraction. Have you ever worked with SPs that dynamically generate SQL code? I see it daily. Not only that, it's code written by professional database administrators.
- pwang 14y ago> If it weren't so domain-specific, it would be the holy grail of languages. That's relatively true of many languages. The reason SQL has been able to be optimized so heavily (and the reason why it's been adopted so broadly) is because it is so domain specific. More specifically, it is optimized for expression set algebraic operations, and certain kinds of kernels to apply to resultant sets. It is most definitely NOT suited for most array or otherwise metrically-oriented data series, which is why you never see it used in HPC to express timeseries transformations or, say, 3D PDE diffusion simulations. For those applications, people have come up with different kinds of specialized languages which are rooted in an more appropriate data abstraction than merely set operations.
- nightski 14y agoYou are assuming the only purpose of doing this IS to generate SQL. In this library that may be the case, but the truth is with say Linq in .NET there are a variety of back ends (Linq to objects being very useful). Many sql operations are very useful when working with data, even outside of a database. None of this is new.