OOP only in modules
Hi all, from the subject of my post, you can see I do not like very much OOP... and I am not the only one... Knowing that python is intrinsecally OO, I propose to move all OOP stuff (classes, instances and so on) to modules. In this way the OOP fan can keep on using it, but in a module recalled by import in the user script. The advantage is that the user can call function and methods by a well-known sintax. Not to mention the sharp increase in re-usability of code... Bye. -- http://mail.python.org/mailman/listinfo/python-list
Re: OOP only in modules
Hi all,
I must thank before Andrea Crotti and Steven D'Aprano, which kindly
replayed to my post... they deserve an answer.
To Andrea Crotti's "OOP makes life easier also to the user"... that is
NOT
my experience...
I'm not pretending that everyone else thinks like me (also if many
people do...
load any search engine with "againt OOP" or "criticisms againt OO" to
verify...)
I was trying to get caller-callee tree from the module trace (like do
cflow
with C sources, together with xref)... I think that UML is a loss of
time...
"trace" has three classes whose methods I can't easily arrange in the
caller-callee tree, mainly because IMHO they are similar to functions
declared inside another function.
So I taught to move classes in a module (trace_classes.py) saved
in the same folder of the python source to be traced.
Only using "from trace_classes import *" in the trace_noclasses.py
which contained
the residual part of trace after removing classes, you had the same
result as
the original trace...
In fact "python trace -t mysource.py" worked the same as:
"python trace_noclasses.py -t mysource.py" if you of course load the
classes
by "from trace_classes import * (as mentioned before)
To trace the module trace.py you can use:
python trace.py -t trace.py - t mysource.py (it seems that you must
include
at least a source to be traced".)
The problems arise if you want to use the standard import...with the
two
components of trace (w/ or w/o classes)... because of the instances
or the obiects defined with class template...
For me its enough to study a module with classes and instances
defined outside them and can use it without referring to internal
istances...
Do you know a module of this kind (trace itself could be the answer
but the
source is too complicated for me...)
I would not like to be compelled to revert to another language as the
suggestion
of Andrea Crotti ("I think that you should probably use another
language if you don't like OOP so much...")
As far Steven D'Aprano and his "Python is based on objects, but it is
not an object-oriented language." is concerned, I could agree with him
(... with some difficulty, however...)
For him (and I agree) "python is a multi-paradigm language: it
includes elements of OOP, functional, procedural and imperative
programming", but the OO example is merily "mylist.sort() # object-
oriented", without citing the classes and the
multiple inheritance or other obscure property.
My main goal is to arrange OO in a paradigmatic manner in order to
apply to it the
procedural scheme. especially to the caller or called modules.
Bye.
--
http://mail.python.org/mailman/listinfo/python-list
Re: OOP only in modules
Hi Andrea,
excuse my beeing criptic (you wrote: "I have some troubles
understanding what you mean") but I coudn't to go on too long.
Now I can conclude my speech...
When I was younger I transformed a big Clipper program in
simil-C in order to apply cflow... and I succeeded...
but Clipper wasn't OO!
To better explain I must introduce cflow...
From: http://www.gnu.org/software/cflow/manual/cflow.txt
/* whoami.c - a simple implementation of whoami utility */
#include
#include
#include
#include
int who_am_i (void) #~13
{
struct passwd *pw;
char *user = NULL;
pw = getpwuid (geteuid ()); #~18
if (pw)
user = pw->pw_name;
else if ((user = getenv ("USER")) == NULL) #~21
{
fprintf (stderr, "I don't know!\n");#~23
return 1;
} #~26
printf ("%s\n", user);
return 0;
}
int main (int argc, char **argv) #~31
{
if (argc > 1)
{
fprintf (stderr, "usage: whoami\n");#~35
return 1;
}
return who_am_i (); #~38
}
Running `cflow' produces the following output:
$ cflow whoami.c
main() :
| ~ all C programs start with main()
+-- fprintf() ~ called from #~35
+-- who_am_i()
# 2instances.py
# from: http://www.freenetpages.co.uk/hp/alan.gauld/tutclass.htm
# w/ some adds up
class C:
def __init__(self, val):
self.val = val
def f(self):
print "hello, my value is:", self.val
# create two instances
a = C(27)
b = C(42)
def E():#~15
print 'hello '+ F()
G() #~17
def F():#~18
return raw_input('Addressed to ') #~19
def G():#~21
print 'Hello world'
# first try sending messages to the instances
a.f(),''
# hello, my value is 27
b.f()
# hello, my value is 42
# now call the method explicitly via the class
C.f(a)
# hello, my value is 27
# Addressing functions
E() #~35
G() #~36
""" call tree w/o classes and objects:
E() #~15 called from #~35
+-- F() #~1816
|+-- raw_input('Addressed to ') # called from 19
+-- G() #~2118
G() #~2136
"""
Beeing the script so small, the above call tree can be
build up by hand, but in every case in am not able to
incorporate classes, instances and method calls...
Instead, if I move "all" the OO references to a module
(for example m2instancesOO.py saved in the same dir as the
part w/o OO)
I could fictitiously trasform OOP in "procedural" programming,
getting therefore only function definitions and calls.
It not an easy task... therefore I called help.
in my experience, I am convinced that call trees (together with xref)
are the main tools to understand not trivial python programs.
Instead of using debuggers, with these tools (and with the
judicious use of trace) you can solve any bug and besides that
acquire a better understanding of the program.
Another advantage of moving OO stuff to modules is the "sharp
increase in re-usability of code...
In my understanding modules are the python's implementation
of libraries very much used by other languages.
Bye.
--
http://mail.python.org/mailman/listinfo/python-list
