Folks,
The futurize and pasteurize components at http://python-future.org/ might be
useful in developing
a code base that runs on both python versions 2 and 3.
By supporting both, you retain flexibility for scientific users.
-- Brian
On 1/16/18, 8:33 PM, "Goodman, Alexander (398K)"
<alexander.good...@jpl.nasa.gov> wrote:
Hi Lewis,
I think that is sort of a hasty action to take. If anything, I question
whether we should even require pydap as a dependency in the first place
since its main advantage (when used as a client-side tool, anyway) is to
provide the ability to load OpenDAP datasets without the netcdf4 library
(which is a core dependency to ocw and pretty much any other earth science
data analysis library out there). In the short term I think we could modify
the conda recipe to drop pydap for python 2.7, as that should fix our CI
problems.
However in the long term we will have no choice but to drop support for
python 2, as most of the pydata stack (ie, almost all of our core
dependencies) will soon be doing so:
http://www.python3statement.org/
This was actually something I was going to discuss with you and Kyo in my
planned meeting next week, as I have considered releasing the new version
of ocw I am developing as a python 3-only codebase. In terms of our current
dependencies, only esgf-pyclient does not support python 3 (but this should
change soon enough).
My one concern is that the scientific community in general has been
resistant to switching (don't want to link anything here, since a quick
google search will yield numerous blog posts on the subject). Having
personally been heavily involved in the process of making ocw python 3, I
personally don't blame them since for those users python 3 just adds
needless compatibility issues without offering them a whole lot of
compelling new features. The most recent set of new features for python
3.x, most notably asyncio (along with the new unicode string model, which
is what actually breaks everything), are of far more use to web developers
than they are to scientists. If it weren't for the fact that the big
projects I mentioned a few paragraphs ago are making a strong push for
python 3, then I am not sure I would even consider it for this project
given our type of userbase. The flipside to this is that as a core
developer, I do understand that maintaining python2/3 support
simultaneously is a rather messy process, and certainly not something I
would be too keen on doing when writing a new codebase in 2018. I'd be fine
with maintaining a python 2.7-only codebase in an ideal world, but
unfortunately that is not the world we are living in so for me personally I
believe there is only one other choice moving forward...
So yeah, just my 2 cents. Ignoring my rant, here's the tl;dr: I am against
dropping python 2.7 support right away, but would be for gradually phasing
it out (especially if we decide to rewrite the codebase).
PS: Which reminds me, the "new codebase" I keep mentioning is just a pet
project of mine (currently dubbed "ocw2"), which makes gratuitous use of
pandas and xarray as a data processing backend, rather than vanilla
numpy/scipy. I'll discuss more details and hopefully open source my code
within the next few weeks.
Thanks,
Alex
On Tue, Jan 16, 2018 at 7:10 PM, lewis john mcgibbney <lewi...@apache.org>
wrote:
> Hi Folks,
> You will notice that our TravisCI builds currently report as being broken.
> This is due to the pydap dependency not being available for Python 2.7.
> Is it time to drop support for Python 2.7 altogether and simplify things?
> Lewis
>
>
> --
> http://home.apache.org/~lewismc/
> http://people.apache.org/keys/committer/lewismc
>
--
Alex Goodman
Data Scientist I
Science Data Modeling and Computing (398K)
Jet Propulsion Laboratory
California Institute of Technology
Tel: +1-818-354-6012
