GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-07-27) - page 1 of 10
 
___________________________________________________________________
Porting a historic Python2 module to Python3
96 points by luch
http://lucasg.github.io/2017/07/21/Porting-an-historic-Python2-m...
___________________________________________________________________
 
_eht - 2 hours ago
Maybe this is an unpopular opinion coming from someone new to
Python (2 years) but the way this versioning was done is definitely
a pain point.  Working with new code and looking up docs to achieve
X, working with existing code and trying to apply the same
solution. God it's annoying.Having said that, I know the decisions
were not made lightly, and were backed by logical analysis. If
nothing else, it's a good case study for the evolution of future
languages (looking at you golang 2.0).
 
opportune - 5 hours ago
I once spent a week porting some python2 researchware into python3.
It was only at the end of that week that I discovered that it was
the actual logic of the researchware that was broken, and not the
way I was porting it. I now distrust all FOSS except for widely
used and tested ones. You would think that a graduate student would
debug (or at least fix to the point of being interpretable) the
work that they spent months on before publishing it as finished and
adding it to pip.And yes, 2to3 fixes 90% of porting problems. But
in my experience, it was especially bad at handling, of all things,
import statements. Definitely not a silver bullet.
 
  ofek - 4 hours ago
  I'd be weary to conflate OSS with what you refer to as
  "researchware". Code coming from academia is notorious for poor
  reproducibility.
 
    opportune - 4 hours ago
    I'm not conflating them, but clearly software can be both
    researchware and open source. I'm not going to start
    distrusting tensorflow or scikit-learn, but I'm going to be
    wary before I invest time in a promising niche software
    package, regardless of whether it was actually from academia or
    not.
 
  sevensor - 4 hours ago
  You have a remarkably rosy view of grad students and their
  relationship to software.  All it has to do is produce output (I
  hesitate to say work) one time, on one computer, under some
  conditions that may never be documented, let alone reproduced.
  This is doubly true if the code just a step in the analysis chain
  and not the actual subject of the research.
 
    opportune - 4 hours ago
    In this case, the software itself was the focus of the
    research. And this grad student still works at a very
    prestigious university for CS.I've worked in academia (as a
    research assistant) before so I'm familiar with shitty grad
    student software. But going to the effort to document and
    present on the software without making sure it even worked?
    That seemed excessively stupid to me.
 
      sevensor - 4 hours ago
      That's dismaying -- not at all surprising, unfortunately, but
      I understand your frustration.  The upside-down incentives in
      the academic world are such that even somebody who ought to
      know better fails to produce useable software because there's
      no payoff.  Actually, it's worse than that -- producing
      software other people can use means you might be giving a leg
      up to the competition, so there's an incetive to produce
      software that appears to work but is in fact useless.
 
  hprotagonist - 4 hours ago
  You would think that a graduate student would debug (or at least
  fix to the point of being interpretable) the work that they spent
  months on before publishing it as finished and adding it to
  pip.HA ha ha ha ha. No. Not even a little.There are a bunch of
  reasons for this, but the big ones are:  1. Scientists aren't
  developers (some of us are exceptions, but we prove the rule). 2.
  The objective function of a grad student is "publish and
  graduate" not "write good code and use it forever".
 
keenerd - 6 hours ago
I've been doing this for ten years.  Why wouldn't you use 2to3?  In
my experience, 2to3 is all you need 95% of the time.  It is really
that good.The only times it doesn't work is with python that is bad
to an unusual degree.  For example, if you make a variable named
"list", overriding the built-in list type.  2to3 freaks right out.
The other type of "bad" python is stuff that abuses the "open
kimono" nature of the language and heavily monkeypatches python
internals.  Or things that depend on version specific binary data,
like pickle files.
 
  [deleted]
 
  jwilk - 5 hours ago
  > 2to3 is all you need 95% of the timeThis is absolutely not the
  case in my experience.2to3 tends to produce something that
  appears to work at first glance, but it actually doesn't.
 
    svara - 2 hours ago
    I agree, although different people's experience may differ
    simply because they were or were not using certain language
    features often.What bites me all the time is the division
    operator. The 2to3 code will run, but produce incorrect
    results. String / byte handling is an obvious other one.
 
    jxramos - 5 hours ago
    2to3 gets all the good low hanging fruit syntatic fixes I've
    found, but it really comes down to the str/bytes divergence and
    how mucked up the mixing was in the py2 code. His comment here
    is the clinch... "pdbparse is among the worst offendants I?ve
    seen since, as any parsing library, it will happily handle and
    transform bytes-like data as string."
 
    acdha - 5 hours ago
    This has not been accurate at all in my experience. It really
    came down to whether the code had supported non-ASCII text
    before ? if there's a huge amount of bytes/str conflation, it's
    a mess but if it followed good Python 2 practice it's been very
    close to convert and run.
 
    _paulc - 2 hours ago
    This lines up with my experience. Strangely I had someone
    submit a bunch of slightly passive-aggressive "Py3 support"
    pull requests to a couple of my repos which were basically the
    result of running 2to3 on the code. They hadn't even bothered
    to run the unit tests (which obviously failed spectacularly).
    It did however prompt me to get Py3 support working properly
    which was actually a good thing.
 
    aaossa - 5 hours ago
    You have any examples? I was planning to use 2to3 in a project,
    can you explain in which case it doesn't work? Thanks!
 
      masklinn - 4 hours ago
      First, I'd recommend python-future rather than 2to3, it has
      additional fixers and replaces some with better
      versions.Second, those only do the fairly straightforward
      changes, fixers are simple AST transformations they don't do
      complex type analysis or anything, you should use them as a
      starting point but don't expect the work to be over by then:
      the 2->3 transitions has a number of API and semantics
      changes which these tools can't handle, text model changes
      are the biggest one[0] but they're not the only one by far.If
      the project is non-trivial, having a good test coverage is
      absolutely crucial.Basically, 2to3 handles the first 90% of
      the work which are mostly drudgery and syntactic fixes,
      you're still on the hook for the second 90% which is more
      subtle.Source: finalising the conversion of a ~200k SLOC
      codebase to cross-version compatibility.[0] not just the
      strict separation of text and bytes, but APIs being set to
      one or the other so you have places where you want to ensure
      bytes, others where you want to ensure text and yet others
      where you need "native strings", some APIs (csv) are also
      incompatibly altered.
 
      tedunangst - 1 hours ago
      Lots of people mention strings, but for a concreteish
      example: you have some code which reads bytes from the
      network, say "cookie", and uses that as a key into a dict.
      Later you try to access the stored value with
      headers["cookie"].This works in python 2. It silently fails
      in python 3 because b"cookie" and "cookie" are different
      keys. Not really related to whether the original code
      supported Unicode or not.
 
  alexchamberlain - 4 hours ago
  I thought 2to3 was designed for converting apps from 2 to 3,
  rather than making them polyglot? I think six could have
  simplified things here, however.
 
    dwringer - 1 hours ago
    Six is definitely excellent for supporting both 2 and 3, but
    all the issues from the article and in these comments still
    persist.  They're just a little bit easier to clean up.
 
    keenerd - 3 hours ago
    You can't make something truly polyglot across all of 2.X and
    all of 3.X.  However much of py3 syntax is supported by py2.
    As far as I know, 2to3 doesn't produce py3-only syntax.  I diff
    the original and the converted code, merging the non-compatible
    parts into a version check.
 
      masklinn - 3 hours ago
      > You can't make something truly polyglot across all of 2.X
      and all of 3.X.There's little reason to though, generally you
      want 2.7 and >=3.x (the simplest is 3.5, 3.4 is fairly easy,
      3.3 is possible but starts being more annoying)> As far as I
      know, 2to3 doesn't produce py3-only syntax.It does: print
      function, metaclass kwarg. It will also generate
      syntactically valid but P2-incompatible code (with_traceback
      calls) as well as possibly semantically break P2 code (rename
      __nonzero__ to __bool__, basestring and unicode to str,
      stdlib changes, raw_input to input, ?)
 
        keenerd - 2 hours ago
        Print() is valid in Python2.  It will print a tuple under
        some conditions, but that is still syntactically valid and
        a graceful degradation.  (Print is for humans to read.  As
        long as a human can understand it, good enough.  Going for
        full identical behavior costs extra :-)  Valid-but-
        incompatible is fine for polyglot stuff.  Merge the files
        and put in a version test around those parts.
 
breatheoften - 2 hours ago
How about a type checked python variant ala typescript that
compiles to python2 or python3?Do: introduce and require the
compile step for awhile, flesh out the language and build it up,
get by-in and an ecosystem while also leveraging compatibility with
python2/3 ecosystems -- then eventually release a python4 that runs
this new typed python language directly!Bring us the beauty!
 
carapace - 3 hours ago
Oh dear God why do you hate my eyes.  Tiny sans-serif gray body
text is of the Devil and should be grounds for irate and
overbearing truculent curmudgeons to whine about on online forums.
 
yegle - 6 hours ago
There's a patch from pytype that backported the type annotation
syntax from python3 to python27:
https://github.com/google/pytype/blob/master/pytype/patches/...
 
  jnwatson - 3 hours ago
  That requires everybody that uses my module to use a patched
  interpreter.  Type comments work fine.Also, that doesn't help
  those of us stuck on Python 3.4, the last version that supports
  Windows XP (don't ask).
 
  sametmax - 5 hours ago
  You don't really need it, Python 2.7 can already use type
  comments.
 
    luch - 3 hours ago
    (author here) by type comments your mean this :
    https://www.python.org/dev/peps/pep-0484/#type-comments ?I
    haven't seen them used anywhere, but that's an okay solution I
    guess.NB : by the way, love your blog :p
 
      carapace - 3 hours ago
      I was experimenting with them a little while ago, along with
      MyPy [1] but I immediately ran into an issue where the type
      system couldn't describe the type I was using, so I had to
      let it go (reluctantly.)[1] http://mypy-lang.org/
 
jwilk - 5 hours ago
https://github.com/Microsoft/microsoft-pdb/pull/27 is labelled cla-
not-required, so it's probably not the best example for   "need to
sign NDA/CLA for sending PR".But some other projects are so
hardcore about CLA enforcement, they won't even accept one-letter
typo-fixes without CLA signed.
 
echion - 3 hours ago
> I?m kinda bummed out that Python devs decided not to backport
Python type hints in Python2.7.Can't comment on the site itself,
so: PEP 484 - Type hints ( https://www.python.org/dev/peps/pep-0484
/#suggested-syntax-f... ) does suggest Python 2.7-compatible type
hints, and PyCharm, and probably other IDEs, do support them (e.g.,
https://www.jetbrains.com/help/pycharm/type-hinting-in-pycha... ).
 
jxramos - 5 hours ago
I really like the suggestion about focusing on PR for PR, that is
pull request public relations. PR diplomacy, very sound advice.
 
radarsat1 - 3 hours ago
In almost every Python-related project I work on, we're developing
in an exciting new language called "Python 2-compatible Python 3
subset".  Twice as must testing, twice as much fun!
 
  crncosta - 3 hours ago
  Yes, this is exactly the issue. Porting to Python 3 was never an
  issue itself, but keep your code compatible with Python 2 (while
  introduce 3) is a nightmare :P
 
  skykooler - 3 hours ago
  I've been working on one project that needs to work in every
  Python verson from 2.4 to 3.3. There are some pretty fun
  gymnastics getting some syntax to work.
 
  metafunctor - 1 hours ago
  Are all these projects some sort of libraries?  Is that why you
  need to support both Python 2 and Python 3?All the projects I've
  worked on moved to Python 3 and never looked back.
 
timcosgrove - 6 hours ago
(100% OT of linked article: "a historic", not "an historic", unless
you pronounce the word
"istoric".)https://en.oxforddictionaries.com/usage/a-historic-
event-or-...
 
  jwilk - 5 hours ago
  Shameless plug: I wrote a spellchecker that finds this kind of
  errors:https://github.com/jwilk/anorack
 
    disconnected - 5 hours ago
    $ echo "Porting an historic Python2 module into Python3" >
    test_file$ ./anorack test_file$ out:1: an historic -> a
    historic /hIst'0rIk/Interesting. What if...$ ...hacks
    phonetics.py to use "en-us" voice...$ ./anorack test_file$
    out:1: an historic -> a historic /hIst'0rIk/Hum... same result.
    What about:$ ...hacks phonetics.py to use "en-wm" voice...$
    ./anorack test_file$Ah, finally someone gets it right :)(just
    having a bit of fun, this is a cool work!)Edit: formatting...
 
      billforsternz - 2 hours ago
      Sorry for my ignorance, what is en-wm ?
 
        jwilk - 2 hours ago
        English as spoken in West MidlandsNo need to feel ignorant;
        it's a nonstandard, eSpeak-specific notation.
 
  nerdponx - 5 hours ago
  "An historic" is not only still acceptable in the USA, but it
  also (IMO) sounds better. The leading "H" is not a strong-
  sounding consonant, and is often dropped in both American and
  British English.
 
    stretchwithme - 3 hours ago
    I will look that up in an history book and get back to you.
 
      greenshackle2 - 2 hours ago
      They're pronounced differently:History: /?hist(?)r?/Historic:
      /hi?st?rik/The 'h' is stressed in 'history', not in
      'historic'. Try pronouncing 'historic' with a stress on the
      first syllable, it sounds wrong. Since it's softer in
      historic it's more natural (to me anyway) to use 'an'.(Also,
      I'm french so I barely pronounce h's to begin with - so in my
      speech the stressed 'h' in history is kinda soft, and the
      unstressed h in historic is barely there.)(edited)
 
  dec0dedab0de - 5 hours ago
  Drives me nuts when people don't pronounce H
 
  fnord123 - 6 hours ago
  >unless you pronounce the word "istoric"Which we do (in Britain
  and the rest of the English speaking world outside North
  America), so "an historic" it is.e.g. from
  BBC:http://www.bbc.co.uk/programmes/p055vr37
 
    craigds - 3 hours ago
    In NZ we definitely pronounce it "historic". But that doesn't
    stop the news anchors from saying "an historic". It sounds
    ridiculous
 
    [deleted]
 
    msla - 5 hours ago
    Just keep in mind the fact that English is a polycentric
    language means your customs are no more or less correct than
    any other.
 
  stretchwithme - 3 hours ago
  There's an history of ignoring the pronunciation of other words
  that start with the exact same sound.
 
jcolella - 6 hours ago
Great article, specially with the sections on coverage on testing.
Also, specifying the process so another can easily reproduce it.
Very nice!
 
pinpeliponni - 3 hours ago
Just tell the Python 2 users frankly to go fuck themselves.
 
  carapace - 3 hours ago
  Or, y'know, don't.
 
    [deleted]
 
  njharman - 28 minutes ago
  It EOL next year, right? That is the when py2 gets to fuck right
  off.
 
  godelski - 2 hours ago
  Aren't there more 2.7 users than 3.x users? I am certain this is
  true in the scientific community. But I also thought it was true
  for the general. So telling the majority of your user base "to go
  fuck themselves" is, generally, not considered a good idea.
 
    [deleted]
 
    thephyber - 1 hours ago
    GP comment seems like a troll. There is no formula as simple as
    "always use 3 and don't bother with 2". Not all python2 modules
    have been ported to python3 and python2 modules are unlikely to
    be future-supported as long as python3.
 
  melling - 3 hours ago
  Swift is 3 years old. Most people who use it will be on the
  latest version Swift 4 within a few months. Apple won?t let
  developers stay behind.While it was unrealistic for Python to be
  that aggressive given its larger community, not forcing the issue
  created a lot of unnecessary work for the community. A benevolent
  dictator should have moved developers along faster.  Having the
  language fragmented for this long is extremely unproductive.
 
    AceJohnny2 - 2 hours ago
    > Apple won?t let developers stay behind.    $ /usr/bin/python
    -V     Python 2.7.10  (on macOS 10.12.5, release 2017-05-15)And
    no system python3. Only through Homebrew/Macports.
 
      melling - 2 hours ago
      I'm not sure I understand your point.  They have a version of
      Perl from 2013 too.Do you think that means they don't care
      about Python?  Perhaps it's not a strategic language for
      them?No one said they the provide a full Unix system or keep
      everything else up to date.  Apple has a very narrow focus on
      what's important to them.
 
    jxramos - 3 hours ago
    I like it, "development tough love", ha. I think looking back
    it becomes clearer in hindsight that it really did consume a
    lot of community energy. I'm vaguely sensing maybe some kind of
    community development bystander effect where fixing and
    upgrading is someone else's problem has kept the divide around
    longer than it needed to be.
 
    BeetleB - 2 hours ago
    Forcing the issue early on would have killed Python3. For the
    first so many years, the majority was against Python 3.
 
    gogopuppygogo - 3 hours ago
    Python 3 faced a lot of friction when it was introduced.There
    was no backwards compatibility with Python 2 and it had
    relatively little adoption.They added Python 3 features to
    Python 2 over the years to encourage adoption of Python 3 as
    the standard.  It worked.Now we just need Apple to ship Mac OS
    with Python 3 instead of 2 as the default and that'll push
    adoption for developers.
 
      mikebenfield - 2 hours ago
      > They added Python 3 features to Python 2 over the years to
      encourage adoption of Python 3 as the standard. It worked.Did
      it really? My impression was the opposite: the fact that so
      much of Python 3 became available in Python 2 made people
      feel like there was no point in moving to Python 3.
 
        viraptor - 42 minutes ago
        It worked both ways. Some new features were ported back,
        some could be ported, but explicitly weren't to encourage
        migration. On the other side, things like the "u" prefix
        got re-added to python 3 for compatibility.
 
    kbenson - 2 hours ago
    Isn't Swift compiled?  I'm not sure it's relevant to the
    specific problems faced here, unless a library written and
    compiled in earlier versions of Swift won't be usable in a
    Swift 4 project.
 
      ori_b - 2 hours ago
      That's the case. Swift is currently not abi compatible, so
      libraries compiled with one Swift version only work with that
      version.
 
        kbenson - 1 hours ago
        Ah, I see. I assume you could compile to a c compatible
        library, but they you would have to deal with marshaling
        costs where the types mismatch, correct?
 
      [deleted]
 
    weberc2 - 3 hours ago
    I don't think Apple could even get away with this if Swift were
    more than 3 years old. I suspect the relationship between
    migration pain and age is exponential.
 
      jpttsn - 1 hours ago
      In part it's age. In part, Apple get away with it because
      they forewarned developers. Swift explicitly intended a "move
      fast and break things" approach to syntax, naming etc.
 
    maxerickson - 2 hours ago
    How would they have forced the issue?
 
      concede_pluto - 1 hours ago
      They should have created an annotation or something saying
      "this file uses the python3 dialect", made python3 run all
      python2 code unmodified (the only way to not require both
      being on $PATH), and halted python2 releases except critical
      security bugs.
 
  sctb - 1 hours ago
  We detached this subthread from
  https://news.ycombinator.com/item?id=14868355 and marked it off-
  topic.
 
  gshulegaard - 3 hours ago
  Given that many popular distros still have Python 2.7 or older as
  their default, this seems unwise.
 
    concede_pluto - 2 hours ago
    Any code needs to declare all its dependencies, whether it's
    python3 or python2. If I didn't want any specific dependencies,
    I'd be targeting POSIX and writing in Bourne shell.
 
    pweissbrod - 1 hours ago
    If you mean OS distros then this is not a concern. Unless your
    python needs are very small then you shouldnt use the OS distro
    for your python apps you should be running them in independent
    virtual environment with independent versions and packages