469,353 Members | 2,066 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,353 developers. It's quick & easy.

python without OO

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

Jul 18 '05
63 4542
Terry Reedy schrieb:
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.
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.
Your Four Steps to Python Object Oriented Programming - vars, lists, dicts,
and finally classes is great.


I'm glad you like it :)

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------
Jul 18 '05 #51
Davor schrieb:
I browsed docs a bit today, and they also confirm what I have believed -
that OO is totally secondary in Python.
OO is not secondary in Python. It's secondary for you :) And Python
leaves the choice to you.
In fact,
object/classes/metaclasses are nothing but *dictionaries with identity*
in python.
Eliminating "nothing but" makes this a true statement :)

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


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 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------
Jul 18 '05 #52
be*******@aol.com wrote:
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).


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("ABCDEFGHIJ")
Py> lst.reverse()
Py> print "".join(lst)
JIHGFEDCBA
Py> print "".join(reversed(lst))
ABCDEFGHIJ

Ditto list.sort() and sorted().

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05 #53
be*******@aol.com wrote:
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."


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 | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05 #54
mi***************@gmail.com schrieb:
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.
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.
There is not much than can be done at the Python level. But I would
see with interest a Python spinoff geared towards simplicity.


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 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------
Jul 18 '05 #55
Davor wrote:
data structures
and
functions that operate on these data structures


Eh? What do you think a class is?

Py> data = range(10)
Py> list.extend(data, 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(range(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 | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05 #56
Peter Maas:
michele.simion...@gmail.com schrieb:
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. No, because Python does not enforce using advanced concepts. You
can write programs that are as simple as in 1991. A group of developersalways has to find some kind of common style with a chance that some
are penalized. This can happen with every language.
No. In theory C++ could be kept as simple as C but in practice it is
not.
There is not much than can be done at the Python level. But I would
see with interest a Python spinoff geared towards simplicity.

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.


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.

Jul 18 '05 #57
<mi***************@gmail.com> wrote:
...
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?"


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

Jul 18 '05 #58
PA <pe************@gmail.com> wrote:
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


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
Jul 18 '05 #59
mi***************@gmail.com wrote:
There is not much than can be done at the Python level. But I would see with interest a Python spinoff geared towards simplicity.
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.


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.


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

Jul 18 '05 #60
> "Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."


Thanks, that was it! ;)

Jul 18 '05 #61
Davor wrote:
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)


Many people have answered your question already, but I thought I would
share my opinion as well, since I think I understand where you are
coming from.

What attracted me to Python was not OO at all but the fact that it was
somewhat similar to PHP (which I was using heavily at the time) but
allowed me to encode certain higher-order programming techniques that
PHP simply could not express. In short, I had become interested in
functional programming after reading David Mertz's "Charming Python"
tutorials, and after x attempts at trying to port the ideas to PHP, I
finally gave up in frustration and started learning Python.

At the time, I was decidedly anti-OO. I grew up around a very liberal,
punk-rock, nonconformist culture, and the amount of hype around OO made
it too easy to hate (and, I suppose, it still does). PHP at the time was
90% procedural; the prevaling attitude (which seems to have changed with
the advent of PHP5) was that procedural code is all you need to solve
most problems. With web scripting, it kind of makes sense, because
(IMHO) objects really don't have much value unless you can hold onto
them long enough for them to be useful, and many web scripts just pipe
data from one place to another. Packing the data into objects is kind of
like putting your possessions into boxes so that you can move them from
one room to another and immediately unpack.

So, I guess you could say, I learned Python in spite of its rich support
for OO. =)

It wasn't until I had to implement a large (to me), complex, graphical
user interface, that I finally had to get off of my soapbox and realize
that I had no better way to create sophisticated GUIs than OO. There are
surely non-OO ways to build fancy GUIs, like functional-reactive
programming, but a) I don't understand them, and b) I had to get my
project done, and used the tools I had and the techniques I knew.

At that time, I started learning about Smalltalk and Alan Kay's emphasis
on the "messaging" aspect of OO, and it started making a lot more sense.
One of the most difficult tasks sometimes is getting various parts of
the screen to update when the user changes a field or clicks a
button--in a way that is manageable and doesn't devolve into spaghetti.

Aside from GUIs, however, I am rarely confronted with a task where I
*need* OO. As a method for encoding abstract data types, it works, but
it seems like more fashion than substance. As many have pointed out, the
difference between "method(obj, args)" and "obj.method(args)" is subtle,
and often inconsequential. In Python, you can program with just modules
and functions/procedures, and never bother with the fact that you are
using objects. Sure, a module is an object, and so is a procedure, but
it's not all up in your face like, say, Java's arcane restriction that
everything belong to some class.

It has been said of Perl programmers that they often dislike
abstraction. Sometimes, I really sympathize with this viewpoint. I hate
having to use a class that offers no value to the problem whatsoever,
merely because an API is hard-wired to use instances of that class. No
abstraction can often be better than a bad abstraction, and when it
comes to debugging, the last thing you want is a bunch of black boxes.

These days, I do use classes and objects in Python, but mainly as a code
organization technique, and only when I actually want my code organized
that way. I tend to start with the problem at hand, building procedures
to remove redundancy and keep my code small and simple. If I start
noticing that a lot of procedures revolve around a particular data
structure, I refactor them into a class. This way, I avoid creating
abstractions that don't fit. It's much more mechanical than any feigned
attempt at "modeling the real world".

I think that functional programming (FP) is a very powerful methodology
that can solve a lot of the same problems as OO, and does some things a
lot better. FP and OO can live in harmony to some extent, but there are
some places where they contradict each other. For instance, FP offers a
mind-blowingly powerful tool called pattern matching, which is like a
switch/case statement on steroids. OO dogma insists that this "violates
encapsulation", and that any form of switch/case is evil... replace
conditional with polymorphism... replace conditional with
polymorphism... replace conditional with polymorphism... repl<hic> On
the other hand, implementing something as seemingly simple as a
"__str__" method in functional languages can be surprisingly non-trivial.

The lesson to be learned here is that each methodology (including
strctures/procedural) has its strong points and weak points, and there
are always tradeoffs to be made. OO's biggest strong point is that a lot
of people grok it, so it's a fashionable and friendly user interface for
a programmer. Python in particular emphasizes this point with its
no-nonsense, lightweight approach to defining classes and using objects.

However, and this really the main point I wanted to make: *no* paradigm
is sufficient to solve any interesting problem. I have gotten sucked
into coutless language and paradigm pissing matches only to go back to
my desk and try to finish a project I'm working on and realize that
(gasp!) programming is still hard. It never stopped being hard! And
sometimes the methodologies just create additional work (cf. jwz's
comment on regular expressions: "now you have two problems").

The best way to crack through tough problems is to learn as many methods
and techniques as you can, and develop an intuition for "the right tool
for the job". What matters most is that you solve the problem at hand,
in a way that people can hopefully understand and maintain later.

Good luck,
Dave
Jul 18 '05 #62
Davor wrote:
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 [...]


Replace "modules" with "classes" in the above quote, and you have the
very essence of object-oriented programming.

(What you describe here *is* object-oriented programming, you're just
trying to avoid the 'class' statement and use module-objects where
'traditional' OO would use class instances.)

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #63
Timo Virkkala wrote:
This guy has got to be a troll. No other way to understand.

--
Timo Virkkala


Not a troll, just another case of premature optimization run amok.

Jul 18 '05 #64

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Andrew Dalke | last post: by
68 posts views Thread by Lad | last post: by
99 posts views Thread by Shi Mu | last post: by
reply views Thread by Fuzzyman | last post: by
reply views Thread by Kurt B. Kaiser | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.