[Python-ideas] add a list.swap() method

Terry Reedy tjreedy at udel.edu
Wed Jun 24 02:09:07 CEST 2009


Raymond Hettinger wrote:
> 
> [Kristján Valur Jónsson]
>> The idea is to speed up the swapping of list elemenst so that
>>     a.swap(b)
>> is equivalent to
>>    a[:], b[:] = b[:], a[:]
>> but without all the overhead of creating slices, assigning them and so 
>> forth.
> 
> The technique is useful and very fast.  I used something similar in 
> setobject.c
> in the set_swap_bodies() function, but it was sufficiently dangerous to
> subclass invariants that it was not exposed to the end-user.
> 
> Subclasses written as C extensions are the most in danger because a
> swap could break their internal invariants and possibly crash the code.
> Pure python list subclasses are only in danger of breaking without 
> crashing.
> 
> While Python is a consenting adults language, I think the basic objects
> like lists should be kept free of dangerous or hard-to-use constructs.
> 
> The problem with the OP's example is that it only makes sense in 
> interactions
> between a list and a list subclass that won't be broken by it.  For 
> straight
> list-to-list interactions, it is better to write "a,b = b,a" (though 
> this is
> not exactly the same thing since the identity of a and b will change,
> not just their contents).  For list subclass uses (a more advanced topic),
> some example will work and some won't (I gave two failing examples in the
> tracker discussion).  When the list subclass is a C extension written by a
> third-party, it may not be possible to know whether or not a swap
> will break invariants.  That's a killer.
> 
> There are a number of places in the language where swapping could
> be used (frozenset to set conversions for example) but the technique
> is fragile and probably should not become part of the language as
> distributed.
> 
> In the OP's use case, it is not hard to build a C extension for his 
> subclasses
> and include a swap() method there.  That is a much less fragile design 
> because
> the subclass already knows about its own internal invariants and it can
> verify that its input source is an exact list.  An OOP design principle 
> is that a
> method should be added to the class that has the most knowledge about
> all of the inputs (in this case, the C extension subclass knows more than
> general purpose lists).   A side benefit of this design (putting swap() 
> in the
> list subclass instead of standard list objects) is that this avoids
> putting dangerous optimizations in the hands of beginning users (i.e. it
> keeps the list API simple and clean).

I learned from this. This seems like an appropriate wiki topic or recipe 
for advanced extension writers.




More information about the Python-ideas mailing list