Seems reasonable to me. Even without python 3.6 in the official repositories for Debian and trusty Ubuntu, it isn't very difficult to install 3.6 with tools like anaconda and pyenv. From my perspective, dropping 3.5 would introduce short term inconvenience for those systems, and simplify our long term maintenance.
On Fri, Sep 7, 2018, 8:51 AM Brian Bouterse <bbout...@redhat.com> wrote: > I'm also +1 on this for the various reasons. Even with the portability > downsides. Also, practically speaking, the batch code is legit, and it will > benfit the stages code a lot. > > On Fri, Sep 7, 2018 at 8:17 AM, Daniel Alley <dal...@redhat.com> wrote: > >> Personally, +1. I ran into this issue myself and it was infuriating to >> deal with. >> >> dict objects preserve insertion-order (officially declared part of >>> the language with Python 3.7). Eliminates a source of subtle >>> "works on 3.6, sometimes works on 3.5" bugs. >>> >> >> Just to expand on this though: >> >> For Ubuntu, it is part of 18.04 LTS. Debian does not have Python 3.6 in >>> stable yet. >>> >> >> It does mean that we won't be able to support Ubuntu 16.04 (or previous) >> or Debian at all until the next release (~May 2019), unless they install a >> newer Python themselves. >> >> On Fri, Sep 7, 2018 at 2:09 AM, Simon Baatz <gmbno...@gmail.com> wrote: >> >>> I had a discussion on IRC with Brian yesterday which led to the >>> question whether we can drop support for Python 3.5. I think there are >>> good reasons for this, see the rationale below. >>> >>> Brian proposed to initiate a vote on this topic (and find out whether >>> this "community thing" works :-) ). >>> >>> Please send feedback by Friday Sept 14th. Especially, let me know if >>> there are specific reasons for depending on Python 3.5. The >>> corresponding issue is 3984 [7]. >>> >>> Cheers, >>> Simon >>> >>> >>> Rationale: >>> >>> The trigger for the discussion was to get rid of boilerplate code like >>> this [0], [1] to handle batches in the stages API. This becomes a >>> single line [2] when using an asynchronous generator [3]. Adding the >>> `batches()` async generator to Pulp core would simplify existing >>> stages and ease implementation of stages in plugins. >>> >>> Async generators have been introduced in Python 3.6. Thus, to make the >>> `batches` generator available in the Pulp core plugin API, we either >>> >>> - have to drop support for Python 3.5 or >>> >>> - reimplement the async generator as an async iterator (which would be >>> more convoluted but looks doable) >>> >>> >>> I prefer to drop 3.5, since this will allow to use additional language >>> features[4]. Among them: >>> >>> - As said, async generators/async comprehensions. Async generators are >>> simpler to write and understand than async iterators. >>> >>> - String interpolation "f-Strings" [5] >>> >>> - dict objects preserve insertion-order (officially declared part of >>> the language with Python 3.7). Eliminates a source of subtle >>> "works on 3.6, sometimes works on 3.5" bugs. >>> >>> - One version less to support is always a good thing (provided nobody >>> really requires it) >>> >>> - Type annotations are currently not used by the Pulp project, but if >>> the project decides to use them in the future: IMHO type annotations >>> (which are great btw.) began to feel “right†with 3.6. Working with >>> them in 3.5 can be clumsy at times. >>> >>> - And of course: [6] >>> >>> >>> Python 3.6 has the OS/distribution support we need: >>> >>> - Python 3.6 SCL is available for RHEL 7 / CentOS 7 >>> - It is part of Fedora as of Fedora 26 >>> >>> For Ubuntu, it is part of 18.04 LTS. Debian does not have Python 3.6 in >>> stable yet. >>> >>> >>> >>> [0] >>> https://github.com/pulp/pulp/blob/631031e38270c5c7c2b2289ff4ab87a058447c5e/plugin/pulpcore/plugin/stages/content_unit_stages.py#L47-L59 >>> [1] >>> https://github.com/pulp/pulp/blob/631031e38270c5c7c2b2289ff4ab87a058447c5e/plugin/pulpcore/plugin/stages/artifact_stages.py#L48-L60 >>> [2] >>> https://github.com/gmbnomis/pulp_cookbook/blob/ca4882cecab16995c5713d27131da8112a5f5a0c/pulp_cookbook/app/tasks/synchronizing.py#L98 >>> [3] >>> https://github.com/gmbnomis/pulp_cookbook/blob/d44ed593925b78c046e1b568810b15acbdad5ac4/pulp_cookbook/app/tasks/synchronizing.py#L26 >>> [4] https://docs.python.org/3/whatsnew/3.6.html >>> [5] >>> https://docs.python.org/3/whatsnew/3.6.html#pep-498-formatted-string-literals >>> [6] https://twitter.com/raymondh/status/844955415259463681 >>> [7] https://pulp.plan.io/issues/3984 >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
