473,321 Members | 1,916 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,321 software developers and data experts.

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.
Aug 21 '08 #1
11 1370
Hussein B:
class Car:
def setspeed(self, speed):
self.speed = speed
def setbrand(self, brand):
self.brand = brand
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.

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.
Sometimes I do the same thing, to to "document" the attributes used.

Bye,
bearophile
Aug 21 '08 #2
Hussein B wrote:
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?
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
Aug 21 '08 #3
Hussein B a écrit :
Hey,
Well, as you all know by now, I'm learning Python :)
One thing that is annoying my is the OOP in Python.
If so, the answer to your question is "obviously, no" !-)

Ok, let's see...
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:
Unless you have a compelling reason, use new-style classes:

class Car(object)
def setspeed(self, speed):
self.speed = speed
def setbrand(self, brand):
self.brand = brand
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 you have a huge class, you can't figure the instance variables of
each object.
If your class is that huge, then it's probably time to either refactor
and/or rethink your design.
So, I created this constructor:
<mode="pedantic">
s/constructor/initialiser/
</mode>

--
def __init__(self):
self.speed = None
self.brand = None
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

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?
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.
Aug 21 '08 #4
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).
Aug 21 '08 #5
Craig Allen wrote:
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).
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.
Aug 21 '08 #6
Craig Allen:
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).
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
Aug 21 '08 #7
En Thu, 21 Aug 2008 14:31:02 -0300, Craig Allen <ca*******@gmail.com>
escribi�:
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
This isn't a good idea as discussed in this recent thread
http://groups.google.com/group/comp....01042e59bcc29/

--
Gabriel Genellina

Aug 21 '08 #8
Bruno Desthuilliers wrote:
Unless you have a really good reason to use an antiquated and deprecated
object model, use "new-style" classes (for a value of "new" being "now
many years old"):
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>

Aug 22 '08 #9
Fredrik Lundh a écrit :
Bruno Desthuilliers wrote:
>Unless you have a really good reason to use an antiquated and
deprecated object model, use "new-style" classes (for a value of "new"
being "now many years old"):

the distinction is gone in 3.0,
Yeps, but not in 2.5.2, which is still the current stable release.
so can we please stop flaming people
Hear hear... Now *this* is a very sound advice.
for
violating a crap rule that's quite often pointless in 2.X and completely
pointless in 3.0?
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.
Aug 22 '08 #10
Bruno Desthuilliers wrote:
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.
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>

Aug 23 '08 #11
Fredrik Lundh a écrit :
Bruno Desthuilliers wrote:
>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.

Yeah, but if you don't need descriptors, new-style classes don't buy you
anything
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...
(except a slight slowdown in certain situations).
Dogmatic
"dogmatic" ???
use
of new-style classes (or any other "new" feature) isn't "pythonic".
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 ?
Aug 26 '08 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

9
by: Tom Evans | last post by:
My basic question: If I have a specific interface which I know is going to be implemented by a number of classes, but there is no implementation commonality between them, what is the preferred...
1
by: asdf sdf | last post by:
i need some advice. i'm a back end programmer historically, but have been exploring python for webapps and enjoying it. i need to build some simple Win client-server or standalone apps. the...
12
by: Nickolay Kolev | last post by:
Hi all, I would like to find a more pythonic way of solving the following: Having a string consisting of letters only, find out the total sound score of the string. The sound score is...
15
by: Ville Vainio | last post by:
Pythonic Nirvana - towards a true Object Oriented Environment ============================================================= IPython (by Francois Pinard) recently (next release - changes are...
10
by: Bulba! | last post by:
Hello everyone, I'm reading the rows from a CSV file. csv.DictReader puts those rows into dictionaries. The actual files contain old and new translations of software strings. The dictionary...
11
by: Charles Krug | last post by:
I've a function that needs to maintain an ordered sequence between calls. In C or C++, I'd declare the pointer (or collection object) static at the function scope. What's the Pythonic way to...
4
by: Carl J. Van Arsdall | last post by:
It seems the more I come to learn about Python as a langauge and the way its used I've come across several discussions where people discuss how to do things using an OO model and then how to design...
3
by: jnair | last post by:
My Tead Lead my object counter code seen below is not pythonic class E(object): _count = 0 def __init__(self): E._count += 1 count = property(lambda self: E._count ) def test(): if...
26
by: Frank Samuelson | last post by:
I love Python, and it is one of my 2 favorite languages. I would suggest that Python steal some aspects of the S language. ------------------------------------------------------- 1. Currently...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.