On Fri, Dec 4, 2015 at 9:29 AM, Bryan Van de Ven <bry...@continuum.io>
wrote:
>
>
>
> > On Dec 4, 2015, at 9:49 AM, Charles R Harris <charlesr.har...@gmail.com>
> wrote:
> >
> >
> >
> > On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor <
> jtaylor.deb...@googlemail.com> 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.
> """
>
>
As a strawman proposal, how about dropping moving to 2.7 and 3.4 minimum
supported version next fall, say around numpy 1.12 or 1.13 depending on how
the releases go.
I would like to here from the scipy folks first.
Chuck
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
