Language change and code breaks

[Bjorn Pettersen]

> From: Peter Hansen [mailto:peter at engcorp.com]
> 
> Bjorn Pettersen wrote:
> > 
[snip]
> > 
> > Well, I for one wrote several thousands of lines of Python 
> code in my
> > last job, and I obviously have no influence on when they're going to
> > upgrade to a newer version of Python. You can probably safely assume
> > that they're not going to put a programmer on fixing 
> programs that are
> > running without any problems. More likely they would upgrade Python,
> > realize that "a bunch" of Python scripts stopped working, and either
> > roll back the Python upgrade, rewrite them in Perl/Java, or 
> find someone
> > with enough Python skills to fix the problems. Neither 
> solution would be
> > good PR for Python...
> 
> I agree it wouldn't be good PR for Python, but presumably neither
> is having division which doesn't behave as newcomers expect.
> We're trying to choose the lesser of two evils.

Yes, we're chosing between people who currently doesn't use Python (but
might in the future), and people who have significant investments in
Python...

> Anyway, if your previous employer upgrades Python for no good
> reason and without checking the Change History where they will
> see all the warnings in BIG PRINT about how existing code might
> break and that they should run "divscan.py" to see if their code
> is safe or not, how can we protect them against themselves?

What if they change because some package they use is no longer supported
with the older version (or has a bugfix that isn't backported, etc.)? In
theory it's always possible to remain with an earlier version, but in
practice it ain't always so <wink>.

"divscan.py" would be a good idea, but since Python is a dynamic
language, all it could do would be to point out all occurrences of
division in your code. You would still have to manually examine each and
every one of them to figure out whether it needed change or not...

> I'm trying to point out that this kind of hypothetical example,
> where some group might upgrade (but not be aware of this issue
> even after lengthy publicity during the transition period) 
> even though they will not actively maintain their code, is 
> not likely, or not worth worrying about for long.

I would hardly call it hypothetical. I'm sure a lot of companies are in
this boat, and most probably don't read c.l.py (the volume is just too
great). The first warning they're probably going to get that a new
version of Python is available is when they call the developer of foo.py
with a problem and he says: "yeah, that's fixed in the latest version --
but it requires Python 2.x". Besides, a minor point change would in most
context indicate minor, source-compatible changes only.

> And that's where the contingency plans come into play: we've 
> provided adequate notice, tools, etc., and yet somebody chose 
> to ignore us and got punished.  Big deal.

Getting Python accepted in an organization as a viable alternative to
Perl requires a lot of hard work. Once you've got a foothold it seems
stupid to shoot yourself in the foot by introducing random
incompatibilities that may or may not provide better traction for
non-users (not to mention the hackish solutions to long division that
would be introduced).

I'm not against making this change per se, however, I think it should be
in the context of an overhaul of the entire numerical system, and it
definitely deserves a 3.0 labelling since that would indicate that there
are incompatible changes involved with upgrading.

-- bjorn