Re: [Python-Dev] map, filter, reduce, lambda
Skip Montanaro
>> Is there a reason def couldn't have been reused in this context?
Guido> You couldn't reuse def, because lambda can start an expression Guido> which can occur at the start of a line, so a line starting with Guido> def would be ambiguous (Python's parser is intentionally Guido> simple-minded and doesn't like having to look ahead more than one Guido> token).
I'll leave that gauntlet thrown, since I have no interest in rewriting Python's parser. Maybe it will spark John Aycock's interest though. ;-)
Did you miss the "intentionally"? Cheers, M. -- at any rate, I'm satisfied that not only do they know which end of the pointy thing to hold, but where to poke it for maximum effect. -- Eric The Read, asr, on google.com
Guido> (Python's parser is intentionally simple-minded ...). >> I'll leave that gauntlet thrown, since I have no interest in >> rewriting Python's parser. Maybe it will spark John Aycock's >> interest though. ;-) Michael> Did you miss the "intentionally"? No. I just assumed it meant Guido didn't personally want to burn lots of brain cells on parsing Python. I doubt he'd be as protective of your neurons. ;-) Skip
Guido> (Python's parser is intentionally simple-minded ...).
>> I'll leave that gauntlet thrown, since I have no interest in >> rewriting Python's parser. Maybe it will spark John Aycock's >> interest though. ;-)
Michael> Did you miss the "intentionally"?
No. I just assumed it meant Guido didn't personally want to burn lots of brain cells on parsing Python. I doubt he'd be as protective of your neurons. ;-)
The parser is intentionally dumb so that the workings of the parser are easy to understand to users who care. Compare C++. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
The parser is intentionally dumb so that the workings of the parser are easy to understand to users who care.
How about the grammar? Is it simple purely so the parser was easier to write? Personally, I have a theory that the one of the main reasons Python considered readable is because parsing it doesn't require more than one token of look ahead.
Compare C++.
"Run away, run away" :-) Neil
Guido van Rossum wrote:
The parser is intentionally dumb so that the workings of the parser are easy to understand to users who care.
How about the grammar? Is it simple purely so the parser was easier to write? Personally, I have a theory that the one of the main reasons Python considered readable is because parsing it doesn't require more than one token of look ahead.
Good point -- the grammar is also intentionally dumb for usability (although there are a few cases where the grammar has to be complicated and a second pass is necessary to implement features that the dumb parser cannot handle, like disambiguating "x = y" from "x = y = z", and detecting keyword arguments). One of my personal theories (fed by a comment here by someone whose name don't recall right now) is that, unlike in other languages, the fact that so little happens at compile time is a big bonus to usability. --Guido van Rossum (home page: http://www.python.org/~guido/)
From: "Guido van Rossum"
One of my personal theories (fed by a comment here by someone whose name don't recall right now) is that, unlike in other languages, the fact that so little happens at compile time is a big bonus to usability.
a "collective" thought stream in a thread about macros: http://aspn.activestate.com/ASPN/Mail/Message/1076878 regards
Guido van Rossum wrote:
Guido van Rossum wrote:
The parser is intentionally dumb so that the workings of the parser are easy to understand to users who care.
How about the grammar? Is it simple purely so the parser was easier to write? Personally, I have a theory that the one of the main reasons Python considered readable is because parsing it doesn't require more than one token of look ahead.
Good point -- the grammar is also intentionally dumb for usability (although there are a few cases where the grammar has to be complicated and a second pass is necessary to implement features that the dumb parser cannot handle, like disambiguating "x = y" from "x = y = z", and detecting keyword arguments).
One of my personal theories (fed by a comment here by someone whose name don't recall right now) is that, unlike in other languages, the fact that so little happens at compile time is a big bonus to usability.
The intentional dumbness of the parser and the grammer are not only good for people who want to understand the implementation. I believe that this simplicity is also one reason why reading Python code seems to be so easy for humans: Although a parser works differently than a human brain (which uses more look-ahead and whole-line perception of course), the lack of complicated analysis necessary while reading is also consuming much less concentration than other languages do. I don't say people cannot read complicated languages. But it is a waste of resources if that cognitive power can be used for the real problem. Most probably another reason why Python is said to "Step back behind the problem". No idea whether this was a planned principle by you or if it happened to be a consequence of other simplicity, Python code is simplest to read and simplest to think. As a side note, list comprehensions with a couple of appended "for..." and "if..." phrases might in fact be a bit controversal, when I think of the above. Instead of Python's straight simplicity with "no suprizes to come", these constructs are a little upside-down, with a lot to remember until getting it all. So the advice to keep these appendices as short as possible is necessary; it is a little similar to reading RPN code. ciao - chris -- Christian Tismer :^) mailto:tismer@tismer.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
participants (6)
-
Christian Tismer -
Guido van Rossum -
Michael Hudson -
Neil Schemenauer -
Samuele Pedroni -
Skip Montanaro