Re: [Numpy-discussion] When to stop supporting Python 2.6?

[David Cournapeau]

On Fri, Dec 4, 2015 at 11:06 AM, Nathaniel Smith  wrote:

> On Fri, Dec 4, 2015 at 1:27 AM, David Cournapeau 
> wrote:
> > I would be in favour of dropping 3.3, but not 2.6 until it becomes too
> > cumbersome to support.
> >
> > As a data point, as of april, 2.6 was more downloaded than all python 3.X
> > versions together when looking at pypi numbers:
> > https://caremad.io/2015/04/a-year-of-pypi-downloads/
>
> I'm not sure what's up with those numbers though -- they're *really*
> unrepresentative of what we see for numpy otherwise. E.g. they show
> 3.X usage as ~5%, but for numpy, 3.x usage has risen past 25%.
> (Source: 'vanity numpy', looking at OS X wheels b/c they're
> per-version and unpolluted by CI download spam. Unfortunately this
> doesn't provide numbers for 2.6 b/c we don't ship 2.6 binaries.) For
> all we know all those 2.6 downloads are travis builds testing projects
> on 2.6 to make sure they keep working because there are so many 2.6
> downloads on pypi :-). Which isn't an argument for dropping 2.6
> either, I just wouldn't put much weight on that blog post either
> way...
>

I agree pypi is only one data point. The proportion is also package
dependent (e.g. django had higher proportion of python 3.X). It is just
that having multiple data points is often more useful than guesses

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] future of f2py and Fortran90+

[Sturla Molden]

On 03/12/15 22:38, Eric Firing wrote:


Right, but for each function that requires writing two wrappers, one in
Fortran and a second one in cython.


Yes, you need two wrappers for each function, one in Cython and one in 
Fortran 2003. That is what fwrap is supposed to automate, but it has 
been abandonware for quite a while.


Sturla

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] When to stop supporting Python 2.6?

[Aldcroft, Thomas]

On Fri, Dec 4, 2015 at 6:13 AM, David Cournapeau  wrote:

>
>
> On Fri, Dec 4, 2015 at 11:06 AM, Nathaniel Smith  wrote:
>
>> On Fri, Dec 4, 2015 at 1:27 AM, David Cournapeau 
>> wrote:
>> > I would be in favour of dropping 3.3, but not 2.6 until it becomes too
>> > cumbersome to support.
>> >
>> > As a data point, as of april, 2.6 was more downloaded than all python
>> 3.X
>> > versions together when looking at pypi numbers:
>> > https://caremad.io/2015/04/a-year-of-pypi-downloads/
>>
>> I'm not sure what's up with those numbers though -- they're *really*
>> unrepresentative of what we see for numpy otherwise. E.g. they show
>> 3.X usage as ~5%, but for numpy, 3.x usage has risen past 25%.
>> (Source: 'vanity numpy', looking at OS X wheels b/c they're
>> per-version and unpolluted by CI download spam. Unfortunately this
>> doesn't provide numbers for 2.6 b/c we don't ship 2.6 binaries.) For
>> all we know all those 2.6 downloads are travis builds testing projects
>> on 2.6 to make sure they keep working because there are so many 2.6
>> downloads on pypi :-). Which isn't an argument for dropping 2.6
>> either, I just wouldn't put much weight on that blog post either
>> way...
>>
>
> I agree pypi is only one data point. The proportion is also package
> dependent (e.g. django had higher proportion of python 3.X). It is just
> that having multiple data points is often more useful than guesses
>

I agree that PyPI numbers appear to be dominated by something other than
user downloads.  As a concrete indication of usage statistics, Tom
Robitaille did a survey earlier this year which showed that about 2% of
respondents were running Python 2.6:

http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/

Astropy is planning to drop support for Python 2.6 in the next major
release (1.2) which is scheduled for about 6 months from now.

- Tom


>
>
> David
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] f2py, numpy.distutils and multiple Fortran source files

[Sturla Molden]

On 03/12/15 22:07, David Verelst wrote:


Can this workflow be incorporated into |setuptools|/|numpy.distutils|?
Something along the lines as:


Take a look at what SciPy does.

https://github.com/scipy/scipy/blob/81c096001974f0b5efe29ec83b54f725cc681540/scipy/fftpack/setup.py

Multiple Fortran files are compiled into a static library using 
"add_library", which is subsequently linked to the extension module.



Sturla

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] When to stop supporting Python 2.6?

[Julian Taylor]

dropping 3.2: +-0 as it would remove some extra code in our broken py3
string handling but not much
dropping 3.3: -1 doesn't gain us anything so far I know
dropping 2.6: -1, I don't see not enough advantage the only issue I know
of is an occasional set literal which gets caught by our test-suite
immediately. Besides 2.6 is still the default in RHEL6. But if there is
something larger which makes it worthwhile I don't know about I have no
objections.


On 04.12.2015 10:27, David Cournapeau wrote:
> I would be in favour of dropping 3.3, but not 2.6 until it becomes too
> cumbersome to support.
> 
> As a data point, as of april, 2.6 was more downloaded than all python
> 3.X versions together when looking at pypi
> numbers: https://caremad.io/2015/04/a-year-of-pypi-downloads/
> 
> David
> 
> On Thu, Dec 3, 2015 at 11:03 PM, Jeff Reback  > wrote:
> 
> pandas is going to drop
> 2.6 and 3.3 next release at end of Jan
> 
> (3.2 dropped in 0.17, in October)
> 
> 
> 
> I can be reached on my cell 917-971-6387
> > On Dec 3, 2015, at 6:00 PM, Bryan Van de Ven  > wrote:
> >
> >
> >> On Dec 3, 2015, at 4:59 PM, Eric Firing  > wrote:
> >>
> >> Chuck,
> >>
> >> I would support dropping the old versions now.  As a related data
> point, matplotlib is testing master on 2.7, 3.4, and 3.5--no more
> 2.6 and 3.3.
> >
> > Ditto for Bokeh.
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org 
> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org 
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
> 
> 
> 
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
> 

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] When to stop supporting Python 2.6?

[David Cournapeau]

I would be in favour of dropping 3.3, but not 2.6 until it becomes too
cumbersome to support.

As a data point, as of april, 2.6 was more downloaded than all python 3.X
versions together when looking at pypi numbers:
https://caremad.io/2015/04/a-year-of-pypi-downloads/

David

On Thu, Dec 3, 2015 at 11:03 PM, Jeff Reback  wrote:

> pandas is going to drop
> 2.6 and 3.3 next release at end of Jan
>
> (3.2 dropped in 0.17, in October)
>
>
>
> I can be reached on my cell 917-971-6387
> > On Dec 3, 2015, at 6:00 PM, Bryan Van de Ven 
> wrote:
> >
> >
> >> On Dec 3, 2015, at 4:59 PM, Eric Firing  wrote:
> >>
> >> Chuck,
> >>
> >> I would support dropping the old versions now.  As a related data
> point, matplotlib is testing master on 2.7, 3.4, and 3.5--no more 2.6 and
> 3.3.
> >
> > Ditto for Bokeh.
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] When to stop supporting Python 2.6?

[Nathaniel Smith]

On Fri, Dec 4, 2015 at 1:27 AM, David Cournapeau  wrote:
> I would be in favour of dropping 3.3, but not 2.6 until it becomes too
> cumbersome to support.
>
> As a data point, as of april, 2.6 was more downloaded than all python 3.X
> versions together when looking at pypi numbers:
> https://caremad.io/2015/04/a-year-of-pypi-downloads/

I'm not sure what's up with those numbers though -- they're *really*
unrepresentative of what we see for numpy otherwise. E.g. they show
3.X usage as ~5%, but for numpy, 3.x usage has risen past 25%.
(Source: 'vanity numpy', looking at OS X wheels b/c they're
per-version and unpolluted by CI download spam. Unfortunately this
doesn't provide numbers for 2.6 b/c we don't ship 2.6 binaries.) For
all we know all those 2.6 downloads are travis builds testing projects
on 2.6 to make sure they keep working because there are so many 2.6
downloads on pypi :-). Which isn't an argument for dropping 2.6
either, I just wouldn't put much weight on that blog post either
way...

(Supporting 2.6 in numpy hasn't been a big deal so far AFAICR, but I'd
be in favor of dropping it as soon as supporting it becomes even a
minor hassle.)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] When to stop supporting Python 2.6?

[Charles R Harris]

On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor  wrote:

> dropping 3.2: +-0 as it would remove some extra code in our broken py3
> string handling but not much
> dropping 3.3: -1 doesn't gain us anything so far I know
> dropping 2.6: -1, I don't see not enough advantage the only issue I know
> of is an occasional set literal which gets caught by our test-suite
> immediately. Besides 2.6 is still the default in RHEL6. But if there is
> something larger which makes it worthwhile I don't know about I have no
> objections.
>

My thought is that dropping 2.6 allows a more unified code base between
Python 2 and Python3. In 2.7 we get


   - The syntax for set literals ({1,2,3} is a mutable set).
   - Dictionary and set comprehensions ({i: i*2 for i in range(3)}).
   - Multiple context managers in a single with
    statement.
   - A new version of the io
    library, rewritten
   in C for performance.
   - The ordered-dictionary type described in *PEP 372: Adding an Ordered
   Dictionary to collections*
   .
   - The new "," format specifier described in *PEP 378: Format Specifier
   for Thousands Separator*
   .
   - The memoryview
    object.
   - A small subset of the importlib
   
   module, described below
   .
   - The repr()  of
   a float x is shorter in many cases: it’s now based on the shortest
   decimal string that’s guaranteed to round back to x. As in previous
   versions of Python, it’s guaranteed that float(repr(x)) recovers x.
   - Float-to-string and string-to-float conversions are correctly rounded.
   The round() 
   function is also now correctly rounded.
   - The PyCapsule
    type, used to
   provide a C API for extension modules.
   - The PyLong_AsLongAndOverflow()
    C
   API function.

In particular, memoryview and PyCapsule are available. Moving to Python 3.3
as a minimum provides unicode literals. Python 3.4 strikes me as the end of
the Python 3 beginning, with future Python development taking off from
there.



Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] When to stop supporting Python 2.6?

[Bryan Van de Ven]

> On Dec 4, 2015, at 9:49 AM, Charles R Harris  
> wrote:
> 
> 
> 
> On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor  
> wrote:
> dropping 3.2: +-0 as it would remove some extra code in our broken py3
> string handling but not much
> dropping 3.3: -1 doesn't gain us anything so far I know
> dropping 2.6: -1, I don't see not enough advantage the only issue I know
> of is an occasional set literal which gets caught by our test-suite
> immediately. Besides 2.6 is still the default in RHEL6. But if there is
> something larger which makes it worthwhile I don't know about I have no
> objections.
> 
> My thought is that dropping 2.6 allows a more unified code base between 
> Python 2 and Python3. In 2.7 we get
> 
>   • The syntax for set literals ({1,2,3} is a mutable set).
>   • Dictionary and set comprehensions ({i: i*2 for i in range(3)}).
>   • Multiple context managers in a single with statement.
>   • A new version of the io library, rewritten in C for performance.
>   • The ordered-dictionary type described in PEP 372: Adding an Ordered 
> Dictionary to collections.
>   • The new "," format specifier described in PEP 378: Format Specifier 
> for Thousands Separator.
>   • The memoryview object.
>   • A small subset of the importlib module, described below.
>   • The repr() of a float x is shorter in many cases: it’s now based on 
> the shortest decimal string that’s guaranteed to round back to x. As in 
> previous versions of Python, it’s guaranteed that float(repr(x)) recovers x.
>   • Float-to-string and string-to-float conversions are correctly 
> rounded. The round() function is also now correctly rounded.
>   • The PyCapsule type, used to provide a C API for extension modules.
>   • The PyLong_AsLongAndOverflow() C API function.
> In particular, memoryview and PyCapsule are available. Moving to Python 3.3 
> as a minimum provides unicode literals. Python 3.4 strikes me as the end of 
> the Python 3 beginning, with future Python development taking off from there.

I'd suggest that anything that unifies the codebase and reduces complexity and 
special cases will not only help current developers, but also lower the bar for 
potential new developers as well. The importance of streamlining and reducing 
the maintenance burden in long-running projects cannot be overstated, in my 
opinion. 

I'd also suggest that Numpy is in a unique position proactively encourage 
people to use more reasonable versions of python, and for those that can't or 
won't (yet) it's not like older versions of Numpy will disappear. A brief 
search seems to affirm my feeling that "2.7 + 3.3/3.4" support is becoming 
fairly standard among a wide range of OSS python projects. 

Regarding RHEL6 comment above, even Nick Coghlan suggests that is not a 
compelling motivation:


http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html

"""
While it's entirely admirable that many upstream developers are generous enough 
to help their end users work around this inertia, in the long run doing so is 
detrimental for everyone concerned, as long term sustaining engineering for old 
releases is genuinely demotivating for upstream developers (it's a good job, 
but a lousy way to spend your free time) and for end users, working around 
institutional inertia this way reduces the pressure to actually get the 
situation addressed properly.
"""

Bryan

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion