Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

Bruno Desthuilliers bruno.42.desthuilliers at websiteburo.invalid
Thu Sep 4 08:43:49 EDT 2008


Marco Bizzarri a écrit :
> Sorry... pressed enter but really didn't want to.
> 
> As I said, let's say I have a class
> 
> class A:
>     def __init__(self):
>          self.x = None
> 
> 
> 
> Python makes the decision to allow the developers to directly access
> the attribute "x",

So do Java, if you make your attribute public (which would be a big 
error given Java's lack of support for computed attribute, but this is 
another problem).

>  so that they can directly write: "a.x = 1", or
> whatever; this has for me the unfortunate side effect that if I write,
> for example "a.y = 1", when I really wanted to write "a.x = 1" no one
> cares about it,

I assume *you* do !-)

But this is barely related to having explicit setters or not - it comes 
from the fact that the default[1] Python's object behaviour is to 
support arbitrary attribute setting.

[1] some objects don't, but this is mostly for optimization reasons.

> and I'm unable to spot this error until later.

Not sure, but IIRC tools like pylint or pychecker might be able to warn 
you about this. But anyway :

> Of course, I know that while I'm fresh, I've a good knowledge of the
> code, and anything else, I will be able to avoid such stupid errors;
> however, I'm afraid of the times when I'm tired, when I have to put my
> hands on the code of someone else, and so on.

The edit/test cycle in Python is usually fast enough so you should spot 
the problem *pretty* quickly. This is at least what I learned from 8+ 
years of python (and a couple other dynamic languages) programming...

Not to say that problems like the one you mention (or similar problems 
with dynamic typing etc) never happens, nor that they're never painful 
to track down and fix - just that they happen way less often than one 
might fear, and are most of the time really quickly spotted and fixed.

> Please, understand that I'm not stating that python is wrong... after
> all, if it is wrong, I can move to a language like Java, which has a
> different approach on it.

I don't think it's a matter of "right" or "wrong" - mostly a matter of 
tradeoffs and balance. But if you go for static typing and (allegedly) 
provable correctness, you may want to have a look at languages like OCaml.

> I'm really very interested in reading past
> discussion on it, if they are available.

Well... Most of these "discussions" alas boil down to bondage&discipline 
proponants asserting - against all evidences - that dynamic languages 
are unsafe and unusable for anything else than simple throw-away scripts 
or toy projects, and dynamic proponants arguing - against all evidences 
- that static typing and everything related is just a waste of time 
(FWIW, you might find myself in the first camp until approx year 2k and 
the second for the five or six following years). And sometimes, someone 
a bit more sensible trying to take a more balanced approach to the 
problem, usually to no avail.



More information about the Python-list mailing list