http://norvig.com/python/python.html

Peter Norvig is about to supply Python versions of the algorithms with the 2nd edition of his AI: A Modern Approach.

So far, so good. In the section about coding convetions he says:

ŠIn general, follow Guido's style conventions, Šbut I have some quirks that I prefer (although I could be talked out of them): ... Š* _ instead of self as first argument to methods: def f(_, x): ...

I'm perfectly aware that the 'self' thing it is just a convetion, OTOH much of the cross-programmer readability of code relies on such convention.

It is good, bad or irrelevant to have such an authoritative book (although about AI not Python directly) adopting such a line-noisy convention?

Maybe nobody cares, but I preferred not to let this go unnoticed. Someone who cares could try to discuss the issue or make it apparent to Mr. Norvig.

Opinions?

regards, Samuele Pedroni.

Peter: My apologies for butting in here without doing full research. I don't know how you reached this set of conventions, so maybe you've got a very good reason; but I don't see it on your webpage. Two of those coding conventions look really ugly to me: 2-space indents and _ for self. I think the code will look horrible! I think everyone should be able to make their own style choices, but I ask you to reconsider. If you have to reconsider one, I would beg you to use 'self' like everybody else. The _ name is already overloaded with multiple meanings in the Python community: it's a shorthand for the last evaluated expression in interactive mode, and some people use it as a dummy variable to assign uninteresting results to. Almost the entire Python community is happy with 4-space indents; if you're worried about your lines getting too long, that's usually a hint that your code can be restructured in a way that's easier on the reader's eye/mind anyway. --Guido van Rossum (home page: http://www.python.org/~guido/)

Wow; I didn't expect this to generate such a response. But I did post the code far before it was ready and put the "I could be talked out of it" there for a reason. So, thank you for your feedback! My reactions: 4 spaces: OK. I have no strong feelings on that, and I think its just an accident of the way my emacs was configured that I started using 2 spaces. I agree that I should make it easier for other people to edit my code, so I'll switch to the default. self: OK, I'll try it. My rationale was: I'm used to Java, where self is usually spelled '', and I figured '_' was the next best thing. I find it much nicer to read because 'self' is too intrusive; I want something that disappears. Compare: _.x, _.y, _.z = x, y, z self.x, self.y, self.z = x, y, z Besides saving 9 characters, I find that the first line I can read at a glance, ignoring the _, while the second I have to look at more carefully. I also like the symmetry of _._ in _._private_slot. However, I recognize I'm doing this as an outsider to the language without much experience reading/writing it. If it is really true that using '_' would be seen as a change to the language and not a personal quirk, then I agree that I shouldn't do it. The first hint I had of this was when I saw something on comp.lang.python (I forget the details) suggesting that an automated tool look for methods with first argument 'self'. So I'll try 'self' for a while, and hope I learn to like it (and learn to read the second sample line above in one glance). If I don't, I'll write here and give you all another chance to innundate me with reasons why I should. -Peter PS - Getting a personal request from Guido reminds me of the time I was at a conference and John McCarthy walked up to the booth of one of the Lisp vendors and said in his usual direct fashion "I hear you have a new version. You should send me one". The booth bimbo had no idea who McCarthy was and politely suggested he pay for a copy. Then someone in the booth with a little more experience came over and said "That's ok -- it's his language, he can have whatever he wants." Guido van Rossum wrote:

...

http://norvig.com/python/python.html

Peter Norvig is about to supply Python versions of the algorithms with the 2nd edition of his AI: A Modern Approach.

So far, so good. In the section about coding convetions he says:

¦In general, follow Guido's style conventions, ¦but I have some quirks that I prefer (although I could be talked out of them): ... ¦* _ instead of self as first argument to methods: def f(_, x): ...

I'm perfectly aware that the 'self' thing it is just a convetion, OTOH much of the cross-programmer readability of code relies on such convention.

It is good, bad or irrelevant to have such an authoritative book (although about AI not Python directly) adopting such a line-noisy convention?

Maybe nobody cares, but I preferred not to let this go unnoticed. Someone who cares could try to discuss the issue or make it apparent to Mr. Norvig.

Opinions?

regards, Samuele Pedroni.

Peter:

My apologies for butting in here without doing full research. I don't know how you reached this set of conventions, so maybe you've got a very good reason; but I don't see it on your webpage.

Two of those coding conventions look really ugly to me: 2-space indents and _ for self. I think the code will look horrible!

I think everyone should be able to make their own style choices, but I ask you to reconsider. If you have to reconsider one, I would beg you to use 'self' like everybody else. The _ name is already overloaded with multiple meanings in the Python community: it's a shorthand for the last evaluated expression in interactive mode, and some people use it as a dummy variable to assign uninteresting results to.

Almost the entire Python community is happy with 4-space indents; if you're worried about your lines getting too long, that's usually a hint that your code can be restructured in a way that's easier on the reader's eye/mind anyway.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-- _____________________________________________________________________ Peter Norvig, Director of Machine Learning, Google, http://google.com pnorvig@google.com, Voice:650-330-0100 x1248, Fax:650-618-1499

] In general, follow Guido's style conventions, ] but I have some quirks that I prefer (although I could be talked ] out of them): ... ] * _ instead of self as first argument to methods: def f(_, x): ...

I dunno; I think sample code should (a) stick rather conservatively to typical usage, apart from the concept being illustrated of course; and (b) strive for maximum readability. For Python, both principles demand that one should write: def foo(bar): if is_list(bar): return sum(map(foo, bar)) else: return [bar] instead of: def foo(bar): if is_list(bar): return sum(map(foo, bar)) else: return [bar] This may be one of those things that only makes sense if you've not a Lisp programmer. (wink) To stray from the topic: I find I only disagree with three points in Peter Norvig's enlightening table of Lisp vs. Python features. http://www.norvig.com/python-lisp.html 1. That "x.slot = y" is not user-extensible. The __setattr__() method does this. 2. That Python's relative lack of control structures is necessarily worse than Lisp's abundance of them. Especially for students, I think this: if is_list(n): return foo_l(n) elif is_str(n) or is_int(n): return foo_a(n) else: raise TypeError is at least as clear, though not as brief, as this: (etypecase n (list (foo-l n)) ((or string integer) (foo-a n))) with the obligatory note in the text to the effect that "'Etypecase' is a form similar to 'case' which selects a clause based on the type..." and so on. 3. That Python doesn't support generic programming. Generic algorithms are expressed as naturally in Python as in any language I know: from operator import add def sum(items): return reduce(add, items) >>> sum([3, 4, 5]) 12 >>> sum([3, 4j, 4-2j]) (7+2j) >>> sum(["py", "th", "o", "n"]) 'python' Likewise it's natural to write functions that can operate on "any sequence", not just lists or tuples, "any file-like object", not just a real file, "any function-like object", etc. Perhaps something more specific is meant by "generic programming". Cheers, ## Jason Orendorff http://www.jorendorff.com/

Guido van Rossum wrote:

I hear that in the Lisp world, when someone complains about the parentheses, the standard response is "once you're used to it, the parentheses disappear". So it is for Python's 'self'. :-)

That may be a good analogy, and as I said, I'm willing to try. But I still think one character is easier to ignore than four, and that there is no compelling argument for 'self' over '_', while there is a positive reason for parens (ease of automated parsing tools).

What's a booth bimbo? :-)

"It's not a sexist phenomenon as such, applying equally to the pretty young men and women who work as scenery at various booths. Universally, these people have no clue about the products they represent; instead they hand out buttons and propaganda, smile nicely, and act as props for the larger show that goes on around them." -- http://www.tidbits.com/tb-issues/TidBITS-159.html#lnk6

--Guido van Rossum (home page: http://www.python.org/~guido/)

OK, OK; When both Guido and E. B. team up against me, I know I'm licked. -Peter Jason Orendorff wrote:

There is no especially compelling reason for Python to have 'self' over '_' or 'me' or '@' or ''.

However, there is a compelling reason for you to choose 'self': "Prefer the standard to the offbeat." --Strunk and White