python without OO

[Francis Girard]

Re: python without OO

Le mercredi 26 Janvier 2005 02:43, Jeff Shannon a écrit :
[color=blue]
> In statically typed languages like C++ and Java, inheritance trees are
> necessary so that you can appropriately categorize objects by their
> type. Since you must explicitly declare what type is to be used
> where, you may need fine granularity of expressing what type a given
> object is, which requires complex inheritance trees. In Python, an
> object is whatever type it acts like -- behavior is more important
> than declared type, so there's no value to having a huge assortment of
> potential types. Deep inheritance trees only happen when people are
> migrating from Java. ;)
>
> Jeff Shannon
> Technician/Programmer
> Credit International[/color]

These lines precisely express my thoughts. Most of the difficulties in OO in
Java/C++ comes from the all mighty goal of preserving type safety. Type
safety is certainly a very desirable goal but it, sometimes, leads to very
complex code only to achieve it. The prize is just too high. The design
patterns that were supposed to save time through high code reuse oftenly
becomes a maintenance nightmare. Something that no one in the company can
understand except a few. Instead of trying to fix some domain specific code,
you end up trying to fix a supposedly highly reusable code that, oh well, you
have to adapt. This is espeacially true if the system had been designed by a
big OO-design-patterns enthusiastic programmer geek.

I am not saying that design patterns are bad. I think that they are an
invaluable gift to OO. I'm only saying that they have indeed a perniciuous
and pervert effect in the real world industry. People become religious about
it and forget to think about a simple solution ...

Being dynamically typed, these kind monster patterns are much less probable.
And the Python philosophy and culture is the very contrary to that trend.

I've been involved in C++/Java projects for the last 8 years. The first time I
met Python, I've been frigthen by its lack of static type safety. But over
the time, I've been convinced by seeing clean Python code over and over
again. In the end, I could appreciate that being simple leads the way to less
bugs, which type safety was supposed to prevent ... Coming from the C++
community, Python had been just like fresh air. It changed me from the
nightmare derscribed in that discussion thread. When I think that comapnies
pay big money for these kind of monsters after having seen a few ppt slides
about it, it makes me shiver.

Regards,

Francis Girard
FRANCE

[PA]

Re: python without OO


On Jan 26, 2005, at 20:39, Francis Girard wrote:
[color=blue]
> When I think that comapnies
> pay big money for these kind of monsters after having seen a few ppt
> slides
> about it, it makes me shiver.[/color]

Right... but... since when does an implementation language of any sort
save a project from its own doom?

Project fails for many reasons but seldomly because one language is
"better" or "worst" than another one.

Cheers

--
PA

http://alt.textdrive.com/

[Francis Girard]

Re: python without OO

Le mercredi 26 Janvier 2005 20:47, PA a écrit :
[color=blue]
> Project fails for many reasons but seldomly because one language is
> "better" or "worst" than another one.[/color]

I think you're right. But you have to choose the right tools that fit your
needs. But I think that's what you meant anyway.
[color=blue]
>
> Cheers
>[/color]

Cheers too,

Francis Girard
FRANCE
[color=blue]
> --
> PA
> http://alt.textdrive.com/[/color]

[Frans Englich]

Re: python without OO

On Wednesday 26 January 2005 18:55, Terry Reedy wrote:
[color=blue]
> Your Four Steps to Python Object Oriented Programming - vars, lists, dicts,
> and finally classes is great. It makes this thread worthwhile. I saved it
> and perhaps will use it sometime (with credit to you) to explain same to
> others.[/color]

I think so too. M.E. Farmer's reflections on management was also a shining
piece of gold in this thread.


Cheers,

Frans

[PA]

Re: python without OO


On Jan 26, 2005, at 21:35, Francis Girard wrote:
[color=blue][color=green]
>> Project fails for many reasons but seldomly because one language is
>> "better" or "worst" than another one.[/color]
>
> I think you're right. But you have to choose the right tools that fit
> your
> needs. But I think that's what you meant anyway.[/color]

Yes. But even with the "best" tool and the "best" intents, projects
still fail. In fact, most IT projects are considered failures:

http://www.economist.com/business/PrinterFriendly.cfm?Story_ID=3423238

Cheers

--
PA

http://alt.textdrive.com/

[Francis Girard]

Re: python without OO

Le mercredi 26 Janvier 2005 21:44, PA a écrit :[color=blue]
> On Jan 26, 2005, at 21:35, Francis Girard wrote:[color=green][color=darkred]
> >> Project fails for many reasons but seldomly because one language is
> >> "better" or "worst" than another one.[/color]
> >
> > I think you're right. But you have to choose the right tools that fit
> > your
> > needs. But I think that's what you meant anyway.[/color]
>
> Yes. But even with the "best" tool and the "best" intents, projects
> still fail. In fact, most IT projects are considered failures:
>
> http://www.economist.com/business/Pr...ory_ID=3423238[/color]

Well, let's go back home for some gardening. My wife will be happy.
[color=blue]
>
> Cheers
>
> --
> PA
> http://alt.textdrive.com/[/color]

[Marc 'BlackJack' Rintsch]

Re: python without OO

In <ct786k$u42$05$ 2@news.t-online.com>, Frank Bechmann (w) wrote:
[color=blue]
> know what's funny: in the Lua mailing list there is currently a
> discussion about adding OO to Lua.[/color]

From my quick glance at the language last year I recall that one can
access elements of tables (in Python: dict()) with this syntax:
``tbl.attr`` and it's also possible to put functions into those tables. So
it's already a prototype based OO language. Remember: you need objects
for an OO language -- classes are optional!

Ciao,
Marc 'BlackJack' Rintsch

[beliavsky@aol.com]

Re: python without OO

Nick Coghlan wrote:[color=blue]
> Davor wrote:[color=green]
> > thanks for the link
> >
> >[color=darkred]
> >>know what's funny: in the Lua mailing list there is currently a
> >>discussion about adding OO to Lua.[/color]
> >
> >
> > I guess most of these newer languages have no choice but to support[/color][/color]
OO[color=blue][color=green]
> > if they want to attract a larger user base :-(...[/color]
>
> Tell me, have you ever defined a C structure, and then written[/color]
various functions[color=blue]
> to operate on that structure (i.e. taking a pointer to the structure[/color]
as their[color=blue]
> first argument)?
>
> Have you then put both the structure definition and the function[/color]
prototypes into[color=blue]
> a single header file and used that header file from other code?
>
> That's OO programming: associating several pieces of information as[/color]
an 'object',[color=blue]
> and associating various methods to operate on instances of those[/color]
objects.

Then why was C++ invented? What you have described can be done in C,
Pascal, and Fortran 90, all of which are generally classified as
procedural programming languages. As Lutz and Ascher say in "Learning
Python", in object-based programming one can pass objects around, use
them in expressions, and call their methods. "To qualify as being truly
object-oriented (OO), though, objects need to also participate in
something called an inheritance hierarchy." Whether true OOP is a Good
Thing is arguable and depends on the situation.

[Timo Virkkala]

Re: python without OO

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

--
Timo Virkkala

[Davor]

Re: python without OO

Timo Virkkala wrote:[color=blue]
> This guy has got to be a troll. No other way to understand.[/color]

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!

[John Hunter]

Re: python without OO

>>>>> "Davor" == Davor <davorss@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.[color=blue][color=green][color=darkred]
>>> import this[/color][/color][/color]
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]

Re: python without OO

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@aol.com]

Re: python without OO

John Hunter wrote:[color=blue][color=green][color=darkred]
> >>>>> "Davor" == Davor <davorss@gmail. com> writes:[/color][/color]
>
> 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.[/color]

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]

Re: python without OO

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

Re: python without OO

>>>>> "beliavsky" == beliavsky <beliavsky@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
[color=blue][color=green][color=darkred]
>>> help([].reverse)[/color][/color][/color]
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