[SciPy-User] SciPy ecosystem and Python 3

[Nathaniel Polish]

I am mostly a lurker here but as a practicing computer scientist and 
engineer, I thought I'd offer my two cents.

We face this issue when getting into any system that is new to us.  Which 
version of unix?  C, C++, Java, PHP, etc...All have their issues with 
respect to versions.  All such systems have life cycles.  Its always best 
to get your work done within a single product cycle.  Shifting in the 
middle of project is usually deadly.

Anyone showing up to numpy etc now to get specific work done should really 
be directed to 2.7.  That's where the maturity is.  3 is where the world is 
going but the time scale is uncertain.  Pushing new users to 3 just to get 
a community is a bad idea.  The experienced folks should be the ones 
establishing the new version.  I know that everyone is trying...

I faced this two years ago when I starting working with numpy.  It was 
confusing.  However I quickly realized as a CS person what was going on. 
2.7 was solid and mature.  Errors that I found could almost always be 
assumed to be my fault.  Everything I was doing could be assumed to have 
been tried by someone else before.  Version 3 had none of those attributes 
so I stuck to 2.7.  This is kind of the way that I feel about C and Unix. 
Solid and mature.  Nothing much new.

For what its worth, if the community does not make the switch to version 3 
reasonably soon, it will risk losing people to other systems that ARE 
successfully moving through new versions.  Its hard with such a far flung 
community but that's what we are.

There, I will now retreat to the shadows from whence I came.  You folks do 
amazing work and I am mostly in awe of its quality.



--On Tuesday, July 02, 2013 8:47 AM +0200 Ralf Gommers 
<ralf.gommers at gmail.com> wrote:

>
>
>
>
>
>
> On Tue, Jul 2, 2013 at 1:55 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>
>
>
>
>
> On 30 June 2013 20:04, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
> That's not quite what I meant. Even on a work pc on which I don't have
> admin rights I will be able to install Anaconda or another distribution.
> All the basic examples in Python and numpy/scipy docs will work. But I
> don't work in a vacuum, so I'll find out at some later stage that some
> code that my co-workers wrote depends on version (current minus 2) of
> some package that only supports 3.x in version (current). This should be
> the exception and not the norm before recommending 3.x imho.
>
>
>
> Again, though, I think your coworkers are more likely to have written
> code which expects Python 2, than Python-3-compatible code which relies
> on an older version of a particular library. But that's a chicken and egg
> problem, and if we always pointed newcomers at the option most likely to
> preserve compatibility with prior code, then we'd never have started
> using Python at all.
>
>
>
>
> I understand it's a chicken and egg problem, but newcomers are not the
> right group to solve that. You want to give them the recommendation that
> helps them get started with the least amount of trouble. One bad
> experience (and having to do some serious debugging or even downgrade to
> 2.x is bad) can be enough to chase them back to Matlab.
>
>
> We'll get there eventually, but only when a good portion (say 50%) of
> existing users and devs have moved.
>
>  
>
>
>
>
> Hans also has a good point: if you're working in a group with a Python
> codebase, they should show you how to set up the preferred environment
> for that.
>
>
>
>
> If only the real world was that simple:)
>  
>
>
>
> I also imagine that we'll need to maintain a warning for some time after
> we start recommending Python 3, along the lines of "If you find code that
> doesn't work, it might be that it was never updated to run on Python 3."
>
>
>
>
> No no no. That's a terrible sentence to write. Imagine you reading that
> if you move to new language X.
>
>
>
>
>  That's not ideal, but I think being able to point newcomers at the
> 'latest and greatest' version by default will still be an important
> improvement.
>
>
>
>
> Please keep in mind that it's much more important to you, as an active
> dev who cares about 3.x adoption, then to them. All newcomers are getting
> for now is some compatibility issues and strings they don't understand.
> On the upside they don't have to move a few years later, but the business
> case is thin.
>
>
> Cheers,
> Ralf
>
>
> P.S. I do agree with you on where we need to go, there's just no need to
> be in a hurry imho
>