Home Original page

Adaptation and typecasting (was Re: [Python-Dev] replacing 'global')

Alex Martelli aleaxit at yahoo.com
Wed Oct 29 02:45:36 EST 2003 
On Wednesday 29 October 2003 03:56, Greg Ewing wrote:
> "Phillip J. Eby" <pje at telecommunity.com>:
> > Given all this, I think I'm okay with saying that adapting from a
> > mutable object to an immutable interface (e.g list->tuple) is an
> > improper use of adaptation.
>
> Expecting such an adaptation to somehow make the underlying
> list unchangeable by any means would be unreasonable, I
> think. I can't see any way of enforcing that other than by
> making a copy, which goes agains the spirit of adaptation.
>
> There still might be uses for it, though, without any
> unchangeability guarantee, such as passing it to something
> that requires a tuple and not just a sequence, but not
> wanting the overhead of making a copy.

There are uses for both permanent (via copy) and temporary
freezing.  For example: checking if a list is an element of a set will
need only temporary freezing -- just enough to let the list supply
a hash value.  Adding the list to the set will need a frozen copy.

Right now, the sets.py code tries for both kinds of adaptation via
special methods -- __as_immutable__ and
__as_temporarily_immutable__ -- but that's just the usual ad
hoc approach.  If we had adaptation I'd want both of these to
go via protocol adaptation, just because that will allow adaptation
strategies to be supplied by protocol, object type AND third
parties -- practicality beats purity, i.e., even though you are
puristically right that adaptation normally shouldn't copy, I find
this one a compelling very practical use case.

Adaptation altering the object itself, as in "setting a flag in the
list to make it permanently reject any further changes", WOULD
on the other hand be a very bad thing -- one could never safely
try adaptation any longer if one had to fear such permanent
effects on the object being adapted.


Alex
More information about the Python-Dev mailing list