syntactic sugar idea for {static,class}methods
Michael Hudson wrote (replying to Barry Warsaw):
Very interesting! Why the square brackets though? Is that just for visual offset or is there a grammar constraint that requires them?
Um, no big reason; they were what Gareth suggested, so I implemented that. He may have got the idea from the slides from one of Guido's presentations -- it was reading them that reminded me I'd done this and wanted to mention it here.
Four reasons for the brackets. 1. Easier for the parser, I think. 2. Visually distinctive. 3. For me, it "reads" better than it would without the brackets. 4. Generalizes to a sequence of transformations. #4 is much the most important of these in my mind. One drawback of allowing an arbitrary list of transformations is that it might not be completely clear what order they're done in. I conjecture that most people will have the same intuition as I do about this, namely that the first-listed transformation is applied first. (It would be less obvious if the list came before the name of the definiendum instead of after.) Oh, and for the record: My suggestion was made long before I ever saw Guido's slides. :-) -- Gareth McCaughan
Gareth McCaughan wrote:
... 4. Generalizes to a sequence of transformations.
For me, this is crucial. A future version of Spark would probably put its parse annotations in the parens. Various type checking systems would probably do the same: def t_whitespace(self, s)[ grammar(r' \s+'), type(Node)]: pass This is going to happen so we need to be confident that we like this use of the syntax. I've been waiting for something like this for a while. Paul Prescod
On Wed, Feb 13, 2002 at 05:11:57PM +0000, Gareth McCaughan wrote:
One drawback of allowing an arbitrary list of transformations is that it might not be completely clear what order they're done in. I conjecture that most people will have the same intuition as I do about this, namely that the first-listed transformation is applied first. (It would be less obvious if the list came before the name of the definiendum instead of after.)
The modifier order [memoize, staticmethod] sounds more like the sentence "foo is a memoized staticmethod" - at least in English it does. In French, Hebrew and several other languages it's the other way around, but Python is definitely English-oriented. So, do adjectives come before or after the noun in Dutch? :-) Oren
On Fri, 15 Feb 2002 04:25:55 -0500, Oren Tirosh
On Wed, Feb 13, 2002 at 05:11:57PM +0000, Gareth McCaughan wrote:
One drawback of allowing an arbitrary list of transformations is that it might not be completely clear what order they're done in. I conjecture that most people will have the same intuition as I do about this, namely that the first-listed transformation is applied first. (It would be less obvious if the list came before the name of the definiendum instead of after.)
The modifier order [memoize, staticmethod] sounds more like the sentence "foo is a memoized staticmethod" - at least in English it does. In French, Hebrew and several other languages it's the other way around, but Python is definitely English-oriented.
Interesting. I read it more as: "Define a function, then memoize it and make it a static method".
So, do adjectives come before or after the noun in Dutch? :-)
I don't think they do. :-) By the way, the fact that adjectives go before nouns in English is one reason why I don't read "def foo() [wibblify]" as if "wibblify" is an adjective. It can't be: it comes after the noun. PS. Court martial. C sharp. Letters patent. Bother. :-) -- g
participants (3)
-
Gareth McCaughan -
Oren Tirosh -
Paul Prescod