Hi,
For what it's worth, python 3.6 is also dropped for astropy 4.2 (RC1 to be
released in the next few days). We haven't yet formally adopted NEP29, but
are very close to it peding some word smithing, and no one from the dev
team was fighting for keeping support for 3.6. or numpy 1.16.
Cheers,
I am in favor of dropping py36 for np1.20, I think it would be good to lead
by example.
Similar to pandas, the next Matplotlib release (3.4 targeted for Dec/Jan)
will not support py36.
Tom
On Tue, Nov 3, 2020 at 9:18 AM Mark Harfouche
wrote:
> Juan made a pretty good argument for keeping 3.6
Juan made a pretty good argument for keeping 3.6 support in the next
scikit-image release, let me try to paraphrase:
- Since nobody has made the PR to explicitly drop python 3.6 from the
scikit-image build matrix, we will continue to support it, but if somebody
were to make the PR, I (Juan) would
On Mon, 2020-11-02 at 06:49 -0600, Juan Nunez-Iglesias wrote:
> I like Ralf's email, and most of all I agree that the existing
> wording is clearer.
>
> My view on the NEP is that it does not mandate dropping support, but
> encourage it. In my projects I would drop it if I had use for Python
> 3.7
I like Ralf's email, and most of all I agree that the existing wording is
clearer.
My view on the NEP is that it does not mandate dropping support, but encourage
it. In my projects I would drop it if I had use for Python 3.7+ features. It so
happens that we want to use PEP-593 so we were gratef
On Mon, Nov 2, 2020 at 7:47 AM Stephan Hoyer wrote:
> On Sun, Nov 1, 2020 at 7:47 PM Stefan van der Walt
> wrote:
>
>> On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote:
>> > I also misunderstood the purpose of the NEP. I assumed it was
>> > intended to encourage projects to drop old versions
On Sun, Nov 1, 2020 at 7:47 PM Stefan van der Walt
wrote:
> On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote:
> > I also misunderstood the purpose of the NEP. I assumed it was
> > intended to encourage projects to drop old versions of Python. Other
> > people have viewed the NEP similarly:
>
: [Numpy-discussion] NumPy 1.20.x branch in two weeks I also misunderstood the purpose of the NEP. I assumed it wasintended to encourage projects to drop old versions of Python. Otherpeople have viewed the NEP similarly:https://github.com/networkx/networkx/issues/4027 If the intention of the NEP is to
On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote:
> I also misunderstood the purpose of the NEP. I assumed it was
> intended to encourage projects to drop old versions of Python. Other
> people have viewed the NEP similarly:
> https://github.com/networkx/networkx/issues/4027
Of all the packag
I also misunderstood the purpose of the NEP. I assumed it was
intended to encourage projects to drop old versions of Python. Other
people have viewed the NEP similarly:
https://github.com/networkx/networkx/issues/4027
If the intention of the NEP is to specify that projects not drop old
version o
NetworkX is currently planning to support 3.6 for our coming 2.6
release (dec 2020) and 3.0 release (early 2021). We had originally
thought about following NEP 29. But I assumed it had been abandoned,
since neither NumPy nor SciPy dropped Python 3.6 on Jun 23, 2020.
NetworkX is likely to continu
pandas has already dropped 3.6 support in our coming 1.2 release (nov 2020);
1.1.x supports 3.6
> On Nov 1, 2020, at 9:04 PM, Charles R Harris
> wrote:
>
>
>
>
> On Sun, Nov 1, 2020 at 6:48 PM Mark Harfouche
> wrote:
>>>
>>> Do you think the proposal is not in compliance? There is no re
On Sun, Nov 1, 2020 at 6:48 PM Mark Harfouche
wrote:
>
>> Do you think the proposal is not in compliance? There is no requirement
>> that we drop anything more than 42 months old, it is just recommended. The
>> change in the Python release cycle has created some difficulty. With the
>> yearly cyc
>
>
> Do you think the proposal is not in compliance? There is no requirement
> that we drop anything more than 42 months old, it is just recommended. The
> change in the Python release cycle has created some difficulty. With the
> yearly cycle, 4 python yearly releases will cover 3-4 years, which
On Sun, Nov 1, 2020 at 4:28 PM Mark Harfouche
wrote:
> I know it seems silly, but would an amendment to NEP29 be reasonable?
>
> Many downstream packages look to numpy to understand what versions should
> be supported and NEP29 gave some good guidance.
> That said, if it is worth ignoring, or rev
I know it seems silly, but would an amendment to NEP29 be reasonable?
Many downstream packages look to numpy to understand what versions should
be supported and NEP29 gave some good guidance.
That said, if it is worth ignoring, or revisiting, some clarity on how to
apply NEP29 given recent develop
On Thu, Oct 29, 2020 at 2:25 PM Charles R Harris
wrote:
> Hi All,
>
> Time to start planning for the 1.20.x branch. These are my thoughts at the
> moment:
>
>- Keep support for Python 3.6. Python 3.7 came out in June 2018, which
>seems too recent to be our oldest supported version.
>-
Hi All,
Time to start planning for the 1.20.x branch. These are my thoughts at the
moment:
- Keep support for Python 3.6. Python 3.7 came out in June 2018, which
seems too recent to be our oldest supported version.
- Drop Python 3.6 for 1.21.x, that will make the oldest supported
vers
18 matches
Mail list logo
