[GTALUG] Python 2 vs python 3 debate

Anthony de Boer adb at adb.ca
Tue Dec 16 22:28:39 UTC 2014


D. Hugh Redelmeier wrote:
> I'm not much of a Python user.  I'm certainly not too aware of things
> in its ecosystem.
> 
> I think that it is good that language powers-that-be consider
> incompatible updates.  Otherwise mistakes are with us forever.  They
> should be infrequent and probably batched.
> 
> It helps a lot if the incompatibility can be mechanically cleansed.
> Second best: mechanically detected statically.  Third best:
> mechanically detected dynamically.  Horrible: just behaving different
> at runtime.
> 
> At some point, the community has to go cold turkey.  No new work on
> libraries etc. for the old thing.  It's like taking off a bandaid: net
> pain is less if the transition is quick.  Of course some kind of
> synchronization would be useful.  What better use of a BDFL.

If you've got reams of mission-critical legacy code written in the
previous version of a language, whether FORTRAN IV or original K&R C or
Perl 4 or whatever other deprecated tongue was spoken by the coders of
yore, a new system that's going to not run that code or misreinterpret it
in interestingly broken ways is _NOT_ going to be your friend (or be of
any immediate practical use in production).

You do need room to introduce new languages, or improved dialects of
existing ones, but there does need to be a way for the versions to
coexist, so your Perl 4, 5, and 6 code each go to their own interpreter,
or GCC can be flagged to parse according to a particular C standard,
and all your old code keeps on happily working.  You cannot go and
rewrite or mechanically-recode or even recompile everything on some
flag day and have perfectly-refactored new code running bug-free by
sunset.

And if some language's BFDL and TPTB decide that the new version is going
to break old code and not support compatibility, the wise coder having to
refactor that codebase goes to a different language entirely because that
bunch are likely to break everything again next time they have a better
idea, and the time after that too.

There is room for code-refactoring projects, if new features make the
code more maintainable (as if! See also: "technical debt" and having to
QA everything again), but they have to run on the downstream timeline and
not be dictated by upstream releasing their whizzy new compiler.

Ideally there's some legacy maintenance on libraries and such, but
there are advantages to a *stable* language where someone isn't
going to tweak the meaning or precedence of something or add a new
reserved keyword or whatever else might change the meaning of some
million-line system that someone doesn't want to refactor.

> How long did C keep "int" is the default type if you neglect to
> mention a type in a declaration?  This should have been a compile-time
> diagnosed error decades ago.
> 
> How long did FORTRAN allow undeclared variables?

A compiler running in default mode can't ever reject something that was
once a valid program, but undefined variables IMHO were always something
that dismerited a warning; maybe declaring the code to be pre-good-taste
could silence the warnings, while a later language revision requiring
proper declarations could make that an error if that mode is declared.

> I don't understand what's so hard about the Python 2 => 3 transition.
> Is it too big a step?  Are there not enough attractions?  Is the first 
> step a lulu[1]?

I've done a wee bit of Python, but not tracking it too closely.  There
are too many languages!

I miss the days when knowing C, shell, and awk would cover all you needed
for Unix utilities.  It seems that nowadays, diving into the source of
some random Linux package that needs something checked or tweaked, every
other time one finds that yet another different language was used; it's
the Tower Of Babel story all over, or if not that then the coding style
is something, ahhh, *unique*.

It's good that language-design research is still happening, and new
languages are getting road-tested, but there's just not the mindspace
for any of us to simultanously master them all, and by the time you
try there will be another three or so to learn.  I'm almost cheering for
evolutionary pressure to cross a few of them off the list!

[1] legacy footnote not supported in this message.

-- 
Anthony de Boer


More information about the talk mailing list