WIP: python 3 compatibility
This the current state of my work on making this python3 compatible.
The approach I took was a mix of running the test and using type annotations and mypy, then add some
.decode()here and there until error disappear ... it still needs a lot of cleanups. It's still messy and too early for review. Anyway, I'll try to extract the "simple" fixes to merge first what's can already be merged.
tests using a pre-created database have not been updated yet and they fail with
FileStorageFormatErroras the test databases was created with python2. Except this, the rest seems working.
tox has been extended, also to run tests with https://github.com/zopefoundation/ZODB/pull/183
@jerome, thanks. I cherry-picked some first patches, but had not had time to dig into the reset. I suggest, when you have time, to split type annotations from
bytes vs stras type annotations require more thought maybe and byts vs str should be easy to get, at least in most of the part.
Thanks again for the fixups & rawext tox coverage. Looking forward for further updates (when you'll have the time).
( I hope it is ok that I did small amendments to the patches )
@kirr thank you ! of course it was OK to amend the patches. Thanks for moving this forward.
I agree that we'll leave the type annotations and the mypy stuff out before merging. I was more interested in trying type annotations in a "real case". I hit quickly a problem that type annotations for standard library are not really complete yet ( with
codecs.encodeand hex encoding - https://github.com/python/typeshed/issues/300 ) and that annotating types is "not so easy" to do in a "good way", for example the :
obj = None # type: Optional[Union[ObjectDelete, ObjectCopy, ObjectData]]
is ugly ( it should be possible to define a parent type for
Object*though, I did not try). Also for the different "hashers", I did not find a way to define an "interface" with type annotations for
hexdigestmethods only in one central place and have a way to check that the classes respect the interface - but again I have not tried much.
( edited to fix grammar mistakes)
@jerome, thanks for feedback and for typing links. Yes, py typing will require more thought. What is easily possible with interfaces in Go, or e.g. with interfaces with zope.interfaces, seems to be not so straightforward with current state of py typing.
I had not studied current py typing landscape yet and for now I suggest we do not delve too much into annotating everything - e.g. if we can properly annotate a parameter to be bytes - that's ok. If we cannot deal with interfaces - we just leave a human readable comment.
Guido is known to delay typing (and other bits) in Python for ages. Most of them started to appear in workable state in around 2000 but it was more than 10 years since only some of them got accepted at least somehow and even today it does not all properly work. Frankly I do not trust today's Python leadership. I will thus consider all possibilities, including moving e.g. to Cython/Pyrex.