Thread: [SQLObject] Zope 2/Python 2.1 support
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Ian B. <ia...@co...> - 2003-07-15 02:39:13
|
So, I'm using Zope 2 for some work, and I really want to use SQLObject. Scratching an itch in the traditional sense. So I'm thinking of making a fork of SQLObject that supports Python 2.1. It would be pretty much frozen at 0.4, and I wouldn't plan to develop it much further once I get it working, but it will make me (and maybe others) who use Zope 2 happier for a while until Zope 3. But I don't actually know a ton about Zope -- I'm relatively new to using it, and I must admit I'm a reluctant user. I know Python 2.1 support is the first step, but typically Zope objects need little doo-dads attached to make them usable. Are there things I need to think about? Architectural advise? Someone excited to help me debug this? I can probably whip up the 2.1 support on my own pretty quick (properties replaced with methods, the metaclass replaced with a builder function, classmethods implemented with a hack), but it's the stuff after that to make it useful in Zope that I'm hoping for help with. Ian |
From: Sidnei da S. <si...@re...> - 2003-07-15 03:17:46
|
On Mon, Jul 14, 2003 at 09:39:54PM -0500, Ian Bicking wrote: | So, I'm using Zope 2 for some work, and I really want to use SQLObject. | Scratching an itch in the traditional sense. So I'm thinking of making | a fork of SQLObject that supports Python 2.1. It would be pretty much | frozen at 0.4, and I wouldn't plan to develop it much further once I get | it working, but it will make me (and maybe others) who use Zope 2 | happier for a while until Zope 3. | | But I don't actually know a ton about Zope -- I'm relatively new to | using it, and I must admit I'm a reluctant user. I know Python 2.1 | support is the first step, but typically Zope objects need little | doo-dads attached to make them usable. Are there things I need to think | about? Architectural advise? Someone excited to help me debug this? I | can probably whip up the 2.1 support on my own pretty quick (properties | replaced with methods, the metaclass replaced with a builder function, | classmethods implemented with a hack), but it's the stuff after that to | make it useful in Zope that I'm hoping for help with. Err... I would not recommend anyone that. It looks like too much trouble for what you want to do. As for myself, I would wait until the pythonlabs folks finish porting the ExtensionClass stuff to be compatible with python2.2 (which should happen RSN, afaict). BUT, if you want to go the Zope 3 route, I would love to give you a hand >:) []'s -- Sidnei da Silva (dreamcatcher) <si...@re...> Debian GNU/Linux 2.4.20-powerpc ppc Any programming language is at its best before it is implemented and used. ----------------------------------------------------------------------- Verified for virus by mail.redesul.com.br Scanner: clamscan / ClamAV - Version 0.54 - Updated 08/07/2003 |
From: Ian B. <ia...@co...> - 2003-07-15 03:43:13
|
On Mon, 2003-07-14 at 22:15, Sidnei da Silva wrote: > Err... I would not recommend anyone that. It looks like too much > trouble for what you want to do. As for myself, I would wait until the > pythonlabs folks finish porting the ExtensionClass stuff to be > compatible with python2.2 (which should happen RSN, afaict). Do you think there is trouble outside of the Python 2.1 issue? It'd be a little annoying, but I'm okay with it -- when I compare it to writing Z SQL methods, porting SQLObject to 2.1 seems quite enjoyable ;) 2.2 has been out for so very long that I don't know what to make of Zope not supporting it. I don't know, I'm not entirely sold on the idea. I'm just trying to make my Zope 2 development time more pleasant, because I'm not enjoying it very much. It's all strictly procedural programming (no OO), and I feel like the way we're using the database has a lot to do with that. So SQLObject seemed like a nice starting point. > BUT, if you want to go the Zope 3 route, I would love to give you a > hand >:) Well, all my Zope work is strictly professional. Certainly when X3 comes around I'll be pushing strongly for the place I'm working for to use it for new projects, and I wouldn't even dismiss the possibility that Zope could convert me in the process, but I don't know that I want to wait for that. Before X3 I am probably going to be pushing them to use something other than Zope, but that may or may not go anywhere. In my non-professional work (where Zope 3 would currently have to live) I'm more interested in other Python web stuff besides Zope. But I'd certainly support making SQLObject and Zope 3 work together. Ian |
From: Sidnei da S. <si...@re...> - 2003-07-15 04:01:24
|
On Mon, Jul 14, 2003 at 10:43:54PM -0500, Ian Bicking wrote: | Do you think there is trouble outside of the Python 2.1 issue? It'd be | a little annoying, but I'm okay with it -- when I compare it to writing | Z SQL methods, porting SQLObject to 2.1 seems quite enjoyable ;) There are some stuff that would scare me. For example, getting a SQLObject Connection to play nicely with the Zope Transaction Machinery. Thats the tricky part. There is also a problem that its quite difficult to get Zope to display non-persistent objects (eg: stuff coming from SQLObject), and you can't mix new-style classes with ExtensionClass. If you just want to use SQLObject to do the same stuff as SQLScript, but in an easier way, you wont have much trouble, but if you want to have SQLObject to behave like content, then it will be quite hard, because you'll need some stuff to be persistent and some not. Or play acquisition tricks to get SQLObjects to behave like they are inside the ZODB. | 2.2 has been out for so very long that I don't know what to make of Zope | not supporting it. | | I don't know, I'm not entirely sold on the idea. I'm just trying to | make my Zope 2 development time more pleasant, because I'm not enjoying | it very much. It's all strictly procedural programming (no OO), and I | feel like the way we're using the database has a lot to do with that. | So SQLObject seemed like a nice starting point. Yes, it may be a nice start. You just need to figure out the easier way to do it. | > BUT, if you want to go the Zope 3 route, I would love to give you a | > hand >:) | | Well, all my Zope work is strictly professional. Certainly when X3 | comes around I'll be pushing strongly for the place I'm working for to | use it for new projects, and I wouldn't even dismiss the possibility | that Zope could convert me in the process, but I don't know that I want | to wait for that. Let's hope this happens soon :) | Before X3 I am probably going to be pushing them to use something other | than Zope, but that may or may not go anywhere. In my non-professional | work (where Zope 3 would currently have to live) I'm more interested in | other Python web stuff besides Zope. But I'd certainly support making | SQLObject and Zope 3 work together. Good to know! Just for curiosity, what is the 'other python stuff' you're interested in? Would it be Twisted? []'s -- Sidnei da Silva (dreamcatcher) <si...@re...> Debian GNU/Linux 2.4.20-powerpc ppc Basic is a high level languish. APL is a high level anguish. ----------------------------------------------------------------------- Verified for virus by mail.redesul.com.br Scanner: clamscan / ClamAV - Version 0.54 - Updated 08/07/2003 |
From: Ian B. <ia...@co...> - 2003-07-15 04:29:13
|
On Mon, 2003-07-14 at 22:58, Sidnei da Silva wrote: > On Mon, Jul 14, 2003 at 10:43:54PM -0500, Ian Bicking wrote: > | Do you think there is trouble outside of the Python 2.1 issue? It'd be > | a little annoying, but I'm okay with it -- when I compare it to writing > | Z SQL methods, porting SQLObject to 2.1 seems quite enjoyable ;) > > There are some stuff that would scare me. For example, getting a > SQLObject Connection to play nicely with the Zope Transaction > Machinery. Thats the tricky part. There is also a problem that its > quite difficult to get Zope to display non-persistent objects (eg: > stuff coming from SQLObject), and you can't mix new-style classes with > ExtensionClass. If you just want to use SQLObject to do the same stuff > as SQLScript, but in an easier way, you wont have much trouble, but if > you want to have SQLObject to behave like content, then it will be > quite hard, because you'll need some stuff to be persistent and some > not. Or play acquisition tricks to get SQLObjects to behave like they > are inside the ZODB. Ack... just thinking about that stuff makes my head hurt. ZODB and acquisition together create this weird environment that always seems unpredictable to me. I'd be quite happy avoiding those -- in fact, anything that allows me to avoid those would be a feature in my mind. (Well, ZODB probably isn't so bad, but I still don't entirely understand how it fits into the entire system) I would expect that SQLObject instances wouldn't live in ZODB, or in the Zope filesystem or anything like that. For rendering and manipulation you'd use Python Scripts and templates and such, i.e., SQLObject instances would never be directly published. > | Before X3 I am probably going to be pushing them to use something other > | than Zope, but that may or may not go anywhere. In my non-professional > | work (where Zope 3 would currently have to live) I'm more interested in > | other Python web stuff besides Zope. But I'd certainly support making > | SQLObject and Zope 3 work together. > > Good to know! Just for curiosity, what is the 'other python stuff' > you're interested in? Would it be Twisted? Nah, I'm not a big fan of Twisted. Nice guys, some good ideas, but I don't think asynchronous programming makes much sense past low-level stuff. Just as an example, SQLObject would not work well with Twisted at all, since it hides blocking code (i.e., database calls), and you have to be very careful about such code when doing asynchronous programming. Twisted is very different from Zope, but just as insular, which is a big drawback for me. I've worked with Webware a fair amount, and I've now I'm hoping to help bring together all the similar alternatives, of which there are an excessive number. And then there's the form processing library which is always on the back of my mind, but always feels a little way off for me... Ian |
From: Sidnei da S. <si...@re...> - 2003-07-15 11:39:13
|
| Ack... just thinking about that stuff makes my head hurt. ZODB and | acquisition together create this weird environment that always seems | unpredictable to me. I'd be quite happy avoiding those -- in fact, | anything that allows me to avoid those would be a feature in my mind. | (Well, ZODB probably isn't so bad, but I still don't entirely understand | how it fits into the entire system) | | I would expect that SQLObject instances wouldn't live in ZODB, or in the | Zope filesystem or anything like that. For rendering and manipulation | you'd use Python Scripts and templates and such, i.e., SQLObject | instances would never be directly published. Ok, thats pretty simple for you to do (maybe not entirely safe, but that's another issue...) . For using it in Python Scripts you'll probably have to make a security assertion that SQLObject classes are importable. I would add one by one until it gets usable, because you may not need all of them. | > Good to know! Just for curiosity, what is the 'other python stuff' | > you're interested in? Would it be Twisted? | | Nah, I'm not a big fan of Twisted. Nice guys, some good ideas, but I | don't think asynchronous programming makes much sense past low-level | stuff. Just as an example, SQLObject would not work well with Twisted | at all, since it hides blocking code (i.e., database calls), and you | have to be very careful about such code when doing asynchronous | programming. Twisted is very different from Zope, but just as insular, | which is a big drawback for me. | | I've worked with Webware a fair amount, and I've now I'm hoping to help | bring together all the similar alternatives, of which there are an | excessive number. And then there's the form processing library which is | always on the back of my mind, but always feels a little way off for | me... Like, you want to write a standalone form processing library for using with SQLObject? Or do you have a existing implementation in mind that you want to adapt? []'s -- Sidnei da Silva (dreamcatcher) <si...@re...> Debian GNU/Linux 2.4.20-powerpc ppc People are going to scream bloody murder about that. -- Seen on linux-kernel ----------------------------------------------------------------------- Verified for virus by mail.redesul.com.br Scanner: clamscan / ClamAV - Version 0.54 - Updated 08/07/2003 |