One more task for this subject, the python 3 implementation does not yet have support for Avro logical types as far as I’ve been able to tell. So a decent amount of code would need to be ported there.
—Ivan > On Nov 22, 2019, at 7:40 AM, Ryan Skraba <[email protected]> wrote: > > Thanks for the info; it sounds reasonable to me! (A big +1 to getting > rid of ant, of course). > > On Thu, Nov 21, 2019 at 12:56 PM Michael A. Smith <[email protected]> > wrote: >> >> i would like to update and maintain the py colleges and deprecate and >> eventually remove the py3 one. >> >> 1. Despite being less modern, the py codebase has been kept somewhat more >> pythonic. Capitalizing `schema.Parse` and the literal translation of the >> java parsing normal form implementation are two oddities we could address. >> There are several issues and pull requests inquiring why the two python >> implementations aren't API compatible. >> 2. Several modules in py3 were never completed. I called out txipc as >> broken, but the tether stuff is missing entirely. >> >> Things we need to do to make this possible: >> >> 1. Make the py codebase compatible with py3.5. I've been working on this, >> while still trying to maintain 2.7 compatibility for now. >> 2. I want to port py3's setup approach, making it possible to package and >> test py without ant. There are lots of benefits, but the only thing on >> topic here is to be able to be able to use multiple python versions at the >> same time. (We should look at tox soon.) >> >> What do you think? >> >> On Thu, Nov 21, 2019 at 04:23 Ryan Skraba <[email protected]> wrote: >> >>> Tick-tock... just bumping this up as the year end approaches! Any >>> interest in making a statement or plan for python2 support for future >>> releases of Avro? >>> >>> There should be one more maintenance release of python 2.7 in 2020 >>> (after sunset) for the accumulated fixes. >>> >>> I'm in the context of looking at the docker+build scripts: keeping or >>> dropping the python2 runtime has little significant impact. >>> >>> Ryan >>> >>> >>> >>> On Tue, Jun 25, 2019 at 1:22 PM Michael A. Smith <[email protected]> >>> wrote: >>>> >>>> Inline… >>>> >>>> On Tue, Jun 25, 2019 at 05:03 Ismaël Mejía <[email protected]> wrote: >>>> >>>>> Probably is a good idea that we publish our policy around python >>>>> support [1] as other projects have done [2]. >>>>> I think supporting python 2 makes sense at least for our latest >>>>> release of this year so probably 1.9.x or eventually 1.10.x. >>>> >>>> >>>> i agree wholeheartedly, but only python 2.7. >>>> >>>> I am not at all familiar with our python3 codebase, are we feature >>>>> equivalent? otherwise maybe worth to create JIRAs and work on those. >>>> >>>> >>>> Not perfectly, and there is work on that, but the biggest gap is that >>>> lang/py is much more extensively tested, but its tests use pyant, which I >>>> have not yet figured out how to port. >>>> >>>> [1] https://pythonclock.org/ >>>>> [2] https://python3statement.org/ >>>>> >>>>> On Tue, Jun 25, 2019 at 9:38 AM Driesprong, Fokko <[email protected] >>>> >>>>> wrote: >>>>>> >>>>>> I'm not sure how much effort we should put into Python2.7 in general, >>>>> since >>>>>> this version is EOL after this year. >>>>>> >>>>>> Cheers, Fokko >>>>>> >>>>>> Op ma 24 jun. 2019 om 03:20 schreef Michael A. Smith < >>>>> [email protected]>: >>>>>> >>>>>>> There's some not-insignificant complexity in the lang/py codebase >>> to >>>>>>> support derelict versions of Python. There are polyfills for json, >>>>> structs, >>>>>>> a whole "StoppableHTTPServer" in avro.tool. >>>>>>> >>>>>>> I created AVRO-2445 and will start removing this stuff now, but >>> wanted >>>>> to >>>>>>> bounce the idea around the list in case there's some obscure >>> reason to >>>>> keep >>>>>>> these things around. >>>>>>> >>>>> >>>
