[PyKDE] qsqlcursor lifetime for qdatatable

[Andreas Kloeckner]

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.

>  
> > i have one more question: how can you avoid the lengthy (~1.5
> > h) complete recompile if you just make *one* change to *one*
> > .sip file? "make" doesn't do the trick for me, it just does
> > nothing.
> 
> You can try maintaining two separate PyQt hierarchies. The first is
> where you compile PyQt, the second where you make modifications and
> only run 'build.py' to generate C++ files, then copy only the
> modified C++ files to the compile hierarchy. sip generates one file
> pair per class, with filenames of the form:
> 
> <module name>/sip<module name><class name>.[cpp | h]
> 
> for example:
> 
> qt/sipqtQClass1.cpp, qt/sipqtQClass1.h
> 
> Depending on the modifications, you may also need to copy the new
> qtcmodule.cpp, sipqtProxyqt.h, and sipqtDeclqt.h to the compile
> directory (those are the filenames for the qt module - other
> modules have similar files). For any module *other than* the qt
> module, I'd just copy the entire modified subdirectory, since other
> modules take very little time to compile compared to the qt module.
> Running 'make' in the compile directory then will only re-compile
> the new files and then link to the pre-existing object files.
> 
> If you add/delete classes, you have to edit the makefiles too
> (unless you copy the entire module subdirectory), but
> adding/deleting/modifying methods should work. Keep the /sip
> directories in sync (or symlink them) in case you eventually do a
> complete rebuild.

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)

andreas