«

> This is just plain wrong for at least C# and C++. *C# wants you to
> explicitly overload "!=", if you have overloaded "==",

While this is as inconvenient as Python at least it doesn't catch you
unawares. C# 1 (or maybe 0.5), Python 0.

> C++ complains
> about "!=" not being defined for class A. *

See above. C++ 1, Python 0.

So in showing my clearly hyperbolic comment was technically incorrect
(something I could have told you myself), you have merely shown that
two languages I find vastly inferior to Python overall are actually
better than it in this case.

> Fortunately, Python isn't designed according to your ideas, and won't
> change, so consider your posting a waste of time. *If feeling like bringing
> such old "issues" up again next time, spend your time learning another
> programming language, as you would obviously not get happy with Python
> anyway ...

OK, if that's your response, that's sad. Of course, I try to learn new
languages all the time. Python is still IMO the best. If the attitude
in the community in response to feedback/criticism has gone from
"maybe you've got a point" to "your a lunatic, we'll never change",
well, only Python will suffer in the long term.

On Jul 24, 8:01*pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> In message
> <52404933-ce08-4dc1-a558-935bbbae7...@r35g2000prm.googlegroups.com>, Jordan
> wrote:
>
> > Except when it comes to Classes. I added some classes to code that had
> > previously just been functions, and you know what I did - or rather,
> > forgot to do? Put in the 'self'. In front of some of the variable
> > accesses, but more noticably, at the start of *every single method
> > argument list.*
>
> The reason is quite simple. Python is not truly an "object-oriented"
> language. It's sufficiently close to fool those accustomed to OO ways of
> doing things, but it doesn't force you to do things that way. You still
> have the choice. An implicit "self" would take away that choice.

You could still explicitly request non-implicit self on a method by
method basis.

On 24 Jul., 11:40, Torsten Bronger <bron...@physik.rwth-aachen.de>
wrote:
> Hallöchen!
>
> Bruno Desthuilliers writes:
> > [...]
>
> > How would you handle this case with an implicit 'self' :
>
> > class Foo(object):
> > pass
>
> > def bar(self):
> > print self
>
> > Foo.bar = bar
>
> Just like this. However, the compiler could add "self" to
> non-decorated methods which are defined within "class".

And $self2, $self3, ... to the object methods of nested classes and
$cls2, $cls3, ... to the classmethods of those classes...?

And when we are at it, here is a nice little exercise for the
proponents of compiler magic.

Write a decorator that takes and returns a method and prints the
object the method is bound to. It's very easy to do it when the object
is passed explicitely:

def print_self(func):
def call(self, *args, **kwd):
print self
return func(self, *args, **kwd)
return call

Conceptual clarity isn't always an entirely bad thing to have.

On Jul 24, 8:21*pm, Jordan <jordanrastr...@gmail.com> wrote:
> If the attitude
> in the community in response to feedback/criticism has gone from
> "maybe you've got a point" to "your a lunatic, we'll never change",
> well, only Python will suffer in the long term.

Personally, I think it has more to do with statements like "there are
plenty of smart Python programmers who will
justify all kinds of idiocy in the name of their holy crusade" than
with your position. You don't begin a discussion by discrediting
anyone who might disagree with you as some kind of religious bigot
while simultaneously holding that you are the only sane voice
speaking.

Jordan a écrit :
> OK, it seems my original reply to Bruno got lost in the Aether
> (apologies therefore if a paraphrased "quantum duplicate" of this
> message is eventually forthcoming.)
>
> Torsten has adequately responded to his second point,

Not MHO, by far.

> so I need only
> replicated what I said for the first.
>
>> Please get your facts, the behaviour *is* actually fully documented:
>
> I have the facts. I know full well the behaviour is documented

Then why do you write, let me quote:

"""
(snip) coding __eq__ (snip) buys you
nothing from the != operator. != isn't (by default) a synonym for the
negation of == (unlike in, say, every other language ever); not only
will Python let you make them mean different things, without
documenting this fact - it actively encourages you to do so.
"""


>- it
> was pointed out at the time of the original discussion. Documenting a
> confusing, unintuitive design decision (whether its in a programming
> language, an end user GUI app or anything in between) doesn't justify
> it.

I was not commenting on the actual design choice, just stating that it
is actually documented.

> To attack a strawman: "foolanguage uses the bar IO library; printing
> to stdout takes about 10 mins on the average machine. But thats ok,
> because look, its documented right here."

And you're talking about strawman ??? Come on, you obviously can tell
the difference between a one-line statement and your above strawman
argument, don't you ?

Please understand that I'm not arguing about this particular design
choice (and FWIW, I'd mostly agree on the point that having a != b
different from not (a == b) is actually a wart). I'm just correcting
your statement about the behaviour of __eq__ / __ne__ not being
documented, which is obviously false.

(snip)

Torsten Bronger a écrit :
> Hallöchen!
>
> Bruno Desthuilliers writes:
>
>> [...]
>>
>> How would you handle this case with an implicit 'self' :
>>
>> class Foo(object):
>> pass
>>
>> def bar(self):
>> print self
>>
>> Foo.bar = bar
>
> Just like this. However, the compiler could add "self" to
> non-decorated methods which are defined within "class".

What's defined within classes are plain functions. It's actually the
lookup mechanism that wraps them into methods (and manage to insert the
current instance as first argument).

Torsten Bronger a écrit :
> Hallöchen!
>
> Kay Schluehr writes:
>
>> On 24 Jul., 11:40, Torsten Bronger <bron...@physik.rwth-aachen.de>
>> wrote:
>>> Bruno Desthuilliers writes:
>>>
>>>> [...]
>>>>
>>>> How would you handle this case with an implicit 'self' :
>>>>
>>>> class Foo(object):
>>>> pass
>>>>
>>>> def bar(self):
>>>> print self
>>>>
>>>> Foo.bar = bar
>>> Just like this. However, the compiler could add "self" to
>>> non-decorated methods which are defined within "class".
>> And $self2, $self3, ... to the object methods of nested classes
>> and $cls2, $cls3, ... to the classmethods of those classes...?
>
> One could surely find ways to realise this. However, the design
> goal should be: Make the frequent case simple, and the rare case
> possible.

Given the (more and more prominent) use of decorators, metaclasses and
other meta-programming techniques in Python, I'm not sure the cases
where you really need access to Python's object model inners are that
"rare". Not in my code at least.

Jordan <>:

>> Fortunately, Python isn't designed according to your ideas, and won't
>> change, so consider your posting a waste of time. Â*If feeling like
>> bringing such old "issues" up again next time, spend your time learning
>> another programming language, as you would obviously not get happy with
>> Python anyway ...
>
> OK, if that's your response, that's sad. Of course, I try to learn new
> languages all the time. Python is still IMO the best. If the attitude
> in the community in response to feedback/criticism has gone from
> "maybe you've got a point" to "your a lunatic, we'll never change",
> well, only Python will suffer in the long term.

I don't really mind, what you think about my response. Python will suffer
from it as little as it will suffer from your complaints: These things
will not change, whatever any of us says about them. So this discussion
unlikely to produce any new insight, especially because this as been
discussed over and over again in the past, without any effect on Python.

Let's just drop this, and if you want to complain next time, just complain
about something, that is really worth being complained about, like for
instance old and outdated modules in the standard library, or real
showstoppers in Python (e.g. the GIL).

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

Lawrence D'Oliveiro a écrit :
> In message
> <52404933-ce08-4dc1-a558->, Jordan
> wrote:
>
>> Except when it comes to Classes. I added some classes to code that had
>> previously just been functions, and you know what I did - or rather,
>> forgot to do? Put in the 'self'. In front of some of the variable
>> accesses, but more noticably, at the start of *every single method
>> argument list.*
>
> The reason is quite simple. Python is not truly an "object-oriented"
> language.

Oh yes ? What's missing exactly ? You have objects that have an id,
state and behaviour, and you have a message-passing mechanism.

You meant "Python is not truly a mainstream class-based language", I think.

> It's sufficiently close to fool those accustomed to OO ways of
> doing things,

s/OO/class-based/

> but it doesn't force you to do things that way. You still
> have the choice. An implicit "self" would take away that choice.

It's not even a question of OO/non-OO. An implicit "self" would take
away some things that makes Python's *object* model so powerful.

> Personally, I think it has more to do with statements like "there are
> plenty of smart Python programmers who will
> justify all kinds of idiocy in the name of their holy crusade" than
> with your position. You don't begin a discussion by discrediting
> anyone who might disagree with you as some kind of religious bigot
> while simultaneously holding that you are the only sane voice
> speaking.

I didn't set out to discredit anyone who might disagree with me; in
fact I didn't in anyway try to pre-empt any person who might disagree
with my thesis. I merely stated an observation - I have in the past
seen seemingly intelligent people take silly stands in the name of
Explicit is greater than Implicit (not just on comp.lang.python, and
not just concerning != or self).

I wish in retrospect I'd had the time, patience and focus to edit the
initial post to make it more measured and less inflammatory, because
its clear the tone detracts from the argument I'm making, which I feel
still stands.

So if you wish, ignore the specifics of the frustration that inspired
me and consider only the thrust of what I'm saying:

"Explicit is better than Implict" considered harmful. Discuss.