Future division patch available (PEP 238)

[Paul Boddie]

Martin von Loewis <loewis at informatik.hu-berlin.de> wrote in message news:<j48zhfgbny.fsf at informatik.hu-berlin.de>...
> 
> No, that is what the transition procedure to support the language
> change must solve. One possible procedure would be
> 
> 1. In 2.2, your algorithm continues to work unless you put some future
>    import into it.
> 
> 2. In 2.3, your algorithm continues to work, but produces a warning
>    the first time integer division is used with the '/'; you could
>    shut off the warning by either adding a future import, or using
>    '//' division.

Although this, of course, overlooks the non-trivial issues of finding
"dangerous" cases of the / operator and replacing them...

> 3. In 2.4, your algorithm will not exactly work very well.
> 
> > But the existing use of division in many applications is going to
> > suddenly work differently, leading to all kinds of strange
> > hard-to-trace bugs, and Pythons advocates are going to end up looking
> > *very* stupid indeed.
> 
> No, that won't be a sudden change.

But over a few releases, which seem to be quite frequent these days,
one may find oneself with quite a collection of "legacy" programs
which can't be guaranteed to run correctly under the most recent
releases. The typical advice in such cases is for people not to
upgrade, with the unfortunate result that certain users are likely to
find themselves stranded on increasingly neglected releases of Python;
particularly as module developers start to rely on newly introduced
features.

The result of leaving people behind in the "upgrade race" is that
Python falls into disuse. Rather than having people say...

  "Have you seen the latest Python? Upgrade now - there are loads of
   cool new features!"

...you get people saying...

  "We're not doing anything in Python any more. It was too hard to
   keep up with all the changes, and we can't get any of the
   extensions for the version we're running."

At least with the "connect" arguments furore (where the signature of
the method changed from 2 arguments to 1 tuple argument), most people
could be largely confident that they either didn't use the method in
question, or that they knew where to find the instances of the
offending method calls - even a "brute force" approach would not have
been too overwhelming for most people, I suspect.

In changing the semantics of the / operator, however, *everyone* is
made to feel insecure. And grep "/" `find . -name "*.py"` (or
whatever), unlike the suitability of such an approach in the case of
"connect", is hardly going to help. Several people are talking about
clever tools: perhaps once they are written, the authors will then
give us the type inferencing system people have been wanting for so
long. <1/2 wink>

Paul