Writing "pythonish" code

[Ben Finney]

Mizipzor <mizipzor at gmail.com> writes:

> The problem isnt in pythons syntax, its in the architecture/design,
> the concept of writing "pythonish code" if you like.

The nomenclature around here for that concept is "Pythonic".

> 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.

Python has no strict prohibition on accessing any attribute of a
class. The convention is to name attributes with a leading underscore
if you don't think they should be accessed from outside the
class.

This allows users of your class (i.e. people writing code that uses
that class) to know what the public interface is -- i.e. all the
attributes that aren't named with a leading underscore -- without
preventing access to the other attributes if that makes for better
code. Since you can't ever know all the possible uses of a class when
you write it, this flexibility is a good thing.

> 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?

Who is "I" in the above question? You should write your classes on the
assumption that you don't know who will be making use of them, and
consider your code to be a means of communication with the later users
(programmers) of your code.

> Or should I see the python classes like c++ structs with functions?

I don't see what benefit this would have; Python classes are classes.

> 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.

To move toward more Pythonic code, you should treat a module as a
logically-coherent collection of functionality. It can contain any
number of classes or other objects. Divide your code into modules by
functionality, not dogmatically by one-class-per-module.

> 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.

Can you articulate what looks ugly? Python makes strong use of
namespaces, so the above looks fine to me: it's clear where everything
is coming from. The only confusion comes from the fact that the module
"foo" and the class "foo" have the same name, which as discussed
doesn't need to be the case unless it actually makes sense.

> So, assuming Im never gonna have more than one instance of the foo
> class

This is a separate assumption, and doesn't necessarily follow from
what you've said above.

> 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"?

Very. This is Python's response to the "Singleton" pattern that some
other languages require: put attributes directly at a module level,
import that module wherever you need those attributes, and you're
guaranteed a single shared instance of the module. A good example is a
module containing a set of attributes defining the configuration for
the application.

-- 
 \               "I was sleeping the other night, alone, thanks to the |
  `\                                    exterminator."  -- Emo Philips |
_o__)                                                                  |
Ben Finney