Python 3K or Python 2.9?

[Wildemar Wildenburger]

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

Hehe, devious idea. I might just try that.

/W

 

[Bruno Desthuilliers]

Bjoern Schliessmann a écrit :

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?

The problem being that there's no such thing as a "method declaration"
in Python - only functions being attributes of a class...

(ok, I know, you meant "functions declared within a class statement").

 

[Terry Reedy]

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

In Python, methods are (functions) contained in (are attributes of)
classes. Hence, by the above, 'this' or 'self' would be set to the class
and not the instance. So the above would require some rewording for
Python.

 

[Bjoern Schliessmann]

Bjoern Schliessmann a écrit :

The problem being that there's no such thing as a "method
declaration" in Python

Yep, there are only definitions. I'm sorry.

- only functions being attributes of a class...

What, IYHO, is the difference between a method and a function?

(ok, I know, you meant "functions declared within a class
statement").

I think that those functions _are_ special ones since the compiler
is able to make "method(instance, a, b)" out of
"instance.method(a, b)". So IMHO, "method definition" makes sense.

Regards,


Björn

 

[Steven D'Aprano]

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?

If you look at the thread "parameter list notation" from ten days or so
ago, TheFlyingDutchman has forked Python and is working on a very special
new language, PIEthun 3.01B. I for one am looking forward to seeing all
the very special features of PIEthun.

 

[Aahz]

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

Except, of course, that it isn't, quite. ;-)
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
http://www.lysator.liu.se/c/ten-commandments.html

 

[Aahz]

and I'll punch a kitten before I accept having to read
Python code guessing if something is a global, a local, or part of
self like I do in C++.

Exactly: the technical objections that are being raised are bogus, and
the REAL objections from the Python community boil down to: we like it
better the way it is now. Bringing technical objections that are easily
debunked doesn't _strengthen_ our real case: in fact, it _weakens_ it.
So, I'd rather see discussants focus on how things SHOULD be, rather
than argue they must stay that way because of technical difficulties
that do not really apply.

The real advantage of making 'self' explicit is that it IS explicit, and
we like it that way, just as much as its critics detest it. Just like,
say, significant indentation, it's a deep part of Python's culture,
tradition, preferences, and mindset, and neither is going to go away (I
suspect, in fact, that, even if Guido somehow suddenly changed his mind,
these are issues on which even he couldn't impose a change at this point
without causing a fork in the community). Making up weak technical
objections (ones that ignore the possibilities of __get__ or focus on
something so "absolutely central" to everyday programming practice as
inspect.getargspec [!!!], for example;-) is just not the right way to
communicate this state of affairs.

While you have a point, I do think that there is no solution that allows
the following code to work with no marker distinguishing the local bar
from the instance's bar; the only question is how you want to mark up
your code:

class C:
def foo(self, bar):
print bar, self.bar

x = C()
x.bar = 'abc'
x.foo()

From that standpoint, there is a technical objection involved. Of
course, the solution can be any of a number of different marker systems
(or even choosing to have no marker and not permit a method to access
both object attributes and locals of the same name), and Python has
chosen to force the use of a marker for all object attributes, while also
choosing to have disjoint namespaces WRT globals and locals for any one
name.
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
http://www.lysator.liu.se/c/ten-commandments.html

 

[TheFlyingDutchman]

If you look at the thread "parameter list notation" from ten days or so

ago, TheFlyingDutchman has forked Python and is working on a very special
new language, PIEthun 3.01B.
I for one am looking forward to seeing all
the very special features of PIEthun.

It will be named PIEthun 3000 as it comes out of Beta. But you're not
alone. From the emails I have been receiving there is anticipation and
excitement from Mumbai to Dusseldorf to Caracas.

 

[Terry Reedy]

in message |> - only functions being attributes of a class...

|What, IYHO, is the difference between a method and a function?

A method is a function accessed as an attribute of a class or instance.
As an object type, it is a *runtime* function wrapper.

|> (ok, I know, you meant "functions declared within a class> statement").

| I think that those functions _are_ special ones

Thinking does not make things so.

|since the compiler is able to make "method(instance, a, b)" out of
|"instance.method(a, b)".

No it does not. The method wrapping is done at runtine. The compiler is
ignorant of the wrapping that will be done.
def meth(self): pass
1 0 LOAD_GLOBAL 0 (c)
3 LOAD_ATTR 1 (meth)
6 CALL_FUNCTION 0
9 RETURN_VALUE

The function gets wrapped as a bound method as part of LOAD_ATTR. When the
compiler sees <expr>(args), it does not know and does not care about the
1 0 LOAD_GLOBAL 0 (C)
3 CALL_FUNCTION 0
6 RETURN_VALUE

It does not notice and does not care that 'C' will be bound to a class.

Terry Jan Reedy

 

[Bruno Desthuilliers]

Bjoern Schliessmann a écrit :

Yep, there are only definitions. I'm sorry.


What, IYHO, is the difference between a method and a function?

A method is a thin wrapper around a function, usually instanciated and
returned by the __get__ method [1] of the function itself when the
function is looked up as an attribute of a class or an instance:
.... def meth(self):
.... print "in %s meth" % self
....

>>> Foo.__dict__['meth']

>>> Foo.meth

>>> Foo().meth

>>>

[1] you may want to read about the descriptor protocol which is the base
mechanism on which methods and properties (computed attributes) are based.

I think that those functions _are_ special ones

They aren't, and you should perhaps read the manual - all this is
documented.

since the compiler
is able to make "method(instance, a, b)" out of
"instance.method(a, b)".

Once again, the compiler has *nothing* to do with this. Else, how could
you do this:
.... print obj
....

>>> Foo.fun = fun
>>> Foo.fun

>>> Foo().fun

>>> fun

>>> Foo.__dict__['fun']

>>>

So IMHO, "method definition" makes sense.

It doesn't.

 

[Bjoern Schliessmann]

A method is a thin wrapper around a function, usually instanciated
and returned by the __get__ method [1] of the function itself when
the function is looked up as an attribute of a class or an
instance:
[...]

That's interesting, thank you for the explanation.

They aren't, and you should perhaps read the manual - all this is
documented.

Found it.

Regards,


Björn

 

[Bjoern Schliessmann]

No it does not. The method wrapping is done at runtine. The
compiler is ignorant of the wrapping that will be done.

Agreed, after reading the docs.

1 0 LOAD_GLOBAL 0 (c)
3 LOAD_ATTR 1 (meth)
6 CALL_FUNCTION 0
9 RETURN_VALUE

The function gets wrapped as a bound method as part of LOAD_ATTR.
When the compiler sees <expr>(args), it does not know and does not
care about the
particular type that <expr> will become. It just assumes that it
will be
callable and emits the code to call it. Consider

That's interesting. BTW, do you know something (apart from the dis
docs) that's worth reading if you're interested in Python byte
code?

Regards,


Björn

 

[Duncan Booth]

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

Other differences that mean it isn't just sugar:

you can save the bound method created by 'instance.method' but not with the
expanded version.

The equivalence depends on the type of 'method', other expansions are
possible: e.g. Class.method(Class, args) or Class.method(args) or invent
your own.

 

[Terry Reedy]

in message That's interesting. BTW, do you know something (apart from the dis
docs) that's worth reading if you're interested in Python byte
code?

------------------
That is the only Python specific thing I remember reading. Of course, it
helps that I learned assembler a long time ago, and that I have used an HP
reverse-polish notation calculator (a fixed-size stack machine), and that I
have seen and understand algorithms for turning prefix and infix to postfix
notation.

tjr

 

[John Roth]

"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 but not
when you call it. If the compiler is smart enough to know that

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.

Pretty close. This is one of the things that's always puzzled me about
the discussion. Making self and cls keyword pseudo-constants that get
the current instance and class from the stack frame (or raise an
exception) would eliminate them from the method header.

It would ALSO eliminate a whole level of indirection in method
invocation and get rid of the instancemethod, classmethod and
staticmethod wrapper classes. This would be a significant
simplification. If it had been done earlier, it would have eliminated
most of the justification for method attributes (those silly @
things), thus showing that unneeded complexity breeds more unneeded
complexity.

John Roth

 

[George Sakkis]

"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

If one *really* wants this, it is doable in python too:
http://www.voidspace.org.uk/python/weblog/arch_d7_2006_12_16.shtml#e583

George

 

[=?ISO-8859-1?Q?Ricardo_Ar=E1oz?=]

TheFlyingDutchman a écrit :

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.


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.



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

<Ironic>

Hi, I'm new to Python, I don't even fully know the language, never done
a full project in Python. What's more, probably I'll never will.
But that's not the point, the point is I want YOU people to modify the
language you know in and out, the program with which you've done many
systems, I want you to change it to suit my whims, so that I'll be
comfortable with the 3 ten liners I'll write.
TIA

</Ironic>

 

[David Trudgett]

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 but not
when you call it. If the compiler is smart enough to know that

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.

Several languages use the "object.method(args)" form, which is syntactic
sugar for "method(object, other_args)" which Ada, for instance, uses.
Knowing this clears up half the confusion (the object /is/ passed as a
parameter whichever syntax is used).

The other half of the confusion is cleared up by considering that
Python methods are ordinary functions that don't magically "know" in
which "class" context they are executing: they must be told via the
first parameter.

David Trudgett

 

[Erik Jones]

Several languages use the "object.method(args)" form, which is
syntactic
sugar for "method(object, other_args)" which Ada, for instance, uses.
Knowing this clears up half the confusion (the object /is/ passed as a
parameter whichever syntax is used).

The other half of the confusion is cleared up by considering that
Python methods are ordinary functions that don't magically "know" in
which "class" context they are executing: they must be told via the
first parameter.

Yes, that is really the crux of the issue, though. While the former
may be syntactic sugar for the latter, once any syntactic sugar has
become prevalent enough, it becomes the expected norm and the latter
becomes clutter or, at best, awkward. It's something that really
just takes a little use until you get to the point where you don't
usually think of it but, every so often, the thought creeps in. I'm
not complaining, just pointing out if you step out of this particular
box, you'll realize that it really is a pointless one. Saying,
"because that's how Python does it" may be the only valid reason, but
that argument is about on par with a six year old's "just because...".



Erik Jones

Software Developer | Emma®
(e-mail address removed)
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

 

[Bruno Desthuilliers]

John Roth a écrit :

Pretty close. This is one of the things that's always puzzled me about
the discussion. Making self and cls keyword pseudo-constants that get
the current instance and class from the stack frame (or raise an
exception) would eliminate them from the method header.

I suppose that by header, you mean prototype or signature. But anyway,
it's not a *method* signature, it's a *function* signature - and the
compiler persists to have nothing to do with all this...

It would ALSO eliminate a whole level of indirection in method
invocation and get rid of the instancemethod, classmethod and
staticmethod wrapper classes. This would be a significant
simplification. If it had been done earlier, it would have eliminated
most of the justification for method attributes (those silly @
things),

"those silly @ things" has *nothing* to do with methods nor with
attributes. It's just syntactic sugar for HOFs. Period.

thus showing that unneeded complexity breeds more unneeded
complexity.

John, there are plenty of other OOPls around that don't requires neither
explicit use of the instance/class reference nor mention of it in the
function . If after having read this whole thread and all relevant
documentation, you still don't understand why Python works that way and
why most of us are *totally* happy with the way it works, I strongly
suggest that you switch to another language. Not that I have nothing
personal against you, but it should be quite clear that this part of
Python is not going to change - FWIW, as Alex pointed out, I doubt even
GvR could impose such a change now.