python without OO

[Davor]

Is it possible to write purely procedural code in Python, or the OO
constructs in both language and supporting libraries have got so
embedded that it's impossible to avoid them? Also, is anyone aware of
any scripting language that could be considered as "Python minus OO
stuff"? (As you can see I'm completely new to Python and initially
believed it's a nice&simple scripting language before seeing all this
OO stuff that was added in over time)
Thanks,
Davor

[John Hunter]

>>>>> "Davor" == Davor <da*****@gmail. com> writes:

Davor> not really - it was not my intention at all - but it seems
Davor> people get upset whenever this OO stuff is mentioned - and
Davor> what I did not expect at all at this forum as I believed
Davor> Python people should not be so OO hardcore (seems not all
Davor> as quite a few have indicated in their
Davor> replies)... Nevertheless, I think the discussion has
Davor> several quite good points! --
Davor> http://mail.python.org/mailman/listinfo/python-list

Consider the case of a list, say

x = [1,2,3,4]

suppose you wanted to reverse the list, so that x becomes [4,3,2,1].
In a procedural language, one might do

x = reverse(x)

In an OO language such as python, one might do

x.reverse()

Is the OO way more obscure and complicated, etc? Not really -- it's
only a minor syntactical difference. One of the core ideas behind OO
programming is that data (the contents of the list 1,2,3,4) and
methods (sorting, reversing) are bound together into a single entity,
the object. On the face of it, this is rather sensible.

You may rightly recoil against unnecessary abstraction and complexity,
abuse of multiple inheritance and so on. That's perfectly sensible.
But object orientation is probably not the bogey man here. python
values readable code that is as simple as possible (but no simpler!)
as you seem to. Focus on the actual problem, which is probably not OO
programming, but colleagues who are making a design more complex than
need be.

Indeed, the third chant in the mantra of python is "Simple is better
than complex."

John-Hunters-Computer:~> python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright" , "credits" or "license" for more information.

import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

[Davor]

I'd like to thank everyone for their replies. The main important lesson
I got is:

Python does not have that many issues with misuse of OO as compared to
Java/C++ because it's *dynamically* typed language and extremely
powerful *dictionary* data structure.

I browsed docs a bit today, and they also confirm what I have believed -
that OO is totally secondary in Python. In fact,
object/classes/metaclasses are nothing but *dictionaries with identity*
in python. Love this approach. In fact, you can very easily implement
your own *OO model* completely separate of Python's OO model... Now I
actually strongly believe that Python's author has introduced the whole
OO model just to attract and make happy OO population... In fact,

*Python's dynamic type checking mechanisms + dictionary is way more
powerful than Java/C++'s static type checking mechanisms + their OO
mechanisms*

and you can definitely be more productive using Python's structured
programming than Java/C++ OO programming :-)... and Python is probably
the best example why we should have skipped OO all together..

---
second, instead of playing with OO plagued design principles do as follows:

1. separate data, functionality, and structure from each other as much
as you can (in Python only valid structural element I've seen so far is
module - ignore objects & classes!)
2. do not assume any have identity (even if the underlying language
model provides and uses one) - so don't pass them around and crazy stuff...

so you get a nice program with separate data structures and functions
that operate on these data structures, with modules as containers for
both (again ideally separated). Very simple to do and maintain no matter
what OO preachers tell you...

Davor

[beliavsky]

John Hunter wrote:

>> "Davor" == Davor <da*****@gmail. com> writes:

Davor> not really - it was not my intention at all - but it seems
Davor> people get upset whenever this OO stuff is mentioned - and
Davor> what I did not expect at all at this forum as I believed
Davor> Python people should not be so OO hardcore (seems not all
Davor> as quite a few have indicated in their
Davor> replies)... Nevertheless, I think the discussion has
Davor> several quite good points! --
Davor> http://mail.python.org/mailman/listinfo/python-list

Consider the case of a list, say

x = [1,2,3,4]

suppose you wanted to reverse the list, so that x becomes [4,3,2,1].
In a procedural language, one might do

x = reverse(x)

In an OO language such as python, one might do

x.reverse()

Is the OO way more obscure and complicated, etc? Not really -- it's
only a minor syntactical difference. One of the core ideas behind OO
programming is that data (the contents of the list 1,2,3,4) and
methods (sorting, reversing) are bound together into a single entity,
the object. On the face of it, this is rather sensible.

I think the OO way is slightly more obscure. It's obvious what x =
reverse(x) does, but it is not clear unless you have the source code
whether x.reverse() reverses x or if it returns a reversed list. If
x.reverse() does the former, a disadvantage relative to the procedural
approach is that a function can be used in an expression. It is clearer
and more concise to write

z = reverse(x) + reverse(y)

than

x.reverse()
y.reverse()
z = x + y

Furthermore, if in Python the algorithm for the reverse function
applies to many kinds of objects, it just needs to be coded once,
whereas a reverse method would have to provided for each class that
uses it (perhaps through inheritance).

[Casey Hawthorne]

"The object-oriented programming paradigm has an undeserved reputation
as being complicated; most of the complexity of languages such as C++
and Java has nothing to do with their object orientation but comes
instead from the type declarations and the mechanisms to work around
them. This is a prime example of how Scheme's approach of removing
restrictions compares with the "piling feature on top of feature"
needed in other languages, such as the C++ template mechanism."

"Handbook of Programming Languages, Volume IV: Functional and Logic
Programming Languages"
Peter H. Salus, editor
1998
page 63

Similarly, now, Java's generics!

--
Regards,
Casey

[John Hunter]

>>>>> "beliavsky" == beliavsky <be*******@aol. com> writes:

beliavsky> I think the OO way is slightly more obscure. It's
beliavsky> obvious what x = reverse(x) does, but it is not clear
beliavsky> unless you have the source code whether x.reverse()

You don't need to read the src, you just need to read the docs

help([].reverse)

Help on built-in function reverse:

reverse(...)
L.reverse() -- reverse *IN PLACE*

beliavsky> reverses x or if it returns a reversed list. If
beliavsky> x.reverse() does the former, a disadvantage relative to
beliavsky> the procedural approach is that a function can be used
beliavsky> in an expression. It is clearer and more concise to
beliavsky> write

beliavsky> z = reverse(x) + reverse(y)

The distinction is not OO versus procedural, it is a decision about
how you choose to write "reverse". The python list implementers of
the reverse object method could have decided to return a new reversed
list rather than do the reverse in place and return None. Then you
could have done

z = x.reverse() + y.reverse()

They could have chosen to reverse the list *in place* and also
returned a reference to self rather than None, in which case you could
do the above as well. w/o digging up the transcripts from the
python-dev mailing list, my guess is that they choose to do it in
place for efficiency in memory and cpu, and chose not to return self
to prevent user confusion. Ie, if a user was allowed to do 'z =
x.reverse() + y.reverse()' they might be surprised to find the side
effect of in place modification.

Likewise, I could easily write a procedural "in place" reverse that
returns None, in which case 'z = reverse(x) + reverse(y)' would not do
what you suggest. My point is that whether a function/method such as
reverse operates in place or on a copy, and whether it returns None or
a reference to a list is independent of OO vs procedural style and is
motivated by considerations of efficiency, readability, and usability.

beliavsky> Furthermore, if in Python the algorithm for the reverse
beliavsky> function applies to many kinds of objects, it just
beliavsky> needs to be coded once, whereas a reverse method would
beliavsky> have to provided for each class that uses it (perhaps
beliavsky> through inheritance).

True, a generic reverse procedure/function can be applied to any data
structure that supports iteration. In the case of python, however,
some iterable data structures are mutable (lists, dicts) and some are
not (strings, tuples). For mutable sequences, an in place reverse is
likely to be more efficient in memory and perhaps CPU than a generic
reverse which returns a new copy. So a specialized method "reverse"
applicable to lists (but not strings and tuples) can be a big win.
Fortunately, python supports both, allowing you to define a general
"reverse" that works for any object that supports the sequence
protocol, as well as to define an object specific reverse method that
may be faster in time and space.

JDH

[Isaac To]

>>>>> "beliavsky" == beliavsky <be*******@aol. com> writes:

beliavsky> I think the OO way is slightly more obscure. It's
beliavsky> obvious what x = reverse(x) does, but it is not clear
beliavsky> unless you have the source code whether x.reverse()
beliavsky> reverses x or if it returns a reversed list.

What make it so clear to you that reverse(x) will always return a
reversed list rather than reversing x in place and return nothing?

beliavsky> It is clearer and more concise to write
beliavsky> z = reverse(x) + reverse(y)
beliavsky> than
beliavsky> x.reverse()
beliavsky> y.reverse()
beliavsky> z = x + y

This isn't anything to do with OO programming. It is something about
using in interface that your audience expects. You have exactly the
same problem whether you are using procedural or OO style. It might
be a case for functional programming, but that's something off-topic.

beliavsky> Furthermore, if in Python the algorithm for the reverse
beliavsky> function applies to many kinds of objects, it just
beliavsky> needs to be coded once, whereas a reverse method would
beliavsky> have to provided for each class that uses it (perhaps
beliavsky> through inheritance).

That the reverse() wants to be a function doesn't mean that the thing
that reverse() operate on doesn't want to be an object. So this isn't
very clear a problem about OO style vs. procedural style, but instead
a problem about "generic" programming style vs. "concrete" programming
style. On the other hand, if the thing that reverse() operate on
isn't an object sharing the same interface, it will be more clumsy to
implement a generic reverse() that works for all the different kinds
of object---even if they share similar interfaces. Try to implement a
generic "reverse" in C when the different type of containers are
encoded as different style struct's accessible from different
function, and you will understand what I mean. So this is,
marginally, a case *for* OO style.

Regards,
Isaac.

[Craig Ringer]

On Wed, 2005-01-26 at 22:28 -0500, Davor wrote:

I browsed docs a bit today, and they also confirm what I have believed -
that OO is totally secondary in Python. In fact,
object/classes/metaclasses are nothing but *dictionaries with identity*
in python. Love this approach.

I was really impressed with the design of the language, especially this
bit. I first "got" it when reading Learning Python 2nd Ed (well *after*
I'd been using Python for a while, but it's always good to read even
intro books to fill out "obvious" things you might've missed). I love
the way the same "It's just a dictionary search" principle applies to
inheritance, scoped variable lookups, etc.

In Python, even metaclasses just operate on the class dictionary. How
pleasantly simple :-) - especially how the step from class factory to
metaclass is so small and approachable.

I also love the way I can chuck a bunch of objects into a functionally
styled processing pipeline, say a series of functions that each just
return the result of a listcomp/genexp.

--
Craig Ringer

[michele.simionato]

Davor wrote:

Thanks,

I do not hate OO - I just do not need it for the project size I'm
dealing with - and the project will eventually become open-source and
have additional developers - so I would prefer that we all stick to
"simple procedural" stuff rather than having to deal with a developer
that will be convincing me that his 50 layers inheritance hierarchy is good since it exists in some weird pattern that he saw somewhere on
some Java design patterns discussion board :-) and other "proper" OO
design issues... Once I opted for C++ in a very small project and
believed everyone will stick with C subset + better type checking
offered through C++ - but I simply could not manage to keep them off
using OO stuff which was just making program more complicated than it
should have been. (note, I am not an experienced developer, nor the
others I'll be working with (even though some think they are:-)), so I prefer preemptively dealing with issue of everyone showing off their OO design skills)

I think Davor is making an important point here: Python has grown in
the last 14 years, and it is no more the simple scripting language
it used to be. In particular, it evolved a lot of OOP "cruft"
(static/classmethods, properties, the __new__ method, super, the new
MRO, descriptors,met aclasses, etc.) and there is more than a learning
curve issue coming with the added complexity. Davor is right: even if
you do not want to use it, the stuff is *there* and somebody in your
team will. So definitely there is an audience of programmers that just
do not have an use for all the sophistication and actually are
penalized by it.

There is not much than can be done at the Python level. But I would
see with interest a Python spinoff geared towards simplicity. Few
months ago there was the Prothon proposal (by all means a terrible
proposal) but the goal that motivated it (simplification , trying
to remove classes) was in my opinion worthwhile.

Now, *how* to remove (or simplify) classes is not at all clear to me,
not I am convinced that prototypes are the right way to go, but still I
feel that there is something wrong with inheritance. Maybe
protocols are the solution, who knows? But in any case I think it
is important to keep searching for semplicity. I do not believe
Python is the definitive language, and it is probabily possible
to introduce something better. It is just that nothing of the
kind appeared until now, but I keep watching at the horizon ;)
Michele Simionato

[Timo Virkkala]

Davor wrote:

Timo Virkkala wrote:

This guy has got to be a troll. No other way to understand.

not really - it was not my intention at all - but it seems people get
upset whenever this OO stuff is mentioned - and what I did not expect at
all at this forum as I believed Python people should not be so OO
hardcore (seems not all as quite a few have indicated in their
replies)... Nevertheless, I think the discussion has several quite good
points!

Yes, sorry about that. I posted too soon. After posting I read more of your
posts and realized that you really mean it, so I tried to cancel my message, but
apparently it got through (news message canceling has never been that reliable..).

I believe that if you take the time to do some Python programming, you can find
out that OO, when used correctly, is not the huge monster your previous
languages had led you to believe it is. In Python, you can use just the right
amount of OO to make things easier and more sensible, without complicating
things with huge inheritance trees and unnecessary polymorphism.

Again, sorry about my premature judgement.

--
Timo Virkkala

[Timo Virkkala]

be*******@aol.c om wrote:

I think the OO way is slightly more obscure. It's obvious what x =
reverse(x) does, but it is not clear unless you have the source code
whether x.reverse() reverses x or if it returns a reversed list. If
x.reverse() does the former, a disadvantage relative to the procedural
approach is that a function can be used in an expression. It is clearer
and more concise to write

Sure, it's clear if in written code you see

x = reverse(x)

To me it would also be clear to see

x.reverse()

But what if you just see in some list that there is a reverse(sequenc e)
function, or that a sequence has a reverse() method? To me, neither of these is
clear. Do they return a new, reversed sequence or reverse in place?

When creating a new API, I would probably use a convention where reverse does it
in place and reversed returns a new. So, in my API,

reverse(x)
y = reversed(x)
x.reverse()
y = x.reversed()

--
Timo Virkkala