OOP only in modules

[newpyth]

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.

 

[Andrea Crotti]

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.

OOP makes like easier also to the user, if you don't like it write your
own non-OOP wrappers around the OOP functions

But I think that you should probably use another language if you don't
like OOP so much...

 

[Steven D'Aprano]

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.

Python is based on objects, but it is not an object-oriented language. It
is a multi-paradigm language: it includes elements of OOP, functional,
procedural and imperative programming. Some of these are fundamental to
Python: the "import" statement is pure imperative style.

For example, Python has:

import module # imperative style
len(mylist) # procedural
map(func, sequence) # functional
mylist.sort() # object-oriented


With a third-party package, Pyke, you can use Prolog-style logic
programming:

http://pyke.sourceforge.net/

(albeit with a procedural syntax). There are probably third-party
packages for agent-based programming as well.

If you don't like OOP, you can write your code using a functional style,
or a procedural style. List comprehensions and generator expressions are
*very* common in Python, which come from functional and pipeline styles
of programming.

If you really, really hate OOP, you can even write your own wrappers for
Python objects.

Unlike Java, Python encourages by example the use of shallow class
hierarchies. Most Python classes are only two levels deep:

object
+-- list
+-- tuple
+-- dict
+-- set
etc.

instead of the deep, complex hierarchies beloved by some OOP languages:

Object
+-- Collection
+-- Sequence
| +-- MutableSequence
| | +-- IndexableMutableSequence
| | +-- SortableIndexableMutableSequence
| | +-- SortableIndexableMutableSequenceArray
| | +-- List
| +-- ImmutableSequence
| +-- IndexableImmutableSequence
| +-- SortableIndexableImmutableSequence
| +-- SortableIndexableImmutableSequenceArray
| +-- Tuple
+-- Mapping
etc.



So while everything in Python is an objects, the language itself is only
partly object oriented, and it rarely gets in the way. The OO aspect of
Python is mostly syntax and namespaces.

 

[newpyth]

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.