[PyKDE] qsqlcursor lifetime for qdatatable

[Jim Bublitz]

On 26-Jun-02 Andreas Kloeckner wrote:
> On Tue, Jun 25, 2002 at 03:29:54PM -0700, Jim Bublitz wrote:
>> On 25-Jun-02 Andreas Kloeckner wrote:
>> > i propose that we redefine the semantics of qdatatable in such
>> > a way that the table always takes posession of its cursor and
>> > frees it itself. (possible by means of setCursor with the
>> > autoDelete parameter) i would be willing to provide a patch
>> > for this, if there is any demand.
 
>> Just a comment (feel free to ignore it): If I understand this
>> correctly, you're suggesting changing the behavior of Qt under
>> PyQt. IMHO, this isn't a good idea, first because users should
>> be able to expect that PyQt works exactly like Qt (to the
>> extent possible, good or bad) and second, because someone will
>> have to maintain the patch (if integrated into PyQt) from now
>> til doomsday. I'm not saying it isn't possible to improve Qt
>> or improve how Qt behaves under Python - I'm more suggesting
>> that you offer the 'patch' as a stand-alone enhancement or
>> add-on, perhaps as a set of subclasses or something similar,
>> but in a separate module.
 
>> As Python use increases, it becomes more likely that people will
>> distribute apps that are PyQt based, and they should be able to
>> expect a standard environment.
 
> yes, but usually people get scared away from a set of bindings
> where the most intuitive way of doing things causes a segfault.
> people program in script languages to escape segfault hell.
> either this deserves a *big* warning in the documentation, or
> (IMHO) it needs to be changed.

> of course you are right in saying that if we want to do
> *everything* just like qt does it in c++, leaving it is the way
> to go. in most cases, i think that's fine. this one gave me a
> 2-hour headache, and  i don't know how many people are willing
> to invest two hours into investigating the cause of failure for
> code that looks perfectly fine.
 
> either way, it needs to be documented in big letters.

Again *personally* (since I don't have much to do with PyQt except
as a user), I think the idea of documenting this is a great idea.
I'm not familiar with the Qt SQL stuff at all, but I've noted from
the list that Hans-Peter Jansen has done a lot of work on
developing example code in this area for PyQt, so that might be a
good place to include docs and examples. Another possibility would
be for someone familiar with the problem to write a few paragraphs
that Phil could include in the PyQt docs.

I'm not that familiar with the subject, but it sounds like
subclassing the affected classes (either in C++ or Python) might
also be a good solution - I've done that just for personal use in
cases where I disagreed with the author and the author wouldn't fix
it, and of course I was right in those cases :) Even though I
had the source and could modify it any way I wanted, subclassing
seemed preferable - it's much cleaner and more resistant to the
inevitable changes that occur in subsequent releases (and of course
I didn't have to modify every new release - just make sure the
subclass was still valid).
  
> how about a wrapper around sip that only writes a new file if the
> output actually differs from the old file - thereby preserving
> the old timestamp in case nothing is changed? (would be willing
> to write that, would be easy as a shell script - which would
> have win32 portability issues)

I'm not sure how you would accomplish this with scripting unless
you're still maintaining two separate PyQt hierarchies. sip simply
dumps all of the C++ files at once - you'd need to rewrite sip to
get inside that process (I'm also just a sip user, not the author).

You could certainly write a script to diff the compile version C++
files against the modified files that were newly generated, and only
copy when a change is detected. You could also write a script that
takes as an argument the name(s) of the modified classes and copies
only those files, along with the 'boilerplate' files like
qtcmodule.cpp if necessary. Actually a script that diffs the files
is more likely to work and would certainly run pretty quickly.

You could get around some of the portablility issues by writing the
script in Python instead of shell. 

PyKDE already includes scripting to rebuild a single module as part
of it's 'build' script (which is quite different from the new
'build.py' for PyQt). I expect future PyKDE releases will include
that ability since I use it *a lot* for debugging, but I also
expect it will be a separate stand-alone script - it's looks
difficult to incorporate in the newer-style build.py script. I'd
also recommend that once you finish debugging, you do a complete
build from scratch as a final 'test'. That sometimes turns up
problems that would otherwise be missed.


Jim