Aydan <hes### [at] hendrik-sachsenet> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > Aydan <hes### [at] hendrik-sachsenet> wrote:
> > > [begin code]
> > > class vector(object):
> > >   def __init__(self,x,y,z):
> > >     self.__x=x
> > >     self.__y=y
> > >     self.__z=z
> >
> > Is that really how you write OO code in Python? Is it just me, or does it
> > look like Python hasn't actually been specifically designed to be an OO
> > language?
> >
> What do you mean?

Well, for one, methods taking 'self' as a parameter seems highly unusual
because in the vast majority of OO programming languages all methods always
have an implicit pseudo-object (usually named 'self' or 'this'). Python
methods taking it explicitly just feels like a kludge that has been tacked
at a later time onto a non-OO language.

Using __ as a syntax to denote a special meaning of functions and variables
is also quite unusual, and likewise feels like a kludge. Programming
languages seldom give any special syntactic meaning to variables and
function names containing underscores. (Instead, they usually use actual
keywords to express, for example, member variable visibility.)

If these (and I'm sure other) syntactic decisions have been made since the
very beginning of Python, I must say that it's... unusual, to put it in
nice terms.

> Everything in Python is an object.

It's quite ambiguous to say that "X is an object".

In programming theory "object" is a synonym for "first-class citizen",
which in turn means that the entity can be stored in variables and data
structures, passed to and returned from subroutines, constructed at
run-time and has an identity (eg. a unique low-level memory address that
can be compared.)

For example a variable of type 'int' in C is an "object" by this definition
(in other words, it's a first-class citizen.) However, one would hardly
classify it as an "object" in the object-oriented sense of the word. For
example, it's not something that can be inherited from (which pretty much
makes it non-OO.)

"Object-oriented language" requires a bit more than just having "everything
is an object" (especially since it's unclear what's meant by "object" in
this context.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Aydan <hes### [at] hendrik-sachsenet> wrote:
> > Warp <war### [at] tagpovrayorg> wrote:
> > > Aydan <hes### [at] hendrik-sachsenet> wrote:
> > > > [begin code]
> > > > class vector(object):
> > > >   def __init__(self,x,y,z):
> > > >     self.__x=x
> > > >     self.__y=y
> > > >     self.__z=z
> > >
> > > Is that really how you write OO code in Python? Is it just me, or does it
> > > look like Python hasn't actually been specifically designed to be an OO
> > > language?
> > >
> > What do you mean?
>
> Well, for one, methods taking 'self' as a parameter seems highly unusual
> because in the vast majority of OO programming languages all methods always
> have an implicit pseudo-object (usually named 'self' or 'this'). Python
> methods taking it explicitly just feels like a kludge that has been tacked
> at a later time onto a non-OO language.
>
> Using __ as a syntax to denote a special meaning of functions and variables
> is also quite unusual, and likewise feels like a kludge. Programming
> languages seldom give any special syntactic meaning to variables and
> function names containing underscores. (Instead, they usually use actual
> keywords to express, for example, member variable visibility.)
>
> If these (and I'm sure other) syntactic decisions have been made since the
> very beginning of Python, I must say that it's... unusual, to put it in
> nice terms.
>
> > Everything in Python is an object.
>
> It's quite ambiguous to say that "X is an object".
>
> In programming theory "object" is a synonym for "first-class citizen",
> which in turn means that the entity can be stored in variables and data
> structures, passed to and returned from subroutines, constructed at
> run-time and has an identity (eg. a unique low-level memory address that
> can be compared.)
>
> For example a variable of type 'int' in C is an "object" by this definition
> (in other words, it's a first-class citizen.) However, one would hardly
> classify it as an "object" in the object-oriented sense of the word. For
> example, it's not something that can be inherited from (which pretty much
> makes it non-OO.)
>
> "Object-oriented language" requires a bit more than just having "everything
> is an object" (especially since it's unclear what's meant by "object" in
> this context.)
>
> --
>                                                           - Warp

I don't know why the pythonians did what they did, but keep in mind that python
is not a compiled language but a dynamic script language. Everything happens at
runtime.
print "\n".join(dir(int)) gives you all member functions of int.
Now you tell me if it's an OO object or not ;o)
As to why self is passed for instance functions? No idea, I see it as something
like main{} for C, it's just done like that and it doesn't disturb me.
I suppose it's a distinction between class functions and instance functions.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Shay <nomail@nomail> wrote:
> > I'm trying to improve myself in this area. I use objects, but there are some
> > things I think I just haven't wrapped my head around. I don't personally know
> > any programmers, so my though process has evolved, for the most part, in
> > isolation.
>
> I think that you might get more responses from the numerous programmers
> here if you ask something more concrete in a more concise and clear manner.
>
> I'm not saying this as any kind of criticism or attack. It's just that
> your post is a bit long and vague, which makes it difficult to discern
> what exactly is it that you have a problem with and what is it that you
> are looking for.
>
> Btw, where have you got the idea that methods shouldn't return anything?
> I have never heard of such a thing.
>
> --
>                                                           - Warp

Post a reply to this message

On 10/16/2012 5:06, Warp wrote:
> Well, for one, methods taking 'self' as a parameter seems highly unusual

A function that takes "self" as the first argument is a method. Otherwise 
it's a function.

> Using __ as a syntax to denote a special meaning of functions and variables
> is also quite unusual,

The constructor is named __init__

The operator+ method is named __add__

And so on. It just avoids special syntax and substitutes special names.

The variable __y is just a plain old variable with the name mangled for 
pseudoreadability, exactly like naming a member variable in C++ m_xyz so you 
remember it's a member variable when you use it. Personally, I never saw the 
point. But since Python doesn't have "private" vs "public" variables, people 
have taken to using leading underscores to mean "don't touch this from outside."

 > Programming
> languages seldom give any special syntactic meaning to variables and
> function names containing underscores. (Instead, they usually use actual
> keywords to express, for example, member variable visibility.)

Unless it, say, a destructor in C++ ;-)

Honestly, I always thought naming the constructor after the class was a 
terrible decision.

> very beginning of Python, I must say that it's... unusual, to put it in
> nice terms.

It *is* unusual. It's not especially broken.

-- 
Darren New, San Diego CA, USA (PST)
   "They're the 1-800-#-GORILA of the telecom business."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 10/16/2012 5:06, Warp wrote:
> > Well, for one, methods taking 'self' as a parameter seems highly unusual

> A function that takes "self" as the first argument is a method. Otherwise 
> it's a function.

Well, duh. How does that change what I said?

> > Using __ as a syntax to denote a special meaning of functions and variables
> > is also quite unusual,

> The constructor is named __init__

> The operator+ method is named __add__

> And so on. It just avoids special syntax and substitutes special names.

It substitutes special syntax by using special syntax... Sounds
contradictory to me.

-- 
                                                          - Warp

Post a reply to this message

On 10/20/2012 23:39, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> On 10/16/2012 5:06, Warp wrote:
>>> Well, for one, methods taking 'self' as a parameter seems highly unusual
>
>> A function that takes "self" as the first argument is a method. Otherwise
>> it's a function.
>
> Well, duh. How does that change what I said?

I'm just explaining why people pass "self" as the first parameter. It's 
basically a declaration.

>>> Using __ as a syntax to denote a special meaning of functions and variables
>>> is also quite unusual,
>
>> The constructor is named __init__
>
>> The operator+ method is named __add__
>
>> And so on. It just avoids special syntax and substitutes special names.
>
> It substitutes special syntax by using special syntax... Sounds
> contradictory to me.

Having underlings as part of the name isn't any more "special" than it is in 
C or C++.  However, I cannot name my own function "operator'" in C++ because 
the "operator" keyword actually is special syntax. I can name my function 
__quote__ in Python because that function name has no special meaning to the 
interpreter.

When the interpreter sees "a + b" it first looks to see who implements 
__add__, and then invokes that. If neither side implements __add__ then it 
goes to the default implementation of adding integers or floats or whatever.

However, my main point was to explain to you what was happening. Whether you 
think it's reasonable after it is explained is up to you.

-- 
Darren New, San Diego CA, USA (PST)
   "They're the 1-800-#-GORILA of the telecom business."

Post a reply to this message

On 10/20/2012 23:39, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> On 10/16/2012 5:06, Warp wrote:
>>> Well, for one, methods taking 'self' as a parameter seems highly unusual
>
>> A function that takes "self" as the first argument is a method. Otherwise
>> it's a function.
>
> Well, duh. How does that change what I said?

Well, to be more specific, you can call a function two ways:

abc(xyz, pdq)

or

xyz.abc(pdq)

They both do the same thing, except the second syntax says "pass xyz as the 
first argument to the function abc() found in the dictionary of the value of 
xyz."  So it's not really changing the syntax or declaring that it's a 
method in any way. It's just saying "I expect you to invoke this in a way 
that looks like a method, because I named the first argument 'self'." If you 
wanted to invoke it on some other object, you could just as easily invoke 
abc(that, pdq) and "self" would become "that".

It's a naming convention, nothing more. Unlike, say, the names of 
constructors and destructors, which things like Java, C++, and C# treat as 
special because they match the name of the enclosing class.

Remember, too, that names in Python are merely variables. A class doesn't 
have a name, but only the variable(s)/dictionary key(s) to which it is 
currently assigned.  So there's no way to identify special properties of a 
class, especially since you can modify the classes at run time.

-- 
Darren New, San Diego CA, USA (PST)
   "They're the 1-800-#-GORILA of the telecom business."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Having underlings as part of the name isn't any more "special" than it is in 
> C or C++.  However, I cannot name my own function "operator'" in C++ because 
> the "operator" keyword actually is special syntax.

'operator' is a keyword that's fairly descriptive. '__' in a variable name
as required syntax isn't very descriptive.

> I can name my function 
> __quote__ in Python because that function name has no special meaning to the 
> interpreter.

That's contradictory with:

> When the interpreter sees "a + b" it first looks to see who implements 
> __add__, and then invokes that.

So it does have a special meaning to the interpreter, or it doesn't?

-- 
                                                          - Warp

Post a reply to this message

On 10/22/2012 6:53, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> Having underlings as part of the name isn't any more "special" than it is in
>> C or C++.  However, I cannot name my own function "operator'" in C++ because
>> the "operator" keyword actually is special syntax.
>
> 'operator' is a keyword that's fairly descriptive. '__' in a variable name
> as required syntax isn't very descriptive.

That's a fair complaint.

>> I can name my function
>> __quote__ in Python because that function name has no special meaning to the
>> interpreter.
>
> That's contradictory with:
>
>> When the interpreter sees "a + b" it first looks to see who implements
>> __add__, and then invokes that.
>
> So it does have a special meaning to the interpreter, or it doesn't?

As I thought I said, __add__ has special meaning, __quote__ does not. It's 
not the presence of the __ that makes it magic. It's the entire name.

-- 
Darren New, San Diego CA, USA (PST)
   "They're the 1-800-#-GORILA of the telecom business."

Post a reply to this message