Attack a sacred Python Cow

[Jordan]

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.  

You're right, of course. Because Python is in so many ways what I'm
looking for in a language, I transform it in my mind to my own,
personal ideal, close to the real existing language but with what I
consider to be the imperfections removed.

I'm not suggesting getting rid of explicit self, even in "Python
4000." Not because of the advantages it gives, which are some but
don't outweigh the net loss in my ledger. It just wouldn't be
Pythonic. I know its not a Pythonic thing to want. Thats my problem -
because I have a largely Pythonic approach in some areas, it upsets me
when there's a mismatch. So lets say I'm -1 for introducing it into a
language and +0 for keeping it in Python now that its entrenched.

If a lot of users keep bringing up something like this, well my
attitude used to be the same as yours - "learn to love Python for what
it is." Maybe

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

Its worth complaining about because I'm not just someone who has
stumbled across Python after years of Java and PHP, and hasn't really
grokked it, and has jumped on the net at once to start a flamewar. I'm
someone who loves Python, uses it in preference to other languages,
and have now returned to it after a bit of a break and its finally hit
me over the head like a tonne of bricks "Hey, I can see exactly what
all those internet trolls were talking about. This *is* a really
annoying and silly state of affairs."

I was trying not to change explicit self, or even != (which has a much
better case.) I was trying to ask the community to reconsider a
premise that the language is built around. Explicit is actually kinda
annoying a lot of the time, viz., java. This is about social and
philosophical adjustments, not technical ones.

In reality? I'll just keep writing Python (hopefully enough so that
explicit self become burned into muscle memory), and use other
languages when necessary (no more C than I have to, looking forward to
dabbling in Erlang soon, and one day overcoming the parentheses phobia
enough to really tackle Lisp properly). When I'm old enough and wise
enough, and have the time, energy and inclination, maybe I'll sit down
and put a proper effort into designing and implementing a new language
that bests suits my own particular style and needs. Just maybe it'll
be good enough that smart people will rally to defend its design
principles from people attacking them on the internet

 

[cokofreedom]

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)

What was the reasoning behind having both __eq__ / __ne__ anyway? To
fit in with the equality comparisons? I do agree this one seems like
a wart, but not a serious one. I'd say it would make more sense for
the interpreter to provide a warning on classes that define one and
not that other, at least if set to a certain level, similar to -3 for
depreciated.

(Or does this exist? I think a "wart" catching level that outputs
potential warts and issues would be a useful addition!)

 

[Jordan]

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

My words aren't as clear as they should be. I mean that Python lets
*you* do something without documenting, or rather stating to use a
better term, that your intention is the non-obvious one. I'm not
saying that Python itself lacks documentation for its own behaviour;
I'm saying it should force you to make your intentions clear and
visible to someone reading your code when you want to do something non-
obvious.

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

Yes, it is. I apologise for the poor construction of my statement
which led to this confusion.

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 ?

I'm talking about strawmen because I was deliberately choosing to
invoke one with rhetorical flourish for the purposes of making my
point forcefully. I wanted people to be clear that I knew perfectly
well what I was doing and that they needn't call me out on it.

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.

Good, at least we've come to a point in this discussion where I can
firmly agree with somebody.

 

[Bruno Desthuilliers]

Torsten Bronger a écrit :

Hallöchen!

Torsten Bronger a écrit :

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

And why does this make the implicit insertion of "self" difficult?

Did I say such a thing ?

Call me pedantic if you want, but I find it easier to understand how
something works when using the appropriate terms, that's all.

I could easily write a preprocessor which does it after all.

A source-code-preprocessor based solution wouldn't do IMHO. But that was
not the point. The point is that a working solution would require to
handle "functions-or-else" defined within a class statement as a special
case, which obviously makes thing more compl[ex|icated]. Now as far as
I'm concerned, as long as such a solution 1/ doesn't impose any
restriction wrt/ current features of Python's object model and 2/
doesn't make any of the currently used "metaprogramming" idioms more
difficult, I just wouldn't care.

 

[cokofreedom]

My words aren't as clear as they should be. I mean that Python lets
*you* do something without documenting, or rather stating to use a
better term, that your intention is the non-obvious one. I'm not
saying that Python itself lacks documentation for its own behaviour;
I'm saying it should force you to make your intentions clear and
visible to someone reading your code when you want to do something non-
obvious.

I take it you are relating to the need for less comments within the
code as the idea is the Python code itself is readable? Or are you
saying that when someone does a clever trick it should be documented
better? I'm a little confused as what you mean by no-documenting? I
always add doc-strings to modules I will be using heavily as well as a
README with them. But that isn't different from programming in other
languages and using comments.

(Do you mean something like JavaDoc?)

 

[Jordan]

You're not a lunatic.

We, and Python itself, change quite readily.

Neither of those mean your ideas in this instance have merit.

You're right, these premises don't lead to this conclusion. Neither do
they lead to its negation, of course.

As it happens, you're wrong on both counts. I do in fact suffer from a
mental illness and have spent a week in a psych ward, so am a lunatic
by some reasonable definitions. Python readily changes in some
regards, but not in others. Of course, a great many things of worth
have this as one of their essential qualities.

Pithy replies are fun.

Thanks for your opinion. I disagree strongly: I think its influence is
nicely balanced by the other important principles that are also
followed.

This isn't just being clever, there's substance here. A clearly stated
opposing position, with a decent if somewhat short justification.

I think you're right insofar as you go - that if someone really sits
down, and thinks clearly about all the Pythonic principles, as a
whole, and in detail, then the net result in the shaping their
thinking will be positive more often than not.

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.

 

[Tim Golden]

Just wondered whether the OP's Subject was a
deliberate play on "flog a dead horse" or
merely an ironic one

TJG

 

[Paul Boddie]

Fortunately, Python isn't designed according to your ideas, and won't
change, so consider your posting a waste of time.

This is the kind of petty response that serves only to shut down
discussion that might actually lead to genuine attempts to remedy
issues (or "warts") with Python. Although the tone of the complaint
was badly chosen, it is always worth jumping over the fence and
considering whether things could be made better. Without complaints
being aired, how do you expect any advances around things like the
"old and outdated modules in the standard library, or real
showstoppers in Python (e.g. the GIL)" that you mention elsewhere?

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

Such a constructive response that is! Instead, I think it is
interesting to consider why methods still require an explicit "self"
parameter - something which has been discussed previously - and
whether there might be a case for omitting it from the signature -
perhaps in a variant of Python - in methods which are defined within
class definitions (as opposed to those assigned to classes later).

Indeed, there's scope for experimentation with Python variants, just
to investigate whether certain features added to CPython can be
considered essential, and which features might be considered of
marginal benefit. I recall that some features (eg. lexical scoping and
closures) were eventually added to Python partly to remedy issues with
lambda definitions, but also because the lack of such features was
cited repeatedly by proponents of other languages. In such a climate,
it can be easier to "meet the challenge" and implement features to
silence the critics rather than to insist that they are of marginal
benefit (although it's interesting to note this in a thread where
improvement suggestions are deemed "a waste of time" - I suppose the
community is now more resistant to suggestions from "unofficial"
sources).

A review of such language "enhancement" decisions would be
interesting, but since one shouldn't expect this from the CPython
implementers, I feel that it is the role of others to do so in their
own experiments. Of course, such experiments are often derided as
"lesser Pythons" or misunderstood, but that's another unfortunate
trait exhibited by parts of the Python community.

Paul

 

[Bruno Desthuilliers]

Jordan a écrit :

My words aren't as clear as they should be. I mean that Python lets
*you* do something without documenting, or rather stating to use a
better term, that your intention is the non-obvious one.

I'm not
saying that Python itself lacks documentation for its own behaviour;
I'm saying it should force you to make your intentions clear and
visible to someone reading your code when you want to do something non-
obvious.

<nitpick>
One could then answer than, the behaviour of __eq__ / __ne__ being
clearly defined and documented, implementing one without the other - or
in such a way that a != b is different from not(a == b) - is by itself
an explicit 'statement of intention' !-)
</nitpick>

(snip strawmens)

Good, at least we've come to a point in this discussion where I can
firmly agree with somebody.

On that concrete case, a priori, yes. wrt/ the 'explicit self', there
are in fact two points:

1/ The mandatory use of 'self' to access the current instance.

As far as I'm concerned, and *even if there was no other technical
reasons*, I wholefully, happily and definitively agree with this choice
- specially in a language like Python (it's not quite the same problem
with Java where you just can't put anything outside a class). It's truly
(and IMHO, of course) a case where explicit-is-better-than-implicit,
period.

Strange enough, I never heard of anyone complaining about the mandatory
use of $this-> in PHP. Nor about the mandatory use of @/@@ in Ruby. Nor
about the 'm_whatever' naming convention in C++. Nor about [add your own
example here].

2/ The need to explicitely declare the 'target' object (self or cls) as
first param of a 'function-to-be-used-as-method'.

Granted, this one may feel a bit "unfinished" at first. And I would not
bet my life on it, but I think one could possibly find some "solution"
that would not as a side-effect impose any restriction wrt/ the current
implementation.

OTHO, given 1/, and since the way Python builds "methods" out of just
two more general constructs (the def statement and the descriptor
protocol) is part of what makes it's object model so powerful, I don't
feel like the price to pay to keep the implementation as simple as
possible is too high. IOW, while I would not turn down a "solution" like
the one mentionned above (let's say -0 as far as I'm concerned), I just
don't think it would be worth the time spent.

Anyway, "explicit is better than implicit" is not the appropriate
dogmatic justification here - but a couple other quotes from the
Python's Zen could apply (left as an exercice to the reader) !-)

 

[Bruno Desthuilliers]

Jordan a écrit :

You're right, of course. Because Python is in so many ways what I'm
looking for in a language, I transform it in my mind to my own,
personal ideal, close to the real existing language but with what I
consider to be the imperfections removed.

I guess you'll find a lot of us guilty here too - but do we really agree
on what we consider to be "imperfections" ?-)

(snip)

I was trying not to change explicit self, or even != (which has a much
better case.) I was trying to ask the community to reconsider a
premise that the language is built around. Explicit is actually kinda
annoying a lot of the time, viz., java. This is about social and
philosophical adjustments, not technical ones.

"explicit-is-etc" - just like the remaining of Python's zen - is a
general philosophy statement, not an absolute rule. Another quote states
that practicality beats purity.

So yes, Python has warts, and one can't get away dogmatically quoting
Python's zen. Even if I'm sometimes myself guilty here, it's certainly
worth taking time to better address criticism, either by aknowledging
effective warts when someone points them out or by explaining (or
pointing to explanations of) the unusual parts of Python's design.

Now since most of the times, criticisms expressed here fall in the
second category, we're happy to learn you'll now take appropriate action
here and help us keep c.l.py a newbie-friendly place !-)

 

[Sebastian \lunar\ Wiesner]

Hallöchen!

Torsten Bronger a écrit :

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

And why does this make the implicit insertion of "self" difficult?
I could easily write a preprocessor which does it after all.

Who said, that it would be "difficult"? He just corrected your statement
about definitions inside a class, and did not make any assumption about
making "self" implicit.

I'd assume, that making self implicit wouldn't be that difficult to assume.
But does the fact, that it could easily be done, alone mean, that it
_should_ be done? The explicit "self" was a design decision, that can't
really be judged by technical arguments from implementation side. Its a
discussion about design from a programmers point of view ...

 

[alex23]

I could easily write a preprocessor which does it after all.

Have you considered actually doing so? That might resolve the whole
issue, if a tool exists for those who want implicit self. After all,
if -you- have the itch...

Perhaps you could leverage off of EasyExtend?

"EasyExtend (EE) is a preprocessor generator and metaprogramming
framework written in pure Python and integrated with CPython. The main
purpose of EasyExtend is the creation of extension languages i.e.
adding custom syntax and semantics to Python."

http://www.fiber-space.de/EasyExtend/doc/EE.html

 

[castironpi]

Torsten Bronger <[email protected]>:

Hallöchen!

Bruno Desthuilliers writes:

Torsten Bronger a écrit :
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).

And why does this make the implicit insertion of "self" difficult?
I could easily write a preprocessor which does it after all.

Who said, that it would be "difficult"?  He just corrected your statement
about definitions inside a class, and did not make any assumption about
making "self" implicit.

I'd assume, that making self implicit wouldn't be that difficult to assume.
But does the fact, that it could easily be done, alone mean, that it
_should_ be done?  The explicit "self" was a design decision, that can't
really be judged by technical arguments from implementation side.  Its a
discussion about design from a programmers point of view ...

I don't think you can infer from 'explicit is better than implicit'
that 'the more explicit the better'. For instance, we don't use:

python.callbyvalue.foo( bar, 1, 2 )
python.callbyref.foo2( bar, x, y )

or further:

foo( byref bar, byval 1, byval 2 )
foo2( byref bar, byref x, byref x )

though some languages do.

Python doesn't do that much implicity, like copying, with the
exception of copying strings, which some string functions do, such as
lower, replace, strip. (Does slicing return a new string?)

What is the most surprisingly implicit behavior in Python? What is
the most explicit?

 

[castironpi]

Jordan a écrit :



I guess you'll find a lot of us guilty here too - but do we really agree
on what we consider to be "imperfections" ?-)

(snip)


"explicit-is-etc" - just like the remaining of Python's zen - is a
general philosophy statement, not an absolute rule. Another quote states
that practicality beats purity.

So yes, Python has warts, and one can't get away dogmatically quoting
Python's zen. Even if I'm sometimes myself guilty here, it's certainly
worth taking time to better address criticism, either by aknowledging
effective warts when someone points them out or by explaining (or
pointing to explanations of) the unusual parts of Python's design.

Now since most of the times, criticisms expressed here fall in the
second category, we're happy to learn you'll now take appropriate action
here and help us keep c.l.py a newbie-friendly place !-)

Something that is pure and explicit is a conflict of priorities with
something that is practical and implicit. As with any rules, there
are going to be times when the priorities in the Zen conflict with one
another, and the Zen is silent on which combination ranks higher.

Some people will hate you for using 'sf' instead of 'self'... but some
hate you for spelling errors too. A temper lost is a flamewar earned.

If you post two equivalent code snippets that both work, we can help
you compare them.

 

[Terry Reedy]

Hallöchen!
> And why does this make the implicit insertion of "self" difficult?
I could easily write a preprocessor which does it after all.

class C():
def f():
a = 3

Inserting self into the arg list is trivial. Mindlessly deciding
correctly whether or not to insert 'self.' before 'a' is impossible when
'a' could ambiguously be either an attribute of self or a local variable
of f. Or do you and/or Jordan plan to abolish local variables for methods?

tjr

 

[Terry Reedy]

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

I will ignore that.

> detracts from the argument I'm making, which I feel still stands.

class C():
def f():
a = 3

You made a complaint and an incomplete proposal identical to what others
have proposed. But here is where the idea always sinks. Suppose as you
propose 'self' is added to the arg list. How is a mindless algorithm to
decide whether to change a to 'self.a' to make it an attribute or leave
it alone as a local variable? Or would you abolish local vars from
methods (which would slow them down)?

As near as I can see, any concrete detailed implementable proposal would
be a more major change in Python or its implementation than
'down-with-self'ers usually admit.

If the argument you refer to is instead that 'Explicit is better than
Implicit' is a bit overused and inadequate as a technical response, then
I agree. But excuse me for being unsure ;-).

Terry Jan Reedy

 

[Benjamin]

"explicit-is-etc" - just like the remaining of Python's zen - is a
general philosophy statement, not an absolute rule. Another quote states
that practicality beats purity.

Very much so. In fact, I'd like you all to take a detour to a recent
bug report [1] where I gained some interesting insight into the Zen.

[1] http://bugs.python.org/issue3364

 

[Lawrence D'Oliveiro]

In message

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

That would mean making OO the default. Which Python doesn't do.

 

[Kay Schluehr]

class C():
def f():
a = 3

Inserting self into the arg list is trivial. Mindlessly deciding
correctly whether or not to insert 'self.' before 'a' is impossible when
'a' could ambiguously be either an attribute of self or a local variable
of f. Or do you and/or Jordan plan to abolish local variables for methods?

tjr

This isn't the problem Jordan tries to address. It's really just about
`self` in the argument signature of f, not about its omission in the
body. Some problems occur when not `self` shall be used but e.g.
`this`. Here one has to specify more:

class C():
__self__ = 'this' # use `this` instead of `self`
def f(a):
this.a = a

or

class C():
def f($this, a): # use `this` instead of `self`
this.a = a

When an $-prefixed parameter is found the automatic insertion of
`self` will be blocked and the $-prefixed parameter name will be used
instead but without the prefix.

 

[s0suk3]

In message


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.

By that logic, C++ is not OO. By that logic, Ruby is not OO. By that
logic, I know of only one OO language: Java

The fact that a language doesn't force you to do object-oriented
programming doesn't mean that it's not object-oriented. In other
words, your words are nonsense.

Sebastian