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.
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).
> 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.
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.