Writing "pythonish" code

[Mizipzor]

Hi, this is my first mail to the list (and any list for that matter)
so any pointers on errors from my part would be appreciated. Im more
used to forums.

To start off, Ive read some python documents and done some small apps
so I think I can say I know it semi-well, and I know c++ very well.
But I want learn python even better, since I know that a company I aim
to be employed by make heavy use of python, knowing python myself
would give me an extra edge.

The problem isnt in pythons syntax, its in the architecture/design,
the concept of writing "pythonish code" if you like. One thing is that
in c++ im used to have private members in classes and no member is
altered except through the public functions of the class. In python
everything is, as far as I know, public. Im confused by this, should I
still have members in the python class that I simply dont edit
directly and let the class do its internal stuff? Or should I see the
python classes like c++ structs with functions?

I guess the ultimate is somewhere in between but I would like a nudge
or two to get there.

Now, the thing that bothers me the most. When I write python modules I
write one class per file, and the file and the class has a common
name. Maybe this is due to c++ habits. The problem is when I import
the module, make an instance of its class and store it in a variable:

foo.py
=========

class foo:
def bar(self):
print "bar"

=========

main.py
=========

import foo

localFoo = foo.foo()
localFoo.bar()

=========

To me, the main.py code above looks very ugly. So, assuming Im never
gonna have more than one instance of the foo class, can I write
something like this:

foo.py
=========

def bar(self):
print "bar"

=========

main.py
=========

import foo

foo.bar()

=========

Thats much more cleaner if you ask me, and kinda a good way to make
sure that you dont have more than one "instance" of the foo class
(which no longer is a class at all). But is it "pythonish"?

Gonna stop now, this mail got a little longer than i first thought.
Any input will be greatly appreciated.

 

[skyofdreams]

Hi, this is my first mail to the list (and any list for that matter)
so any pointers on errors from my part would be appreciated. Im more
used to forums.

To start off, Ive read some python documents and done some small apps
so I think I can say I know it semi-well, and I know c++ very well.
But I want learn python even better, since I know that a company I aim
to be employed by make heavy use of python, knowing python myself
would give me an extra edge.

The problem isnt in pythons syntax, its in the architecture/design,
the concept of writing "pythonish code" if you like. One thing is that
in c++ im used to have private members in classes and no member is
altered except through the public functions of the class. In python
everything is, as far as I know, public. Im confused by this, should I
still have members in the python class that I simply dont edit
directly and let the class do its internal stuff? Or should I see the
python classes like c++ structs with functions?

I guess the ultimate is somewhere in between but I would like a nudge
or two to get there.

as far as i know, the class attributes haven't privilege identifier.
I think If in C++ i need friend relationship between 2 classes, then in
python, i'll access the attribute directly.
in other cases, i treat it as class, suspose it's private attribute , just
like classes in C++.

To me, the main.py code above looks very ugly. So, assuming Im never
gonna have more than one instance of the foo class, can I write
something like this:

foo.py
=========

def bar(self):
print "bar"

=========

main.py
============
from foo import foo
foo().bar()

try this, it's ok, "from foo import foo" the first "foo" is module-name,
the latter foo is class name.
the formal package import tutortial link is
http://docs.python.org/tut/node8.html#SECTION008400000000000000000

Thats much more cleaner if you ask me, and kinda a good way to make
sure that you dont have more than one "instance" of the foo class
(which no longer is a class at all). But is it "pythonish"?

Gonna stop now, this mail got a little longer than i first thought.
Any input will be greatly appreciated.

HTH
-skyofdreams

 

[James Stroud]

Hi, this is my first mail to the list (and any list for that matter)
so any pointers on errors from my part would be appreciated. Im more
used to forums.

To start off, Ive read some python documents and done some small apps
so I think I can say I know it semi-well, and I know c++ very well.
But I want learn python even better, since I know that a company I aim
to be employed by make heavy use of python, knowing python myself
would give me an extra edge.

The problem isnt in pythons syntax, its in the architecture/design,
the concept of writing "pythonish code" if you like. One thing is that
in c++ im used to have private members in classes and no member is
altered except through the public functions of the class. In python
everything is, as far as I know, public. Im confused by this, should I
still have members in the python class that I simply dont edit
directly and let the class do its internal stuff? Or should I see the
python classes like c++ structs with functions?

I guess the ultimate is somewhere in between but I would like a nudge
or two to get there.

Now, the thing that bothers me the most. When I write python modules I
write one class per file, and the file and the class has a common
name. Maybe this is due to c++ habits. The problem is when I import
the module, make an instance of its class and store it in a variable:

foo.py
=========

class foo:
def bar(self):
print "bar"

=========

main.py
=========

import foo

localFoo = foo.foo()
localFoo.bar()

=========

To me, the main.py code above looks very ugly. So, assuming Im never
gonna have more than one instance of the foo class, can I write
something like this:

foo.py
=========

def bar(self):
print "bar"

=========

main.py
=========

import foo

foo.bar()

=========

Thats much more cleaner if you ask me, and kinda a good way to make
sure that you dont have more than one "instance" of the foo class
(which no longer is a class at all). But is it "pythonish"?

Gonna stop now, this mail got a little longer than i first thought.
Any input will be greatly appreciated.

The "import foo ... foo.bar()" way is preferred. Your instincts are correct.

If you want to write pythonic style, here are some references in roughly
the order I would read them after the tutorial--this is not a ranking
but more ordered for study:

1. google and read the "python style guide"
2. "How to Think like a Computer Scientist" (google it)
3. Read this email list and take notes--these people know
4. David Mertz's "Text Processing in Python" -- a classic (google it)
5. John Grayson's "Python and Tkinter Programming" (Manning)
6. "Programming Python" by Mark Lutz (O'Reilly)

I'm sure the cookbook (Ed. Alex Martelli) should be in there, but I
haven't read it extensively so I don't know where it fits. Probably #7.

James

 

[Toby A Inkster]

One thing is that in c++ im used to have private members in classes and
no member is altered except through the public functions of the class.

By convention, class members starting with a single underscore are
considered private.

This is much the same as the convention that on UNIX, files that start with
a dot are considered hidden -- there is nothing actually *preventing* a
programme from showing you these files in a directory listing, but by
convention it won't, unless you explicitly ask to see them.

Class members starting with a double underscore are "mangled" which makes
it more difficult for other code (even subclasses!) to access the member.
Difficult though -- not impossible.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/CSS/Javascript/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

 

[Neil Cerutti]

By convention, class members starting with a single underscore
are considered private.

An important consideration is that this convention is simply a
lower level of enforcement than C++ provides. Private members in
C++ are accessible if you use pointers.

Class members starting with a double underscore are "mangled"
which makes it more difficult for other code (even subclasses!)
to access the member. Difficult though -- not impossible.

I think it's best to never use such names in new code. Python's
mangling is troubled, since it uses unqualified names in the
mangle, resulting in ambiguity.

 

[Istvan Albert]

Now, the thing that bothers me the most. When I write python modules I
write one class per file, and the file and the class has a common
name. Maybe this is due to c++ habits.

Python modules typically contain multiple classes and module level
functions as well. That way having to deal with redundant names such
as foo.foo comes up less often.

Also it is a good habit to make capitalize class names, that way
writing:

from foo import Foo, bar

makes it clear that one is a class the other a function.

i.

PS: here is my personal pet peeve ... say it out loud ... I love the
functionality it offers and saved me a lot of work, yet I have to make
his conscious effort to keep these names: package, module, class
apart.

from elementtree.ElementTree import ElementTree

 

[bearophileHUGS]

Mizipzor:

To me, the main.py code above looks very ugly.

With time, and looking at other people code, you will learn what
pythonic means, in the meantime you can remember that into your Python
code if you find something that makes you write too much code, or you
see something "ugly", then that's probably the wrong way to write it.
The language is designed in a way that often the simpler and shorter
things are the right ones. There are exceptions to that rule (like
avoiding to use import *, using xrange instead of range, etc), but
it's a stating point.

Bye and welcome here,
bearophile