Patrick Totzke <patricktot...@gmail.com> writes:
> Quoting David Bremner (2017-11-28 23:59:26)
>> Floris Bruynooghe <f...@devork.be> writes:
>>
>> >
>> > Lastly there are some downsides to the choices I made:
>> > - I ended up going squarely for CPython 3.6+. Choosing Python
>> > 3 allowed better API design, e.g. with keyword-only parameters
>> > etc. Choosing CPython 3.4+ restricts the madness that can
>> > happen with __del__ and gives some newer (tho now unused)
>> > features in weakref.finalizer.
>> > - This is no longer drop-in compatible.
>> > - I haven't got to a stage where my initial goal of speed has
>> > been proven yet.
>>
>> I guess you'll have to convince the maintainers / users of alot and afew
>> that this makes sense before we go much further. I'd point out that
>> Debian stable is only at python 3.5, so that makes me a bit wary of this
>> (being able to run the test suite on debian stable and similar aged
>> distros useful for me, and I suspect other developers).
>>
>> I know there are issues with memory management in the current bindings,
>> so that may be a strong reason to push to python 3.6; it seems to need
>> more investigation at the moment.
>>
>> d
>
>
> I am generally in favour of modernizing the notmuch python bindings,
> especially when it comes to memory management and exception handling.
>
> At the moment, the alot interface officially only supports python v2.7
> but our dependencies have now mostly been updated and we are working on
> port to python 3, see here: https://github.com/pazz/alot/pull/1055
>
> @Floris, you are welcome to join #alot on freenode if you want to
> discuss details on that.
>
> You mention that your new API breaks compatibility with the existing
> ones. Do you have some demo code that uses the new API for reference?
Short, untested, example which works with what's posted:
db = notdb.Database.create()
# or
db = notdb.Database(path=None, mode=notdb.Database.MODE.READ_WRITE)
print(db.path) -> pathlib.Path (a py34 dependency)
if 'unread' in db.tags: # tags behaves like a set
print('unread mail!')
with db.atomic():
msg = db.add('/path/to/file')
mdg = db.get('/path/to/file')
msg = db.find('some-msgid')
db.remove('path/to/other/file')
# sorry, don't have a query interface yet
assert 'unread' in msg.tags
for tag in msg.tags:
print(f'a tag: {tag}')
with msg.frozen(): # Message.frozen() not yet implemented
msg.tags.clear() # all set operations supported
msg.tags.add('atag')
msg.tags_to_flags()
I imagine the query interface would be something like:
with db.query('tag:atag') as query:
print(f'results: {query.count}')
for msg in query:
print(msg.path)
But to be honest I've been spending most time on getting the
memory-safety figured (which I hope I finally did) so far and I think
the tag handling is so far the nicest thing to show off. They're
completely normal Python sets with no special behaviour at all (well,
that's not true - there's the binary interface, see the code posted for
this).
Actually, this last point is kind of important and I failed to mention
it before too. The existing Python bindings convert many bytes from
libnotmuch to Python strings, that is unicode on Python 3. For many it
uses b'bytes'.decode('utf-8', errors='ignore') which is a sane default
if you want to display things. But if you need to round-trip a tag and
store it again you might be changing the tag. I've not found the right
way to handle binary data (e.g. also needed for messageid) everywhere
yet but for tags I've gone with:
for tag in iter(msg.tags): # iter() normally called implicitly by for loop
print(f'All unicode this: {tag}')
for tag in msg.tags.iter(encoding=None):
other_msg.tags.add(tag) # This passes pure bytes around, loses nothing
# What I've used for message ID for now is a "BinString" type
print(f'All just unicode: {msg.messageid}')
binary_msgid = bytes(msg.messageid) # No lossy conversion
This BinString stuff is somewhat hacky, not sure how sane that is. The
second iterator on tags feels somewhat cleaner. Likewise tags could be
BinString as well instead of plain str.
Cheers,
Floris
_______________________________________________
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
