python without OO

[Isaac To]

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()
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]

Re: python without OO

On Wed, 2005-01-26 at 22:28 -0500, Davor wrote:
[color=blue]
> 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.[/color]

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

Re: python without OO

Davor wrote:[color=blue]
> 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[/color]
is[color=blue]
> 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[/color]
I[color=blue]
> prefer preemptively dealing with issue of everyone showing off their[/color]
OO[color=blue]
> design skills)
>[/color]

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]

Re: python without OO

Davor wrote:[color=blue]
> Timo Virkkala wrote:[color=green]
>> 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![/color]

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]

Re: python without OO

beliavsky@aol.c om wrote:[color=blue]
> 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[/color]

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

[Peter Maas]

Re: python without OO

Terry Reedy schrieb:[color=blue]
> But if the class method syntax were
> manditory, there would be class and/or class hierarchy bloat due to the
> unlimited number of possible functions-of-a-float and large number of
> actual such functions that have been written.[/color]

You are right. I'm not an OO purist, I just wanted to convince Davor,
that anti-OO purism can be harmful too. It's good for programmers to
have a choice.
[color=blue]
> Your Four Steps to Python Object Oriented Programming - vars, lists, dicts,
> and finally classes is great.[/color]

I'm glad you like it :)

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0 BtcGx1c3IuZGU=\ n'.decode('base 64')
-------------------------------------------------------------------

[Peter Maas]

Re: python without OO

Davor schrieb:[color=blue]
> I browsed docs a bit today, and they also confirm what I have believed -
> that OO is totally secondary in Python.[/color]

OO is not secondary in Python. It's secondary for you :) And Python
leaves the choice to you.
[color=blue]
> In fact,
> object/classes/metaclasses are nothing but *dictionaries with identity*
> in python.[/color]

Eliminating "nothing but" makes this a true statement :)

[color=blue]
> 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...[/color]

I believe that your belief is wrong :) Guido van Rossum has introduced
OO to Python because it's a useful concept.
[color=blue]
> 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..[/color]

Sigh. Proceed as you like but be aware that dogmatism - OO as well as
anti-OO is always a poor guide. OO wasn't invented as a marketing buzz
but to support programming styles that emerged in non-OO languages to
control the increasing complexity of programs.
[color=blue]
> 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...[/color]

The bad thing about OO preachers is not OO but preaching. And you
are preaching, too ;)

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0 BtcGx1c3IuZGU=\ n'.decode('base 64')
-------------------------------------------------------------------

[Nick Coghlan]

Re: python without OO

beliavsky@aol.c om wrote:[color=blue]
> 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).[/color]

Indeed, this is why Python not only provides the list.reverse() method to
reverse a list in place, but also provides the reversed() function to reverse
any sequence:

Py> lst = list("ABCDEFGHI J")
Py> lst.reverse()
Py> print "".join(lst )
JIHGFEDCBA
Py> print "".join(reverse d(lst))
ABCDEFGHIJ

Ditto list.sort() and sorted().

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@email. com | Brisbane, Australia
---------------------------------------------------------------

http://boredomandlaziness.skystorm.net

[Nick Coghlan]

Re: python without OO

beliavsky@aol.c om wrote:[color=blue]
> 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."[/color]

Again, behavioural inheritiance is something which can be done manually via
delegation or function tables.

What a language with OO support adds is special syntax for something that you
could have done anyway - the OO support just makes it easier and clearer (well,
C++ aside).

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@email. com | Brisbane, Australia
---------------------------------------------------------------

http://boredomandlaziness.skystorm.net

[Peter Maas]

Re: python without OO

michele.simiona to@gmail.com schrieb:[color=blue]
> 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.[/color]

No, because Python does not enforce using advanced concepts. You
can write programs that are as simple as in 1991. A group of developers
always has to find some kind of common style with a chance that some
are penalized. This can happen with every language.
[color=blue]
> There is not much than can be done at the Python level. But I would
> see with interest a Python spinoff geared towards simplicity.[/color]

I think this would be useless because advanced concepts exist for
a reason. A simplified spin-off would aquire advanced concepts
over time and would just become a clone of Python.

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0 BtcGx1c3IuZGU=\ n'.decode('base 64')
-------------------------------------------------------------------

[Nick Coghlan]

Re: python without OO

Davor wrote:[color=blue]
> data structures
> and
> functions that operate on these data structures[/color]

Eh? What do you think a class is?

Py> data = range(10)
Py> list.extend(dat a, range(5))
Py> list.sort(data)
Py> print data
[0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 6, 7, 8, 9]

The fact that data.extend(ran ge(5)) and data.sort() are alternative spellings
for the second and third lines doesn't change the fact that a class is just a
data structure grouped with a bunch of functions that operate on that data
structure.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@email. com | Brisbane, Australia
---------------------------------------------------------------

http://boredomandlaziness.skystorm.net

[michele.simionato@gmail.com]

Re: python without OO

Peter Maas:[color=blue]
>michele.simion ...@gmail.com schrieb:[/color]
[color=blue][color=green]
>> 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[/color][/color]
just[color=blue][color=green]
>> do not have an use for all the sophistication and actually are
>> penalized by it.[/color][/color]
[color=blue]
>No, because Python does not enforce using advanced concepts. You
>can write programs that are as simple as in 1991. A group of[/color]
developers[color=blue]
>always has to find some kind of common style with a chance that some
>are penalized. This can happen with every language.[/color]

No. In theory C++ could be kept as simple as C but in practice it is
not.
[color=blue][color=green]
>> There is not much than can be done at the Python level. But I would
>> see with interest a Python spinoff geared towards simplicity.[/color][/color]
[color=blue]
>I think this would be useless because advanced concepts exist for
>a reason. A simplified spin-off would aquire advanced concepts
>over time and would just become a clone of Python.[/color]

And then we will need another simplified spinoff ;)
There is always a fight between simplificity and complexity.
Some complexity is not needed, and I am sure even in Python
something could be dropped. But it is difficult to find what can
be removed. Remember that Saint-Exupery quote? Something
like "a work of art is finished when there is nothing left to remove?"
M.S.

[Alex Martelli]

Re: python without OO

<michele.simion ato@gmail.com> wrote:
...[color=blue]
> Some complexity is not needed, and I am sure even in Python
> something could be dropped. But it is difficult to find what can
> be removed. Remember that Saint-Exupery quote? Something
> like "a work of art is finished when there is nothing left to remove?"[/color]

Saint-Éxupery was an engineer (and a pioneer of flight) and so he was
referring to a designer (and no doubt had in mind those planes...), not
to an artist (not his fault if he's better remembered as a novelist;-).

As for what can be removed from Python, one could start at
<http://www.python.org/peps/pep-3000.html> -- while each of us will find
there some "complexity " one loves and uses often (be it lambda, buffer,
reload, ...), it's a good start.


Alex

[Alex Martelli]

Re: python without OO

PA <petite.abeille @gmail.com> wrote:
[color=blue]
> 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]

The main thesis of the article you quote (although it acknowledges that
other think differently) is that better tools (including iterative, NOT
waterfall, development; and, agile programming approaches, more
generally) are the way to mitigate that horrid track record.


Alex

[beliavsky@aol.com]

Re: python without OO

michele.simiona to@gmail.com wrote:
[color=blue][color=green][color=darkred]
> >> There is not much than can be done at the Python level. But I[/color][/color][/color]
would[color=blue][color=green][color=darkred]
> >> see with interest a Python spinoff geared towards simplicity.[/color][/color]
>[color=green]
> >I think this would be useless because advanced concepts exist for
> >a reason. A simplified spin-off would aquire advanced concepts
> >over time and would just become a clone of Python.[/color]
>
> And then we will need another simplified spinoff ;)
> There is always a fight between simplificity and complexity.
> Some complexity is not needed, and I am sure even in Python
> something could be dropped. But it is difficult to find what can
> be removed. Remember that Saint-Exupery quote? Something
> like "a work of art is finished when there is nothing left to[/color]
remove?"[color=blue]
> M.S.[/color]

"Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."

I know this quote because it is the motto of the F programming language
http://www.fortran.com/F/ , a "simplified spinoff" of Fortran 95.