GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-11-15) - page 1 of 10
 
___________________________________________________________________
Numpy: Plan for dropping Python 2.7 support
253 points by AndrewDucker
https://github.com/numpy/numpy/blob/master/doc/neps/dropping-pyt...
___________________________________________________________________
 
Pxtl - 11 minutes ago
After such a long and painful road from 2 to 3, I feel like the
Python developers aimed too low in fixing the legacy problems that
existed in 2.All that time for Unicode.  Not concurrency or type
safety or static guarantees or better lambda syntax or anything fun
like that.  Just Unicode.
 
mastax - 1 hours ago
Better title: Numpy's plan for dropping Python 2.7 support
 
  sctb - 57 minutes ago
  Thanks, we updated the headline to be closer to the original
  title.
 
mattbillenstein - 1 hours ago
* at the end of 2019I guess it's due -- Python 3 finally has some
improvements to the runtime that I think will start to pull more
Python2 people over.
 
  boulos - 1 hours ago
  Their plan is more nuanced than "at the end of 2019". From a
  numpy feature standpoint, it's EOY 2018, bugs through EOY 2019:>
  Until December 31, 2018, all NumPy releases will fully support
  both Python2 and Python3.Starting on January 1, 2019, any new
  feature releases will support only Python3.The last Python2
  supporting release will be designated as a long term support
  (LTS) release, meaning that we will continue to merge bug fixes
  and make bug fix releases for a longer period than usual.
  Specifically, it will be supported by the community until
  December 31, 2019.
 
ben_w - 29 minutes ago
I hope Apple takes this as a reason to upgrade the default Python
version installed on OS X, otherwise this could be a needless
headache.
 
  x0x0 - 24 minutes ago
  virtualenv plus virtualenvwrapper makes this really easy... using
  a virtualenv can be as easy as   workon #{projectname}
 
    untog - 14 minutes ago
    Yes, but it's great to be able to use Python for simple
    scripting tasks too. In that context it's way too much to
    expect a user to download virtualenv, so instead people just
    write things for 2.x
 
raker - 1 hours ago
Good to see that it will be a quiet transition.  Linus would
approve.
 
  jwilk - 43 minutes ago
  Linus?
 
reggieband - 56 minutes ago
I cheered Python's slow and steady 2.7 -> 3 move when it began but
I'll admit I started to have some doubts a couple of years ago when
it still had not completed. In hindsight I think it has been
exceptionally well managed and is likely to keep Python in good
stead for many years to come.
 
ncw33 - 1 hours ago
How dedicated to keep it going so long! Maintenance this long-term
is a time-sucking activity.
 
rossdavidh - 1 hours ago
At the SciPy 2017 conference, for the first time I saw speakers who
were presenting new libraries say that they were not going to be
developing Python2 versions.  Quite a change from a year or two
ago.
 
  StavrosK - 1 hours ago
  All my libraries have been py3-only since around last year. I'm
  also not caring much about supporting 2 on the old ones I
  maintain. 2 is pretty old, it's time to move on.
 
    username223 - 1 hours ago
    > 2 is pretty old, it's time to move on.Why?  Just because
    "it's pretty old?"  The 2-to-3 change seems mostly cosmetic.
    When Python users ignored 3, Python devs started flogging their
    dead horse.  When the horse still refused to move, disappointed
    riders started shouting "shame!" at users who suggested that
    the horse looked dead.  Eventually, the riders tied ropes to
    the horse and pulled it along the ground.  The onlookers either
    switched to bicycles and cars, or figured that they might as
    well ride the man-hauled carcass awhile longer.
 
      dwb - 55 minutes ago
      That's a very melodramatic comment for someone who clearly
      hasn't been keeping track of the 3.x changelogs ? which
      pretty much all contain at least one compelling update to the
      language. Modern Python is v3. Legacy support drop-off is the
      same with any project.
 
        username223 - 15 minutes ago
        I was going for "humor" more than "melodrama," but maybe I
        failed at both...  The actual breaking changes between 2.x
        and early 3.x struck me as cosmetic and pointless.To
        compare: Perl went one way by breaking everything to
        essentially make a new language, and failed to get people
        to switch; C++ bent over backwards to maintain
        compatibility, and failed to fundamentally evolve the
        language.  Python basically failed in both ways, changing
        the language just enough to break most people's code, while
        changing it too little to effect significant change.  It
        combines most of the disadvantages of both backward
        compatibility and novelty, with few of the advantages of
        either.
 
bjt2n3904 - 52 minutes ago
I've said it before, I'll say it again. I don't care for
everything-is-unicode-by-default.You can take my Python 2 when you
pry it from my cold dead hands.
 
  derefr - 38 minutes ago
  You know the phrase, "you don't have to go home, but you can't
  stay here"?You don't have to move to Python 3, but Python 2 is
  gonna be EOLed. If you don't agree with Python 3's stances on
  things, it might be time to find another language entirely.
 
    xapata - 26 minutes ago
    Nah, I'm sure you will be able to get commercial support for at
    least another decade.
 
    nas - 23 minutes ago
    I think the amount of Python 2 source code existing in the
    world is too large for Python 2.7.x to stop working.  A lot of
    that code is just never going to get ported to Python 3.
    Companies don't have the budget to do it.  So, somehow there
    will still be a Python 2 interpreter to run the code, even
    after 2020.That said, when nearly all of the Python 3rd-party
    library developers are targeting Python 3, do you really want
    to be stuck on 2.x?  I think that's going to be the ultimate
    death of new Python 2.x development.  The NumPy example seems
    typical.  I.e. the cost of supporting 2.x is very soon not
    going to be worth it.It seems clear to me now that there is not
    going to be a large faction of 3rd party library developers who
    refuse to move from 2.x.  That is unlike Perl 5.  As a Python
    developer, this is very happy result.  The 2 to 3 transition
    was extremely painful but it appears to be mostly behind us
    now.  Having two separate "flavours" of Python (2.x and 3.x)
    would have been bad.
 
      derefr - 17 minutes ago
      > I think the amount of Python 2 source code existing in the
      world is too large for Python 2.7.x to stop working. A lot of
      that code is just never going to get ported to Python 3.
      Companies don't have the budget to do it. So, somehow there
      will still be a Python 2 interpreter to run the code, even
      after 2020.Sure, but?as other people mention down-
      thread?there are still COBOL programs, and even COBOL
      (maintenance) developers. There's just no community for
      active, new COBOL development. That's what it means for a
      language to be EOLed.
 
  ggm - 8 minutes ago
  I too felt 7 bit ascii was a good thing, and I believe I know
  members of the original ANSI committee who worked on it.But, I
  now live and work in the Asia-Pacific region, and I regularly
  interact with data and content which is not represented in 7 bit
  ascii. This has altered my perspective.My comrades from 7 bit
  land also migrated into a world of homophones. It is entirely
  true you can get into some awful places regarding what things
  look like and what semantically they mean, but the one thing that
  has never come up, is what errors of handling it introduced into
  the code: the code, is doing what it does. It is how you
  interpret it, that has to change.uStrings just work. Unclench
  your Undead fists, and accept the news from your brothers and
  sisters outside of paper tape.
 
  praulv - 50 minutes ago
  Yes, one of the most painful aspects of Python 2 to 3 migration.
 
    Bedon292 - 30 minutes ago
    I found the opposite. When having to deal with utf-8 text, I
    hated life in 2, but 3 handles it with ease. It made life so
    much better.
 
    rcthompson - 24 minutes ago
    Of course string encoding is the most painful aspect of
    migrating from Python 2 to 3. The backwards-incompatible fix to
    how Python handles string encoding is literally the reason
    Python 3 exists.
 
  nas - 46 minutes ago
  I don't think anyone is going to pry it from you.  If you want to
  keep using 2.7, go ahead.  It's open source so you can even hire
  someone to keep maintaining it for you.However, be aware that the
  vast majority of the people maintaining Python have moved on to
  3.x.  2.7.x continues to be maintained because the team believes
  in giving people a stable platform and a long maintenance window.
  Long does not mean forever though and most of the people back-
  porting fixes to 2.7.x will stop by 2020.So, you should have a
  plan for that.  May give 3.x a spin and see how it works for you.
  I feel like 3.x adoption is speeding up because people have tried
  porting their code and decided that "yes, 3.x is better".
 
  rcthompson - 18 minutes ago
  I'm open to the argument that Python 3's handling of string
  encoding is not ideal. But after using Python 3, I'm not willing
  to go back to a language that allows the programmer to freely mix
  encoded and decoded strings and uses the same type to represent
  both. That way lies insanity, and I'm glad to be rid of it.In
  Python 2, I could never seem to figure out how to do string
  encoding properly. After trying and failing to reason about the
  code and put the calls to str.encode() and str.decode() in what I
  thought was the right place, my only viable solution was to
  sprinkle random calls to str.encode() and str.decode() throughout
  my code like magic pixie dust until errors stopped happening. In
  Python 3, if I do it wrong, I get an easy-to-debug TypeError. For
  bonus points, if I use Mypy, I can get that error without even
  having to run the code.
 
  hetman - 42 minutes ago
  It replaces one set of quirky hacks for a different set, just in
  different parts of your code. So in a way it's no worse.I have to
  say I was sceptical of Ruby 1.9's new approach to Unicode
  thinking Python 3.0's approach looked much cleaner. It does on
  paper. In practice though, I have to admit I get where Ruby was
  going with it all now.
 
    Something1234 - 39 minutes ago
    Whats the difference between the approaches?
 
    hyperbovine - 38 minutes ago
    I wonder if this has anything to do with Matz being Japanese. I
    do my best to avoid Unicode at all costs because as a native
    English speaker ASCII was working out great for me.
 
      derefr - 37 minutes ago
      Even if you're only shipping to an English-speaking US
      audience, people are still going to be throwing Unicode at
      your app. One word: emojis.
 
pletnes - 1 hours ago
That?s about the same time python 2 support drops in general.
Sounds strange to support packages after the underlying python has
moved on.Kudos to the numpy team for writing the most awesome
python module under the sun, and for providing great support!
 
  jwilk - 36 minutes ago
  It's not strange. Python developers might declare Python 2.X
  EOLed, but that won't stop people from using it. Like it or not,
  Python 2.X is not going away.
 
BoppreH - 24 minutes ago
To preempt the inevitable discussion of which version to use,
please refer to the amazing FAQ created by Eevee:
https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-p...As a
library writer, I cannot wait until we get rid of this self-
inflicted handicap of writing in a subset of two incompatible
languages. I'm glad the heavyweights are joining the cause.
 
smaili - 1 hours ago
It would be interesting to see whether Python 2 is the longest
supported major version for a programming language.
 
  fredley - 1 hours ago
  Define 'supported'? Many banks are still writing COBOL.
 
    kinkrtyavimoodh - 52 minutes ago
    By that logic any language can be supported by never upgrading
    the system. Support implies some kind of active support from
    the creators / maintainers of the language, not active use by
    people.
 
      projectramo - 42 minutes ago
      Exactly.Otherwise I could argue Commodore still "supports"
      the Commodore basic in a Commodore 64.
 
  ken - 32 minutes ago
  Picking a version longevity winner probably depends on whether
  you mean specification, or implementation.ANSI Common Lisp was
  standardized in 1994, and there have been no updates to the
  language since then.  There are several supported implementations
  (though the implementations have probably all incremented their
  major version at least once since then).It seems that JavaScript
  gave up numbering at 1.8.5 [1], so you might consider it to still
  be on "JavaScript 1.x", which dates back to 1996.[1]:
  https://en.wikipedia.org/wiki/JavaScript#Version_history
 
  neuronexmachina - 3 minutes ago
  I guess there's TeX. Knuth released version 3.0 in 1989, and it's
  currently on ?3.14159265.
 
  santaclaus - 1 hours ago
  LLVM recently got support for Fortran (through Flang), so Python
  2 has at least 30 years to go...
 
  pm215 - 1 hours ago
  Python 2 came out in 2000 and goes EOL 2020 I think. Perl 5 was
  released in 1994 and has no planned EOL date, so it is currently
  winning by a fair margin.
 
    brians - 27 minutes ago
    And 2 vs 1 is really only a licensing issue. Python 1.4, from
    1996, is not so different!
 
  kzrdude - 1 hours ago
  How do we compare it with C89 implementations out there?
 
  CJefferson - 1 hours ago
  What? No! Python 2 is only 17 years old.I can still run Java, C,
  C++ and Perl 5 (picking the first 4 languages that occur) that
  were written before then, with no problems.
 
    jhasse - 2 minutes ago
    Most C++ code wont compile for multiple reasons. For example
    using namespace std will result in errors if your code calls a
    function which is now part of std.
 
    xapata - 23 minutes ago
    Which version? Aren't we on Java 9 now?
 
  Elv13 - 1 hours ago
  ANSI C (C89), Fortran 66 and COBOL 61 will easily be the most
  serious contenders.
 
    eesmith - 10 minutes ago
    I think the OP is looking for something a bit different, not
    oldest supported programming language but longest time between
    major updates to the language.This is a bit hard to address
    because Python does incremental language changes, as well as
    major changes, while the languages you listed have formal
    specifications.Python 2 from creation in 2000 to end of new
    development will be 19 years.Fortran 66 was around for 11
    years, replaced by Fortran 77 and then Fortran 90, 95, 2003,
    and 2008. I think those dates are what the OP is looking
    for.C89 to C99 was 10 years. Then C11 12 years later.COBOL 61
    was followed by 65, 68, 74, 85, and then the poorly supported
    2002 followed by 2014.I think a better contender is MUMPS, made
    an ANSI standard in 1995 and ISO standard in 1999. It's still
    in use in healthcare and financial applications.
    https://en.wikipedia.org/wiki/MUMPSAnother contender is Rexx,
    ANSI X3.274 / 1996.Both Rexx and MUMPS are ranked in the range
    50-100 on TIOBE.Then there's FORTH, with FORTH-79, FORTH-83
    (both de facto) and then ANS Forth in 1994. But that might be
    cheating as I think (based on hearsay) most Forth users
    specialize their implementations rather follow ANS Forth.Those
    are still in reasonably wide-spread use. I think something like
    ALGOL, last revised in 1973, is outside of what the OP was
    thinking about.
 
rectangletangle - 17 minutes ago
This is great news. I've been working with Python 3 for a few years
now, and it really is a nicer language than 2. Granted 2.7 is a
hard act to follow.Even though the transition from 2 to 3 has been
slow, I take it as a positive sign about the Python ecosystem. The
general Python community has traditionally erred toward stability,
and conservative feature introduction. The gradual introduction of
large changes to the core language reflects that
characteristic.Hopefully this will cajole Python 2.7 users to
migrate. Assuming you have decent test coverage, the migration
generally isn't that difficult.If you do a lot of NLP or string
processing, the sane unicode support is worth it alone.
 
fredley - 1 hours ago
Good. The glacial migration from Python 2 to 3 is one of the worst
things about an otherwise fantastic ecosystem. The tide is turning
though, with Django having already dropped support for 2, and now
with Numpy too hopefully Python 2 can be properly consigned to the
history books.For people wondering why it's been like this for
almost a decade(!) since Python 3.0 was released: Python 3.0 was
actually terrible. It lacked many critical things, and was riddled
with bugs and security flaws until 3.3, which was released 4 years
after 3.0. This cemented in many people's minds the idea that
Python 3 was a bad thing. Python 2 was and is a fantastic
programming language, so it was a very high bar to move up from.
Python 3 has come a long way since then, Python 3.6 is now a decent
step up from 2.7.
 
  wybiral - 1 hours ago
  Yeah, for the longest time everyone kept using library support as
  an excuse for sticking with 2. But at this point I think it's the
  exception that a decent Python library doesn't support 3, rather
  than the rule.The only one that comes to mind for me is fabric,
  to be honest.
 
    ihuman - 1 hours ago
    > But at this point I think it's the exception that a decent
    Python library doesn't support 3, rather than the rule.Right
    now 187 of the top 200 packages on Pypi support Python 3.
    https://python3wos.appspot.com/
 
      takluyver - 9 minutes ago
      Infrastructure changes to PyPI made it hard to work out what
      the top packages are. http://py3readiness.org/ is another
      effort, which currently lists 345/360 packages as Python 3
      compatible.
 
      fredley - 1 hours ago
      And of the 13 not migrated, 9 are Mozilla packages, so
      they're probably just waiting to write them all in Rust...
 
        j605 - 1 hours ago
        Those are internal tools at best so it won't matter that
        much for migration.
 
          reificator - 31 minutes ago
          That list is of the top packages.  If internal Mozilla
          tools are downloaded enough to become top 200, then
          either Mozilla is larger than I thought or Python is
          smaller than I thought.
 
          derefr - 40 minutes ago
          Why are internal tools showing up in the top 200 PyPI
          package list?
 
    smnrchrds - 1 hours ago
    Twisted port is a work in progress.
 
      wybiral - 58 minutes ago
      Ah, forgot about twisted. The new asyncio stuff probably
      changes a lot for how something like that could be
      implemented.
 
    Bedon292 - 23 minutes ago
    I have always been interested in that cycle. We use 2 because
    NumPy supports it still. NumPy supports it because we use it.
    If a major library had dropped support earlier on, I am curious
    what would have happened.
 
      wybiral - 20 minutes ago
      I bet the same dynamic happened with Linux distributions
      including Python 2 as the default as well. Double whammy.
 
    projectramo - 43 minutes ago
    Yes, but during the long migration, it was no mere
    excuse.Almost every time I tried to use a library, it was 2.7
    only.That situation has only changed recently, and with it
    people have moved on to 3. (Which sort of underscores that the
    library support was the main issue).
 
    jihadjihad - 42 minutes ago
    > The only one that comes to mind for me is fabricSpeaking of
    Fabric, does anyone know of any Python 3 projects similar to
    it? I've been using Fabric3 since the switch but it's not a 1:1
    port. I'd consider dropping it in favor of something better if
    it exists.
 
      ghostwriter - 38 minutes ago
      - http://www.pyinvoke.org/ - http://click.pocoo.org/
 
      wybiral - 29 minutes ago
      The Fabric dev(s) seem to be developing a v2 branch with
      Python 3 support: https://github.com/fabric/fabric/tree/v2But
      I'm not sure how far along it is yet.
 
  Figs - 36 minutes ago
  Frankly, I still haven't seen a single reason to switch to
  Python3 beyond the fact that the original authors have gotten
  bored of providing security and bugfix updates and will stop in
  2020. That's it.The only thing in the last decade or so of
  Python3's existence that even got me slightly interested in using
  it was asyncio, and after looking into it a bit, it frankly seems
  like more trouble than its worth.I know Python 2.7 extremely
  well. It works perfectly fine for just about everything I use it
  for. It's STABLE. For the tasks I use it for, it runs faster than
  Python3... (Not that performance is my greatest concern when
  using Python.) So, please tell me -- why on earth is it a good
  thing that people are trying to kill off Python2? What exactly
  makes Python 3.6 a "decent step up" from 2.7? I'm still at the
  point of thinking, as you said, that Python3 is a bad thing.
 
    takluyver - 14 minutes ago
    For anything non-trivial, 95% of the value is in the library
    ecosystem. So long as most prominent libraries kept releasing
    new features for Python 2 and 3, there's inevitably not a big
    pull factor to upgrade. That's changing as a number of major
    libraries start to make releases that require Python 3.From a
    library maintainer POV, I do want to use Python 3. There's no
    one killer feature, but rather a bunch of small ones, like more
    specific exception classes (FileNotFoundError etc.).But if you
    want to keep using Python 2.7, no-one will take it away from
    you.
 
    nas - 12 minutes ago
    > Frankly, I still haven't seen a single reason to switch to
    Python3 beyond the fact that the original authors have gotten
    bored of providing security and bugfix updates and will stop in
    2020. That's it.It seems pretty clear now that 3rd party
    library developers are going to stop releasing packages that
    support 2.x and target only 3.x.  Isn't that a bigger problem
    for Python 2.7 hold outs?Originally, I was not super excited
    about Python 3.  I liked "print" as a keyword.  I liked the
    space efficiency and speed of latin-1 strings by default.  I
    did a lot of network protocol stuff and bytes() was a pain to
    use.  I knew how to use the 'u' prefix to get unicode when I
    needed.  However, after using Python 3 for a few years now, I
    find Python 2 clumsy.  Print as a function is better.  Unicode
    works better.  The implementation is just as fast or faster
    than Python 2 and getting faster every release.  If you tried
    Python 3 a few releases ago, you should give it another go.  It
    has matured a lot.
 
    PunchTornado - 11 minutes ago
    Because python3 is the new version.
 
    [deleted]
 
    brians - 30 minutes ago
    The change to string handling justifies it for me. Writing
    `u?foo?` everywhere is a pain, and the rest of the 2.7 model is
    extraordinarily prone to runtime errors. With 3.6, I don?t have
    those problems.
 
      pc2g4d - 20 minutes ago
      Yeah, I was pretty much sold on Python 3 when I stopped
      having to use the `codecs` module to read my files and when
      it would strictly enforce the separation between `bytes` and
      `str`, rather than having to manually track what sort of
      sequence I was dealing with.
 
      fredley - 18 minutes ago
      Yes, and while performance on some tasks has gotten worse, on
      others it has got much better - JSON serialisation in
      particular, which was huge for us. Python 3.7 will be faster
      again in many areas.
 
    xapata - 28 minutes ago
    Until you've used them for a while, you won't believe how
    pleasant f-strings are. It's worth the upgrade.
 
    SatvikBeri - 18 minutes ago
    Optional type annotations did it for me - I don't usually use
    them, but I find them very helpful on a few types of tasks.
 
  oconnor663 - 8 minutes ago
  I think there were also more compatibility issues prior to 3.3
  (when they started allowing u"") for libraries that did want to
  support both. It seems like the core team predicted that the most
  popular migration path for libraries would be `2to3` or something
  like that, when in fact the single-codebase-supporting-both
  strategy has been much more popular? Probably the transition
  would've been easier if everyone had seen that coming.
 
    nas - 3 minutes ago
    That's correct.  If something like "six" would have been
    provided as part of 3.0, things would have went more smoothly.
    There could have been some language changes in 3.0 to make
    single-codebase easier.  It was only later that the core
    developers realised that would be the normal way for libraries
    to support Python 3 (e.g allowing u prefix on strings in 3.x).
    Quite a bit of time was wasted while this got sorted out.
    Things are a lot better now.  Soon, I think most people will
    stop worrying about 2.x backwards compatibility.
 
  timsayshey - 28 minutes ago
  If this is the case then wouldn't re-naming it Python 4 shake the
  negative view of it? Guess it's too late now for Python but I've
  seen it done in other open source projects and it worked pretty
  well.
 
    lghh - 17 minutes ago
    "Python 4?? People have not even migrated to Python 3 yet!"
 
    llukas - 15 minutes ago
    Python 3.4+ doesn't have negative view.
 
  bunderbunder - 15 minutes ago
  Wild speculation (I'm relatively new to Python), it might also
  have to do with the Python community having several
  personalities.Python 3 solves a lot of problems for me, as
  someone who does a lot of NLP work, and generally has to deal
  with strings from the outside world and multiple languages and
  all that on a more-or-less constant basis. I imagine it solves
  some problems for Web developers, too, though possibly to a
  lesser extent. But I don't see a whole lot of devops people being
  eager to jump off of Python 2, and I'm not sure I see it solving
  more annoyances in that domain than the process of migrating to
  Python 3 would create, either.