Dear Andi, many thanks for your review of the patch and helpful comments.
As mentioned in my previous mail to the list I’m afraid to let you know that we currently cannot put more effort into this task. This may change in the future of course. However, with „funding“ my idea was to look for open source funding such as provided by the Python Software Foundation (e.g.): https://www.python.org/psf/grants That’s probably worth a try - especially because the PSF is well known, has some sponsors and also receives donations by companies using Python and Python related projects on regular basis… > Thank you for the work done so far, it's looking really good but it needs to > be refreshed to JCC/trunk and latest Python 3 to minimize work on my side. Ok. Maybe ASF could contact PSF and ask for such a grant that could be uses to > hire back the contractor who did the JCC Python 3 port originally and have > him/her refresh it for the latest JCC on trunk ? (If he/she is willing to do so … that’s another question). Just thinking about ways to get this forward. I’m afraid I cannot provide more support currently ,-( best regards, Thomas — > Am 06.01.2017 um 22:01 schrieb Andi Vajda <va...@apache.org>: > > > I now took a look at the python 3 patches you sent a link to in an earlier > message and here is the gist of my thoughts: > - Moving the Python 3 is desirable but what about Python 2 support today > in 2017 ? I have no desire to support both for PyLucene manually. If, > somehow, there can be two versions of JCC, one for Python 2, one for > Python 3 and the PyLucene tests can be 2to3'd automatically, then the > Python 3 support idea looks more attractive already. Supporting two > versions of JCC is fine until 2020. > > - The JCC patches look very reasonable but should be updated to the latest > Python 3. In particular, the internal Python 3 string representation was > changed again after 3.2 (?) and has clever optimizations possible based > on the internal byte size of characters chosen by Python (internally) > for each string, based on the range of the characters used in the string. > This makes it possible to often just copy chars from Python to Java. > I just did a rewrite for this in PyICU (another long > term project of mine, https://github.com/ovalhub/pyicu/ > <https://github.com/ovalhub/pyicu/>) and the Python 3 > string story got much cleaner post 3.2 (at least more > understandable). Lots of bugs with long unicode chars (forgot the proper > term, sorry) got fixed along the way (emoticon support, yay). > > So, if you're prepared to fund this effort, it might be best to hire > back the contractor who did the JCC Python 3 port originally and have > him/her refresh it for the latest JCC on trunk (not too many changes > happened in the past few years) and to the use the Python internal string > APIs that appeared post Python 3.2. The ones in use in the patch are > deprecated already. I love it that we'd then shed _all_ backwards > compatibility baggage in JCC going forward in Python 3.x, x >= 6. > > If you get the JCC/Python3 patches into a shape where I can apply them to > trunk without trouble and using the latest CPython string APIs: > https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_AsUCS4 > <https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_AsUCS4> > and related (PyUnicode_KIND, etc...) > then there is a good chance that PyLucene/JCC would be fully supported > with Python 3.x, x >= 6. > > - The PyLucene patches should probably be redone so that they can be > automated with 2to3. If we get JCC in shape, I can take care of the rest. > > Thank you for the work done so far, it's looking really good but it needs to > be refreshed to JCC/trunk and latest Python 3 to minimize work on my side. > > Andi..
