Any comments? My draft of a new PEP.

Bruce Sass bsass at freenet.edmonton.ab.ca
Fri Aug 17 18:39:27 EDT 2001


On Fri, 17 Aug 2001, Courageous wrote:
<...re: reserving keywords...>
> >It may reduce "__future__ kludges", but __future__ can do more than
> >just tie up keywords...  I don't thing many uses of __future__ would
> >be avoided.  In a sense, it would be like trading a working time
> >machine for prescient visions.
>
> You're of course correct, but suppose that the new division semantics
> were to be implemented on the keyword "div" and that keyword had been
> reserved? I personally continue to believe (STRONGLY!) that new division
> semantics should be introduced in this way, in particular because of
> synergy with the current divmod() function.This would make it so that those
> who want even integer division semantics could get what they want while
> at the same time ensuring that all old code continues to work as it used to.

I don't disagree with you, and have given a knee-jerk like
reaction to what appears to be a series of kludges.

How about a well defined infrastructure for upgrades,
incorporating: __future__, __past__, and warnings (reserved
keywords?).

e.g., It looks like this...

version
   +0.0    +0.1    +0.2    +0.3    +0.4
   --+-------+-------+-------+-------+--
     |       |       |       |       |
     |  (1)  |  (2)  |  (3)  |  (4)  |  (5)
     |       |       |       |       |warnings disappear
     |       |       |       |
     |       |       |       |past disappears
     |       |       |
     |       |       |new feature is the default
     |       |       |future disappears
     |       |       |a past is enabled
     |       |       |warnings change
     |       |
     |       |warnings enabled
     |
     |future enabled

(1) early testing
(2) it's gonna happen
(3) can `quick fix' any bugs
(4) no more quick fix, but better than `no clue'
(5) just like the feature always existed

...is a reasonable representation of what an upgrade looks like
(well, if it had a better generalization of the scale).

Perhaps a new feature proposal should include a timeline, code common
to all/most feature upgrades can be factored out and presented as part
of the API... the dream target could be a codified timeline that gets
turned into the appropriate Python command line options, warning
messages, __magic__ stuff, ...


- Bruce






More information about the Python-list mailing list