Attack a sacred Python Cow

[D'Arcy J.M. Cain]

Re: Attack a sacred Python Cow

On Sat, 26 Jul 2008 16:25:18 +0200
Torsten Bronger <bronger@physik .rwth-aachen.dewrote:

Isn't this a showstopper all by itself?

>
Yes. But I've seen no code that uses some other word. Emacs'
syntax highlighting even treats it as reserved. So I think that
other counter-arguments are stronger.
>
The in my opinion strongest one is that automatic insertion of
"self" would make Python less verbose but more complicated.

Well, if we are arguing over which reason to not change it is more
important than I would say that we are in "violent agreement." :-)

--
D'Arcy J.M. Cain <darcy@druid.ne t | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

[Torsten Bronger]

Re: Attack a sacred Python Cow

Hallöchen!

D'Arcy J.M. Cain writes:

On Sat, 26 Jul 2008 16:25:18 +0200
Torsten Bronger <bronger@physik .rwth-aachen.dewrote:
>

>>Isn't this a showstopper all by itself?

>>
>Yes. But I've seen no code that uses some other word. Emacs'
>syntax highlighting even treats it as reserved. So I think that
>other counter-arguments are stronger.
>>
>The in my opinion strongest one is that automatic insertion of
>"self" would make Python less verbose but more complicated.

>
Well, if we are arguing over which reason to not change it is more
important than I would say that we are in "violent agreement."
:-)

Oh, I've never been in favour of the change
(news:87zlo7y2w n.fsf@physik.rw th-aachen.de). I just don't think
that some popular counter-arguments are compelling. ;-)

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten.bronger @jabber.rwth-aachen.de

[Kay Schluehr]

Re: Attack a sacred Python Cow

On 26 Jul., 09:45, Torsten Bronger <bron...@physik .rwth-aachen.de>
wrote:

Hallöchen!
>
Terry Reedy writes:

[...]

>

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' if they want instead of the 'self' version. And
again, not everyone writes in English.

>
Of course, "self" would have to become a reserved word.

??

This is an extra requirement. Why do you want to make 'self' a keyword?

[Torsten Bronger]

Re: Attack a sacred Python Cow

Hallöchen!

Kay Schluehr writes:

On 26 Jul., 09:45, Torsten Bronger <bron...@physik .rwth-aachen.de>
wrote:

>>
>Terry Reedy writes:
>>

>>[...]
>>>
>>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' if they want instead of the 'self' version.
>>And again, not everyone writes in English.

>>
>Of course, "self" would have to become a reserved word.

>
??
>
This is an extra requirement. Why do you want to make 'self' a
keyword?

How could one determine which other identifier must be inserted into
the method's signature?

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten.bronger @jabber.rwth-aachen.de

[Aahz]

Re: Attack a sacred Python Cow

In article <5845bf4f-65bf-4a36-b9fe-25cd896b6926@q2 8g2000prh.googl egroups.com>,
Jordan <jordanrastrick @gmail.comwrote :

>
>The point I was trying to make originally was that applying any mantra
>dogmatically , including Explicit is better than implicit, can lead to
>bad results. Perhaps having Practicality beats purity is enough of a
>reminder of that fact for the Python community :-)

IMO, you made a big mistake in combining your point with two other meaty
issues (whether method definitions should include self and whether !=
should use __eq__() as a fallback). Moreover, your point is IMO not
sufficiently proven (that is, I see little evidence that Python
development follows any one point of the Zen of Python dogmatically).

You should therefore not be particularly surprised that the discussion
has gone sideways to your intentions -- especially when you start with a
flamebait Subject: line of "attacking sacred cows"! If solid discussion
is your goal, I suggest that you wait a couple of weeks and start over
with a brand-new thread.
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!

[Michele Simionato]

Re: Attack a sacred Python Cow

On Jul 26, 5:28 pm, a...@pythoncraf t.com (Aahz) wrote:

IMO, you made a big mistake in combining your point with two other meaty
issues (whether method definitions should include self and whether !=
should use __eq__() as a fallback).

<snip>

 If solid discussion
is your goal, I suggest that you wait a couple of weeks and start over
with a brand-new thread.

I fully subscribe this. The point about __eq__ is legitimate and could
be discussed with quite tones.
I was bitten by this surprising behavior just a few
days ago, I had defined __eq__ and I expected __neq__
to be defined in the obvious way. I saw that it was
not the case and I figured out immediately that
I had to override __neq__ explicitely (I have
the "explicit is better than implicit" mantra
ingrained in my mind too), I did so and everything
worked out as a charm. Total time loss: five minutes.
So, it is not a big point. Still I think
that it would make sense to automatically
define __neq__ as the negation of __eq__.
I suppose the developers did not want to make a special
case in the implementation and this is also a legitimate
concern.

Michele Simionato

[Paul Boddie]

Re: Attack a sacred Python Cow

On 26 Jul, 06:06, Terry Reedy <tjre...@udel.e duwrote:

Paul Boddie wrote:

"The problem is that the explicit requirement to have self at the
start of every method is something that should be shipped off to the
implicit category."

Here, I presume that the author meant "at the start of every method
signature".

There is no requirement to have 'self' in the parameter list. It can be
's', 'this', 'me', 'yo'(Spanish for I), or 'cls' (for class methods), or
any other identifier in whatever language.

But Jordan apparently wanted to omit that parameter. The omission of
all mentions of "self" could be regarded as a bonus, but it's a non-
trivial goal.

In 3.0, identifiers are not restricted to ascii but can be any unicode
'word' as defined in the manual.
>
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. However, I think this
is pretty silly. Just write the name you want.

If, as I wrote, you permit the omission of "self" in method signatures
defined within class definitions, then you could still insist on
instance attribute qualification using "self" - exactly as one would
when writing Java according to certain style guidelines.

Paul

[Terry Reedy]

Re: Attack a sacred Python Cow



Carl Banks wrote:

On Jul 24, 4:11 am, Jordan <jordanrastr... @gmail.comwrote :

>Of course not.
>>
>I just think Explicit is better than Implicit is taken seriously by a
>large segment the Python community as a guiding principle,

>
Yeah, try telling that to the people who advise writing "if x" instead
of "if x==0", or "if s" instead of "if len(s)==0".

Whether or not one should write 'if x' or 'if x != 0' [typo corrected]
depends on whether one means the general 'if x is any non-null object
for which bool(x) == True' or the specific 'if x is anything other than
numeric zero'. The two are not equivalent. Ditto for the length example.

What people do properly advise against is the strictly redundant 'if x
is True' or 'if x == True'. Both imply a misunderstandin g of how 'if'
works in Python.

As a side note, the usefulness of specific comparisons is greater in 3.0
where spurious comparisons raise exceptions. In 3.0, 'if x >= 0'
specifically means 'if x is a number comparable to ints that is greater
than or equal to 0'. In 3.0, [] ==/!= 0 are still False/True, but one
could exclude incomparables with 'if 0 <= x >= 0' (==0) or 'if x 0 or
x < 0' (!=0). Any such specific comparisons could be used with this
pattern.

try:
x = []
if x >= 0:
print('should not get here')
except TypeError as m:
if m.args[0].startswith('un orderable types:'):
print('Here because of bad comparison')

Terry Jan Reedy

[Terry Reedy]

Re: Attack a sacred Python Cow



Torsten Bronger wrote:

Hallöchen!
>
Terry Reedy writes:
>

>[...]
>>
>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' if they want instead of the 'self' version. And
>again, not everyone writes in English.

>
Of course, "self" would have to become a reserved word. You could
say that this may break some code,

Will break.

but I don't see much freedom removed from the language.
After all, being a German, I still can't
write "Für i in range(10)". ;-)

But you can write 'for ubermenchen in range(10):' and in 3.0, with
diacritics added. Would you really feel no loss of freedom if Guido
make i0, i1, ... into keywords, which means they could not be used
elsewhere, and mandated them as for loop index variables?

[Terry Reedy]

Re: Attack a sacred Python Cow



Nikolaus Rath wrote:

>
I think you misunderstood him.

I did, but addressed the below in another post.

What he wants is to write
>

class foo:
def bar(arg):
self.whatever = arg + 1
>
instead of
>
class foo:
def bar(self, arg)
self.whatever = arg + 1
>
so 'self' should *automatically* only be inserted in the function
declaration, and *manually* be typed for attributes.

which means making 'self' a keyword just so it can be omitted. Silly
and pernicious.

tjr

[Terry Reedy]

Re: Attack a sacred Python Cow



Torsten Bronger wrote:

Hallöchen!
>
D'Arcy J.M. Cain writes:
>

>On Sat, 26 Jul 2008 09:45:21 +0200
>Torsten Bronger <bronger@physik .rwth-aachen.dewrote:
>>

>>Of course, "self" would have to become a reserved word. You
>>could say that this may break some code, but I don't see much
>>freedom

>Isn't this a showstopper all by itself?

>
Yes. But I've seen no code that uses some other word.

There is a lot of code you have not seen. Really. In informal code I
use 's' and 'o' for 'self' and 'other'. I don't usually post such
because it is not considered polite. So you have seen a biased sample
of the universe.

[Torsten Bronger]

Re: Attack a sacred Python Cow

Hallöchen!

Terry Reedy writes:

Torsten Bronger wrote:
>

>Terry Reedy writes:
>>

>>[...]
>>>
>>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' if they want instead of the 'self' version.
>>And again, not everyone writes in English.

>>
>Of course, "self" would have to become a reserved word. You
>could say that this may break some code,

>
Will break.

No more than Python 3.0 breaks.

>but I don't see much freedom removed from the language. After
>all, being a German, I still can't write "Für i in range(10)".
>;-)

>
But you can write 'for ubermenchen in range(10):' and in 3.0, with
diacritics added. Would you really feel no loss of freedom if
Guido make i0, i1, ... into keywords, which means they could not
be used elsewhere, and mandated them as for loop index variables?

I would, but I consider "self" becoming a keyword not even in the
same league as i0, i1 etc.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten.bronger @jabber.rwth-aachen.de

[Terry Reedy]

Re: Attack a sacred Python Cow



Paul Boddie wrote:

On 26 Jul, 06:06, Terry Reedy <tjre...@udel.e duwrote:

>Paul Boddie wrote:

>>"The problem is that the explicit requirement to have self at the
>>start of every method is something that should be shipped off to the
>>implicit category."

>
Here, I presume that the author meant "at the start of every method
signature".
>

>There is no requirement to have 'self' in the parameter list. It can be
>'s', 'this', 'me', 'yo'(Spanish for I), or 'cls' (for class methods), or
>any other identifier in whatever language.

>
But Jordan apparently wanted to omit that parameter. The omission of
all mentions of "self" could be regarded as a bonus, but it's a non-
trivial goal.

Reword. There is no requirement to name the instance anything in
particular. Thus there is no requirement at present that the first
parameter, which gives the name of the instance, be anything in
particular.

>In 3.0, identifiers are not restricted to ascii but can be any unicode
>'word' as defined in the manual.
>>
>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. However, I think this
>is pretty silly. Just write the name you want.

>
If, as I wrote, you permit the omission of "self" in method signatures
defined within class definitions, then you could still insist on
instance attribute qualification using "self" - exactly as one would
when writing Java according to certain style guidelines.

Which is what I said in the first sentence of my next paragraph, which
you clipped.
"Or the proposal would have to be that 'self' is mandatory for all
programmers in all languages." To clarify " ... that 'self' be the
mandatory instance name for all Python programmers regardless of
inclination or the natural language they otherwise use as a basis for
identifiers."

In sum, if the instance name is omitted from the parameter list, it must
either be discovered or mandated, and def statements in direct class
scope have to be treated differently from def statements elsewhere.

Terry Jan Reedy

[Torsten Bronger]

Re: Attack a sacred Python Cow

Hallöchen!

Terry Reedy writes:

Torsten Bronger wrote:
>

>D'Arcy J.M. Cain writes:
>>

>>On Sat, 26 Jul 2008 09:45:21 +0200
>>Torsten Bronger <bronger@physik .rwth-aachen.dewrote:
>>>
>>>Of course, "self" would have to become a reserved word. You
>>>could say that this may break some code, but I don't see much
>>>freedom
>>>
>>Isn't this a showstopper all by itself?

>>
>Yes. But I've seen no code that uses some other word.

>
There is a lot of code you have not seen. Really. In informal
code I use 's' and 'o' for 'self' and 'other'. I don't usually
post such because it is not considered polite. So you have seen a
biased sample of the universe.

I didn't say that no code breaks, nor that I've analysed more than
0.1% of the global Python code. But still, this doesn't convice me.
I still think that only a very small fraction of Python code would
break. Since no one can make a global analysis, it is more sensible
to compare it with the amount of code broken by Python 3.0 in my
opinion.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten.bronger @jabber.rwth-aachen.de

[Carl Banks]

Re: Attack a sacred Python Cow

On Jul 26, 5:07 pm, Terry Reedy <tjre...@udel.e duwrote:

Whether or not one should write 'if x' or 'if x != 0' [typo corrected]
depends on whether one means the general 'if x is any non-null object
for which bool(x) == True' or the specific 'if x is anything other than
numeric zero'.  The two are not equivalent.  Ditto for the length example.

Can you think of any use cases for the former? And I mean something
where it can't be boiled down to a simple explicit test for the sorts
of arguments you're expecting; something that really takes advantage
of the "all objects are either true or false" paradigm.

The best thing I can come up with out of my mind is cases where you
want to check for zero or an empty sequence, and you want to accept
None as an alternative negative as well. But that's pretty weak.

The use case of simply passing something to a function that accepts
any boolean doesn't count. For instance, I could write:

def nand(a,b):
return not (a and b)

And then I could use it like this, even if x is an interger and y a
string:

if nand(x,y):

But that doesn't buy much since I could just pass in the explicit
tests like this:

if nand(x!=0,y!="" ):


Carl Banks