Attack a sacred Python Cow

[Bruno Desthuilliers]

Lawrence D'Oliveiro a écrit :

In message


Change "distribution" to "program" and you're on the right track.

Since just everything that can be bound to a name is actually an object,
I don't see how you could do anything in Python without using objects.

Now if what you meant is that nothing in Python forces you into
designing your program the OO way, then Java is not an OOPL neither
(never seen a Java program where you have classes with only static
methods and classes with only public attributes - IOW, functions and
structs ?).

 

[Bruno Desthuilliers]

Jordan a écrit :
(snip)

about Python Zen:

Perhaps we're just looking at an instance of a wider problem - smart
people boil good ideas down into short slogans, which are nice and
memorable and somewhat helpful, but can lead to bad consequences when
lots of others start overusing or misunderstanding them.

This is true for just each and every "golden rule" in programming - like
"goto are evil", "globals are evil", "side effects are evil", "early
returns are evil", "public attributes are evil", etc... If you blindly
apply any rule without understanding the rationales behind it, then
you're into cargo-cult thinking. And once you understand the reasons
that led someone to formulate such a rule, you just don't have to bother
about it anymore - you just use your common sense to do what seems
appropriate in a given situation.

 

[Russ P.]

Google is your friend:http://mail.python.org/pipermail/python-3000/2006-April/000793.html

What Guido rejected there is most certainly *not*
what I suggested. I agree with Guido on that one.

 

[Derek Martin]

There is no requirement to have 'self' in the parameter list.

But there is a requirement to have *something* which refers to the
object instance. Why can't this be implicit with a keyword defined in
python to refer to it?

So the proposal would have to be that the compiler scan the function
body and decide which dotted name prefix is the one to be implicitly
added. Have fun writing the discovery algorithm.

That's crazy talk.

Or the proposal would have to be that 'self' is mandatory for all
programmers in all languages. I think *that* would be pernicious.
People are now free to write the more compact 's.sum = s.a + s.b + s.c'

s = self

There, your problem is fixed. Besides, in general, it's better
programming practie to use meaningful names, with fairly obvious and
well-understood exceptions.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIjMaMdjdlQoHP510RAi9AAJ9byGW+Z8SpcpsOTa5/Gxv1Q0p4RQCeI9r9
RxR6az2XlvRV2lqulhW992g=
=SX6e
-----END PGP SIGNATURE-----

 

[Russ P.]

The question isn't "why not", but "why". The status quo works well as it
is, even if it isn't perfect. Prove that implicit self is a good idea --
or at least prove that it is an idea worth considering.

"I don't like typing self" doesn't convince me. The same argument could
be made typing parentheses, colons, commas, etc. We could end up with
something like this:

class Foo base
def method x y z
.args = list x y z

That's not necessarily wrong, but it's not Python.

And what does that have to do with my suggestion? Absolutely nothing.
It's a red herring that you seem to be using to obscure the fact that
you have no rational argument to make.

By the way, according to your "reasoning," Python 2.5 was *not* Python
when 2.1 was the latest version. But now it is! Yes, Python has
actually changed, yet remained Python. What a concept!

It's not enough to show that a change "isn't bad" -- you have to show
that it is actively good. Why should Python make any changes to the
current explicit self without a clear and solid reason to change?






By "better" do you mean "uglier"? If so, I agree with you. If not, then I
disagree that it is better.

You seem to be freaked out by an empty argument. Actually, it bothers
me a bit too, which is why I suggested that a period could be used as
the first argument to indicate that, like Clint Eastwood in The Good,
the Bad, and the Ugly, "self" had no name here.

"Don't need to look at the method signature" is not an argument in favour
of implicit self. You don't need to look at the method signature when
you're using an explicit self either.

Actually, you do. The name "self" could be used for any argument -- or
even for a local variable. No good programmer would do such a thing,
of course, but not all programmers are good programmers (and not all
Python programmers read the stern admonitions against such practices
on this forum). And if you are reviewing critical code, you had darn
well better verify that "self" is the first argument. With my
proposal, you would not need to do that.

Is that a major advantage? No. But it is a minor advantage. And it is
perfectly logical.

Am I suggesting that unnamed first arguments should always be used?
No, of course not. But I am saying that in some cases it can unclutter
and simplify the code.

What happens with class-methods? With the cls (or if you prefer klass)
convention, it is simple to tell what object I am referring to. Now I
have to go back to the method signature to see if it is a class method or
instance method, instead of just looking at the explicit name.

Bzzzzt. Wrong again. The exact same convention could apply there. And
the same benefits apply: less clutter and no need to keep the name of
the first argument in your head when reading the code.

Even uglier than the first. Convince me there's a benefit.

Actually, I think it's elegant. And I'll bet that if Guido had
suggested it, you would think it was beautiful. Why force a name to be
used when none is needed? Think about lambda functions.

 

[Derek Martin]

You know, there are some programmers who haven't started with C++ or Java.

Indeed, I'm one of them. In fact, I've never written even a single
program in either language (except maybe hello world or the
equivalent), and still, I have always thought that explicitly naming
the class instance variable in the parameter list of the object's
methods was a wart (albeit a very minor one) in Python. It's a waste
of typing.

Would I? How would I do that here?

You missed the point. The variable "other" in your posted class is
not intended to always refer to the same *object*... Whereas "self"
is and does, and that was what was meant. In such a case, you'd
obviously convert the variable to a class property.

Regardless of how it's implementd, it's such a common idiom to use
self to refer to object instances within a class in Python that it
ought to be more automatic. Personally, I kind of like the idea of
using @ and thinking of it more like an operator... Kind of like
dereferencing a pointer, only with an implied pointer name.

class foo:
def __init__():
@.increment = 2

def bar(a)
return a + @.increment

I'm sure all the Pythonistas will hate this idea though... ;-) To be
honest, it smacks a little of Perl's magic variables, which I actually
hate with a passion. This is the only place in Python I'd consider
doing something like this.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIjM24djdlQoHP510RAjTtAJ4wLwVPBnLacpyZ7k/++534A/RlQwCgkkFe
bcd7NfxqgBAdIrbTYKLOeBs=
=mYoU
-----END PGP SIGNATURE-----

 

[Bruno Desthuilliers]

Derek Martin a écrit :

Come on, this sounds like a schoolyard argument. This comes down to a
matter of style, and as such, is impossible to prove. It's largely a
question of individual preference.

That said, the argument in favor is rather simple:

1. This is an extremely common idiom in Python
2. It is completely unnecessary, and the language does not suffer for
making it implicit
3. Making it implicit reduces typing, reduces opportunities for
mistakes, and arguably increases consistency.

"arguably", indeed, cf below.

As for the latter part of #3, self (or some other variable) is
required in the parameter list of object methods,

It's actually the parameter list of the *function* that is used as the
implementation of a method. Not quite the same thing. And then,
consistency mandates that the target object of the method is part of the
parameter list of the *function*, since that's how you make objects
availables to a function.

however when the
method is *called*, it is omitted.

Certainly not. You need to lookup the corresponding attribute *on a
given object* to get the method. Whether you write

some_object.some_method()

or

some_function(some_object)

you still need to explicitely mention some_object.

It is implied, supplied by Python.

Neither. The target object is passed to the function by the method
object, which is itself returned by the __get__ method of function
objects, which is one possible application of the more general
descriptor protocol (the same protocol that is used for computed
attributes). IOW, there's nothing specific to 'methods' here, just the
use of two general features (functions and the descriptor protocol).
FWIW, you can write your own callable, and write it so it behave just
like a function here:

import types

class MyCallable(object):
def __call__(self, obj):
print "calling %s with %s" % (self, obj)
def __get__(self, instance, cls):
return types.MethodType(self.__call__, instance, cls)

class Foo(object):
bar = MyCallable()

print Foo.bar
f = Foo()
f.bar()

Thus when an object method is called, it must be called with one fewer
arguments than those which are defined. This can be confusing,
especially to new programmers.

This is confusing as long as you insist on saying that what you
"def"ined is a method - which is not the case.

It can also be argued that it makes the code less ugly, though again,
that's a matter of preference.


But he did... he pointed out that *it saves work*, without actually
being bad. Benefit, without drawback. Sounds good to me!


Yes, actually, it is.

It isn't, since there's no "method signature" to look at !-)

If there is a well-defined feature of Python
which provides access to the object within itself,

The point is that you don't get access to the object "within itself".
You get access to an object *within a function*.

The fact that a function is defined within a class statement doesn't
imply any "magic", it just creates a function object, bind it to a name,
and make that object an attribute of the class. You have the very same
result by defining the function outside the class statement and binding
it within the class statement, by defining the function outside the
class and binding it to the class outside the class statement, by
binding the name to a lambda within the class statement etc...

then the
opportunities for mistakes when someone decides to use something else
are lessened.


That isn't necessarily true. If you're using someone else's code, and
they didn't use "self" -- or worse yet, if they chose this variable's
name randomly throughout their classes -- then you may well need to
look back to see what was used.

It's bad programming, but the world is full of bad programmers, and we
don't always have the choice not to use their code. Isn't one of
Python's goals to minimize opportunities for bad programming?

Nope. That's Java's goal. Python's goals are to maximize opportunities
for good programming, which is quite different.

Providing a keyword equivalent to self and removing the need to name
it in object methods is one way to do that.

It's also a way to make Python more complicated than it needs to be. At
least with the current state, you define your functions the same way
regardless of how they are defined, and the implementation is
(relatively) easy to explain. Special-casing functions definition that
happens within a class statement would only introduce a special case.
Then you'd have to explain why you need to specify the target object in
the function's parameters when the function is defined outside the class
but not when it's defined within the class.

IOW : there's one arguably good reason to drop the target object from
functions used as methods implementation, which is to make Python looks
more like Java, and there's at least two good reason to keep it the way
it is, which are simplicity (no special case) and consistency (no
special case).

Anyway, the BDFL has the final word, and it looks like he's not going to
change anything here - but anyone is free to propose a PEP, isn't it ?

 

[Derek Martin]

The question isn't "why not", but "why". The status quo works well as it
is, even if it isn't perfect. Prove that implicit self is a good idea --
or at least prove that it is an idea worth considering.

Come on, this sounds like a schoolyard argument. This comes down to a
matter of style, and as such, is impossible to prove. It's largely a
question of individual preference.

That said, the argument in favor is rather simple:

1. This is an extremely common idiom in Python
2. It is completely unnecessary, and the language does not suffer for
making it implicit
3. Making it implicit reduces typing, reduces opportunities for
mistakes, and arguably increases consistency.

As for the latter part of #3, self (or some other variable) is
required in the parameter list of object methods, however when the
method is *called*, it is omitted. It is implied, supplied by Python.
Thus when an object method is called, it must be called with one fewer
arguments than those which are defined. This can be confusing,
especially to new programmers.

It can also be argued that it makes the code less ugly, though again,
that's a matter of preference.

It's not enough to show that a change "isn't bad" -- you have to show
that it is actively good.

But he did... he pointed out that *it saves work*, without actually
being bad. Benefit, without drawback. Sounds good to me!

"Don't need to look at the method signature" is not an argument in favour
of implicit self.

Yes, actually, it is. If there is a well-defined feature of Python
which provides access to the object within itself, then the
opportunities for mistakes when someone decides to use something else
are lessened.

You don't need to look at the method signature when you're using an
explicit self either.

That isn't necessarily true. If you're using someone else's code, and
they didn't use "self" -- or worse yet, if they chose this variable's
name randomly throughout their classes -- then you may well need to
look back to see what was used.

It's bad programming, but the world is full of bad programmers, and we
don't always have the choice not to use their code. Isn't one of
Python's goals to minimize opportunities for bad programming?
Providing a keyword equivalent to self and removing the need to name
it in object methods is one way to do that.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIjNOedjdlQoHP510RAtotAJ95r36fE916fPj17A4JTvQ3QeDRRQCfdTfl
KHUhu1W4mJv/t81hTZw8LyA=
=Qcfc
-----END PGP SIGNATURE-----

 

[Colin J. Williams]

On Jul 26, 2:25 pm, Terry Reedy

You take the name down to a single letter. As I suggested in an
earlier post on this thread, why not take it down to zero letters? You
could if Python accepted something like

class Whatever:

def fun( , cat):

.cat = cat

This is even better than the single-character name, not only because
it is shorter, but also because there is no question that you are
referring to "self." No need to look back at the method signature to
verify that.

For those who don't like the way the empty first argument looks, maybe
something like this could be allowed:

def fun( ., cat):

I don't see the need for the comma in fun.

Colin W.

 

[Russ P.]

Derek Martin a écrit :







"arguably", indeed, cf below.


It's actually the parameter list of the *function* that is used as the
implementation of a method. Not quite the same thing. And then,
consistency mandates that the target object of the method is part of the
parameter list of the *function*, since that's how you make objects
availables to a function.


Certainly not. You need to lookup the corresponding attribute *on a
given object* to get the method. Whether you write

some_object.some_method()

or

some_function(some_object)

you still need to explicitely mention some_object.


Neither. The target object is passed to the function by the method
object, which is itself returned by the __get__ method of function
objects, which is one possible application of the more general
descriptor protocol (the same protocol that is used for computed
attributes). IOW, there's nothing specific to 'methods' here, just the
use of two general features (functions and the descriptor protocol).
FWIW, you can write your own callable, and write it so it behave just
like a function here:

import types

class MyCallable(object):
def __call__(self, obj):
print "calling %s with %s" % (self, obj)
def __get__(self, instance, cls):
return types.MethodType(self.__call__, instance, cls)

class Foo(object):
bar = MyCallable()

print Foo.bar
f = Foo()
f.bar()


This is confusing as long as you insist on saying that what you
"def"ined is a method - which is not the case.




It isn't, since there's no "method signature" to look at !-)


The point is that you don't get access to the object "within itself".
You get access to an object *within a function*.

The fact that a function is defined within a class statement doesn't
imply any "magic", it just creates a function object, bind it to a name,
and make that object an attribute of the class. You have the very same
result by defining the function outside the class statement and binding
it within the class statement, by defining the function outside the
class and binding it to the class outside the class statement, by
binding the name to a lambda within the class statement etc...




Nope. That's Java's goal. Python's goals are to maximize opportunities
for good programming, which is quite different.


It's also a way to make Python more complicated than it needs to be. At
least with the current state, you define your functions the same way
regardless of how they are defined, and the implementation is
(relatively) easy to explain. Special-casing functions definition that
happens within a class statement would only introduce a special case.
Then you'd have to explain why you need to specify the target object in
the function's parameters when the function is defined outside the class
but not when it's defined within the class.

IOW : there's one arguably good reason to drop the target object from
functions used as methods implementation, which is to make Python looks
more like Java, and there's at least two good reason to keep it the way
it is, which are simplicity (no special case) and consistency (no
special case).

Anyway, the BDFL has the final word, and it looks like he's not going to
change anything here - but anyone is free to propose a PEP, isn't it ?

The issue here has nothing to do with the inner workings of the Python
interpreter. The issue is whether an arbitrary name such as "self"
needs to be supplied by the programmer.

Neither I nor the person to whom you replied to here (as far as I can
tell) is suggesting that Python adopt the syntax of Java or C++, in
which member data or functions can be accessed the same as local
variables. Any suggestion otherwise is a red herring.

All I am suggesting is that the programmer have the option of
replacing "self.member" with simply ".member", since the word "self"
is arbitrary and unnecessary. Otherwise, everything would work
*EXACTLY* the same as it does now. This would be a shallow syntactical
change with no effect on the inner workings of Python, but it could
significantly unclutter code in many instances.

The fact that you seem to think it would change the inner functioning
of Python just shows that you don't understand the proposal.

 

[Russ P.]

The issue here has nothing to do with the inner workings of the Python
interpreter. The issue is whether an arbitrary name such as "self"
needs to be supplied by the programmer.

Neither I nor the person to whom you replied to here (as far as I can
tell) is suggesting that Python adopt the syntax of Java or C++, in
which member data or functions can be accessed the same as local
variables. Any suggestion otherwise is a red herring.

All I am suggesting is that the programmer have the option of
replacing "self.member" with simply ".member", since the word "self"
is arbitrary and unnecessary. Otherwise, everything would work
*EXACTLY* the same as it does now. This would be a shallow syntactical
change with no effect on the inner workings of Python, but it could
significantly unclutter code in many instances.

The fact that you seem to think it would change the inner functioning
of Python just shows that you don't understand the proposal.

It just occurred to me that Python could allow the ".member" access
regardless of the name supplied in the argument list:

class Whatever:

def fun(self, cat):

.cat = cat
self.cat += 1

This allows the programmer to use ".cat" and "self.cat"
interchangeably. If the programmer intends to use only the ".cat"
form, the first argument becomes arbitrary. Allowing him to use an
empty argument or "." would simply tell the reader of the code that
the ".cat" form will be used exclusively.

When I write a function in which a data member will be used several
times, I usually do something like this:

data = self.data

so I can avoid the clutter of repeated use of "self.data". If I could
just use ".data", I could avoid most of the clutter without the extra
line of code renaming the data member. A bonus is that it becomes
clearer at the point of usage that ".data" is member data rather than
a local variable.

 

[Steven D'Aprano]

And what does that have to do with my suggestion? Absolutely nothing.

Not at all. You're suggesting a change to Python's syntax. I've suggested
a couple more changes to Python syntax. I don't intend them to be taken
seriously, but only to illustrate a point that syntax defines how a
language is written. You want to change that.

It's a red herring that you seem to be using to obscure the fact that
you have no rational argument to make.

I don't have to make a rational argument for keeping the status quo. That
status quo just *is*. You want people to change, you need to convince
them that such a change is not just "not bad" but a serious advantage,
enough to make up for all the work required to implement it.

I'm listening. Tell me why removing self if not merely harmless, but
actively better.

[...]

You seem to be freaked out by an empty argument. Actually, it bothers me
a bit too, which is why I suggested that a period could be used as the
first argument to indicate that, like Clint Eastwood in The Good, the
Bad, and the Ugly, "self" had no name here.

Well there you go now. How should we *talk* about this piece of code? Try
writing a comment or docstring, or even sitting down with a fellow
programmer and discussing it. What do you call this implicit Object With
No Name?

def fun( , cat):
.cat = cat # assumes that the Object With No Name has foo

versus

def fun(self, cat):
self.cat = cat # assumes that self has foo

Before you suggest that people will continue to call the first argument
"self" but just not write it down anywhere, I suggest that's a terrible
idea and one which will confuse a lot of people. "Where's this 'self'
defined? I can't find it anywhere!"

A slightly better suggestion is "the instance", but that fails here:

class C(object):
def method(, other):
assert isinstance(other, C)
.cat = other # assumes that the instance has foo
# er, that is to say, the implicit instance,
# not the other instance


The ability to talk easily about the code is invaluable. Implicit self
makes it harder to talk about the code.


[...]

Actually, I think it's elegant. And I'll bet that if Guido had suggested
it, you would think it was beautiful.

Oh please. I think the syntax for ternary if is ugly, and Guido came up
with that, and it doesn't even use punctuation.

Why force a name to be used when none is needed?

But a name is needed.

class Foo(base1, base2, base3):
def meth(self, arg):
super(Foo, self).meth(arg)
print self
try:
value = _cache[self]
except KeyError:
value = some_long_calculation(self)


How do you pass self to arbitrary functions without a name?

 

[Steven D'Aprano]

I don't see the need for the comma in fun.

<tongue firmly in cheek>
Or the parentheses and colon. Can we remove them too?

 

[Terry Reedy]

On Jul 27, 12:39 pm, Bruno Desthuilliers

All I am suggesting is that the programmer have the option of
replacing "self.member" with simply ".member", since the word "self"
is arbitrary and unnecessary.

I presume you are proposing the opposite also, that ".member" would
internally be expanded to "self.member".

As I said before, that, or something near like it (it is hard to exactly
compare underspecified proposals) has be suggested and rejected, even if
someone gave you not the exact reference. For one thing, as Guido
noted, a single . can be hard to see and easy to miss, depending on
one's eyesight, environmental lighting, and exact display medium,
including font.

I suspect Guido's other reasons have been covered, but I do not want
misquote him. I will leave you to search the pydev list archives.

> Otherwise, everything would work *EXACTLY* the same as it does now.

If I understand you, that would mean that .attribute would raise
NameError: name 'self' is not defined
if used anywhere where 'self' was not defined.

 

[Terry Reedy]

When I write a function in which a data member will be used several
times, I usually do something like this:

data = self.data

so I can avoid the clutter of repeated use of "self.data".

Another reason people do this is for speed, even if self.data is used
just once but in a loop.

 

[Russ P.]

Not at all. You're suggesting a change to Python's syntax. I've suggested
a couple more changes to Python syntax. I don't intend them to be taken
seriously, but only to illustrate a point that syntax defines how a
language is written. You want to change that.

But the syntax change I am suggesting is trivial compared to the
draconian examples you gave.

I don't have to make a rational argument for keeping the status quo. That
status quo just *is*. You want people to change, you need to convince
them that such a change is not just "not bad" but a serious advantage,
enough to make up for all the work required to implement it.

I'm listening. Tell me why removing self if not merely harmless, but
actively better.

[...]

I thought I did just that. I am very meticulous about the appearance
of my code, and the less cluttered the better. That's one of the main
reasons that I use Python. My suggestion would be relatively trivial
to implement, yet it would dramatically reduce clutter. You may not
agree, but I think the case is strong.

Well there you go now. How should we *talk* about this piece of code? Try
writing a comment or docstring, or even sitting down with a fellow
programmer and discussing it. What do you call this implicit Object With
No Name?

How do Java and C++ programmers talk about the instance for which the
method was called? I wasn't aware that that was a problem for them.

def fun( , cat):
.cat = cat # assumes that the Object With No Name has foo

versus

def fun(self, cat):
self.cat = cat # assumes that self has foo

Before you suggest that people will continue to call the first argument
"self" but just not write it down anywhere, I suggest that's a terrible
idea and one which will confuse a lot of people. "Where's this 'self'
defined? I can't find it anywhere!"

Any programmer who can't get past that point needs to find a new line
of work -- such as moving furniture.

A slightly better suggestion is "the instance", but that fails here:

class C(object):
def method(, other):
assert isinstance(other, C)
.cat = other # assumes that the instance has foo
# er, that is to say, the implicit instance,
# not the other instance

The ability to talk easily about the code is invaluable. Implicit self
makes it harder to talk about the code.

I can only imagine what you must think about lambda functions and list
comprehensions.

[...]

Actually, I think it's elegant. And I'll bet that if Guido had suggested
it, you would think it was beautiful.

Oh please. I think the syntax for ternary if is ugly, and Guido came up
with that, and it doesn't even use punctuation.

Off topic, but I happen to like Guido's ternary "if." I use it
wherever I can, within reason.

Why force a name to be used when none is needed?

But a name is needed.

class Foo(base1, base2, base3):
def meth(self, arg):
super(Foo, self).meth(arg)
print self
try:
value = _cache[self]
except KeyError:
value = some_long_calculation(self)

How do you pass self to arbitrary functions without a name?

I didn't say you *never* need the name. If you need it, then use it.
But if you don't need it, you shouldn't be forced to use a name just
for the sake of having a name.

 

[alex23]

What Guido rejected there is most certainly *not*
what I suggested. I agree with Guido on that one.

Orly?

Ian Bicking wrote: "I propose that the self argument be removed from
method definitions."

Philip Eby suggested:

def .aMethod(arg1, arg2):
return .otherMethod(arg1*2+arg2)

Guido shot them all down by stating:

[Y]ou're proposing to hide a
fundamental truth in Python, that methods are "just" functions whose
first argument can be supplied using syntactic sugar

Any more reading comprehension we can do for you?

 

[Derek Martin]

It's actually the parameter list of the *function* that is used as the
implementation of a method. Not quite the same thing.

The idea that Python behaves this way is new to me. For example, the
tutorials make no mention of it:

http://docs.python.org/tut/node11.html#SECTION0011300000000000000000

The Python reference manual has very little to say about classes,
indeed. If it's discussed there, it's buried somewhere I could not
easily find it.

consistency mandates that the target object of the method is part of
the parameter list of the *function*, since that's how you make
objects availables to a function.

Fair enough, but I submit that this distinction is abstruse, and
poorly documented, and also generally not something the average
application developer should want to or have to care about... it's of
interest primarily to computer scientists and language enthusiasts.
The language should prefer to hide such details from the people using
it.

Certainly not.

Seems not so certain to me... We disagree, even after your careful
explanation. See below.

You need to lookup the corresponding attribute *on a given object*
to get the method. Whether you write

some_object.some_method()

or

some_function(some_object)

you still need to explicitely mention some_object.

But these two constructs are conceptually DIFFERENT, whether or not
their implementation is the same or similar. The first says that
some_method is defined within the name space of some_object. The
second says that some_object is a parameter of some_function...

Namespace != parameter!!!!!!!!!

To many people previously familiar with OO programming in other
languages (not just Java or C++), but not intimately familiar with
Python's implementation details, the first also implies that
some_method is inherently part of some_object, in which case
explicitly providing a parameter to pass in the object naturally seems
kind of crazy. The method can and should have implicit knowledge of
what object it has been made a part. Part of the point of using
objects is that they do have special knowledge of themselves... they
(generally) manipulate data that's part of the object. Conceptually,
the idea that an object's methods can be defined outside of the scope
of the object, and need to be told what object they are part
of/operating on is somewhat nonsensical...

This is confusing as long as you insist on saying that what you
"def"ined is a method - which is not the case.

I can see now the distinction, but please pardon my prior ignorance,
since the documentation says it IS the case, as I pointed out earlier.
Furthermore, as you described, defining the function within the scope
of a class binds a name to the function and then makes it a method of
the class. Once that happens, *the function has become a method*.

To be perfectly honest, the idea that an object method can be defined
outside the scope of an object (i.e. where the code has no reason to
have any knowledge of the object) seems kind of gross to me... another
Python wart. One which could occasionally be useful I suppose, but a
wart nonetheless. This seems inherently not object-oriented at all,
for reasons I've already stated. It also strikes me as a feature
designed to encourage bad programming practices.

Even discounting that, if Python had a keyword which referenced the
object of which a given peice of code was a part, e.g. self, then a
function written to be an object method could use this keyword *even
if it is defined outside of the scope of a class*. The self keyword,
once the function was bound to an object, would automatically refer to
the correct object. If the function were called outside of the
context of an object, then referencing self would result in an
exception.

You'll probably argue that this takes away your ability to define a
function and subsequently use it both as a stand-alone function and
also as a method. I'm OK with that -- while it might occasionally
be useful, I think if you feel the need to do this, it probably means
your program design is wrong/bad. More than likely what you really
needed was to define a class that had the function as a method, and
another class (or several) that inherits from the first.

The point is that you don't get access to the object "within itself".
You get access to an object *within a function*.

Thus methods are not really methods at all, which would seem to
suggest that Python's OO model is inherently broken (albeit by design,
and perhaps occasionally to good effect).

The fact that a function is defined within a class statement doesn't
imply any "magic",

It does indeed -- it does more than imply. It states outright that
the function is defined within the namespace of that object, and as
such that it is inherently part of that object. So why should it need
to be explicitly told about the object of which it is already a part?

It further does indeed imply, to hordes of programmers experienced
with OO programming in other languages, that as a member, property,
attribute, or what ever you care to call it, of the object, it should
have special knowledge about the object of which it is a part. It
just so happens that in Python, this implication is false.

IOW : there's one arguably good reason to drop the target object from
functions used as methods implementation, which is to make Python looks
more like Java

No, that's not the reason. I don't especially like Java, nor do I use
it. The reason is to make the object model behave more intuitively.

, and there's at least two good reason to keep it the way it is,
which are simplicity (no special case) and consistency (no special
case).

Clearly a lot of people find that it is less simple TO USE. The point
of computers is to make hard things easier... if there is a task that
is annoying, or tedious, or repetitive, it should be done by code, not
humans. This is something that Python should do automatically for its
users.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIjT9mdjdlQoHP510RAnxjAKC7rqfzfYCDhLLhI+M/ZZCDYCdmBwCfYp0k
+/raNY4nvrMQvXwoKWcZMxo=
=wTKA
-----END PGP SIGNATURE-----

 

[Lawrence D'Oliveiro]

In message

You mean the keyword "this"? It's just a feature. How does that make a
difference on being or not being OO?

Because it was one of the things the OP was complaining about (see above).

 

[castironpi]

Derek Martin a écrit :

Nope. That's Java's goal. Python's goals are to maximize opportunities
for good programming, which is quite different.

+1 QOTW