Not fully OO ?

[Kay Schluehr]

It sounds like you think that you -can- write OO programs in Python,
but you don't have to. I agree.

The whole point of OO is providing high level ( system level ) not low
level ( interpreter level ) semantics. Partitioning a system into
isolated and communicating objects is a strong and important metaphor.
Recently there were some comments on the web that mentioned Erlang to
be pretty much OO in this respect although Erlang is functional and
has no base level notion of an "object". It's even well known that Joe
Armstrong holds low opinions about the entire object business.

Notice that I believe that the popular meme that OO is "bolted on"
Python has little if nothing to do with OO itself but with API
consistency. When people have to type len(x) instead of x.len() this
breaks their expectations on how the language has to behave.

 

[Méta-MCI (MVP)]

Hi!

Everything ... are an object.

It's true ; but a language built around the objects, and OOP, are two
different concepts.

@-salutations

 

[Méta-MCI \(MVP\)]

Bonjour !

AMHA, ceux qui ont écrit ce texte ont une mauvaise idée de ce que sont
les variables en Python.
Ils ont sans doute trop en tête les notions des variables en C ou en
Basic, et ne se sont pas penchés sur les spécificités de Python.

@-salutations

 

[Fredrik Lundh]

I don't think he meant that Python is wrong somehow, but that the OO
babble of what happens for 2+2 is wrong. The babble said that, when the
code is executed, an __add__ message is sent to the 2 object, with
another 2 object as the parameter. That statement is incorrect: no
message is sent at all, but the result is available even before the
program starts.

On the other hand, the inability to distinguish between "as if" and
"hah, I've looked under the covers" isn't necessarily a good trait for a
programmer. If he bases his mental model on concrete implementation
details of a production quality software product, he's bound to end up
with a cargo-cultish understanding of fundamental issues. If he uses it
to win arguments, people will flip his bozo bit pretty quickly.

</F>

 

[Ricardo Aráoz]

The whole point of OO is providing high level ( system level ) not low
level ( interpreter level ) semantics. Partitioning a system into
isolated and communicating objects is a strong and important metaphor.
Recently there were some comments on the web that mentioned Erlang to
be pretty much OO in this respect although Erlang is functional and
has no base level notion of an "object". It's even well known that Joe
Armstrong holds low opinions about the entire object business.

Notice that I believe that the popular meme that OO is "bolted on"
Python has little if nothing to do with OO itself but with API
consistency. When people have to type len(x) instead of x.len() this
breaks their expectations on how the language has to behave.

x.__len__()

 

[Craig Allen]

It is clear to me that Python is a multiparadigmed object oriented
language. It is clearly possible to write procedural code... that is,
Python does not force object oriented syntax or concepts on you and
insist you define everything in such a structure. Is the OO it allows
full OO, I think so, and the only way to argue otherwise I think is to
point out that the "main" function is just the module level itself,
and is not part of an object... which is just the sort of pedantic
things purists like to hang their hat on.

personally I am very much the sort that believe in "trust the
programmer" and likes languages that provide a freedom to use various
complementary paradigms, in the style of C++. Compared to that, it's
clear that Python is quite object oriented even in the sense of
drawing you to build things in object oriented ways... just not
strictly requiring it. Which is good, it allows some interesting
patterns which play quite well with object oriented desirgn (i.e.
module as singleton)... in fact, that plays so well as a singleton,
some would say the module is just an object anyway, and indeed, the
intepreter tends to agree.

So python may turn out to be pure OO, where Objects SIMULATE
procedural programming paradigms and allow that paradigm as a result,
on top of OO.

cheers.

 

[Tim Rowe]

So python may turn out to be pure OO

I think that's the sort of thing the pedants would hang that hats on,
too. Python isn't *pure* OO, in that it lets the programmers do non-OO
if they want to, but it is *fully* OO in that it includes everything
required to do OO. But maybe the original blogger meant by "fully OO"
what I mean by "Pure OO"?

The question I usually ask is "Does this language help me get the job
done?" Python often does. That's all that really matters, isn't it?

 

[Craig Allen]

if they want to, but it is *fully* OO in that it includes everything

required to do OO. But maybe the original blogger meant by "fully OO"
what I mean by "Pure OO"?

it seems to me this is what was meant... pure OO, AND forced to use
it.

My personal feeling is that python is multiparadigmed and I'm more
than fine with that.

BUT, I am going to hold onto what I've noticed which is that Python
seems to use OO deeply, well into the interpreter, and that the
procedural styles available at the Python source level pretty much are
built on top of this OO model, given you accept a module as an object,
which it seems to be within the source code... but in the end, it's
just words and the most important thing is that python is a tool you
can use to make a computer do what you want, and whatever you call it
may just be a distraction. cheers.

 

[Lawrence D'Oliveiro]

In message

It is clearly possible to write procedural code... that is,
Python does not force object oriented syntax or concepts on you ...

Object orientation IS procedural.

 

[Lawrence D'Oliveiro]

"... Python supports OOP and classes to an extent, but is not a full OOP
language."

Python allows you to use OO-style constructs, but doesn't force you to have
inheritance and subclasses if you don't want to. Duck typing is usually a
much more flexible approach.

 

[James Mills]

Object orientation IS procedural.

Correction: OOP is Imperative.

--JamesMills

 

[Lawrence D'Oliveiro]

In message

Wikipedia puts it decently: "mainly for OO programming, but with some
procedural elements."

"Procedural" is the opposite of "functional", not "object-oriented".

 

[Bruno Desthuilliers]

Lawrence D'Oliveiro a écrit :

In message


"Procedural" is the opposite of "functional", not "object-oriented".

AFAIK, the "opposite" if functional is imperative, not procedural. But
let's not waste too much time on terminology arguments...

 

[Steven D'Aprano]

AFAIK, the "opposite" if functional is imperative, not procedural. But
let's not waste too much time on terminology arguments...

We're not wasting time on terminology arguments, we're wasting time on
definitional debates.

 

[Patrick Mullen]

Depending on the scale of the website I am making, how much I care
about editing it in the future, and how much I just want to get
something up, I will occasionally use php. And I am a self confessed
php hater But it's generally the fastest way I know to get
something up. So even terrible languages can have their uses!

 

[Bruno Desthuilliers]

Patrick Mullen a écrit :

Depending on the scale of the website I am making, how much I care
about editing it in the future, and how much I just want to get
something up, I will occasionally use php. And I am a self confessed
php hater But it's generally the fastest way I know to get
something up. So even terrible languages can have their uses!

Sorry but I fail to see how it relates to the current thread ???

 

[Steven D'Aprano]

Patrick Mullen a écrit :

Sorry but I fail to see how it relates to the current thread ???

I think Patrick is responding to a comment from Tino Wildenhain:

Well then it still depends on the perception of "job done". For example
PHP programmers would bet their soul that their language of choice is
exactly the right one to "get the job done."
[end quote]

Patrick, you will cause much less confusion if you quote relevant parts
of the text you are replying too.

 

[Tim Rowe]

Well then it still depends on the perception of "job done". For example
PHP programmers would bet their soul that their language of choice is
exactly the right one to "get the job done."
You and me would indeed see a different picture on the level of doneness
of such jobs ;-)

Well, I did say "Often". Before now I've struggled for ages to write a
Python program to do a job, then when I've tried C# all the problems
have fallen away and the job was done in an hour or so. But other
times it has been the other way around; I've done stuff in Python that
I wouldn't know where to begin with in other languages. One of my
constant refrains is that *no* tool is ideal for *all* jobs!

 

[Aaron \Castironpi\ Brady]

Well, I did say "Often". Before now I've struggled for ages to write a
Python program to do a job, then when I've tried C# all the problems
have fallen away and the job was done in an hour or so. But other
times it has been the other way around; I've done stuff in Python that
I wouldn't know where to begin with in other languages. One of my
constant refrains is that *no* tool is ideal for *all* jobs!

I thought procedural and imperative were the same.

"Sorry, but you forgot to phrase your expression in the form of a
command."
I'll take 'modules' for $500, Alex.

 

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

We're not wasting time on terminology arguments, we're wasting time on
definitional debates.

Point taken. But still a waste of time !-)