Python 3K or Python 2.9?

[Ben Finney]

I would mention that an instance is passed as the first parameter
argument of a method if the methods were declared with the extra
argument and called with the extra argument:

a = MyClass()

my_method(a,someParameter)

Are you unaware that this is the way it works already?
... def bar(self, baz):
... print baz
... Traceback (most recent call last):
spam

The latter two statements are equivalent. The 'instance.method(args)'
syntax is just sugar for 'Class.method(instance, args)'.

 

[Ben Finney]

So everything that isn't passed explicitly is "magic"?

No. Everything that's not explicit is "magic", in that it potentially
needs to be explained to a newcomer the first time they encounter it.

 

[TheFlyingDutchman]

That looks like a case of "There's more than one way to do it".
The first form is definitely consistent with the
method declaration, so there's a lot to be said for using that style
when teaching people to make classes -> send self, receive self.

The latter two statements are equivalent. The 'instance.method(args)'
syntax is just sugar for 'Class.method(instance, args)'.

I think I saw where Guido Van Rossum had referred to something as
"syntactic sugar" in some python.org page. I am not familiar with
sugar as related to syntax. Is it being used as a synonym for "easier
way of doing it"?

 

[Steven D'Aprano]

That looks like a case of "There's more than one way to do it". The
first form is definitely consistent with the method declaration, so
there's a lot to be said for using that style when teaching people to
make classes -> send self, receive self.

I think it is a horrible thing to teach beginners. Would you teach them
to write 1.__add__(1) instead of 1+1?

I think that beginners should be taught to write

instance.method(arguments)

and then only introduced to

class.method(instance, arguments)

when they progress to needing to know what happens under the hood.

I think I saw where Guido Van Rossum had referred to something as
"syntactic sugar" in some python.org page. I am not familiar with sugar
as related to syntax. Is it being used as a synonym for "easier way of
doing it"?

"Syntactic sugar" is not really well defined, it's a fuzzy concept, but
in a nutshell it is special syntax made to "sweeten" the language by
giving an easier way to write common tasks.

It's hard to find examples of syntactic sugar that everybody agrees are
syntactic sugar, but I consider the following to be good (in the sense of
useful, obvious and well-thought-out) examples:

alist[-1] for alist[len(alist)-1]

list comprehensions and generator expressions


Perhaps less attractive, but still very(?) useful, examples of syntactic
sugar are decorators and the "X if C else Y" ternary operator.

 

[Ben Finney]

(Please, preserve attribution lines so it's clear who wrote what in
your quoted material.)

That looks like a case of "There's more than one way to do it".

Indeed, but there's only one *obvious* way to do it. (The latter, in
this case.)

The first form is definitely consistent with the method declaration,
so there's a lot to be said for using that style when teaching
people to make classes -> send self, receive self.

Sure, go ahead and teach that way if you like; it'll work fine.

I think I saw where Guido Van Rossum had referred to something as
"syntactic sugar" in some python.org page. I am not familiar with
sugar as related to syntax. Is it being used as a synonym for
"easier way of doing it"?

Specifically an easier way of doing it provided by the language syntax
(hence "syntactic sugar"). As in, "the form 'foo += 1' is syntactic
sugar for 'foo = foo + 1'".

 

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :

"this" in C++ and Java is not shown in the parameter list, which was
what he was
complaining about. He wants

class MyClass:
def SomeFunction(someParameter):
self.someParameter = someParameter

not

class MyClass:
def SomeFunction(self, someParameter):
self.someParameter = someParameter


The confusing way about the current Python method when you first
encounter it is
why is "self" being passed in when you write the function

At this stage, it's not "passed in", it's declared in the arguments list.

but not
when you call it.

It *is* passed when you call the function.

If the compiler is smart enough to know that

The compiler has absolutely nothing to do with it. It's the object model
that takes care of this. Quick explanation:

- functions objects implement the descriptor protocol.
- when a function which is an attribute of a class is looked up on an
instance of that class, the __get__ method of the function object is
called with the instance (and class) as arguments.
- this method returns a closure wrapping the instance, the class and the
function object itself
- when this closure is called, it itself prepends the instance to the
args it receives, calls the function with these args, and returns the
result.

This is why you need tho declare the instance as the first argument, but
don't need to pass it explicitely *when calling the function as a method
of an object*. Notice that you can still use the function directly,
passing the instance by yourself. And that you can define a function
outside a class and then attach it to a class. To make a long story
short, Python's methods are just thin temporary wrappers around plain
functions.

a = MyClass()
a.SomeFunction(12)

SomeFunction() has a "self" implicitly added to the parameter list, it
seems that it should be smart enough to know that a function defined
in a class has a "self" implicitly added to the parameter list.

The compiler has nothing to do with it, and where you define the
function is totally orthogonal:

def truc(obj):
print obj

class Toto(object):
pass

Toto.trac = truc

t = Toto()
t.trac()

 

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :

That looks like a case of "There's more than one way to do it".

Nope, on the contrary. The nice thing with this model is that you don't
have distinct rules for functions and methods, since methods are just
plain functions.

I think I saw where Guido Van Rossum had referred to something as
"syntactic sugar" in some python.org page. I am not familiar with
sugar as related to syntax. Is it being used as a synonym for "easier
way of doing it"?

Yes. "syntactic sugar" mostly means "nicer, simpler syntax for something
that could be done without". And one of the *great* strength of Python
is that it exposes both the syntactic sugar for the most common uses
case and the underlying implementation for most advanced tricks.

 

[Piet van Oostrum]

T> The confusing way about the current Python method when you first
T> encounter it is
T> why is "self" being passed in when you write the function but not
T> when you call it.

It *is* passed when you call it, but it is written before the method name
instead of after it. Some people have called this an "infix" call similar
to infix operators.

 

[Piet van Oostrum]

BF> The latter two statements are equivalent. The 'instance.method(args)'
BF> syntax is just sugar for 'Class.method(instance, args)'.

It is more than just syntactic sugar because the Class is derived from the
instance at runtime.

 

[Bjoern Schliessmann]

I am not talking about how the implementation of a C++ or Java
compiler uses the this pointer/this reference internally. I am
talking about how an author describes in English the "this"
pointer/reference in their book on programming C++ or Java.

Ah, okay.

I don't think you will find them saying that under the covers
"this" was passed to the method (if in fact it is). They just say
that it refers to the current object inside that object's method.

Mh, in my book, there is (quickly translated from german):

| Instance pointer (C++ only)
|
| The /this/ pointer is a feature of all non-static class methods.
| Every non static method is extended internally by a /this/
| argument. To that argument the compiler passes a pointer to the
| instance for which the method is being called.
(Dirk Louis, C/C++-Kompendium, Markt&Technik-Verlag, 2000)

And that's only from the pointer chapter. The OOP chapters are more
detailed. And no, it's no book about compiler architecture, it's a
compendium.

Here is a link to a tutorial where Sun is talking about the this
reference:
http://java.sun.com/docs/books/tutorial/java/javaOO/thiskey.html

That's a tutorial for getting you started, no reference
documentation or in-depth course.

I am referring to C++. If someone is trying to learn the language,
knowledge of the internal implemenation is counter-productive in
my opinion because it distracts from the details they need to
learn.

In a language like C++ it is beneficial to know some inner
workings -- in the same way like it's beneficial to know some inner
workings of a computer if you want to use it.

BTW, C is not for nothing called "portable assembler"

If they are experienced and want to learn about the internals to
potentially help them code in the most blazingingly fast manner
they ideally would just be reminded they are using C++ and not
some slower byte-code executed language where it could possibly
matter.

I don't know if it's just me, but I tend to understand stuff like
virtual methods much better if I know *why* they exist, and not
just *that* they do. That makes judging if and when I need them
easier.

Regards,


Björn

 

[Alex Martelli]

That looks like a case of "There's more than one way to do it".
The first form is definitely consistent with the
method declaration, so there's a lot to be said for using that style
when teaching people to make classes -> send self, receive self.

On the other hand, the second form is not polymorphic: it doesn't allow
for foo to be an instance of some OTHER class (possibly subclassing Foo
and overriding bar) -- it will call the Foo version of bar anyway.

type(foo).bar(foo, "spam") *IS* almost semantically equivalent to the
obviousy simpler foo.bar("spam") -- but doesn't cover the possibility
for foo to do a *per-instance* override of 'bar'.

getattr(foo, 'bar', functools.partial(type(foo).bar, foo))("spam") is
getting closer to full semantic equivalence. And if you think that's
"another OBVIOUS way of doing it" wrt foo.bar("spam"), I think your
definition of "obvious" may need a reset (not to mention the fact that
the "equivalent" version is way slower;-).

Foo.bar(foo, "spam")'s different semantics are important when any
implementation of type(foo).bar (or other method yet) wants to BYPASS
polymorphism to redirect part of the functionality to a specific type's
implementation of bar ('super' may help in some cases, but it keeps some
polymorphic aspects and pretty often you just want to cut all
polymorphism off and just redirect to ONE specific implementation).


Alex

 

[TheFlyingDutchman]

Well I'm with Bruce Eckel - there shouldn't be any argument for the
object in the class method parameter list. But since Python 3 was
"code-named" 3000 (implying but not delivering big changes... I don't
think it required big changes) and since it still has an explicit
object parameter it's a given that it's not gonna happen in any
revisions.

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods. But Perl does it as well.
I think the label "mainstream OO language" is as valid being applied
to Perl as it is to Python.

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.

 

[TheFlyingDutchman]

That's a tutorial for getting you started, no reference
documentation or in-depth course.

Here's a FAQ item where they refer to it as I think Python should have
done it - a special predefined variable:

http://www.faqs.org/docs/javap/c5/s5.html

"Java provides a special, predefined variable named "this" that you
can use for such purposes. The variable, this, is used in the source
code of an instance method to refer to the object that contains the
method. This intent of the name, this, is to refer to "this object,"
the one right here that this very method is in. If x is an instance
variable in the same object, then this.x can be used as a full name
for that variable. If otherMethod() is an instance method in the same
object, then this.otherMethod() could be used to call that method.
Whenever the computer executes an instance method, it automatically
sets the variable, this, to refer to the object that contains the
method."



"this" is hard to query on but I would be interested in seeing some
site talking about Java where "this" is mentioned as being "passed
in".

 

[Wildemar Wildenburger]

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.

Isn't one of the main ideas behind python that it doesn't force you to
do (well, declare) anything? And by "ideas" I mean "design decisions".
Thats exactly what makes python great for prototyping; you just do it
and see if it works. As soon as you need to declare things you have to
change stuff in at least 2 places for every change of heart you have.

(Can you tell I'm currently forced to developing in Java? (Which I'm
currently avoiding to do, by wasting my time on usenet.))

/W

 

[TheFlyingDutchman]

Isn't one of the main ideas behind python that it doesn't force you to
do (well, declare) anything? And by "ideas" I mean "design decisions".
Thats exactly what makes python great for prototyping; you just do it
and see if it works. As soon as you need to declare things you have to
change stuff in at least 2 places for every change of heart you have.

(Can you tell I'm currently forced to developing in Java? (Which I'm
currently avoiding to do, by wasting my time on usenet.))

But if you are looking at code you didn't write, it's nice to be able
to see all the member variables that a class has listed separate from
method code.

I think static typing helps in trying to deduce what code is doing,
particularly when you are looking at function definitions. You don't
have to work to find out what type of variables it takes.

 

[Stefan Bellon]

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods.

Ada 95 does. And Ada 95 was the first standardized OO language. Now
with Ada 2005 you can either pass the the object explicitly as first
parameter (like in Ada 95) or you can call the method on the object
(like in Java, C++, Python, ...) and the object is passed implicitly.

 

[Marc 'BlackJack' Rintsch]

But if you are looking at code you didn't write, it's nice to be able
to see all the member variables that a class has listed separate from
method code.

That information is usually in the `__init__()` method and the class
docstring.

I think static typing helps in trying to deduce what code is doing,
particularly when you are looking at function definitions. You don't
have to work to find out what type of variables it takes.

This should either be obvious or in the docstring.

Ciao,
Marc 'BlackJack' Rintsch

 

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :

Well I'm with Bruce Eckel - there shouldn't be any argument for the
object in the class method parameter list.

def fun(obj, *args, **kw):
# generic code here that do something with obj

import some_module
some_module.SomeClass.fun = fun

This is why uniformity is important.

But anyway, I think it's quite clear that Python won't drop the explicit
self, so it looks like you have to live with it or choose another language.

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods.

to methods. class methods gets the class as first parameter.

Anyway, there are a lot of things that Python doesn't do like "other
mainstream OO languages", and that's a GoodThing.

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.

I definitively think you'd be happier with some other language.

 

[TheFlyingDutchman]

(Can you tell I'm currently forced to developing in Java? (Which I'm
currently avoiding to do, by wasting my time on usenet.))

Maybe you can sneak Jython into the mix. Just describe it as "this
Java scripting language".

 

[Bjoern Schliessmann]

Here's a FAQ item where they refer to it as I think Python should
have done it - a special predefined variable:

Maybe. Personally, I like it the way it is in Python.

Why don't you make a preprocessor which accepts method declarations
without "self" and fixes them?

Regards,


Björn