Python Source Code Beautifier

[Alan Franzoni]

Re: Python Source Code Beautifier

Il Tue, 06 Mar 2007 01:55:54 -0300, Gabriel Genellina ha scritto:

The problem is that other people -not necesarily "smarter and more
experienced" than you- may use those features, and perhaps you have to
read, understand and modify some code written by someone else.
So, you should at least know what "a += b" means, even if you are not
going to use it.

That's sure, and I'm in fact glad to know that by now. I still think it's
risky, BTW. Python is dynamically typed, after all, and there's no 'a
priori' way to know if 'a' is a list or another type, especially another
container type.

If we rely on duck typing, by the way, we may encounter two types quacking
like ducks, flying like ducks, but in fact acting as slightly different
ducks. I should remember as well, when designing a container type that I
want to use in place of a list, to carefully craft an __iadd__ method which
works just like the a list's own __iadd__ method; if I forget, I may
introduce a subtle error.


--
Alan Franzoni <alan.franzoni. xyz@gmail.com>
-
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

[Gabriel Genellina]

Re: Python Source Code Beautifier

En Wed, 07 Mar 2007 10:29:29 -0300, Alan Franzoni
<alan.franzoni_ invalid@geemail .invalidescribi ó:

Il Tue, 06 Mar 2007 01:55:54 -0300, Gabriel Genellina ha scritto:

If we rely on duck typing, by the way, we may encounter two types
quacking
like ducks, flying like ducks, but in fact acting as slightly different
ducks. I should remember as well, when designing a container type that I
want to use in place of a list, to carefully craft an __iadd__ method
which
works just like the a list's own __iadd__ method; if I forget, I may
introduce a subtle error.

I'm not sure of your concerns. If you want to provide your own container
that mimics a list, there are a lot more things to consider than __iadd__
(See the UserList class or this ListMixin recipe:
http://aspn.activestate.com/ASPN/Coo...Recipe/440656).

__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)

--
Gabriel Genellina

[Alan Franzoni]

Re: Python Source Code Beautifier

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 <alan.franzoni. xyz@gmail.com>
-
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

[Gabriel Genellina]

Re: Python Source Code Beautifier

En Thu, 08 Mar 2007 13:13:23 -0300, Alan Franzoni
<alan.franzoni_ invalid@geemail .invalidescribi ó:

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_contai ner = 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