Hacker News Reader

Comment by matthewmc3 | Hacker News Reader

You forgot perhaps the most important one:

3. six

`six` was instrumental in repairing the Python schism by giving people a way to incrementally move their 2.7 code to Python 3, and write code that was compatible in both. The six project didn't exist at first and the path to Python 3 was too painful without it. Six solved all that by smoothing over built-in libraries with different casing between versions, incompatible core libraries, the addition of unicode strings, print changing to a function, etc, etc. Perl 5 to Perl 6 (aka Raku) never got that.

View on HN

Six was one component but not the only one. Python 2.7 also backported a number of early Python 3 features, Python 2 features were reintroduced in basically every P3 version until at least 3.5 (although after 3.3 they were pretty minor), and a lot of extensive migration guides were written (my main bible was eevee's).

In my experience, six was a relatively minor part, and you could get by with your own little compat file for just the stuff you needed, even on relatively big projects. I even found it beneficial to do so because instead of just slapping six.moves everywhere you'd have to re-evaluate some of the old decisions (e.g. at $dayjob at the time we were using all of urllib, urllib2, and requests for HTTP calls, not using six provided strong motivation to just move everything to requests). This also made for a lot less churn when removing Python 2 compatibility.

> Python 2 features were reintroduced in basically every P3 version until at least 3.5

If they had just done this from the beginning there wouldn't even have been such upgrade drama in the first place... like, as an obvious example, removing u'' syntax for unicode strings immediately at 3.0 was just idiotic: if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all (a la Ruby 2's Unicode reboot, which concerned a lot of people but was a nothing-burger next to the insanity of Python 3).

Sure but importantly they did realise they had erred and course-corrected.

> if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all

Having been there and done that, nah, the text model changes alone required significant work to square up in most packages. And there were plenty of other semantics changes.

But you could have made those changes incrementally in a way that more cleanly worked across both Python 2 (which already had this split: the default type was just wrong; all of my code, for instance, worked great!... it was just super awkward, as it had tons of u's thrown all over the place). Where they ended up with the language (after, like, 3.7) was much more incremental from Python 2 than the early path to how they got there. To be explicit: it isn't about having to put in upgrade effort, it is about upgrade discontinuity.

It's very true, I feel like one of the most useful things python had was stuff like "from __future__ import print_function"

As a user, you may not appreciate six, but popular libraries like Django would've never made the jump without six.py;

I’m not talking as a user, I’m talking as a person who ported 350kLOCs of python from 2 to 3.

Django absolutely would have been ported: it was ported without six by Vinay Sajip (building on an earlier work of Martin von Löwis). In fact a limited shim layer was initially committed based on Vinay’s efforts: https://github.com/django/django/commit/5e6ded2e58597fa324c5...

The team ultimately decided to use and re-export six for the convenience of the ecosystem, not out of any sort of necessity.

six did help a lot. Didn't help with some things, though, like strings vs bytes vs bytearray.

Reply on news.ycombinator.com