PEP 238 (revised)

Christian Tanzer tanzer at swing.co.at
Fri Jul 27 09:38:21 EDT 2001


> > Keeping old interpreters around doesn't work for my biggest worry:
> > use of old scripts with new versions of TTTech's applications. In this
> > context, TTTech ships an application containing a new interpreter to a
> > customer who might still have old scripts around. These scripts might
> > come from a third party and be totally opaque to the customer itself
> > (e.g., a script to import from a tool of company XYZ into TTTech's
> > TTPplan). 
> 
> Well, I hope that making the change Python 3.0 does the right thing
> for you.  It shouldn't be hard to alert your customers that Python 2
> is required for your company's applications.  Like Perl 4 and Perl 5,
> Python 2 and Python 3 will probably live alongside for many years.

Well, I'd prefer not to get stuck with Python 2.0 forever. Unlike many
I usually enjoy the new features you add to the language :-)

> > I agree that exact emulation of old versions doesn't make sense. What
> > I would propose is to enable Python somehow to identify old code
> > (e.g., by absence of a version specifier) and let it raise an
> > exception when `/` is applied to two integer arguments by old code.
> > This would avoid both permanent warts and silent breakage of old code.
> 
> Requiring a version specifier in all new code is very annoying.  The
> future statement is annyoing too, but at least it's a transitional
> measure.

I agree and that's the reason I didn't want to propose any concrete
way of tagging new stuff. But I was hoping that maybe someone comes up
with a cleaver idea how mark new code in a non-intrusive and thus
non-annoying way.

Someone proposed a change in file extension. Too bad, that this
doesn't cover all cases (like my user scripts which are fed to
execfile).

> I agree that if we really need to have a way to explicitly request
> past behavior, "from __past__ import ..." is a decent syntax.  I just
> noticed that PEP 236 (the __future__ PEP) mentions this as an
> possibility (although the author claims it is unlikely).

Explicitly marking the past won't work for my case. If a file is
touched anyway, it should be fixed properly. I'm worried about the
files out of reach.

> I just looked it up at dictionary.com, and the meaning of quotient is
> just the result of a division.  One source even mentions that the
> quotient is rational if the operands are.

My Langenscheidt English/Geman dictionary just gives quotient <-->
Quotient.

But my Webster's New Encyclopedic Dictionary tells me:

    quotient: the number resulting from the division of one number by
    another [Latin quotiens `how many times`, from quot `how many`]

If they had only written integer in place of number! OTOH, one learns
in school that (integer) division gives a quotient and a remainder. So
I think quotient is still better than `floor division`. How many
newbies are going to know the meaning of floor?

-- 
Christian Tanzer                                         tanzer at swing.co.at
Glasauergasse 32                                       Tel: +43 1 876 62 36
A-1130 Vienna, Austria                                 Fax: +43 1 877 66 92





More information about the Python-list mailing list