Python 3K or Python 2.9?

[Bjoern Schliessmann]

Re: Python 3K or Python 2.9?

Stefan Behnel wrote:

Bjoern Schliessmann wrote:

>If this was needless, why do C++ and Java have the "this"
>pointer?

>
Be careful when you use the word "needless" in the context of
Java.

Umm, why? I didn't introduce it.

Regards,


Björn

--
BOFH excuse #8:

static buildup

[TheFlyingDutchman]

Re: Python 3K or Python 2.9?

On Sep 12, 3:53 pm, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n.. .@spamgourmet.c omwrote:

TheFlyingDutchm an wrote:

In C++ and Java I don't believe "this" is ever referred to as an
implicit function parameter.

>
Oh yes, it is. All methods use it as a base address into instances.
Implicitly though.

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.

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.

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

If it is in fact a real parameter in the underlying compiled-code
implementation, that knowledge hurts more than it helps.

>
To which language are you referring here, Python or C++? No matter
what, I still don't really understand why it hurted.
>

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. 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. ;)

[Ben Finney]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an <zzbbaadd@aol.c omwrites:

I am talking about how an author describes in English the "this"
pointer/reference in their book on programming C++ or Java.
>
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.

In other words, it's magic, and the behaviour has to be explained so
the reader knows where the undeclared 'this' comes from.

How is that preferable to the magic of "instance is passed as the
first argument to a method"?
--
\ "If nothing changes, everything will remain the same." -- |
`\ Barne's Law |
_o__) |
Ben Finney

[TheFlyingDutchman]

Re: Python 3K or Python 2.9?

On Sep 12, 5:47 pm, Ben Finney <bignose+hate s-s...@benfinney. id.au>
wrote:

TheFlyingDutchm an <zzbba...@aol.c omwrites:

I am talking about how an author describes in English the "this"
pointer/reference in their book on programming C++ or Java.

>

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.

>
In other words, it's magic, and the behaviour has to be explained so
the reader knows where the undeclared 'this' comes from.

I would disagree that it _has_ to be explained where it came from. I
think knowing that the compiler is providing it is sufficient. Any
further knowledge of what the compiler is doing under the covers to
provide it is unnecessary. Sun made no mention of where "this" comes
from in that link I provided.

>
How is that preferable to the magic of "instance is passed as the
first argument to a method"?

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,som eParameter)

Then it makes sense to me to talk about it.

[Peter Decker]

Re: Python 3K or Python 2.9?

On 9/12/07, Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

TheFlyingDutchm an <zzbbaadd@aol.c omwrites:
>

I am talking about how an author describes in English the "this"
pointer/reference in their book on programming C++ or Java.

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.

>
In other words, it's magic, and the behaviour has to be explained so
the reader knows where the undeclared 'this' comes from.
>
How is that preferable to the magic of "instance is passed as the
first argument to a method"?

So everything that isn't passed explicitly is "magic"? I suppose
__builtin__ counts as magic, too?

Define 'self' as a keyword, and its usage becomes no more magical than
'def' or 'break'.

--

# p.d.

[Ben Finney]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an <zzbbaadd@aol.c omwrites:

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,som eParameter)

Are you unaware that this is the way it works already?

>>class Foo(object):

... def bar(self, baz):
... print baz
...

>>foo = Foo()
>>Foo.bar("spam ")

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unbound method bar() must be called with Foo instance as first argument (got str instance instead)

>>Foo.bar(foo , "spam")

spam

>>foo.bar("spam ")

spam

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

--
\ "Choose mnemonic identifiers. If you can't remember what |
`\ mnemonic means, you've got a problem." -- Larry Wall |
_o__) |
Ben Finney

[Ben Finney]

Re: Python 3K or Python 2.9?

"Peter Decker" <pydecker@gmail .comwrites:

On 9/12/07, Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

How is that preferable to the magic of "instance is passed as the
first argument to a method"?

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

--
\ "Pinky, are you pondering what I'm pondering?" "I think so, |
`\ Brain, but if the plural of mouse is mice, wouldn't the plural |
_o__) of spouse be spice?" -- _Pinky and The Brain_ |
Ben Finney

[TheFlyingDutchman]

Re: Python 3K or Python 2.9?

>>Foo.bar(foo , "spam")
>>foo.bar("spam ")

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.metho d(args)'
syntax is just sugar for 'Class.method(i nstance, 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]

Re: Python 3K or Python 2.9?

On Wed, 12 Sep 2007 19:40:04 -0700, TheFlyingDutchm an wrote:

> >>Foo.bar(foo , "spam")
> >>foo.bar("spam ")

>
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(in stance, arguments)

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

>The latter two statements are equivalent. The 'instance.metho d(args)'
>syntax is just sugar for 'Class.method(i nstance, 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"?

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



--
Steven

[Ben Finney]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an <zzbbaadd@aol.c omwrites:

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

>>Foo.bar(foo , "spam")
>>foo.bar("spam ")

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

--
\ "I don't know half of you half as well as I should like, and I |
`\ like less than half of you half as well as you deserve." -- |
_o__) Bilbo Baggins |
Ben Finney

[Bruno Desthuilliers]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an a écrit :

On Sep 12, 4:40 am, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n.. .@spamgourmet.c omwrote:

>Ivan Voras wrote:

>>What does "self" have to do with an object model? It's an
>>function/method argument that might as well be hidden in the
>>compiler without ever touching the role it has (if not, why?). I
>>agree that it's needless noise in a language.

>If this was needless, why do C++ and Java have the "this" pointer?
>>

"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(so meParameter):
self.someParame ter = someParameter
>
not
>
class MyClass:
def SomeFunction(se lf, someParameter):
self.someParame ter = 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]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an a écrit :

> >>Foo.bar(foo , "spam")
> >>foo.bar("spam ")

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

>The latter two statements are equivalent. The 'instance.metho d(args)'
>syntax is just sugar for 'Class.method(i nstance, 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"?

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]

Re: Python 3K or Python 2.9?

>>>>TheFlyingDu tchman <zzbbaadd@aol.c om(T) wrote:

>TThe confusing way about the current Python method when you first
>Tencounter it is
>T why is "self" being passed in when you write the function but not
>Twhen 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 <piet@cs.uu.n l>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C 4]
Private email: piet@vanoostrum .org

[Piet van Oostrum]

Re: Python 3K or Python 2.9?

>>>>Ben Finney <bignose+hate s-spam@benfinney. id.au(BF) wrote:

>BFThe latter two statements are equivalent. The 'instance.metho d(args)'
>BFsyntax is just sugar for 'Class.method(i nstance, args)'.

It is more than just syntactic sugar because the Class is derived from the
instance at runtime.
--
Piet van Oostrum <piet@cs.uu.n l>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C 4]
Private email: piet@vanoostrum .org

[Alex Martelli]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an <zzbbaadd@aol.c omwrote:

>>Foo.bar(foo , "spam")
>>foo.bar("spam ")

>
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(f oo, "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.parti al(type(foo).ba r, 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