Is my thinking Pythonic?

Hey,
Well, as you all know by now, I'm learning Python :)
One thing that is annoying my is the OOP in Python.
Consider this code in Java:
--
public class Car {
private int speed;
private String brand;
// setters & getters
}
--
With one look at the top of the class, you can know that each
instance has two instance variables (speed & brand).
I tried to transform in into Python:
--
class Car:
def setspeed(self, speed):
self.speed = speed
def setbrand(self, brand):
self.brand = brand
--
If you have a huge class, you can't figure the instance variables of
each object.
So, I created this constructor:
--
def __init__(self):
self.speed = None
self.brand = None
--
This way, I can figure the instance variables by just reading the
__init__ method.
What do you think of my approach? is it considered Pythonic?
Any suggestions?
Thank you all.

re: Is my thinking Pythonic?

Hussein B:You can also learn the _attribute and __attribute conventions.
In Python getter/setters are used less often, you can remove those two
setters and just access the attributes from outside.
Later, in derived classes, if you want to make their workings more
complex you can add properties.
Note that Python isn't able to inline things as HotSpot does, so each
getter/setter (or dot: foo.bar.baz is slower than foo.bar) you use
your code slows down.

Sometimes I do the same thing, to to "document" the attributes used.

Bye,
bearophile

re: Is my thinking Pythonic?

Hussein B wrote:
The approach is exactly right - instance variable should be (don't have to,
though) declared inside the __init__-method.

However, you *are* unpythonic in defining getters and setters. These are a
java-atrocity that mainly exists because java has no concept of properties
or delegates, and thus can't add code to instance variable assignments.
Thus one needs to wrap *all* variables into get/set-pairs, such that in the
case of a behavior-change (e.g. lazyfying) one does not need to change
client-code.

Maybe this reading will help you adjust your mindset:

http://dirtsimple.org/2004/12/python-is-not-java.html


Diez

re: Is my thinking Pythonic?

Hussein B a écrit :If so, the answer to your question is "obviously, no" !-)

Ok, let's see...
Unless you have a compelling reason, use new-style classes:

class Car(object)
Java, C++ etc require getters and setters because they have no support
for computed attributes, so you cannot turn a plain attribute into a
computed one without breaking code. Python has good support for computed
attributes, so you just don't need these getters and setters. The
pythonic translation would be:

class Car(object):
def __init__(self, speed, brand):
self.speed = speed
self.brand = brand
If your class is that huge, then it's probably time to either refactor
and/or rethink your design.
<mode="pedantic">
s/constructor/initialiser/
</mode>

If I may ask : why don't you pass speed and brand as parameters ? If you
want to allow a call without params, you can always use default values, ie:

class Car(object):
def __init__(self, speed=None, brand=None):
self.speed = speed
self.brand = brand

As far as I'm concerned - and modulo the question about initiliser's
params - I consider good style to set all instance attributes to
sensible default values in the initializer whenever possible, so, as you
say, you don't have to browse the whole code to know what's available.

Now remember that Python objects (well, most of them at least) are
dynamic, so attributes can be added outside the class statement body.

re: Is my thinking Pythonic?

generally, I name the members in the Class definition and set them to
None there...

class Car:
speed = None
brand = None

def __init__():
self.speed = defaultspeed #alternately, and more commonly, get
this speed as a initializer argument
self.brand = defaultbrand


That solves the issue of being able to "see" all the members of an
object by reading code... however, this all goes out the window when
composing an instance dynamically (i.e. metaclass type stuff).

re: Is my thinking Pythonic?

Craig Allen wrote:
While I use this idiom myself, one must be cautious not to create unwanted
side-effects if anything mutable comes into play:

class Foo:
bar = []

def baz(self):
self.bar.append(2)


will *not* make bar instance-variable, but keep it as class-variable.

re: Is my thinking Pythonic?

Craig Allen:
I think that's better to avoid class attributes if you don't need
them, then shade them with object attributes with the same name, etc,
it looks like a way to make things messy...

Bye,
bearophile

re: Is my thinking Pythonic?

En Thu, 21 Aug 2008 14:31:02 -0300, Craig Allen <callen314@gmail.com>
escribi�:
This isn't a good idea as discussed in this recent thread
http://groups.google.com/group/comp....01042e59bcc29/

--
Gabriel Genellina

re: Is my thinking Pythonic?

Bruno Desthuilliers wrote:
the distinction is gone in 3.0, so can we please stop flaming people for
violating a crap rule that's quite often pointless in 2.X and completely
pointless in 3.0?

</F>

re: Is my thinking Pythonic?

Fredrik Lundh a écrit :Yeps, but not in 2.5.2, which is still the current stable release.
Hear hear... Now *this* is a very sound advice.
Given the lack of proper support for the descriptor protocol in
old-style classes and a couple other diverging behaviors, I wouldn't say
that advising newcomers to use new-style classes is so pointless.

re: Is my thinking Pythonic?

Bruno Desthuilliers wrote:
Yeah, but if you don't need descriptors, new-style classes don't buy you
anything (except a slight slowdown in certain situations). Dogmatic use
of new-style classes (or any other "new" feature) isn't "pythonic".

</F>

re: Is my thinking Pythonic?

Fredrik Lundh a écrit :Except being python-3000 ready wrt/ diverging behavious - like
overriding __magic__ methods on a per-instance basis. Ok, this is
certainly not a very common case, but still we've seen questions about
this on this ng...
"dogmatic" ???
You're right to quote the word "new" here - how many years since Python
grew a new object model explicitely intended to replace the original one ?