Re: [Discuss] MXNet Python 3.6 Support Deprecation
Numpy team decided to wait another 4 weeks before dropping Python 3.5. So they'll drop it in the 1.19 release. Reference: https://mail.python.org/pipermail/numpy-discussion/2019-October/080191.html On Wed, 2019-11-06 at 14:36 -0800, Pedro Larroy wrote: > In Numpy they are considering dropping 3.5 support for 1.18 or 1.19. > > P. > > On Tue, Nov 5, 2019 at 11:15 PM Xingjian SHI wrote: > > > I don’t think we should drop Python 3.5 now because Ubuntu 16.04 ships > > with that version. I suggest that we should revisit it next year. > > > > Best, > > Xingjian > > > > From: Sheng Zha > > Sent: Tuesday, August 27, 2019 10:49 AM > > To: d...@mxnet.apache.org > > Subject: Re: [Discuss] MXNet Python 3.6 Support Deprecation > > > > Good summary. At the start the discussion thread my ask is to announce the > > intention of py2 deprecation in the next release, and then actually > > deprecate py2 in the next major release. Thus, the appropriate timing for > > dropping py2 support in CI should be the start of the next major release. > > The py35 vs py36 discussion will not affect the outcome of py2 deprecation. > > > > BTW, one alternative option to a formal voting in the Apache way is to > > through lazy consensus [1], which could apply more in our project. Given > > the positive feedback in this discussion thread, I will assume lazy > > consensus in 72hrs on py2 deprecation as defined above. > > > > [1] https://community.apache.org/committers/lazyConsensus.html > > > > On 2019/08/27 00:19:14, Marco de Abreu wrote: > > > Pedro, > > > > > > thanks for already starting these efforts, but it might be too early for > > > that. Right now, this is a discussion thread where we try to gather > > > different opinions in order to lay a good base for a future voting > > thread. > > > In there, we would define the detailed timeline, versions etc. Until the > > > vote has passed, I'd say that it's too early to draw any conclusions. So > > > far, there are two open discussion points: > > > > > > 1. Which Python version to support. 3.5 vs 3.6 is currently in the > > > discussion due to Ubuntu 16.04 being shipped with 3.5 while the biggest > > > market share being 3.6 as of now. > > > 2. When to do the deprecation. EOY to match with official Python 2 > > > deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with the > > > next major release (2.0) to adhere to semantic versioning. > > > > > > Once these points (and any future ones) have been properly discussed and > > > the community came to an agreement, we can formalize it with a voting > > > thread. Until then, I'd recommend to refrain from any actions or > > > user-facing communication regarding this topic. > > > > > > Best regards, > > > Marco > > > > > > On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy < > > pedro.larroy.li...@gmail.com> > > > wrote: > > > > > > > I have sent a PR that removes Python2 from CI. But was closed. I > > thought > > > > everyone was +1 on this one. This would remove quite a bit of load on > > CI: > > > > https://github.com/apache/incubator-mxnet/pull/15990 > > > > > > > > If it's not the right time to do this, what steps do we need to take? > > > > > > > > Pedro. > > > > > > > > > > > > On Mon, Aug 26, 2019 at 1:27 AM Leonard Lausen > > wrote: > > > > > Lieven Govaerts writes: > > > > > > Hi, > > > > > > > > > > > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Pedro stated "Seems 3.6 is a reasonable choice." and there have > > been a > > > > > > > few +1 after Chaitanya's reply to Pedro. I would like to check if > > > > these > > > > > > > only refer to Chaitanya's mail about a dedicated "improvement" > > effort > > > > or > > > > > > > about dropping 3.5. > > > > > > > > > > > > > > Thus two questions: > > > > > > > > > > > > > > 1) Are there any concerns about dropping Python 3.5? Now is your > > > > chance > > > > > to > > > > > > > speak up if you think so. > > >
Re: [Discuss] MXNet Python 3.6 Support Deprecation
In Numpy they are considering dropping 3.5 support for 1.18 or 1.19. P. On Tue, Nov 5, 2019 at 11:15 PM Xingjian SHI wrote: > I don’t think we should drop Python 3.5 now because Ubuntu 16.04 ships > with that version. I suggest that we should revisit it next year. > > Best, > Xingjian > > From: Sheng Zha > Sent: Tuesday, August 27, 2019 10:49 AM > To: d...@mxnet.apache.org > Subject: Re: [Discuss] MXNet Python 3.6 Support Deprecation > > Good summary. At the start the discussion thread my ask is to announce the > intention of py2 deprecation in the next release, and then actually > deprecate py2 in the next major release. Thus, the appropriate timing for > dropping py2 support in CI should be the start of the next major release. > The py35 vs py36 discussion will not affect the outcome of py2 deprecation. > > BTW, one alternative option to a formal voting in the Apache way is to > through lazy consensus [1], which could apply more in our project. Given > the positive feedback in this discussion thread, I will assume lazy > consensus in 72hrs on py2 deprecation as defined above. > > [1] https://community.apache.org/committers/lazyConsensus.html > > On 2019/08/27 00:19:14, Marco de Abreu wrote: > > Pedro, > > > > thanks for already starting these efforts, but it might be too early for > > that. Right now, this is a discussion thread where we try to gather > > different opinions in order to lay a good base for a future voting > thread. > > In there, we would define the detailed timeline, versions etc. Until the > > vote has passed, I'd say that it's too early to draw any conclusions. So > > far, there are two open discussion points: > > > > 1. Which Python version to support. 3.5 vs 3.6 is currently in the > > discussion due to Ubuntu 16.04 being shipped with 3.5 while the biggest > > market share being 3.6 as of now. > > 2. When to do the deprecation. EOY to match with official Python 2 > > deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with the > > next major release (2.0) to adhere to semantic versioning. > > > > Once these points (and any future ones) have been properly discussed and > > the community came to an agreement, we can formalize it with a voting > > thread. Until then, I'd recommend to refrain from any actions or > > user-facing communication regarding this topic. > > > > Best regards, > > Marco > > > > On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy < > pedro.larroy.li...@gmail.com> > > wrote: > > > > > I have sent a PR that removes Python2 from CI. But was closed. I > thought > > > everyone was +1 on this one. This would remove quite a bit of load on > CI: > > > > > > https://github.com/apache/incubator-mxnet/pull/15990 > > > > > > If it's not the right time to do this, what steps do we need to take? > > > > > > Pedro. > > > > > > > > > On Mon, Aug 26, 2019 at 1:27 AM Leonard Lausen > wrote: > > > > > > > Lieven Govaerts writes: > > > > > Hi, > > > > > > > > > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen > > > wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> Pedro stated "Seems 3.6 is a reasonable choice." and there have > been a > > > > >> few +1 after Chaitanya's reply to Pedro. I would like to check if > > > these > > > > >> only refer to Chaitanya's mail about a dedicated "improvement" > effort > > > or > > > > >> about dropping 3.5. > > > > >> > > > > >> Thus two questions: > > > > >> > > > > >> 1) Are there any concerns about dropping Python 3.5? Now is your > > > chance > > > > to > > > > >> speak up if you think so. > > > > >> > > > > >> > > > > > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are > > > > supported > > > > > for 5 years, so for 16.04 LTS it ends in 1.5 years. > > > > > > > > > > I'm not saying you should wait for 1.5 more years, people can > upgrade > > > to > > > > > 18.04 LTS after all, but may I suggest you make this switch in a > major > > > > > release only? More specifically, ensure that Python 3.6-only code > > > doesn't > > > > > accidentally gets merged into a 1.5.X patch release. &
Re: [Discuss] MXNet Python 3.6 Support Deprecation
I don’t think we should drop Python 3.5 now because Ubuntu 16.04 ships with that version. I suggest that we should revisit it next year. Best, Xingjian From: Sheng Zha Sent: Tuesday, August 27, 2019 10:49 AM To: d...@mxnet.apache.org Subject: Re: [Discuss] MXNet Python 3.6 Support Deprecation Good summary. At the start the discussion thread my ask is to announce the intention of py2 deprecation in the next release, and then actually deprecate py2 in the next major release. Thus, the appropriate timing for dropping py2 support in CI should be the start of the next major release. The py35 vs py36 discussion will not affect the outcome of py2 deprecation. BTW, one alternative option to a formal voting in the Apache way is to through lazy consensus [1], which could apply more in our project. Given the positive feedback in this discussion thread, I will assume lazy consensus in 72hrs on py2 deprecation as defined above. [1] https://community.apache.org/committers/lazyConsensus.html On 2019/08/27 00:19:14, Marco de Abreu wrote: > Pedro, > > thanks for already starting these efforts, but it might be too early for > that. Right now, this is a discussion thread where we try to gather > different opinions in order to lay a good base for a future voting thread. > In there, we would define the detailed timeline, versions etc. Until the > vote has passed, I'd say that it's too early to draw any conclusions. So > far, there are two open discussion points: > > 1. Which Python version to support. 3.5 vs 3.6 is currently in the > discussion due to Ubuntu 16.04 being shipped with 3.5 while the biggest > market share being 3.6 as of now. > 2. When to do the deprecation. EOY to match with official Python 2 > deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with the > next major release (2.0) to adhere to semantic versioning. > > Once these points (and any future ones) have been properly discussed and > the community came to an agreement, we can formalize it with a voting > thread. Until then, I'd recommend to refrain from any actions or > user-facing communication regarding this topic. > > Best regards, > Marco > > On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy > wrote: > > > I have sent a PR that removes Python2 from CI. But was closed. I thought > > everyone was +1 on this one. This would remove quite a bit of load on CI: > > > > https://github.com/apache/incubator-mxnet/pull/15990 > > > > If it's not the right time to do this, what steps do we need to take? > > > > Pedro. > > > > > > On Mon, Aug 26, 2019 at 1:27 AM Leonard Lausen wrote: > > > > > Lieven Govaerts writes: > > > > Hi, > > > > > > > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen > > wrote: > > > > > > > >> Hi, > > > >> > > > >> Pedro stated "Seems 3.6 is a reasonable choice." and there have been a > > > >> few +1 after Chaitanya's reply to Pedro. I would like to check if > > these > > > >> only refer to Chaitanya's mail about a dedicated "improvement" effort > > or > > > >> about dropping 3.5. > > > >> > > > >> Thus two questions: > > > >> > > > >> 1) Are there any concerns about dropping Python 3.5? Now is your > > chance > > > to > > > >> speak up if you think so. > > > >> > > > >> > > > > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are > > > supported > > > > for 5 years, so for 16.04 LTS it ends in 1.5 years. > > > > > > > > I'm not saying you should wait for 1.5 more years, people can upgrade > > to > > > > 18.04 LTS after all, but may I suggest you make this switch in a major > > > > release only? More specifically, ensure that Python 3.6-only code > > doesn't > > > > accidentally gets merged into a 1.5.X patch release. > > > > > > > > thanks, > > > > > > > > Lieven > > > > > > Hi Lieven, > > > > > > thanks. I believe the Python version compatibility falls under the > > > semantic versioning umbrella of things not to break within any 1.x > > > release. Thus above suggestion would be with respect to a 2.x release or > > > experimental / preview / new features added to 1.x, without affecting > > > existing 1.x features. It would not affect 1.5.x patch releases. > > > > > > Best regards, > > > Leonard > > > > > > > > > >> 2) Should new MXNet 1.x (experimental?) functionality (for example > > numpy > > > >> compatible interface) only target the Python versions to be supported > > in > > > >> MXNet 2? The current plan is to make many MXNet 2 features available > > as > > > >> "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 for > > > >> these features may impact design and functionality and create > > > >> unnecessary technical debt. > > > > > >
Re: [Discuss] MXNet Python 3.6 Support Deprecation
Good summary. At the start the discussion thread my ask is to announce the intention of py2 deprecation in the next release, and then actually deprecate py2 in the next major release. Thus, the appropriate timing for dropping py2 support in CI should be the start of the next major release. The py35 vs py36 discussion will not affect the outcome of py2 deprecation. BTW, one alternative option to a formal voting in the Apache way is to through lazy consensus [1], which could apply more in our project. Given the positive feedback in this discussion thread, I will assume lazy consensus in 72hrs on py2 deprecation as defined above. [1] https://community.apache.org/committers/lazyConsensus.html On 2019/08/27 00:19:14, Marco de Abreu wrote: > Pedro, > > thanks for already starting these efforts, but it might be too early for > that. Right now, this is a discussion thread where we try to gather > different opinions in order to lay a good base for a future voting thread. > In there, we would define the detailed timeline, versions etc. Until the > vote has passed, I'd say that it's too early to draw any conclusions. So > far, there are two open discussion points: > > 1. Which Python version to support. 3.5 vs 3.6 is currently in the > discussion due to Ubuntu 16.04 being shipped with 3.5 while the biggest > market share being 3.6 as of now. > 2. When to do the deprecation. EOY to match with official Python 2 > deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with the > next major release (2.0) to adhere to semantic versioning. > > Once these points (and any future ones) have been properly discussed and > the community came to an agreement, we can formalize it with a voting > thread. Until then, I'd recommend to refrain from any actions or > user-facing communication regarding this topic. > > Best regards, > Marco > > On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy > wrote: > > > I have sent a PR that removes Python2 from CI. But was closed. I thought > > everyone was +1 on this one. This would remove quite a bit of load on CI: > > > > https://github.com/apache/incubator-mxnet/pull/15990 > > > > If it's not the right time to do this, what steps do we need to take? > > > > Pedro. > > > > > > On Mon, Aug 26, 2019 at 1:27 AM Leonard Lausen wrote: > > > > > Lieven Govaerts writes: > > > > Hi, > > > > > > > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen > > wrote: > > > > > > > >> Hi, > > > >> > > > >> Pedro stated "Seems 3.6 is a reasonable choice." and there have been a > > > >> few +1 after Chaitanya's reply to Pedro. I would like to check if > > these > > > >> only refer to Chaitanya's mail about a dedicated "improvement" effort > > or > > > >> about dropping 3.5. > > > >> > > > >> Thus two questions: > > > >> > > > >> 1) Are there any concerns about dropping Python 3.5? Now is your > > chance > > > to > > > >> speak up if you think so. > > > >> > > > >> > > > > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are > > > supported > > > > for 5 years, so for 16.04 LTS it ends in 1.5 years. > > > > > > > > I'm not saying you should wait for 1.5 more years, people can upgrade > > to > > > > 18.04 LTS after all, but may I suggest you make this switch in a major > > > > release only? More specifically, ensure that Python 3.6-only code > > doesn't > > > > accidentally gets merged into a 1.5.X patch release. > > > > > > > > thanks, > > > > > > > > Lieven > > > > > > Hi Lieven, > > > > > > thanks. I believe the Python version compatibility falls under the > > > semantic versioning umbrella of things not to break within any 1.x > > > release. Thus above suggestion would be with respect to a 2.x release or > > > experimental / preview / new features added to 1.x, without affecting > > > existing 1.x features. It would not affect 1.5.x patch releases. > > > > > > Best regards, > > > Leonard > > > > > > > > > >> 2) Should new MXNet 1.x (experimental?) functionality (for example > > numpy > > > >> compatible interface) only target the Python versions to be supported > > in > > > >> MXNet 2? The current plan is to make many MXNet 2 features available > > as > > > >> "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 for > > > >> these features may impact design and functionality and create > > > >> unnecessary technical debt. > > > > > >
Re: [Discuss] MXNet Python < 3.6 Support Deprecation
Pedro, thanks for already starting these efforts, but it might be too early for that. Right now, this is a discussion thread where we try to gather different opinions in order to lay a good base for a future voting thread. In there, we would define the detailed timeline, versions etc. Until the vote has passed, I'd say that it's too early to draw any conclusions. So far, there are two open discussion points: 1. Which Python version to support. 3.5 vs 3.6 is currently in the discussion due to Ubuntu 16.04 being shipped with 3.5 while the biggest market share being 3.6 as of now. 2. When to do the deprecation. EOY to match with official Python 2 deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with the next major release (2.0) to adhere to semantic versioning. Once these points (and any future ones) have been properly discussed and the community came to an agreement, we can formalize it with a voting thread. Until then, I'd recommend to refrain from any actions or user-facing communication regarding this topic. Best regards, Marco On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy wrote: > I have sent a PR that removes Python2 from CI. But was closed. I thought > everyone was +1 on this one. This would remove quite a bit of load on CI: > > https://github.com/apache/incubator-mxnet/pull/15990 > > If it's not the right time to do this, what steps do we need to take? > > Pedro. > > > On Mon, Aug 26, 2019 at 1:27 AM Leonard Lausen wrote: > > > Lieven Govaerts writes: > > > Hi, > > > > > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen > wrote: > > > > > >> Hi, > > >> > > >> Pedro stated "Seems 3.6 is a reasonable choice." and there have been a > > >> few +1 after Chaitanya's reply to Pedro. I would like to check if > these > > >> only refer to Chaitanya's mail about a dedicated "improvement" effort > or > > >> about dropping 3.5. > > >> > > >> Thus two questions: > > >> > > >> 1) Are there any concerns about dropping Python 3.5? Now is your > chance > > to > > >> speak up if you think so. > > >> > > >> > > > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are > > supported > > > for 5 years, so for 16.04 LTS it ends in 1.5 years. > > > > > > I'm not saying you should wait for 1.5 more years, people can upgrade > to > > > 18.04 LTS after all, but may I suggest you make this switch in a major > > > release only? More specifically, ensure that Python 3.6-only code > doesn't > > > accidentally gets merged into a 1.5.X patch release. > > > > > > thanks, > > > > > > Lieven > > > > Hi Lieven, > > > > thanks. I believe the Python version compatibility falls under the > > semantic versioning umbrella of things not to break within any 1.x > > release. Thus above suggestion would be with respect to a 2.x release or > > experimental / preview / new features added to 1.x, without affecting > > existing 1.x features. It would not affect 1.5.x patch releases. > > > > Best regards, > > Leonard > > > > > > >> 2) Should new MXNet 1.x (experimental?) functionality (for example > numpy > > >> compatible interface) only target the Python versions to be supported > in > > >> MXNet 2? The current plan is to make many MXNet 2 features available > as > > >> "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 for > > >> these features may impact design and functionality and create > > >> unnecessary technical debt. > > >
Re: [Discuss] MXNet Python < 3.6 Support Deprecation
I have sent a PR that removes Python2 from CI. But was closed. I thought everyone was +1 on this one. This would remove quite a bit of load on CI: https://github.com/apache/incubator-mxnet/pull/15990 If it's not the right time to do this, what steps do we need to take? Pedro. On Mon, Aug 26, 2019 at 1:27 AM Leonard Lausen wrote: > Lieven Govaerts writes: > > Hi, > > > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen wrote: > > > >> Hi, > >> > >> Pedro stated "Seems 3.6 is a reasonable choice." and there have been a > >> few +1 after Chaitanya's reply to Pedro. I would like to check if these > >> only refer to Chaitanya's mail about a dedicated "improvement" effort or > >> about dropping 3.5. > >> > >> Thus two questions: > >> > >> 1) Are there any concerns about dropping Python 3.5? Now is your chance > to > >> speak up if you think so. > >> > >> > > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are > supported > > for 5 years, so for 16.04 LTS it ends in 1.5 years. > > > > I'm not saying you should wait for 1.5 more years, people can upgrade to > > 18.04 LTS after all, but may I suggest you make this switch in a major > > release only? More specifically, ensure that Python 3.6-only code doesn't > > accidentally gets merged into a 1.5.X patch release. > > > > thanks, > > > > Lieven > > Hi Lieven, > > thanks. I believe the Python version compatibility falls under the > semantic versioning umbrella of things not to break within any 1.x > release. Thus above suggestion would be with respect to a 2.x release or > experimental / preview / new features added to 1.x, without affecting > existing 1.x features. It would not affect 1.5.x patch releases. > > Best regards, > Leonard > > > >> 2) Should new MXNet 1.x (experimental?) functionality (for example numpy > >> compatible interface) only target the Python versions to be supported in > >> MXNet 2? The current plan is to make many MXNet 2 features available as > >> "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 for > >> these features may impact design and functionality and create > >> unnecessary technical debt. >
Re: [Discuss] MXNet Python < 3.6 Support Deprecation
Lieven Govaerts writes: > Hi, > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen wrote: > >> Hi, >> >> Pedro stated "Seems 3.6 is a reasonable choice." and there have been a >> few +1 after Chaitanya's reply to Pedro. I would like to check if these >> only refer to Chaitanya's mail about a dedicated "improvement" effort or >> about dropping 3.5. >> >> Thus two questions: >> >> 1) Are there any concerns about dropping Python 3.5? Now is your chance to >> speak up if you think so. >> >> > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are supported > for 5 years, so for 16.04 LTS it ends in 1.5 years. > > I'm not saying you should wait for 1.5 more years, people can upgrade to > 18.04 LTS after all, but may I suggest you make this switch in a major > release only? More specifically, ensure that Python 3.6-only code doesn't > accidentally gets merged into a 1.5.X patch release. > > thanks, > > Lieven Hi Lieven, thanks. I believe the Python version compatibility falls under the semantic versioning umbrella of things not to break within any 1.x release. Thus above suggestion would be with respect to a 2.x release or experimental / preview / new features added to 1.x, without affecting existing 1.x features. It would not affect 1.5.x patch releases. Best regards, Leonard >> 2) Should new MXNet 1.x (experimental?) functionality (for example numpy >> compatible interface) only target the Python versions to be supported in >> MXNet 2? The current plan is to make many MXNet 2 features available as >> "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 for >> these features may impact design and functionality and create >> unnecessary technical debt.
Re: [Discuss] MXNet Python < 3.6 Support Deprecation
Hi, On Thu, 22 Aug 2019 at 17:01, Leonard Lausen wrote: > Hi, > > Pedro stated "Seems 3.6 is a reasonable choice." and there have been a > few +1 after Chaitanya's reply to Pedro. I would like to check if these > only refer to Chaitanya's mail about a dedicated "improvement" effort or > about dropping 3.5. > > Thus two questions: > > 1) Are there any concerns about dropping Python 3.5? Now is your chance to > speak up if you think so. > > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are supported for 5 years, so for 16.04 LTS it ends in 1.5 years. I'm not saying you should wait for 1.5 more years, people can upgrade to 18.04 LTS after all, but may I suggest you make this switch in a major release only? More specifically, ensure that Python 3.6-only code doesn't accidentally gets merged into a 1.5.X patch release. thanks, Lieven > 2) Should new MXNet 1.x (experimental?) functionality (for example numpy > compatible interface) only target the Python versions to be supported in > MXNet 2? The current plan is to make many MXNet 2 features available as > "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 for > these features may impact design and functionality and create > unnecessary technical debt. > > > Personally I argue for targeting only 3.6+ as > - 3.5 will go EOL in 388 days and a potential MXNet 2 release together > with our Semantic Versioning backwards compatibility guarantees would > keep us "stuck" on 3.5 for the years to come. JetBrains 2018 survey > showed only 11% of users used 3.5. > - 3.6 introduced a number of fundamental and relevant changes that we > may want to build on and for which we can expect user adoption to > increase over the years (thus MXNet should try to be compatible). > - "PEP 526: Syntax for variable annotations" which we may even be able > to use for shape typing along the lines of numpy > > https://docs.google.com/document/d/1vpMse4c6DrWH5rq2tQSx3qwP_m_0lyn-Ij4WHqQqRHY/ > - asyncio module is stable with 3.6 and associated 3.7 language > features such as contextvars only have backports for 3.6. Some parts > of Gluon currently rely on thread-local state, which is not correct > if users call MXNet from within asyncio code. > Locking ourselves to 3.5 means we can't support these and may provide > a bad user-experience in coming years. > - Part of the Ecosystem (GluonNLP) only support 3.6+ anyways. > > I would also like to cite James MacGlashan to point out how targeting > 3.6+ could help usability and attract more users: > > Pipe dream: I'd love it if Mxnet not only dropped Python 2 support for > a more consistent design, but also went all in on Python 3.6 for type > hint integration. There are enough different types involved in MXNet > that types can help clarify usage, particularly for disambiguating > symbol vs ndarray vs list vs tuple; tuple of ints rather than tuple of > floats; etc. > > https://github.com/apache/incubator-mxnet/issues/8703#issuecomment-520881450 > > Thus we can see targeting 3.6+ as a great opportunity for the MXNet > project! > > Best regards > Leonard > > "Srivastava, Rohit Kumar" writes: > > +1 > > > > On 7/19/19, 12:59 PM, "Zhu Zhaoqi" wrote: > > > > +1 > > > > Lin Yuan 于2019年7月19日周五 上午12:06写道： > > > > > +1 > > > > > > On Fri, Jul 19, 2019 at 12:03 AM Chaitanya Bapat < > chai.ba...@gmail.com> > > > wrote: > > > > > > > +1 definitely. > > > > > > > > Going forward, > > > > MXNet repo as it stands has ~95,000+ lines of Python code [1] > > > > OpenEdx has a million (10x) LOC and this mammoth effort of > porting from > > > > Python 2 to 3 is treated as a separate project named Incremental > > > > Improvement. [2] > > > > We can take inspiration from them and have a similar effort by > calling > > > > action from the community. Issues can be maintained in a > separate JIRA > > > > board to track high priority tasks. > > > > > > > > Also, I can see gluon-nlp adding themselves to the Python3 > statement. > > > Once > > > > the vote passes, one of us could submit a PR to add MXNet as > well. > > > > > > > > [1] https://codeclimate.com/ > > > > [2] > > > > > > > > https://open.edx.org/blog/python-2-is-ending-we-need-to-move-to-python-3/ > > > > > > > > > > > > On Thu, 18 Jul 2019 at 21:39, Kshitij Kalambarkar < > > > > kshitijkalambar...@gmail.com> wrote: > > > > > > > > > +1 > > > > > > > > > > On Fri, Jul 19, 2019, 04:28 Pedro Larroy < > pedro.larroy.li...@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > Seems 3.6 is a reasonable choice. > > > > > > > > > > > > On Thu, Jul 18, 2019 at 2:15 PM Marco de Abreu < > > > > marco.g.ab...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > Looking at EOL is certainly a good idea! I think once we > get closer > > > > to > > > > > >
Re: [Discuss] MXNet Python < 3.6 Support Deprecation
+1 On Thu, Aug 22, 2019 at 11:22 PM Junru Shao wrote: > +1 for 3.6+ > > On Thu, Aug 22, 2019 at 8:54 AM Marco de Abreu > wrote: > > > +1 for 3.6+ > > > > Yuan Tang schrieb am Do., 22. Aug. 2019, > 08:08: > > > > > +1 to target 3.6+ > > > > > > On Thu, Aug 22, 2019 at 11:01 AM Leonard Lausen > > wrote: > > > > > > > Hi, > > > > > > > > Pedro stated "Seems 3.6 is a reasonable choice." and there have been > a > > > > few +1 after Chaitanya's reply to Pedro. I would like to check if > these > > > > only refer to Chaitanya's mail about a dedicated "improvement" effort > > or > > > > about dropping 3.5. > > > > > > > > Thus two questions: > > > > > > > > 1) Are there any concerns about dropping Python 3.5? Now is your > chance > > > to > > > > speak up if you think so. > > > > > > > > 2) Should new MXNet 1.x (experimental?) functionality (for example > > numpy > > > > compatible interface) only target the Python versions to be supported > > in > > > > MXNet 2? The current plan is to make many MXNet 2 features available > as > > > > "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 > for > > > > these features may impact design and functionality and create > > > > unnecessary technical debt. > > > > > > > > > > > > Personally I argue for targeting only 3.6+ as > > > > - 3.5 will go EOL in 388 days and a potential MXNet 2 release > together > > > > with our Semantic Versioning backwards compatibility guarantees > would > > > > keep us "stuck" on 3.5 for the years to come. JetBrains 2018 survey > > > > showed only 11% of users used 3.5. > > > > - 3.6 introduced a number of fundamental and relevant changes that we > > > > may want to build on and for which we can expect user adoption to > > > > increase over the years (thus MXNet should try to be compatible). > > > > - "PEP 526: Syntax for variable annotations" which we may even be > > able > > > > to use for shape typing along the lines of numpy > > > > > > > > > > > > > > https://docs.google.com/document/d/1vpMse4c6DrWH5rq2tQSx3qwP_m_0lyn-Ij4WHqQqRHY/ > > > > - asyncio module is stable with 3.6 and associated 3.7 language > > > > features such as contextvars only have backports for 3.6. Some > > parts > > > > of Gluon currently rely on thread-local state, which is not > correct > > > > if users call MXNet from within asyncio code. > > > > Locking ourselves to 3.5 means we can't support these and may > provide > > > > a bad user-experience in coming years. > > > > - Part of the Ecosystem (GluonNLP) only support 3.6+ anyways. > > > > > > > > I would also like to cite James MacGlashan to point out how targeting > > > > 3.6+ could help usability and attract more users: > > > > > > > > Pipe dream: I'd love it if Mxnet not only dropped Python 2 support > > for > > > > a more consistent design, but also went all in on Python 3.6 for > type > > > > hint integration. There are enough different types involved in > MXNet > > > > that types can help clarify usage, particularly for disambiguating > > > > symbol vs ndarray vs list vs tuple; tuple of ints rather than tuple > > of > > > > floats; etc. > > > > > > > > > > > > > > https://github.com/apache/incubator-mxnet/issues/8703#issuecomment-520881450 > > > > > > > > Thus we can see targeting 3.6+ as a great opportunity for the MXNet > > > > project! > > > > > > > > Best regards > > > > Leonard > > > > > > > > "Srivastava, Rohit Kumar" > writes: > > > > > +1 > > > > > > > > > > On 7/19/19, 12:59 PM, "Zhu Zhaoqi" wrote: > > > > > > > > > > +1 > > > > > > > > > > Lin Yuan 于2019年7月19日周五 上午12:06写道： > > > > > > > > > > > +1 > > > > > > > > > > > > On Fri, Jul 19, 2019 at 12:03 AM Chaitanya Bapat < > > > > chai.ba...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > +1 definitely. > > > > > > > > > > > > > > Going forward, > > > > > > > MXNet repo as it stands has ~95,000+ lines of Python code > [1] > > > > > > > OpenEdx has a million (10x) LOC and this mammoth effort of > > > > porting from > > > > > > > Python 2 to 3 is treated as a separate project named > > > Incremental > > > > > > > Improvement. [2] > > > > > > > We can take inspiration from them and have a similar effort > > by > > > > calling > > > > > > > action from the community. Issues can be maintained in a > > > > separate JIRA > > > > > > > board to track high priority tasks. > > > > > > > > > > > > > > Also, I can see gluon-nlp adding themselves to the Python3 > > > > statement. > > > > > > Once > > > > > > > the vote passes, one of us could submit a PR to add MXNet > as > > > > well. > > > > > > > > > > > > > > [1] https://codeclimate.com/ > > > > > > > [2] > > > > > > > > > > > > > > > > > > > > > > > https://open.edx.org/blog/python-2-is-ending-we-need-to-move-to-python-3/ > > > > > > > > > > > > > > > > > > > > > On Thu, 18 Jul 2019 at 21:39, Kshitij Kalambarkar < > > >
Re: [Discuss] MXNet Python < 3.6 Support Deprecation
+1 for 3.6+ On Thu, Aug 22, 2019 at 8:54 AM Marco de Abreu wrote: > +1 for 3.6+ > > Yuan Tang schrieb am Do., 22. Aug. 2019, 08:08: > > > +1 to target 3.6+ > > > > On Thu, Aug 22, 2019 at 11:01 AM Leonard Lausen > wrote: > > > > > Hi, > > > > > > Pedro stated "Seems 3.6 is a reasonable choice." and there have been a > > > few +1 after Chaitanya's reply to Pedro. I would like to check if these > > > only refer to Chaitanya's mail about a dedicated "improvement" effort > or > > > about dropping 3.5. > > > > > > Thus two questions: > > > > > > 1) Are there any concerns about dropping Python 3.5? Now is your chance > > to > > > speak up if you think so. > > > > > > 2) Should new MXNet 1.x (experimental?) functionality (for example > numpy > > > compatible interface) only target the Python versions to be supported > in > > > MXNet 2? The current plan is to make many MXNet 2 features available as > > > "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 for > > > these features may impact design and functionality and create > > > unnecessary technical debt. > > > > > > > > > Personally I argue for targeting only 3.6+ as > > > - 3.5 will go EOL in 388 days and a potential MXNet 2 release together > > > with our Semantic Versioning backwards compatibility guarantees would > > > keep us "stuck" on 3.5 for the years to come. JetBrains 2018 survey > > > showed only 11% of users used 3.5. > > > - 3.6 introduced a number of fundamental and relevant changes that we > > > may want to build on and for which we can expect user adoption to > > > increase over the years (thus MXNet should try to be compatible). > > > - "PEP 526: Syntax for variable annotations" which we may even be > able > > > to use for shape typing along the lines of numpy > > > > > > > > > https://docs.google.com/document/d/1vpMse4c6DrWH5rq2tQSx3qwP_m_0lyn-Ij4WHqQqRHY/ > > > - asyncio module is stable with 3.6 and associated 3.7 language > > > features such as contextvars only have backports for 3.6. Some > parts > > > of Gluon currently rely on thread-local state, which is not correct > > > if users call MXNet from within asyncio code. > > > Locking ourselves to 3.5 means we can't support these and may provide > > > a bad user-experience in coming years. > > > - Part of the Ecosystem (GluonNLP) only support 3.6+ anyways. > > > > > > I would also like to cite James MacGlashan to point out how targeting > > > 3.6+ could help usability and attract more users: > > > > > > Pipe dream: I'd love it if Mxnet not only dropped Python 2 support > for > > > a more consistent design, but also went all in on Python 3.6 for type > > > hint integration. There are enough different types involved in MXNet > > > that types can help clarify usage, particularly for disambiguating > > > symbol vs ndarray vs list vs tuple; tuple of ints rather than tuple > of > > > floats; etc. > > > > > > > > > https://github.com/apache/incubator-mxnet/issues/8703#issuecomment-520881450 > > > > > > Thus we can see targeting 3.6+ as a great opportunity for the MXNet > > > project! > > > > > > Best regards > > > Leonard > > > > > > "Srivastava, Rohit Kumar" writes: > > > > +1 > > > > > > > > On 7/19/19, 12:59 PM, "Zhu Zhaoqi" wrote: > > > > > > > > +1 > > > > > > > > Lin Yuan 于2019年7月19日周五 上午12:06写道： > > > > > > > > > +1 > > > > > > > > > > On Fri, Jul 19, 2019 at 12:03 AM Chaitanya Bapat < > > > chai.ba...@gmail.com> > > > > > wrote: > > > > > > > > > > > +1 definitely. > > > > > > > > > > > > Going forward, > > > > > > MXNet repo as it stands has ~95,000+ lines of Python code [1] > > > > > > OpenEdx has a million (10x) LOC and this mammoth effort of > > > porting from > > > > > > Python 2 to 3 is treated as a separate project named > > Incremental > > > > > > Improvement. [2] > > > > > > We can take inspiration from them and have a similar effort > by > > > calling > > > > > > action from the community. Issues can be maintained in a > > > separate JIRA > > > > > > board to track high priority tasks. > > > > > > > > > > > > Also, I can see gluon-nlp adding themselves to the Python3 > > > statement. > > > > > Once > > > > > > the vote passes, one of us could submit a PR to add MXNet as > > > well. > > > > > > > > > > > > [1] https://codeclimate.com/ > > > > > > [2] > > > > > > > > > > > > > > > > > https://open.edx.org/blog/python-2-is-ending-we-need-to-move-to-python-3/ > > > > > > > > > > > > > > > > > > On Thu, 18 Jul 2019 at 21:39, Kshitij Kalambarkar < > > > > > > kshitijkalambar...@gmail.com> wrote: > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > On Fri, Jul 19, 2019, 04:28 Pedro Larroy < > > > pedro.larroy.li...@gmail.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Seems 3.6 is a reasonable choice. > > > > > > > > > > > > > > > > On
Re: [Discuss] MXNet Python < 3.6 Support Deprecation
+1 for 3.6+ Yuan Tang schrieb am Do., 22. Aug. 2019, 08:08: > +1 to target 3.6+ > > On Thu, Aug 22, 2019 at 11:01 AM Leonard Lausen wrote: > > > Hi, > > > > Pedro stated "Seems 3.6 is a reasonable choice." and there have been a > > few +1 after Chaitanya's reply to Pedro. I would like to check if these > > only refer to Chaitanya's mail about a dedicated "improvement" effort or > > about dropping 3.5. > > > > Thus two questions: > > > > 1) Are there any concerns about dropping Python 3.5? Now is your chance > to > > speak up if you think so. > > > > 2) Should new MXNet 1.x (experimental?) functionality (for example numpy > > compatible interface) only target the Python versions to be supported in > > MXNet 2? The current plan is to make many MXNet 2 features available as > > "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 for > > these features may impact design and functionality and create > > unnecessary technical debt. > > > > > > Personally I argue for targeting only 3.6+ as > > - 3.5 will go EOL in 388 days and a potential MXNet 2 release together > > with our Semantic Versioning backwards compatibility guarantees would > > keep us "stuck" on 3.5 for the years to come. JetBrains 2018 survey > > showed only 11% of users used 3.5. > > - 3.6 introduced a number of fundamental and relevant changes that we > > may want to build on and for which we can expect user adoption to > > increase over the years (thus MXNet should try to be compatible). > > - "PEP 526: Syntax for variable annotations" which we may even be able > > to use for shape typing along the lines of numpy > > > > > https://docs.google.com/document/d/1vpMse4c6DrWH5rq2tQSx3qwP_m_0lyn-Ij4WHqQqRHY/ > > - asyncio module is stable with 3.6 and associated 3.7 language > > features such as contextvars only have backports for 3.6. Some parts > > of Gluon currently rely on thread-local state, which is not correct > > if users call MXNet from within asyncio code. > > Locking ourselves to 3.5 means we can't support these and may provide > > a bad user-experience in coming years. > > - Part of the Ecosystem (GluonNLP) only support 3.6+ anyways. > > > > I would also like to cite James MacGlashan to point out how targeting > > 3.6+ could help usability and attract more users: > > > > Pipe dream: I'd love it if Mxnet not only dropped Python 2 support for > > a more consistent design, but also went all in on Python 3.6 for type > > hint integration. There are enough different types involved in MXNet > > that types can help clarify usage, particularly for disambiguating > > symbol vs ndarray vs list vs tuple; tuple of ints rather than tuple of > > floats; etc. > > > > > https://github.com/apache/incubator-mxnet/issues/8703#issuecomment-520881450 > > > > Thus we can see targeting 3.6+ as a great opportunity for the MXNet > > project! > > > > Best regards > > Leonard > > > > "Srivastava, Rohit Kumar" writes: > > > +1 > > > > > > On 7/19/19, 12:59 PM, "Zhu Zhaoqi" wrote: > > > > > > +1 > > > > > > Lin Yuan 于2019年7月19日周五 上午12:06写道： > > > > > > > +1 > > > > > > > > On Fri, Jul 19, 2019 at 12:03 AM Chaitanya Bapat < > > chai.ba...@gmail.com> > > > > wrote: > > > > > > > > > +1 definitely. > > > > > > > > > > Going forward, > > > > > MXNet repo as it stands has ~95,000+ lines of Python code [1] > > > > > OpenEdx has a million (10x) LOC and this mammoth effort of > > porting from > > > > > Python 2 to 3 is treated as a separate project named > Incremental > > > > > Improvement. [2] > > > > > We can take inspiration from them and have a similar effort by > > calling > > > > > action from the community. Issues can be maintained in a > > separate JIRA > > > > > board to track high priority tasks. > > > > > > > > > > Also, I can see gluon-nlp adding themselves to the Python3 > > statement. > > > > Once > > > > > the vote passes, one of us could submit a PR to add MXNet as > > well. > > > > > > > > > > [1] https://codeclimate.com/ > > > > > [2] > > > > > > > > > > > > https://open.edx.org/blog/python-2-is-ending-we-need-to-move-to-python-3/ > > > > > > > > > > > > > > > On Thu, 18 Jul 2019 at 21:39, Kshitij Kalambarkar < > > > > > kshitijkalambar...@gmail.com> wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > On Fri, Jul 19, 2019, 04:28 Pedro Larroy < > > pedro.larroy.li...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > Seems 3.6 is a reasonable choice. > > > > > > > > > > > > > > On Thu, Jul 18, 2019 at 2:15 PM Marco de Abreu < > > > > > marco.g.ab...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > Looking at EOL is certainly a good idea! I think once we > > get closer > > > > > to > > > > > > > > deprecation, we can check adoption statistics to make a > > > > well-informed >
Re: [Discuss] MXNet Python < 3.6 Support Deprecation
+1 to target 3.6+ On Thu, Aug 22, 2019 at 11:01 AM Leonard Lausen wrote: > Hi, > > Pedro stated "Seems 3.6 is a reasonable choice." and there have been a > few +1 after Chaitanya's reply to Pedro. I would like to check if these > only refer to Chaitanya's mail about a dedicated "improvement" effort or > about dropping 3.5. > > Thus two questions: > > 1) Are there any concerns about dropping Python 3.5? Now is your chance to > speak up if you think so. > > 2) Should new MXNet 1.x (experimental?) functionality (for example numpy > compatible interface) only target the Python versions to be supported in > MXNet 2? The current plan is to make many MXNet 2 features available as > "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet 1 for > these features may impact design and functionality and create > unnecessary technical debt. > > > Personally I argue for targeting only 3.6+ as > - 3.5 will go EOL in 388 days and a potential MXNet 2 release together > with our Semantic Versioning backwards compatibility guarantees would > keep us "stuck" on 3.5 for the years to come. JetBrains 2018 survey > showed only 11% of users used 3.5. > - 3.6 introduced a number of fundamental and relevant changes that we > may want to build on and for which we can expect user adoption to > increase over the years (thus MXNet should try to be compatible). > - "PEP 526: Syntax for variable annotations" which we may even be able > to use for shape typing along the lines of numpy > > https://docs.google.com/document/d/1vpMse4c6DrWH5rq2tQSx3qwP_m_0lyn-Ij4WHqQqRHY/ > - asyncio module is stable with 3.6 and associated 3.7 language > features such as contextvars only have backports for 3.6. Some parts > of Gluon currently rely on thread-local state, which is not correct > if users call MXNet from within asyncio code. > Locking ourselves to 3.5 means we can't support these and may provide > a bad user-experience in coming years. > - Part of the Ecosystem (GluonNLP) only support 3.6+ anyways. > > I would also like to cite James MacGlashan to point out how targeting > 3.6+ could help usability and attract more users: > > Pipe dream: I'd love it if Mxnet not only dropped Python 2 support for > a more consistent design, but also went all in on Python 3.6 for type > hint integration. There are enough different types involved in MXNet > that types can help clarify usage, particularly for disambiguating > symbol vs ndarray vs list vs tuple; tuple of ints rather than tuple of > floats; etc. > > https://github.com/apache/incubator-mxnet/issues/8703#issuecomment-520881450 > > Thus we can see targeting 3.6+ as a great opportunity for the MXNet > project! > > Best regards > Leonard > > "Srivastava, Rohit Kumar" writes: > > +1 > > > > On 7/19/19, 12:59 PM, "Zhu Zhaoqi" wrote: > > > > +1 > > > > Lin Yuan 于2019年7月19日周五 上午12:06写道： > > > > > +1 > > > > > > On Fri, Jul 19, 2019 at 12:03 AM Chaitanya Bapat < > chai.ba...@gmail.com> > > > wrote: > > > > > > > +1 definitely. > > > > > > > > Going forward, > > > > MXNet repo as it stands has ~95,000+ lines of Python code [1] > > > > OpenEdx has a million (10x) LOC and this mammoth effort of > porting from > > > > Python 2 to 3 is treated as a separate project named Incremental > > > > Improvement. [2] > > > > We can take inspiration from them and have a similar effort by > calling > > > > action from the community. Issues can be maintained in a > separate JIRA > > > > board to track high priority tasks. > > > > > > > > Also, I can see gluon-nlp adding themselves to the Python3 > statement. > > > Once > > > > the vote passes, one of us could submit a PR to add MXNet as > well. > > > > > > > > [1] https://codeclimate.com/ > > > > [2] > > > > > > > > https://open.edx.org/blog/python-2-is-ending-we-need-to-move-to-python-3/ > > > > > > > > > > > > On Thu, 18 Jul 2019 at 21:39, Kshitij Kalambarkar < > > > > kshitijkalambar...@gmail.com> wrote: > > > > > > > > > +1 > > > > > > > > > > On Fri, Jul 19, 2019, 04:28 Pedro Larroy < > pedro.larroy.li...@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > Seems 3.6 is a reasonable choice. > > > > > > > > > > > > On Thu, Jul 18, 2019 at 2:15 PM Marco de Abreu < > > > > marco.g.ab...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > Looking at EOL is certainly a good idea! I think once we > get closer > > > > to > > > > > > > deprecation, we can check adoption statistics to make a > > > well-informed > > > > > > > decision that gives us the most advantages without > dropping the > > > ball > > > > > on a > > > > > > > majority of users (or supporting a branch that is going > EOL soon). > > > A > > > > > > survey > > > > > > > from 2018 [1] determined the following distribution: > > > >
