Il Wed, 07 Mar 2007 14:13:28 -0300, Gabriel Genellina ha scritto:
> __iadd__, in general, is not *required* to modify the instance in place
> (but should try to do that, if possible). After this code:
> b = a
> a += c
> you can't assert than a and b both refer to the *same* object, as before.
> If you need that, don't use += at all. (For a generic object, I mean. The
> built-in list "does the right thing", of course)
Surely _I_ can't, and _I_ won't. But take the opposite example.
Let's say I'm using an external library, and that library's author provides
any kind of 'convenience' container type he feels useful for the library's
purposes, but without forcing a type constraint to the parameters passed to
a certain function - as should be done in a language like python, and 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).
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.
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?
--
Alan Franzoni <[EMAIL PROTECTED]>
-
Togli .xyz dalla mia email per contattarmi.
Remove .xyz from my address in order to contact me.
-
GPG Key Fingerprint (Key ID = FE068F3E):
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
--
http://mail.python.org/mailman/listinfo/python-list
