Thread: [SQLObject] my updateSchema small routine
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: sophana <so...@zi...> - 2006-09-23 21:55:49
|
Here is my (very small) contribution to sqlobject, that I find very cool to program with. There are 3 parts: - pickle support: I store sqlobject instances directly in my web session object which is picked. - getNone is just a helper routine ... - a very interesting one is updateSchema: I was trying to find a simple way to change the sqlobject schema, and propagate it into the database automaticaly. This is now possible with updateSchema which drops or add columns that are not in the database. The routine won't change anything if you don't set the doIt arg to True I know this should have been written in the SqlMeta class, but as I have multiple environment (prod+multiple dev) I need my project to be portable, and I don't want to change anything in sqlobject. I found some changes that could be done un sqlobject's col.py: the mysqlCreateSql ( or more precisely _extraSQL()) does not use the default parameter. So when adding a new column, I can't give it a default value for already existing rows. When I have some time (not now), I will try to make a clean patch+tests. (SQLObject 0.7.1dev) class MySqlObject(SQLObject): class sqlmeta: style = MixedCaseStyle() def __getstate__(self): return self.id def __setstate__(self,id): pass def __new__(cls, *args, **kw): if len(args) == 1: return cls.get(args[0]) return SQLObject.__new__(cls, *args, **kw) def __getnewargs__(self): return (self.id,) def getNone(cls,id): try: return cls.get(id) except SQLObjectNotFound: return None except: raise getNone=classmethod(getNone) def updateSchema(self, doIt=False, connection=None): conn = connection or self._connection schema={} cols=self.sqlmeta.columns for a in conn.columnsFromSchema(self.sqlmeta.table, self): schema[a.name]=a #print a.name if a.name not in cols.keys(): print a.name ,'not in class' if doIt: conn.query('ALTER TABLE %s DROP COLUMN %s'%(self.sqlmeta.table,str(a.name))) for name,col in cols.iteritems(): if name not in schema.keys(): print name ,'not in schema' if doIt: conn.addColumn(self.sqlmeta.table,col) updateSchema=classmethod(updateSchema) |
From: Oleg B. <ph...@ph...> - 2006-09-24 06:48:10
|
On Sun, Sep 24, 2006 at 12:03:04AM +0200, sophana wrote: > Here is my (very small) contribution to sqlobject, that I find very cool > to program with. Thank you! > When I have some time (not now), I will try to make a clean patch+tests. > (SQLObject 0.7.1dev) At that time SQLObject 0.7.1 final will be released, so your patch will go to the trunk, and thus should be created and tested against the trunk. > class MySqlObject(SQLObject): Oops, at the first glance I thought (guessing from the name) it is MySQL-only! ;) PikleableSQLObject? > def __setstate__(self,id): > def getNone(cls,id): Preferred style is: def __setstate__(self, id): def getNone(cls, id): (spaces) and 4 spaces for an indent: try: return cls.get(id) except SQLObjectNotFound: return None except: raise With all those print's this > def updateSchema(self, doIt=False, connection=None): looks like a debugging procedure... Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ilias L. <il...@la...> - 2006-10-01 18:07:13
|
Oleg Broytmann wrote: > On Sun, Sep 24, 2006 at 12:03:04AM +0200, sophana wrote: >> Here is my (very small) contribution to sqlobject, that I find very cool >> to program with. ... > With all those print's this > >> def updateSchema(self, doIt=False, connection=None): > > looks like a debugging procedure... > > Oleg. shouldn't this be used by the team? I mean, it's a _very_ important functionality. . -- http://lazaridis.com |
From: sophana <so...@zi...> - 2006-10-01 18:57:27
|
Ilias Lazaridis a =E9crit : > Oleg Broytmann wrote: > =20 >> On Sun, Sep 24, 2006 at 12:03:04AM +0200, sophana wrote: >> =20 >>> Here is my (very small) contribution to sqlobject, that I find very c= ool >>> to program with. >>> =20 > ... > > =20 >> With all those print's this >> >> =20 >>> def updateSchema(self, doIt=3DFalse, connection=3DNone): >>> =20 >> looks like a debugging procedure... >> >> Oleg. >> =20 > > shouldn't this be used by the team? > > I mean, it's a _very_ important functionality. > > . > > =20 It's true that it helps a lot when upgrading the schema. I don't understand why it was not in SqlObject before. I tried to use sqlObjectAdmin but I couldn't even find this functionality which fits in so few lines of code. To resume what it does, it compares the columns in the object and in the database. It deletes all columns that are not in the SqlObject declaration, and add missing ones to the database. It suffers from default values not being set correctly because _extraSQL method in col.py that does not add default values. Default values are important when upgrading a schema... When you don't set doIt to True, the method only tells what it is going to do. This is important if you don't want a column to be deleted by accident... |
From: Ilias L. <il...@la...> - 2006-10-01 18:54:20
|
Oleg Broytmann wrote: > On Sun, Oct 01, 2006 at 09:06:57PM +0300, Ilias Lazaridis wrote: >>>> def updateSchema(self, doIt=False, connection=None): >> shouldn't this be used by the team? > > In what way? to integrate it into sqlobject. As I understand, it does not provide (currently) automated schema evolution. I would be interested in contributing to this, too (if I get some support from the existing team). my use-case is this one: http://case.lazaridis.com/wiki/TurboGearsProductEvaluation . -- http://lazaridis.com |
From: Ilias L. <il...@la...> - 2006-10-01 21:30:47
|
Oleg Broytmann wrote: > On Sun, Oct 01, 2006 at 09:53:59PM +0300, Ilias Lazaridis wrote: >> As I understand, it does not provide (currently) automated schema evolution. >> >> I would be interested in contributing to this, too (if I get some > > You are welcome. > >> support from the existing team). > > I would very much like to see any team around. :-/ > > What support do you need? normall just some answers to questions about the internals. but it looks a little inactive this project. >> my use-case is this one: >> http://case.lazaridis.com/wiki/TurboGearsProductEvaluation > > Which one of those? the whole thing is the use case. . -- http://lazaridis.com |
From: Ilias L. <il...@la...> - 2006-10-02 15:32:05
|
Oleg Broytmann wrote: > On Mon, Oct 02, 2006 at 12:30:16AM +0300, Ilias Lazaridis wrote: >> Oleg Broytmann wrote: >>>> I would be interested in contributing to this, too (if I get some >>>> support from the existing team). >>> What support do you need? >> normall just some answers to questions about the internals. > > I'll try to do my best, though there are some parts of SQLObject that I > do not fully understand, especially caching and some unobvious parts of > inheritance. I see. >> but it looks a little inactive this project. > > It is not, it just somewhat slow. Ian Bicking, the original author, is > designing a new generation SQLObject2, where is the SQLObject2 project located? and when is the planned release? > while I am working on SQLObject. I'd > like to see more people around, as there are many things to do... yes, I've noticed that even the project-infrastructure is not that operative. . -- http://lazaridis.com |
From: Oleg B. <ph...@ph...> - 2006-10-01 18:13:36
|
On Sun, Oct 01, 2006 at 09:06:57PM +0300, Ilias Lazaridis wrote: > >> def updateSchema(self, doIt=False, connection=None): > > > shouldn't this be used by the team? In what way? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2006-10-01 19:18:47
|
On Sun, Oct 01, 2006 at 09:53:59PM +0300, Ilias Lazaridis wrote: > As I understand, it does not provide (currently) automated schema evolution. > > I would be interested in contributing to this, too (if I get some You are welcome. > support from the existing team). I would very much like to see any team around. :-/ What support do you need? > my use-case is this one: > http://case.lazaridis.com/wiki/TurboGearsProductEvaluation Which one of those? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ilias L. <il...@la...> - 2006-10-01 21:37:50
|
sophana wrote: > Ilias Lazaridis a écrit : >> Oleg Broytmann wrote: >> >>> On Sun, Sep 24, 2006 at 12:03:04AM +0200, sophana wrote: >>> >>>> Here is my (very small) contribution to sqlobject, that I find very cool >>>> to program with. >>>> >> ... >> >> >>> With all those print's this >>> >>> >>>> def updateSchema(self, doIt=False, connection=None): >>>> >>> looks like a debugging procedure... >>> >>> Oleg. >>> >> shouldn't this be used by the team? >> >> I mean, it's a _very_ important functionality. >> >> . >> >> > It's true that it helps a lot when upgrading the schema. > I don't understand why it was not in SqlObject before. > I tried to use sqlObjectAdmin but I couldn't even find this > functionality which fits in so few lines of code. I had provided a similar solution for the django orm layer: http://case.lazaridis.com/browser/django/rework/evolve.py but that was not integrated. > To resume what it does, it compares the columns in the object and in the > database. > It deletes all columns that are not in the SqlObject declaration, and > add missing ones to the database. > > It suffers from default values not being set correctly because _extraSQL > method in col.py that does not add default values. > Default values are important when upgrading a schema... would this be much effort to add this? what do you think? > When you don't set doIt to True, the method only tells what it is going > to do. > This is important if you don't want a column to be deleted by accident... . -- http://lazaridis.com |
From: sophana <so...@zi...> - 2006-10-02 07:52:31
|
Ilias Lazaridis a =E9crit : >> It suffers from default values not being set correctly because _extraS= QL >> method in col.py that does not add default values. >> Default values are important when upgrading a schema... >> =20 > > would this be much effort to add this? > > what do you think? > > =20 2 small lines. Very simple, but to be tested with multiple types. I didn't do it because it's dificult for me to manage changes to sqlobject in my 3 diferent locations. |
From: Dan P. <da...@ag...> - 2006-10-02 18:01:29
|
On Monday 02 October 2006 11:16, Oleg Broytmann wrote: > -- do not break compatibility, remember, SQLObject is still supports > Python 2.2; Unfortunately this is more a desired thing than an actual fact. SQLObject depends on FormEncode, and FormEncode contains python2.4 specific code. It is true that for the moment that code is not operational and can be removed, but unless you rely on some distribution to have packaged them for you and fixed these problems already, or you know how to deal with them yourself, it doesn't. For people who simply take the source and attempt a setup.py install, it will not work with anything older than 2.4 unless they modify the source. -- Dan |
From: Oleg B. <ph...@ph...> - 2006-10-02 08:13:11
|
On Mon, Oct 02, 2006 at 12:30:16AM +0300, Ilias Lazaridis wrote: > Oleg Broytmann wrote: > >> I would be interested in contributing to this, too (if I get some > >> support from the existing team). > > > > What support do you need? > > normall just some answers to questions about the internals. I'll try to do my best, though there are some parts of SQLObject that I do not fully understand, especially caching and some unobvious parts of inheritance. > but it looks a little inactive this project. It is not, it just somewhat slow. Ian Bicking, the original author, is designing a new generation SQLObject2, while I am working on SQLObject. I'd like to see more people around, as there are many things to do... Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2006-10-02 08:17:07
|
On Mon, Oct 02, 2006 at 12:37:23AM +0300, Ilias Lazaridis wrote: > would this be much effort to add this? In the beginning it would. The developer's learning curve is steep 'cause I am trying not to accept quick'n'direty hacks. You have to learn SQLObject test suite. GUIDELINES TO PATCHING The quality of patches is determined by the following conditions: -- small, clear, non-invasive patches are the best ones; patches that change public API in an incompatible way cannot be applied to the bugfix branches; -- do not break compatibility, remember, SQLObject is still supports Python 2.2; SQLObject works with a lot of database backends, with MySQL, PostgreSQL and SQLite being the three major ones; for example, different versions of MySQLdb (mysql-python DB API 2 driver) work differently in relation to unicode, a patch should not make MySQLConnection more unicode-aware because it breaks other connection classes - SQLObject currently works only with non-unicode string queries; -- the quality of code; never do "copy/paste programming" - do code reuse as much as possible; -- there must be at least a test; the more tests the better; -- documentation is a big plus. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ilias L. <il...@la...> - 2006-10-02 15:38:27
|
Oleg Broytmann wrote: > On Mon, Oct 02, 2006 at 12:37:23AM +0300, Ilias Lazaridis wrote: >> would this be much effort to add this? > > In the beginning it would. The developer's learning curve is steep 'cause > I am trying not to accept quick'n'direty hacks. You have to learn SQLObject > test suite. 'chirugical' additions can be quick&dirty, they do not interfere with the existent API. e.g. an additional(!) function "evolveTable", clearly marked as "in-development" can be added immediately to a development trunk. > GUIDELINES TO PATCHING > > The quality of patches is determined by the following conditions: > > -- small, clear, non-invasive patches are the best ones; patches that > change public API in an incompatible way cannot be applied to the bugfix > branches; > > -- do not break compatibility, remember, SQLObject is still supports Python > 2.2; SQLObject works with a lot of database backends, with MySQL, > PostgreSQL and SQLite being the three major ones; for example, different > versions of MySQLdb (mysql-python DB API 2 driver) work differently in > relation to unicode, a patch should not make MySQLConnection more > unicode-aware because it breaks other connection classes - SQLObject > currently works only with non-unicode string queries; again, a "development" tagged function can be tested and modified more and more. > -- the quality of code; never do "copy/paste programming" - do code reuse > as much as possible; ok > -- there must be at least a test; the more tests the better; ok, but tests can be provided from interested parties, too (after becoming exited about the provided "development" function addition). > -- documentation is a big plus. again, can be provided incrementally > Oleg. I think it is important to get new functionality into the actual development version. It can be later removed if it cannot be stabelized. If yes, the function (here: evolveTable) is moved to "alpha", "beta" and the "final" status. . -- http://lazaridis.com |
From: Oleg B. <ph...@ph...> - 2006-10-02 16:38:08
|
On Mon, Oct 02, 2006 at 06:37:42PM +0300, Ilias Lazaridis wrote: > > -- there must be at least a test; the more tests the better; > > ok, but tests can be provided from interested parties, too (after > becoming exited about the provided "development" function addition). The real situation here is usually worse than that - I have hard time asking the developers to provide tests for their patches, even less for other's patches. > I think it is important to get new functionality into the actual > development version. It can be later removed if it cannot be stabelized. They tends to be forgotten if not debugged at once. > where is the SQLObject2 project located? http://sqlobject.org/2/ > and when is the planned release? I don't think it will be released any tome soon. It needs a lot of work, as far as I understand. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ilias L. <il...@la...> - 2006-10-02 22:05:57
|
Oleg Broytmann wrote: > On Mon, Oct 02, 2006 at 06:37:42PM +0300, Ilias Lazaridis wrote: >>> -- there must be at least a test; the more tests the better; >> ok, but tests can be provided from interested parties, too (after >> becoming exited about the provided "development" function addition). > > The real situation here is usually worse than that - I have hard time > asking the developers to provide tests for their patches, even less for > other's patches. I see. Possibly the process of providing tests should be simplified. >> I think it is important to get new functionality into the actual >> development version. It can be later removed if it cannot be stabelized. > > They tends to be forgotten if not debugged at once. ??? not with an active user-base. >> where is the SQLObject2 project located? > > http://sqlobject.org/2/ > >> and when is the planned release? > > I don't think it will be released any tome soon. It needs a lot of work, > as far as I understand. I think I understand. Possibly it's time to rearrange the efforts subjecting SQLObject. . -- http://lazaridis.com |
From: Dan P. <da...@ag...> - 2006-10-02 18:11:04
|
On Monday 02 October 2006 18:37, Ilias Lazaridis wrote: > > -- documentation is a big plus. > > again, can be provided incrementally Experience shows that this almost never happens. Once someone gets his pet code integrated, they never care to document it. They know how it works and don't need documentation, so they don't bother. What is worse is that (in my experience) they don't even return to maintain their code (in case it was something more than a bug fix) and the original author is forced to fix and maintain their code later. Currently the SQLObject documentation is scarce. There are so many things you can only find out about if you read the source, and there are things in the existing documentation that are no longer accurate and can be misleading. And I haven't seen any incremental addition to them, but while I read the code I discover new undocumented things added regularly. -- Dan |
From: Ilias L. <il...@la...> - 2006-10-02 22:10:32
|
Dan Pascu wrote: > On Monday 02 October 2006 18:37, Ilias Lazaridis wrote: >>> -- documentation is a big plus. >> again, can be provided incrementally > > Experience shows that this almost never happens. Once someone gets his pet > code integrated, they never care to document it. They know how it works > and don't need documentation, so they don't bother. > What is worse is that (in my experience) they don't even return to > maintain their code (in case it was something more than a bug fix) and > the original author is forced to fix and maintain their code later. > > Currently the SQLObject documentation is scarce. There are so many things > you can only find out about if you read the source, and there are things > in the existing documentation that are no longer accurate and can be > misleading. And I haven't seen any incremental addition to them, but > while I read the code I discover new undocumented things added regularly. I see. Al this you've mentioned gives me the impression of a badly organized project. Basicly this starts from the project resources. I mean, trac is really a nice tool, especially for the python-domain. And I think every python project should have this front-end to the SVN. . -- http://lazaridis.com |
From: Dan P. <da...@ag...> - 2006-10-02 23:44:11
|
On Tuesday 03 October 2006 01:07, Ilias Lazaridis wrote: > Dan Pascu wrote: > > On Monday 02 October 2006 18:37, Ilias Lazaridis wrote: > >>> -- documentation is a big plus. > >> > >> again, can be provided incrementally > > > > Experience shows that this almost never happens. Once someone gets > > his pet code integrated, they never care to document it. They know > > how it works and don't need documentation, so they don't bother. > > What is worse is that (in my experience) they don't even return to > > maintain their code (in case it was something more than a bug fix) > > and the original author is forced to fix and maintain their code > > later. > > > > Currently the SQLObject documentation is scarce. There are so many > > things you can only find out about if you read the source, and there > > are things in the existing documentation that are no longer accurate > > and can be misleading. And I haven't seen any incremental addition to > > them, but while I read the code I discover new undocumented things > > added regularly. > > I see. > > Al this you've mentioned gives me the impression of a badly organized > project. I think you got it all wrong here. I'm not talking particularly about sqlobject. I was expressing my experience with a dozen open source projects I participated in as either an active developer or just a user. It's the quality of the people that contribute to a project that gives the result, not as much how resources are managed. You have to have what to manage in the first place. An opensource project is not a company where people are motivated by a salary and have deadlines they must respect and a management in front of which they have to answer. It's _very_ difficult to get quality developers that are willing to devote their time in the long run to a project, and stay course for a long time. Not to mention that when the project leader doesn't appear to show any kind of interest about the project anymore, what kind of message do you think that will send to new developers trying to get involved? No wonder it is perceived as an abandoned camp, where effort is not worth investing anymore. And the way you put it makes it the perfect example of what I just said. When Oleg tried to outline some basic rules for code submissions, which were only meant to improve the project management, you were the first one to question the need to provide the documentation, suggesting that it can be provided later (incrementally), when everything indicates that such approach almost always fails. I have seen countless cases of people contributing substantial new features to a project without documenting their changes, and after their work was integrated they dissapeared not to be seen ever again. Good luck trying to get them to write the documentation later. Heck, they didn't even bother to fix bugs in their code after their patches got in the main source. So, can you explain how do you think that undermining the requirements that Oleg put in place would provide better organization for the project? -- Dan |
From: Ilias L. <il...@la...> - 2006-10-04 22:42:31
|
Dan Pascu wrote: > On Tuesday 03 October 2006 01:07, Ilias Lazaridis wrote: >> Dan Pascu wrote: >>> On Monday 02 October 2006 18:37, Ilias Lazaridis wrote: >>>>> -- documentation is a big plus. >>>> again, can be provided incrementally >>> Experience shows that this almost never happens. Once someone gets >>> his pet code integrated, they never care to document it. They know >>> how it works and don't need documentation, so they don't bother. >>> What is worse is that (in my experience) they don't even return to >>> maintain their code (in case it was something more than a bug fix) >>> and the original author is forced to fix and maintain their code >>> later. >>> >>> Currently the SQLObject documentation is scarce. There are so many >>> things you can only find out about if you read the source, and there >>> are things in the existing documentation that are no longer accurate >>> and can be misleading. And I haven't seen any incremental addition to >>> them, but while I read the code I discover new undocumented things >>> added regularly. >> I see. >> >> Al this you've mentioned gives me the impression of a badly organized >> project. > > I think you got it all wrong here. I'm not talking particularly about > sqlobject. I was expressing my experience with a dozen open source > projects I participated in as either an active developer or just a user. > It's the quality of the people that contribute to a project that gives the > result, not as much how resources are managed. You have to have what to > manage in the first place. An opensource project is not a company where > people are motivated by a salary and have deadlines they must respect and > a management in front of which they have to answer. It's _very_ difficult > to get quality developers that are willing to devote their time in the > long run to a project, and stay course for a long time. Not to mention > that when the project leader doesn't appear to show any kind of interest > about the project anymore, what kind of message do you think that will > send to new developers trying to get involved? No wonder it is perceived > as an abandoned camp, where effort is not worth investing anymore. ok. > And the way you put it makes it the perfect example of what I just said. > When Oleg tried to outline some basic rules for code submissions, which > were only meant to improve the project management, you were the first one > to question the need to provide the documentation, suggesting that it can > be provided later (incrementally), when everything indicates that such > approach almost always fails. I have seen countless cases of people > contributing substantial new features to a project without documenting > their changes, and after their work was integrated they dissapeared not > to be seen ever again. Good luck trying to get them to write the > documentation later. Heck, they didn't even bother to fix bugs in their > code after their patches got in the main source. > > So, can you explain how do you think that undermining the requirements > that Oleg put in place would provide better organization for the project? I just think that the requirements are not necessary within an active project. But I realize that SQLObject is not that active. . -- http://lazaridis.com |
From: Oleg B. <ph...@ph...> - 2006-10-02 18:12:12
|
On Mon, Oct 02, 2006 at 09:01:14PM +0300, Dan Pascu wrote: > On Monday 02 October 2006 11:16, Oleg Broytmann wrote: > > -- do not break compatibility, remember, SQLObject is still supports > > Python 2.2; > > Unfortunately this is more a desired thing than an actual fact. SQLObject [skip] > it will not work with anything older than 2.4 Well, I must admit I have stopped testing SQLObject with Python 2.2 because py.test had stopped working with 2.2. But I do regular testing with Python 2.3 - and SQLObject works. So I think there is a chance it works with 2.2. I know there is code in FormEncode that only works with 2.4, but I don't think it prevents SQLObject from working. I'll look into it again... Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Dan P. <da...@ag...> - 2006-10-02 18:30:38
|
On Monday 02 October 2006 21:12, Oleg Broytmann wrote: > On Mon, Oct 02, 2006 at 09:01:14PM +0300, Dan Pascu wrote: > > On Monday 02 October 2006 11:16, Oleg Broytmann wrote: > > > -- do not break compatibility, remember, SQLObject is still > > > supports Python 2.2; > > > > Unfortunately this is more a desired thing than an actual fact. > > SQLObject > > [skip] > > > it will not work with anything older than 2.4 > > Well, I must admit I have stopped testing SQLObject with Python 2.2 > because py.test had stopped working with 2.2. But I do regular testing > with Python 2.3 - and SQLObject works. So I think there is a chance it I use it with 2.3 and it works. but my formencode is modified. > works with 2.2. I know there is code in FormEncode that only works with > 2.4, but I don't think it prevents SQLObject from working. I'll look it does. unless that code is removed from formencode, sqlobject will not load. at least last time I checked was like this. Since then I use the formencode that is packaged by debian, and they have fixed it so I'm no longer up to date with the formencode changes. It doesn't matter that sqlobject doesn't actually use that code. it loads the file that contains it (after an import) and python2.3 cannot parse it at import time. -- Dan |
From: Oleg B. <ph...@ph...> - 2006-10-02 19:07:36
|
On Mon, Oct 02, 2006 at 09:30:33PM +0300, Dan Pascu wrote: > > works with 2.2. I know there is code in FormEncode that only works with > > 2.4, but I don't think it prevents SQLObject from working. > > it does. I just installed FormEncode from SVN: > python2.3 Python 2.3.5 (#1, Nov 19 2005, 17:43:50) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import formencode.formgen Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.3/site-packages/FormEncode-0.6.1dev_r1960-py2.3.egg/formencode/formgen.py", line 12 @dispatch.generic() ^ SyntaxError: invalid syntax >>> import sqlobject I ran a few tests from the SQLObject test suite - all tests passed. So I believe it works at least with Python 2.3. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Dan P. <da...@ag...> - 2006-10-02 20:04:57
|
On Monday 02 October 2006 22:07, Oleg Broytmann wrote: > I ran a few tests from the SQLObject test suite - all tests passed. > So I believe it works at least with Python 2.3. I can confirm it works with python2.3 as I use them together successfully. That import was the only issue I encountered and the issue is that formencode (which is a dependency of sqlobject) won't install under python2.3 without that code removed (else it won't be able to byte compile it). So maybe I expressed myself wrongly, the issue is not with sqlobject, but with formencode on which sqlobject depends. But as long as you can't install a dependency under an older version of python that will reflect on the sqlobject's ability to work properly. That was what I mean to say in the first place. My guess is that the formencode .egg you installed didn't try to bytecompile itself. If it did, it would have failed under python2.3 unless edited out. -- Dan |