Python Source Code Beautifier

[Gabriel Genellina]

En Thu, 08 Mar 2007 13:13:23 -0300, Alan Franzoni  
<alan.franzoni_invalid at geemail.invalid> escribió:

> this
> container does create a copy of the object even employing incremental
> operators.
>
> Now, let's suppose I find that container type not useful for my purposes,
> *or* I have already written a different container type which mimicks a
> list's behaviour (adding some kind of functionality, of course).

If the library relies on that behavior, it should be documented as such.  
If you provide an alternative container that does not respect that  
interfase, it's your fault. It it was not documented, it's theirs.

> Now, let's suppose a certain function in that library should give a  
> certain
> result based on the contents of that container, but without modifying the
> original object, but it needs to modify it in order to do some  
> operations.
>
> if the function looks like this:
>
> def foo(container):
> 	container += [1, 2, 3]
> 	...
>
> it might happen that the original object gets modified even when it
> shouldn't, depending on the actual object passed to the library.

And that would be bad coding style in the library. += is an augmented  
assignment, *can* be carried in place, or not. If they want a different  
value for the container, why not just write:

extended_container = container + [1,2,3]

You can't write bulletproof code, but some constructs are safer than  
others.

> What I just mean... I don't see calling extend() to be that painful in
> respect to += . If there were no other way to do it, I would agree it  
> would
> be useful. But if there're such methods, do we really need this syntactic
> sugar to introduce confusion?

Feel free to write a PEP suggesting removal of += and *= from lists.
http://www.python.org/dev/peps/

-- 
Gabriel Genellina