Обсуждение: 2.4.2 code ready
Hi Federico, I've fixed the two outstanding bug, so the code should be fine for the release. About the problem of the ghost mx.DateTime, I've reverted building its support if the includes are found at compile time, but now import doesn't fail if the module is not found at runtime. I would wait for Jason+Stephen to clean up the windows part of the setup, then I think we can release. -- Daniele
On 04/06/11 17:50, Daniele Varrazzo wrote: > About the problem of the ghost mx.DateTime, I've reverted building its > support if the includes are found at compile time, but now import > doesn't fail if the module is not found at runtime. > > I would wait for Jason+Stephen to clean up the windows part of the > setup, then I think we can release. Hi, yesterday I had a good look at all the code and every single change seems fine to me. I merged everything but there is a little quirk: I see that you're using lower case for SQL keywords like the transaction levels while the PostgreSQL preferred lettering is uppercase (just have a look at the manuals). I think it would be better to just be coherent with PostgreSQL documentation. Also waiting on Jason+Stephen for any windows fix before the release. federico -- Federico Di Gregorio federico.digregorio@dndg.it Studio Associato Di Nunzio e Di Gregorio http://dndg.it Best friends are often failed lovers. -- Me
On Wed, Jun 8, 2011 at 8:52 AM, Federico Di Gregorio <federico.digregorio@dndg.it> wrote: > yesterday I had a good look at all the code and every single change > seems fine to me. I merged everything but there is a little quirk: I see > that you're using lower case for SQL keywords like the transaction > levels while the PostgreSQL preferred lettering is uppercase (just have > a look at the manuals). I think it would be better to just be coherent > with PostgreSQL documentation. Do you mean in the python interface or internally? Or in the docs? FWIW for isolevel values I've take the lettering from the effectively stored values of the GUC, e.g. SHOW default_isolation_level gives "serializable" even if you set it uppercode (however they are parsed non case sensitive, just to be sure). The values accepted by the python set_transaction() are not case sensitive, and I've preferred documenting them lowercase because it's easier to type and doesn't feel "alien" in python code. But more likely I've not understood what you are referring to :) > Also waiting on Jason+Stephen for any windows fix before the release. Finished a few minutes ago to verify their changes, both on linux and on mingw. The seup cleanup branch is merged in my devel now. -- Daniele
On 08/06/11 10:30, Daniele Varrazzo wrote: > On Wed, Jun 8, 2011 at 8:52 AM, Federico Di Gregorio > <federico.digregorio@dndg.it> wrote: > >> > yesterday I had a good look at all the code and every single change >> > seems fine to me. I merged everything but there is a little quirk: I see >> > that you're using lower case for SQL keywords like the transaction >> > levels while the PostgreSQL preferred lettering is uppercase (just have >> > a look at the manuals). I think it would be better to just be coherent >> > with PostgreSQL documentation. > Do you mean in the python interface or internally? Or in the docs? > > FWIW for isolevel values I've take the lettering from the effectively > stored values of the GUC, e.g. SHOW default_isolation_level gives > "serializable" even if you set it uppercode (however they are parsed > non case sensitive, just to be sure). The values accepted by the > python set_transaction() are not case sensitive, and I've preferred > documenting them lowercase because it's easier to type and doesn't > feel "alien" in python code. > > But more likely I've not understood what you are referring to :) I was referring to the docs and to the Python function parameters. I know that lowercase is more pythonic but using the same casing as PostgreSQL docs is a big plus, imho. federico -- Federico Di Gregorio federico.digregorio@dndg.it Studio Associato Di Nunzio e Di Gregorio http://dndg.it We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. -- D.E.Knuth