Re: New Python bindings (was: Crash with Python bindings)

2018-04-04 Thread Brian May
David Bremner writes: > That's not an itch I personally have, but as I said in the next > paragraph, if someone want's to take on the project of maintaining a > wheel, we'll render the same kind of assistance we give *BSD/Linux/MacOS > package maintainers. We're happy to look

Re: New Python bindings (was: Crash with Python bindings)

2018-03-28 Thread David Bremner
Brian May writes: > David Bremner writes: > >> We tried this before, and it didn't work out very well. Bindings tend to >> depend on a strict matching of versions with the underlying library, so >> distributing them seperately doesn't really make

Re: New Python bindings (was: Crash with Python bindings)

2018-03-28 Thread Brian May
David Bremner writes: > We tried this before, and it didn't work out very well. Bindings tend to > depend on a strict matching of versions with the underlying library, so > distributing them seperately doesn't really make sense to me. You need > the underlying libraries, so

Re: New Python bindings (was: Crash with Python bindings)

2018-03-28 Thread Floris Bruynooghe
On Wed, Mar 28 2018, David Bremner wrote: > Brian May writes: > >> I can into this thread late. However, my priorities for python bindings >> would be: > > [...] >> * Packages should be available from pypi.python.org >> > > We tried this before, and it didn't work out

Re: New Python bindings (was: Crash with Python bindings)

2018-03-28 Thread Floris Bruynooghe
On Wed, Mar 28 2018, Brian May wrote: > Justus Winter writes: > >>> This is exactly what I have fixed in my alternative bindings which I >>> created around the end of last year [0]. So we do have an idea of how >>> to fix this, at the time I said I do believe that it's

Re: New Python bindings (was: Crash with Python bindings)

2018-03-28 Thread David Bremner
Brian May writes: > I can into this thread late. However, my priorities for python bindings > would be: [...] > * Packages should be available from pypi.python.org > We tried this before, and it didn't work out very well. Bindings tend to depend on a strict matching of

Re: New Python bindings (was: Crash with Python bindings)

2018-03-28 Thread Brian May
Justus Winter writes: >> This is exactly what I have fixed in my alternative bindings which I >> created around the end of last year [0]. So we do have an idea of how >> to fix this, at the time I said I do believe that it's possible to also >> do this for the existing

Re: New Python bindings (was: Crash with Python bindings)

2018-03-26 Thread Floris Bruynooghe
On Wed, Mar 21 2018, Justus Winter wrote: > > Floris Bruynooghe writes: > >> This is exactly what I have fixed in my alternative bindings which I >> created around the end of last year [0]. So we do have an idea of how >> to fix this, at the time I said I do believe that it's

New Python bindings (was: Crash with Python bindings)

2018-03-21 Thread Justus Winter
Hi Floris :) Floris Bruynooghe writes: > This is exactly what I have fixed in my alternative bindings which I > created around the end of last year [0]. So we do have an idea of how > to fix this, at the time I said I do believe that it's possible to also > do this for the

Re: Crash with Python bindings

2018-03-18 Thread Floris Bruynooghe
Daniel Kahn Gillmor writes: > On Fri 2018-03-16 19:30:37 +0100, Floris Bruynooghe wrote: >> If someone can hook pytest runs with various python versions into the >> notmuch test suit I'd be very much obliged and probably have another go >> at this as it's still an

Re: Crash with Python bindings

2018-03-16 Thread Daniel Kahn Gillmor
On Fri 2018-03-16 19:30:37 +0100, Floris Bruynooghe wrote: > If someone can hook pytest runs with various python versions into the > notmuch test suit I'd be very much obliged and probably have another go > at this as it's still an interesting problem and gives a nice way > forward. I don't

Re: Crash with Python bindings

2018-03-16 Thread Floris Bruynooghe
Hi all, David Bremner writes: > "W. Trevor King" writes: > >> you can avoid the abort (which happens when q.__del__ is called after >> db.__del__). We could make that sort of cleanup easier with context >> managers for Query objects (we have them for

Re: Crash with Python bindings

2018-03-16 Thread Justus Winter
David Bremner writes: > "W. Trevor King" writes: > >> you can avoid the abort (which happens when q.__del__ is called after >> db.__del__). We could make that sort of cleanup easier with context >> managers for Query objects (we have them for databases

Re: Crash with Python bindings

2018-03-16 Thread David Bremner
"W. Trevor King" writes: > you can avoid the abort (which happens when q.__del__ is called after > db.__del__). We could make that sort of cleanup easier with context > managers for Query objects (we have them for databases since [3]), and > they look like the only object that

Crash with Python bindings

2016-01-12 Thread Konrad Hinsen
Hi everyone, I have been writing quite a few Python scripts for notmuch before running into a strange bug. Here is a minimal script producing it: -- from notmuch import Query, Database def foo(bar): pass db = Database() q = Query(db, "*")

Re: Crash with Python bindings

2016-01-12 Thread Konrad Hinsen
Hi Justus, > So I guess what happens is that Python3 changed how the interpreter > environment is torn down and they actually destroy the 'q' object. If > that is so, then your data is indeed safe. That reminds me of a recent change in object finalization in Python 3:

Re: Crash with Python bindings

2016-01-12 Thread Konrad Hinsen
David Bremner writes: >> from notmuch import Query, Database >> >> def foo(bar): >> pass >> >> db = Database() >> q = Query(db, "*") >> db.close() > > Do you really call the constructor without a path? Or are you censoring > the script for some reason? No path means

Re: Crash with Python bindings

2016-01-12 Thread David Bremner
David Bremner writes: >> No path means path=None, which stands for the path from >> ~/.notmuch-config. That's exactly what I want. Is there some reason not >> to rely on this mechanism? > > Oh sorry, I'm (obviously) not that familiar with the python bindings. Nothing to do

Re: Crash with Python bindings

2016-01-12 Thread W. Trevor King
On Tue, Jan 12, 2016 at 03:23:46PM +0100, Konrad Hinsen wrote: > Hi Justus, > > > So I guess what happens is that Python3 changed how the > > interpreter environment is torn down and they actually destroy the > > 'q' object. If that is so, then your data is indeed safe. > > That reminds me of a

Re: Crash with Python bindings

2016-01-12 Thread David Bremner
Konrad Hinsen writes: > Hi everyone, > > I have been writing quite a few Python scripts for notmuch before > running into a strange bug. Here is a minimal script producing it: > > -- > from notmuch import Query,

Re: Crash with Python bindings

2016-01-12 Thread David Bremner
Konrad Hinsen writes: > David Bremner writes: > >>> from notmuch import Query, Database >>> >>> def foo(bar): >>> pass >>> >>> db = Database() >>> q = Query(db, "*") >>> db.close() >> >> Do you really call the constructor without a path? Or

Re: Crash with Python bindings

2016-01-12 Thread W. Trevor King
On Tue, Jan 12, 2016 at 10:41:57AM +0100, Konrad Hinsen wrote: > -- > from notmuch import Query, Database > > def foo(bar): > pass > > db = Database() > q = Query(db, "*") > db.close() > -- > >

Binding access to ~/.notmuch-config (was: Crash with Python bindings)

2016-01-12 Thread W. Trevor King
On Tue, Jan 12, 2016 at 03:03:15PM -0400, David Bremner wrote: > Nothing to do with Konrad's crash, but I consider the fact that the > python bindings read ~/.notmuch-config to be a kind of layering > violation, since that file belongs to the CLI, while the bindings > are supposed to provide