Re: [pygtk] python modules/classes best practices?

[Robert Park]

On Mon, Jan 31, 2011 at 2:22 PM, Robert Park  wrote:
> On Mon, Jan 31, 2011 at 5:52 AM, Roberto Cavada  wrote:
>> Then I guess your GUI is necessarily very small. I cannot imagine a large
>> GUI all fitted into a module, and even within one single class. How do you
>> separate the GUI logics and the presentation layers? Can you split the GUI
>> into (interconnected, still decoupled) pieces? ( someone calls them
>> components.) If you have components, you can reuse/factorize code in
>> different parts of a single application, or you can rearrange the GUI for
>> another application.
>
> I don't totally follow you here. In "app.py" I have a single class
> with many methods. Some methods provide the actual application logic,
> and some methods are just boring signal handlers for various tedious
> GUI activities. However, I do import other classes that represent
> specific things (photo files, XML files, etc), and use them in
> sensible ways.

Wait, I think I'm starting to understand what you're saying. I do
understand the MVC concept because I have some experience with Ruby on
Rails.

Ok, what about this: What if I took my interesting application logic
methods, moved them into their own class, and then inherited from that
in the main app class? That would then make it essentially trivial to
make a second class that inherits the app logic code, which would
allow me to (for example) make a commandline interface to the same app
functionality without duplicating any of the app logic code.

Is that a sensible way to use inheritance in this case? Or is there
some larger picture that I'm missing?

Thanks again!

-- 
http://exolucere.ca
___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] python modules/classes best practices?

[Robert Park]

On Mon, Jan 31, 2011 at 5:52 AM, Roberto Cavada  wrote:
> On 01/30/2011 11:53 PM, Robert Park wrote:
>> [...] but now that the other classes are in other files,
>> the module _itself_ is providing the same encapsulation that the class
>> was giving me, and is thus redundant.
>
> In this perspective, you are using classes as mere namespaces of your
> functions and variables. As I said, if you do not exploit hierarchies and
> relations (and you don't as you have no inheritance and no polymorphism)
> there is very little difference between module and class levels (IMO there
> are some disadvantages with modules, see below).

Right, I'm not using any inheritance for the main app class, no. What
kind of things would I want to inherit from that would be useful to my
application? I just literally have no idea what I could inherit from
there.

I do use inheritance in a small way with my Photograph class, but
that's very minor.

>> My point with that example was not that the second version was better,
>> but that they were so similar that it proves that the module itself is
>> "good enough" and that I don't actually benefit from having this
>> particular class inside a module.
>
> If you don't see advantages with classes, let's stay with benefits of having
> only modules. Do you see any that are not syntactic like number of dots
> between IDs and 'self' appearing as first formal param?

Now, I did say that I'm not arguing against classes in general, only
that one specific class. And no, I started this thread solely because
I was searching for syntactical simplification for my application.

>>> Indeed if your application code fits into a thousand of LOC, you can
>>> choose whatever style you like, either having everything pushed into one
>>> module or split into classes/packages/modules, no really matters.
>>
>> Ok, but I am not arguing against all classes, just the class that
>> represents the graphical interface that the user interacts with.
>
> Then I guess your GUI is necessarily very small. I cannot imagine a large
> GUI all fitted into a module, and even within one single class. How do you
> separate the GUI logics and the presentation layers? Can you split the GUI
> into (interconnected, still decoupled) pieces? ( someone calls them
> components.) If you have components, you can reuse/factorize code in
> different parts of a single application, or you can rearrange the GUI for
> another application.

I don't totally follow you here. In "app.py" I have a single class
with many methods. Some methods provide the actual application logic,
and some methods are just boring signal handlers for various tedious
GUI activities. However, I do import other classes that represent
specific things (photo files, XML files, etc), and use them in
sensible ways.

>> Can you explain how module-globals make code less portable? Is there a
>> platform on which Python doesn't support module globals? I'm genuinely
>> curious.
>
> Mmm, 'portability' was a bad term I chose, as it can create
> misunderstandings I am sorry about that. I probably had to talk about
> 'reuse'. Extending my objections, what if you wanted to have:
> - threads involved

I did try threads once and found it was quite terrifying, but that was
WITH the class definition, not module globals!

> - unittests of some parts

I have a large test suite and I don't really see how this would make
any difference. The testsuite calls "app.some_method()" and the syntax
is the same whether "app" is an instance of a class, or a whole
module.

> If you have poor locality of your code, you'll get into troubles. Using
> module-level variables does not help with locality.

Ok, that is a good point and that is pretty much the major problem
that I ran into when i tried (and failed) to actually do the class
methods -> module globals conversion that I've been talking about.

Thanks for your responses everybody, this has given me a lot to think
about and I think I'm learning. ;-)

-- 
http://exolucere.ca
___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] python modules/classes best practices?

[Robert Park]

On Mon, Jan 31, 2011 at 3:59 AM, A.T.Hofkamp  wrote:
>> Ok, but I'm asking if the module itself provides the same "heirarchies
>> and relations" that I'm getting from the class. That is, when my
>
> No, you don't have inheritance with modules.

Ok.

> That holds, until you add a second window, or you create custom widgets that
> you use in your application GUI.
> (At least, that is where I'd expect those things.)

Well, the app already has many "windows". There's a preferences dialog
window, an open files dialog, about dialog, quit confirmation dialog,
etc. They're all quite simple and I don't see much benefit to having
those be in separate classes. They're all part of "the app" and are in
the app's main class.

>> Well, one way that i'm attempting to make everything more readable is
>> by getting rid of the term "self" that is littered throughout my
>> program.
>
> Every Python programmer understands what self means. He/she knows instantly
> what you are doing.
> Don't confuse 'short code' with 'readable code'. While related, they are not
> the same thing.

There's a good point!

Thanks for your input, it's been enlightening.


-- 
http://exolucere.ca
___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] python modules/classes best practices?

[Roberto Cavada]

On 01/30/2011 11:53 PM, Robert Park wrote:

 

[...] but now that the other classes are in other files,
the module _itself_ is providing the same encapsulation that the class
was giving me, and is thus redundant.



In this perspective, you are using classes as mere namespaces of 
your functions and variables. As I said, if you do not exploit 
hierarchies and relations (and you don't as you have no inheritance 
and no polymorphism) there is very little difference between module 
and class levels (IMO there are some disadvantages with modules, see 
below).



My point with that example was not that the second version was better,
but that they were so similar that it proves that the module itself is
"good enough" and that I don't actually benefit from having this
particular class inside a module.



If you don't see advantages with classes, let's stay with benefits 
of having only modules. Do you see any that are not syntactic like 
number of dots between IDs and 'self' appearing as first formal param?



Indeed if your application code fits into a thousand of LOC, you can
choose whatever style you like, either having everything pushed into one
module or split into classes/packages/modules, no really matters.


Ok, but I am not arguing against all classes, just the class that
represents the graphical interface that the user interacts with.



Then I guess your GUI is necessarily very small. I cannot imagine a 
large GUI all fitted into a module, and even within one single 
class. How do you separate the GUI logics and the presentation 
layers? Can you split the GUI into (interconnected, still decoupled) 
pieces? ( someone calls them components.) If you have components, 
you can reuse/factorize code in different parts of a single 
application, or you can rearrange the GUI for another application.



have a handful of classes that represent various kinds of data that my
application uses, and that makes great sense because each class can be
instantiated multiple times and each instance represents something
meaningful.



Typically the top-level logics, controller and presentation of the 
GUI is instantiated only once, but this does not mean that it is not 
meaningful. Again, classes are not supposed to be instantiated 
multiple times.



However, if your application is intended to grow up, if you need
contracts (interfaces) to agree with other programmers, if you need to


Ok, but how does having module top-level functions instead of class
instance methods (for a class that can only be instantiated once) make
any difference?



In principle no, in practice it largely helps. I think it is trivial 
to say that the introduction of OOP did not change the software, as 
you can do whatever with a procedural-paradigm, as well as you can 
do OOP with a non-OOP language. OOPs is only for reducing 
(hopefully) costs of software.



Can you explain how module-globals make code less portable? Is there a
platform on which Python doesn't support module globals? I'm genuinely
curious.



Mmm, 'portability' was a bad term I chose, as it can create 
misunderstandings I am sorry about that. I probably had to talk 
about 'reuse'. Extending my objections, what if you wanted to have:

- threads involved
- unittests of some parts
- code generated by metaclasses at compile time
- refactoring needs, e.g. you want to move your code (or part of it) 
in a different possibly larger place.


If you have poor locality of your code, you'll get into troubles. 
Using module-level variables does not help with locality.


My two cents,
r.

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] python modules/classes best practices?

[A.T.Hofkamp]

Robert Park wrote:

On Sun, Jan 30, 2011 at 3:16 PM, Roberto Cavada  wrote:

On Sat, 2011-01-29 at 23:22 -0700, Robert Park wrote:
[...]

But I just can't shake this feeling that having a class to represent
just the GUI when it's already inside of a module is somehow
redundant. There will only ever be one instance of that class. What
good is that?

The fact that classes can be instantiated multiple times is not the
(only) reason for having classes. Inheritance and polymorphism give the
real sense to OOP - IMO - and having information hidden into hierarchies
and relations make the design easy to understand, extend, maintain, etc.


Ok, but I'm asking if the module itself provides the same "heirarchies
and relations" that I'm getting from the class. That is, when my


No, you don't have inheritance with modules.


entire project was in one file, it made sense to have the class for
it's encapsulation, but now that the other classes are in other files,
the module _itself_ is providing the same encapsulation that the class
was giving me, and is thus redundant.


Sort of, indeed.

That holds, until you add a second window, or you create custom widgets that you use in your 
application GUI.

(At least, that is where I'd expect those things.)


My point with that example was not that the second version was better,
but that they were so similar that it proves that the module itself is
"good enough" and that I don't actually benefit from having this
particular class inside a module.


One concept you may want to keep is that 'import xyz' does nothing except 
importing.
If you perform assignments at toplevel, importing has side effects.
For normal execution this is not a problem, for debugging it may be useful to have to explicitly 
call setup, like you have in __init__(self).



Ok, but how does having module top-level functions instead of class
instance methods (for a class that can only be instantiated once) make
any difference? Either way there is a rigid API that I can be held to


For your case, it matters very little. The question is mostly when do you move the code one level 
deeper, now, or when you want to extend the program.
The disadvantage of the latter is that you first need to do refactoring before you can extend. Since 
that may happen after 2 years, it means you then have to understand what you did now.


Another consideration is other users, and/or other programs.
Other users will expect things to be one level deeper, so for their readability it is advisable to 
code it that way.
In the same way, if you make more of these programs, chances are you are also going to make programs 
where the code is one level deeper. That means that you will have two coding styles for the 
top-level function instead of one, which is more difficult to manage correctly.




Well, one way that i'm attempting to make everything more readable is
by getting rid of the term "self" that is littered throughout my
program.


Every Python programmer understands what self means. He/she knows instantly 
what you are doing.
Don't confuse 'short code' with 'readable code'. While related, they are not 
the same thing.


Just my 2 cents,
Albert
___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] python modules/classes best practices?

[Robert Park]

On Sun, Jan 30, 2011 at 3:16 PM, Roberto Cavada  wrote:
> On Sat, 2011-01-29 at 23:22 -0700, Robert Park wrote:
> [...]
>> But I just can't shake this feeling that having a class to represent
>> just the GUI when it's already inside of a module is somehow
>> redundant. There will only ever be one instance of that class. What
>> good is that?
>
> The fact that classes can be instantiated multiple times is not the
> (only) reason for having classes. Inheritance and polymorphism give the
> real sense to OOP - IMO - and having information hidden into hierarchies
> and relations make the design easy to understand, extend, maintain, etc.

Ok, but I'm asking if the module itself provides the same "heirarchies
and relations" that I'm getting from the class. That is, when my
entire project was in one file, it made sense to have the class for
it's encapsulation, but now that the other classes are in other files,
the module _itself_ is providing the same encapsulation that the class
was giving me, and is thus redundant.

>> I could just ditch the class and have all the class
>> methods be top-level module function definitions, and then I could
>> rename "main.py" into "appname.py", and in my runner script, change
>> this code:
>>
>> from appname.main import AppName
>> AppName().main()
>>
>> into this:
>>
>> from appname import appname
>> appname.main()
>
> Frankly I cannot see a substantial difference in terms of quality.
> (Can you measure the quality from the number of keystrokes?)

My point with that example was not that the second version was better,
but that they were so similar that it proves that the module itself is
"good enough" and that I don't actually benefit from having this
particular class inside a module.

> Indeed if your application code fits into a thousand of LOC, you can
> choose whatever style you like, either having everything pushed into one
> module or split into classes/packages/modules, no really matters.

Ok, but I am not arguing against all classes, just the class that
represents the graphical interface that the user interacts with. I
have a handful of classes that represent various kinds of data that my
application uses, and that makes great sense because each class can be
instantiated multiple times and each instance represents something
meaningful.

> However, if your application is intended to grow up, if you need
> contracts (interfaces) to agree with other programmers, if you need to

Ok, but how does having module top-level functions instead of class
instance methods (for a class that can only be instantiated once) make
any difference? Either way there is a rigid API that I can be held to
for compatibility, the only difference is that if I get rid of the
class, then the module _itself_ can be treated as if it is an instance
of what was previously the class. In fact, doing it the way I suggest
makes it easier to enforce that there be only one instance, because
modules can only be imported once (Python enforces this; secondary
import statements are effectively no-ops).

> decompose the application into hierarchies of functional modules, you
> will very quickly end up floundering into a spaghetti nightmare if you
> don't organize your code base accordingly.

I'm well aware of the benefits of having short, well-defined
functions. My app is quite well organized. The question was simply "is
there some benefit I don't see to having these particular functions be
part of a class, rather than just having them as module top-levels and
pretending that the module itself behaves like an instance of the
class?"

>> Another reason why I care about this issue is that method invocations
>> are slower when there's a period in the name, so eg calling
>> "self.foobar()" is by definition slower than simply calling
>> "foobar()", so there's a minor speed boost to be had by ditching the
>> class and replacing it with all module-global functions.
>
> In python, generally, these optimizations are not very meaningful. Your
> may be trying to reduce complexity of your algorithms, but one further
> level of indirection and similar details make no actual difference.
>
> Much more important is how your code looks like (do you really exploit
> the language, or do you write your code like e.g. in java?), and how
> your code is organized. My personal way for evaluating python code I
> write and read, is wonder if I can understand what a function does
> without worrying about the details of the implementation. If not
> convinced, there is certainly a better approach to make it better
> (shorter, more elegant, more readable).

Well, one way that i'm attempting to make everything more readable is
by getting rid of the term "self" that is littered throughout my
program.

>> One thing I changed recently that got me thinking about this is that I
>> changed GtkBuilder from being an instance variable to a top-level
>> module variable.
>
> Sometimes I use aliases like you, especially in loops where it makes
> sense, but onl

Re: [pygtk] python modules/classes best practices?

[Roberto Cavada]

Hi,

On Sat, 2011-01-29 at 23:22 -0700, Robert Park wrote:
[...]
> But I just can't shake this feeling that having a class to represent
> just the GUI when it's already inside of a module is somehow
> redundant. There will only ever be one instance of that class. What
> good is that? 

The fact that classes can be instantiated multiple times is not the
(only) reason for having classes. Inheritance and polymorphism give the
real sense to OOP - IMO - and having information hidden into hierarchies
and relations make the design easy to understand, extend, maintain, etc.

> I could just ditch the class and have all the class
> methods be top-level module function definitions, and then I could
> rename "main.py" into "appname.py", and in my runner script, change
> this code:
> 
> from appname.main import AppName
> AppName().main()
> 
> into this:
> 
> from appname import appname
> appname.main()

Frankly I cannot see a substantial difference in terms of quality. 
(Can you measure the quality from the number of keystrokes?) 

Indeed if your application code fits into a thousand of LOC, you can
choose whatever style you like, either having everything pushed into one
module or split into classes/packages/modules, no really matters.

However, if your application is intended to grow up, if you need
contracts (interfaces) to agree with other programmers, if you need to
decompose the application into hierarchies of functional modules, you
will very quickly end up floundering into a spaghetti nightmare if you
don't organize your code base accordingly. 

python-gtkmvc  may be
overkilling for toys and small applications, but drives/allows you to
split the logics and presentation layers, and to split the views and the
models into hierarchies of classes - the opposite direction you seemed
to be exploring. 

> Another reason why I care about this issue is that method invocations
> are slower when there's a period in the name, so eg calling
> "self.foobar()" is by definition slower than simply calling
> "foobar()", so there's a minor speed boost to be had by ditching the
> class and replacing it with all module-global functions.

In python, generally, these optimizations are not very meaningful. Your
may be trying to reduce complexity of your algorithms, but one further
level of indirection and similar details make no actual difference. 

Much more important is how your code looks like (do you really exploit
the language, or do you write your code like e.g. in java?), and how
your code is organized. My personal way for evaluating python code I
write and read, is wonder if I can understand what a function does
without worrying about the details of the implementation. If not
convinced, there is certainly a better approach to make it better
(shorter, more elegant, more readable). 

> One thing I changed recently that got me thinking about this is that I
> changed GtkBuilder from being an instance variable to a top-level
> module variable. 

Sometimes I use aliases like you, especially in loops where it makes
sense, but only if the alias is kept local and close to the place where
it is used. However, introducing aliases makes the code harder to
understand, and if the alias is global to the module (like in your
example) the code is less portable/usable prone to errors. 

r.


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/