Future division patch available (PEP 238)

[Paul Boddie]

Guido van Rossum <guido at python.org> wrote in message news:<cpd76qqfow.fsf at cj20424-a.reston1.va.home.com>...
> paul at boddie.net (Paul Boddie) writes:
> 
> > But over a few releases, which seem to be quite frequent these days,
> > one may find oneself with quite a collection of "legacy" programs

[...]

> I think it will be inevitable for many Pythons to come to provide a
> way to turn off the new division rules.  I am currently working on a
> command line option for this.

But a command line option isn't nearly as fine-grained as may be
demanded in this case: different modules may use different / operator
semantics. Then, some kind of directive is needed, and I can see the
"one true division operator" code authors not wanting to pollute their
code with such "vulgarity", whilst old code may not be conveniently
modified. So how do you manage this?

[...]

> > "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>
> 
> That's not a bad idea.  Maybe the race for the best division upgrade
> tool will have practical type inference as a side effect.
> Traditionally, "mostly correct" type inference has been rejected as
> too dangerous; but in a conversion tool, it would be much better than
> nothing.

Given that satisfactory Python type inference has been hanging around
unsolved for years, I think you'll need to put off this change for
quite some time. Anyway, if anyone is going to put that amount of
effort in, they might as well end up with a new language where they
decide the rules. In other words, what is the motivation for devising
a comprehensive type inference system for Python without deciding to
take such a project along a different path of development from Python
itself? (See Vyper for an example of this.)

Paul