Booleans, integer division, backwards compatibility; where is Python going?

[Alex Martelli]

Thomas Bellman wrote:

> Alex Martelli <aleax at aleax.it> wrote:
> 
>> Once you're using (e.g.) iterators in your package, or subclassing
>> a standard class, there's no extra cost in having the modules of
>> your package use (e.g.) generators or true-division as well, so
>> why shouldn't a package author freely do so?
> 
> For the specific case of iterators, it is fairly easy to add a
> backwards compatible interface to your classes, so they work even
> in an older interpreter:
        ...
> Then just let your classes inherit from IteratorEmulator.  This,
> of course, assumes that you don't need __getitem__() for other

Too big an assumption, IMHO - it rules out all those of your
classes which are mappings (maybe half of your containers).

And that's not all -- you may be USING iterators quite apart
from EXPOSING iterators for your classes.  "for x in adict:"
is faster as well as smoother than "for x in adict.keys():".

That's one more backwards-compatibility kludge you'd need to
build -- e.g. your own iter function when there's no builtin
one.  Oh, and, your own dict class when there's no builtin 
dict type -- can't just use UserDict if anywhere you are
calling dict with a sequence of pairs (not strictly speaking
an iterator issue, but close).

> purposes, or that you are returning infinite sequences.
> 
> Generators, inheriting from builtin types, and true division, are
> not as easy to get running in an older interpreter, so if you are
> using one of *them*, you might as well use iterators too.

Wrapping all of your meant-to-be-true divisions into your own
function truediv(a,b) is no klunkier than wrapping all of
your iterations-over-dictionaries into iter(somedict) (with
your own implementation of iter if it ain't builtin).   Both
are clunky aplenty.  Depending on what builtin type you are
inheriting from, that may be easier (UserDict in lieu of
dict, for example -- that's pretty easy to arrange in some
backwards-compatibility preable) or hardish (defining file as
an inheritable class that autodelegates to a file object) --
in either case arranging to pass your objects to the Python
framework can be a real problem (some pieces want true file
object, true dictionaries, and the like -- admittedly even
in 2.2 some internal uses bypass your method overrides and
do the equivalent of dict.__getitem__(theobj, thekey) and
so on:-).


Alex