Oh, and one more thing, I think it'd make sense for Apache Beam to sign https://python3statement.org/. The promise is that we'd discontinue Python 2 support *in* 2020, which is not committing us to January if we're not ready. Worth a vote?
On Thu, Sep 19, 2019 at 3:58 PM Robert Bradshaw <rober...@google.com> wrote: > > Exactly how long we support Python 2 depends on our users. Other than > those that speak up (such as yourself, thanks!), it's hard to get a > handle on how many need Python 2 and for how long. (Should we send out > a survey? Maybe after some experience with 2.16?) > > On the one hand, the whole ecosystem is finally moving on, and even if > Beam continues to support Python 2 our dependencies, or other projects > that are being used in conjunction with Beam, will also be going > Python 3 only. On the other hand, Beam is, admittedly, quite late to > the party and could be the one holding people back, and looking at how > long it took us, if we just barely make it by the end of the year it's > unreasonable to say at that point "oh, and we're dropping 2.7 at the > same time." > > The good news is that 2.16 is shaping up to be a release I would > recommend everyone migrate to Python 3 on. The remaining issues are > things like some issues with main sessions (which already has issues > in Python 2) and not supporting keyword-only arguments (a new feature, > not a regression). I would guess that even 2.15 is already good enough > for most people, at least to kick the tires and running tests to start > the effort. > > (I also agree with the sentiment that once we go 3.x only, it'll be > likely harder to maintain a 2.x LTS... but the whole LTS thing is > being discussed in another thread.) > > On Thu, Sep 19, 2019 at 2:44 PM Chad Dombrova <chad...@gmail.com> wrote: > > > > Hi all, > > I had a read through this thread in the archives. It occurred before I > > joined the mailing list, so I hope that this email connects up with the > > thread properly for everyone. > > > > I'd like to respond to the following points: > > > >> I believe we are referring to two separate things with support: > >> - Supporting existing releases for patches - I agree that we need to give > >> users a long enough window to upgrade. Great if it happens with an LTS > >> release. Even if it does not, I think it will be fair to offer patches on > >> the last python 2 supporting release during some part of 2020 if that > >> becomes necessary. > >> - Making new releases with python 2 support - Each new Beam release with > >> python 2 support will implicitly extend the lifetime of beam's python 2 > >> support. I do not think we need to extend this to beyond 2019. 2 releases > >> (~ 3 months) after solid python 3 support will very likely put the last > >> python 2 supporting release to last quarter of 2019 already. > > > > > > With so many important features still under active development > > (portability, expansion, external IO transforms, schema coders) and new > > versions of executors tied to the Beam source, staying behind is not really > > an option for many of us, and with python3 support not yet fully completed, > > the window in which Beam is fully working for both python versions is > > rapidly approaching 2 months, and could ultimately be even less, depending > > on how long it takes to complete the dozen remaining issues in Jira, and > > whatever pops up thereafter. > > > >> The cost of maintaining Python 2.7 support is higher than 0. Some issues > >> that come to mind: > >> - Maintaining Py2.7 / Py 3+ compatibility of Beam codebase makes it > >> difficult to use Python 3 syntax in Beam which may be necessary to support > >> and test syntactic constructs introduced in Python 3. > >> - Running additional test suites increases the load on test infrastructure > >> and increases flakiness. > > > > > > I would argue that the cost of maintaining a python2-only LTS version will > > be far greater than maintaining python2 support for a little while longer. > > Dropping support for python2 could mean a number of things from simply > > disabling the python2 tests, to removing 2-to-3 idioms in favor of > > python3-only constructs. If what you have in mind is anything like the > > latter then the master branch will become quite divergent from the LTS > > release, and backporting changes will be not be as simple as cherry-picking > > commits. All-in-all, I think it's a lose/lose for everyone -- users and > > developers, of which I am both -- to drop python2 support on such a short > > timeline. > > > > I'm an active contributor to this project and it will put me and the > > company that I work for in a very bad position if you force us onto an LTS > > release in early 2020. I understand the appeal of moving to python3-only > > code and I want to get there too, but I would hope that you give your users > > are much time to transition their own code as the Beam project itself has > > taken. I'm not asking for a full 12 months to transition, but more than a > > couple will be required. > > > > thanks, > > -chad > > > > > > > >
