Comment by pak | Hacker News Reader

Comment by pak | Hacker News Reader

Parent Full thread

>I hate implicit hidden defaults and assumptions.

Your implicit hidden default is my handy abbreviation.

Imagine if we didn't have contractions in English.

For that previous sentence, is it really at all frightening that the "didn't" meant "did not" but we haven't (ha) written it out? Could it possibly mean anything else? Wouldn't English be all the more stilted and ugly if there were only one explicit and verbose way (a Python design principle) of negating verbs?

If I redefined the "self" as any other name Pythonistas would hate on me for being unidiomatic. Most editors highlight "self" in anticipation of what it means. In fact, I have never seen code where specifying another name would be justifiable. The only conclusion from this situation is that it is a de facto keyword and re-specifying it every. single. time. is a waste of programmatic breath.

And for this reason, every time I tab between languages and get my favorite "function takes 1 argument (2 given)" error, (by the way: a completely bewildering message for a programmer from every other language, rereading the method definition and wondering where the second argument is coming from [1]), I mutter curses at my terminal for Python relentlessly carrying this wart into its third decade.

Implicit and explicit are relative to expectations. Python moves the implicitness into the way arguments are passed to methods. It is not any more explicit when placed in the context of all other OOP languages, but rather an eccentric convention.

[1]: 800 results on SO. Read them and weep. http://stackoverflow.com/search?q=Python+takes+arguments+giv...

I'll agree with this entirely. As a newcomer to Python, I found the explicit "self" argument to be confusing. And now I just find it irritating. It breaks convention with every other OO language; it's additional meaningless noise in method definitions; and most importantly it violates the convention used by nearly every other programming language I'm aware of, which is that method definition argument lists and method call argument lists should match up.

When method call argument one is method definition argument two, things get confusing quickly. What's the benefit to readability? Python has plenty of other implicit rules (semantic whitespace being the most troublesome--though ironically its primary benefit of readability runs counter to the visual noise of the explicit self arg), and as pak points out, explicit "self" in the method def just moves the implicitness elsewhere in the code.

I like the explicit self. It makes the language much simpler, clearer and less "magic".

> It breaks convention with every other OO language

Lua, Go, and Rust all have explicit self.

Just for the record, you can do cool stuff that you couldn't do (as easily) if you had implicit `self`. Here's an example[1] that I'm moderately proud of.

[1] https://github.com/MediaCrush/PyCrush/blob/master/pycrush.py...

This just seems like flamewar material, much in the same vein as programmers (brogrammers?) that get red in the face over Python cramping their style by forcing structure via whitespace.

It's not flamewar material. GVR himself has acknowledged everything (edit in response to @EdwardDiego: most of what) I said. (http://neopythonic.blogspot.com/2008/10/why-explicit-self-ha...) The main contention holding back GVR and 3.1 from fixing this once and for all is that decorators currently need to manipulate the explicit self. From my perspective, it seems like Python decorators are [ab]used to reimplement basic features in other OOP systems, like class methods, and there are elegant ways of getting around this given a shift in certain concepts (like class << self in Ruby). It's odd to me that they were willing to break so much code with 3.0 (by "fixing" strings and Unicode) but a couple decorators held this one back.

> GVR himself has acknowledged everything I said

I hate to be picky, but he only acknowledged portions of what you said.

> but a couple decorators held this one back.

@classmethod and @staticmethod are somewhat important language features to not break.

>@classmethod and @staticmethod are somewhat important language features

And strings aren't? Whatever, I understand that there are tradeoffs and to people that only use Python, the aesthetic blemishes tend to matter less. To people that use it in the context of other languages, it sticks out like a bad paint job or a prominent stain. This, and many more opinions than I could express succinctly, are on the reddit thread for GVR's post.

http://www.reddit.com/r/programming/comments/79h9y/guido_van...

@redditrasberry: To make a bad analogy, it's like a stain on your carpet in your front hallway. If you live with it for long enough you won't even see it any more. But to visitors coming to your house it's the most obvious thing. And it's particularly noticeable because the rest of Python is so nice - it's like I'm visiting an art gallery and everything is beautiful and pristine, but there on the carpet at the entrance is this huge stain that nobody has ever cleaned up.

> And strings aren't?

Not sure how explicit self breaks strings? You've lost me on the way I'm afraid.

If we're quoting Reddit comments at each other:

> You may be used to a different kind of magic. Perhaps the magic of a variable called this appearing inside your method, or the magic in which an un-prefixed variable name somevar is sometimes a local but at other times a member variable this.somevar. So it may take a little time to get used to Python's style, but isn't it only because you are used to the other magic?

Explicit self is hardly a burden after about 10 minutes of learning Python, and there's really little objective argument to be made in favour of or against it as opposed to everything else.

You quoted JavaScript as 'not needing it' before, and dear God, JS is the worst of all languages to reference, given how the this keyword is a calling context, which every man and his framework takes liberties with.

Re: strings, I was referring to what I said already and you quoted only part of it:

> It's odd to me that they were willing to break so much code with 3.0 (by "fixing" strings and Unicode) but a couple decorators held this one back.

How much code did the new strings break, exactly? What code it may have broken most likely benefits from the new unicode treatment, it was the worst thing about Python strings.

Removing self would be a far more massive change - it wouldn't just impact certain strings, it would impact every Python class.

>> GVR himself has acknowledged everything I said

> I hate to be picky, but he only acknowledged portions of what you said.

Read it and for me he did not acknowledge anything at all.

They said they weren't going to fix everything with Py3.

Please do not confuse dislike of semantic whitespace for structure-less preferences. I want my blocks to be explicit so the computer can know the difference between between incorrect indentation and a block ending. I also do not want to make tabs versus spaces any more flamewar inducing than it already is.

Reply on news.ycombinator.com