Attack a sacred Python Cow

[castironpi]

Re: Attack a sacred Python Cow

On Jul 24, 11:49 am, "Sebastian \"lunar\" Wiesner"
<basti.wies...@ gmx.netwrote:

Torsten Bronger <bron...@physik .rwth-aachen.de>:
>
>
>

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 ...
>
--
Freedom is always the freedom of dissenters.
                                      (Rosa Luxemburg)

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.callbyva lue.foo( bar, 1, 2 )
python.callbyre f.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?

[Torsten Bronger]

Re: Attack a sacred Python Cow

Hallöchen!

Sebastian \"lunar\" Wiesner writes:

Torsten Bronger <bronger@physik .rwth-aachen.de>:
>

>Bruno Desthuilliers writes:
>>

>>Torsten Bronger a écrit :
>>>
>>>Bruno Desthuilliers writes:
>>>>
>>>[...]
>>>>
>>>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.

If it is not the implementation, I don't see why the "definition
inside a class" matters at all. It can be realised as a
transformation of the syntax tree and would even be transparent for
the compiling steps after it.

Tschö,
Torsten.

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

[castironpi]

Re: Attack a sacred Python Cow

On Jul 24, 11:43 am, Bruno Desthuilliers
<bdesth.quelque ch...@free.quel quepart.frwrote :

Jordan a écrit :
>

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 guess you'll find a lot of us guilty here too - but do we really agree
on what we consider to be "imperfecti ons" ?-)
>
(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 !-)

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]

Re: Attack a sacred Python Cow



Torsten Bronger wrote:

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]

Re: Attack a sacred Python Cow



Jordan wrote:

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]

Re: Attack a sacred Python Cow

On Jul 24, 11:43 am, Bruno Desthuilliers
<bdesth.quelque ch...@free.quel quepart.frwrote :

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

Re: Attack a sacred Python Cow

In message
<8233fbfb-ad9b-43ef-b722-9738ef129d0b@q5 g2000prf.google groups.com>, Jordan
wrote:

On Jul 24, 8:01 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new _zealandwrote:
>

>In message
><52404933-ce08-4dc1-a558-935bbbae7...@r3 5g2000prm.googl egroups.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.

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

[Kay Schluehr]

Re: Attack a sacred Python Cow

On 25 Jul., 03:01, Terry Reedy <tjre...@udel.e duwrote:

Torsten Bronger wrote:

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

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@gmail.com]

Re: Attack a sacred Python Cow

On Jul 24, 5:01 am, Lawrence D'Oliveiro <l...@geek-
central.gen.new _zealandwrote:

In message
<52404933-ce08-4dc1-a558-935bbbae7...@r3 5g2000prm.googl egroups.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.

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

[Nikolaus Rath]

Re: Attack a sacred Python Cow

Terry Reedy <tjreedy@udel.e duwrites:

Torsten Bronger wrote:

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

Why do you think that 'self' should be inserted anywhere except in the
arg list? AFAIU, the idea is to remove the need to write 'self' in the
arg list, not to get rid of it entirely.


Best,

-Nikolaus

--
»It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that.«
-J.H. Hardy

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

[cokofreedom@gmail.com]

Re: Attack a sacred Python Cow

>

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

No, what it means is that it might support OO but doesn't have to, it
isn't the only way to code.

Supporting and Being OO are very different.

[s0suk3@gmail.com]

Re: Attack a sacred Python Cow

On Jul 25, 3:38 am, cokofreedom@gma il.com wrote:

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.

>
No, what it means is that it might support OO but doesn't have to, it
isn't the only way to code.
>

"Support OO but it doesn't have to"? That sounds like saying that in
some Python implementations you'll be able to use OO, but that you
just might bump into a Python distribution where you would type

class MClass:
pass

at the interpreter and it would give you an syntax error. Is that what
you mean?

Supporting and Being OO are very different.

I guess at this point it's rather pointless to discuss this because of
the different and deep level of interpretation that we might have on
the words "support" and "be." IMO, the obvious thing to say is that a
language that *supports* OO can also be said to *be* OO. However, it
would seem just ridiculous to me to say the same thing about a
language like, e.g., Perl, where OO is so pathetic. But maybe this is
just a game of words...

I consider Python to *be* OO, anyway.

Sebastian

[Lie]

Re: Attack a sacred Python Cow

On Jul 24, 9:26 pm, Jordan <jordanrastr... @gmail.comwrote :

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

Forgive me in advance, but that is just a day dream, however good a
language design is, there WILL be other people who disagree with the
corner cases. Python is one example, even with Guido that is great at
designing language, there are many edges in python that many people
disagree and attack from time to time, but not every one of those
edges got fixed, why? Because it is impossible to appeal everyone, if
the language is changed according to your (or other's) idea, there
will be some other people who don't like it (with your examples, it
might be the people who are used to functional programming and people
who want to implement a very complex behavior in __eq__ and __ne__).
What seemed to be the obviously correct behavior for you would be
unexpected for some other people (this is also in python's Zen
although in a slightly twisted kind of way[1]: "There should be one--
and preferably only one --obvious way to do it; Although that way may
not be obvious at first unless you're Dutch.").

[1] Basically, the Zen is saying that whether and idea is the
obviously correct way to do something is measured by Guido's measuring
tape. Basically it's also saying that python is designed according to
what HE thinks is obviously correct.

The Zen you're attacking: "Explicit is better than implicit," is a
generally good advice, although as you mentioned, it doesn't fit every
single cases in the world, which leads us to the other Zen[2]:
"Special cases aren't special enough to break the rules; Although
practicality beats purity."

[2] In our case, "Explicit is better than implicit" is the "rules",
the corner cases where implicit is a generally better choice is the
"special cases". The first verse ("Special cases ... break rules")
implies that everything should be explicit, no exceptions, while the
second verse ("practicali ty beats purity") means that if something
breaking the rule makes it more practical, then you don't have to
follow the rules[3]. These two statements contradicts each other,
implying an implicit Zen: "Foolish consistency is the hobgoblin's
little minds", it is OK to break the rules sometimes.

[3] Despite saying this, I also have to emphasize that what is
practical or not is measured by Guido's tape.

With this explained, I hope you understand the point I'm making:
"There is no The Perfect Language, that is liked by everyone in the
world." The moral is, if you like a language, try to resist its warts
and know that each wart have its own story. You don't have to like the
warts, but you just need to stand to it.

[alex23]

Re: Attack a sacred Python Cow

On Jul 25, 9:49 pm, Lie <Lie.1...@gmail .comwrote:

These two statements contradicts each other,
implying an implicit Zen: "Foolish consistency is the hobgoblin's
little minds", it is OK to break the rules sometimes.

"A foolish consistency is _the_ hobgoblin of little minds." (Ralph
Waldo Emerson, although the emphasis is mine)

I do like your version, though :)

[Terry Reedy]

Re: Attack a sacred Python Cow



Kay Schluehr wrote:

On 25 Jul., 03:01, Terry Reedy <tjre...@udel.e duwrote:

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

That is not at all how I read him, so I will let him respond if he
wishes. The main problem moving a function from module scope to class
scope is prefixing the proper variables. Adding a param name, whether
'self', 's', 'this', or whatever, is trivial and hardly worth the ink.