On Mon, Aug 28, 2000 at 05:54:13AM -0500, Guido van Rossum wrote:
> > However, it also allows this at the top level, currently:
> > >>> def print(x):
> > ... print "printing", x
> > ...
> Initially I thought this would be fine, but on second thought I'm not
> so sure. To a newbie who doesn't know all the keywords, this would be
> confusing:
>
> >>> def try(): # my first function
> ... print "hello"
> ...
> >>> try()
> File "<stdin>", line 1
> try()
> ^
> SyntaxError: invalid syntax
> >>>
>
> I don't know how best to fix this -- using different syntax for 'def'
> inside a class than outside would require a complete rewrite of the
> grammar, which is not a good idea. Perhaps a 2nd pass compile-time
> check would be sufficient.
Hmm. I'm not really sure. I think it's nice to be able to use
'object.print', and it would be, well, inconsistent, not to allow
'module.print' (or module.exec, for that matter), but I realize how
confusing it can be.
Perhaps generate a warning ? :-P
> I believe that one other thing is needed: keyword parameters (only in
> calls, not in definitions). Also, I think you missed a few reserved
> words, e.g. 'and', 'or'. See Lib/keyword.py!
Ahh, yes. I knew there had to be a list of keywords, but I was too tired to
go haunt for it, last night ;)
> A comment on the patch: wouldn't it be *much* better to change the
> grammar to introduce a new nonterminal, e.g. unres_name, as follows:
> unres_name; NAME | 'for' | 'if' | 'while' | 'else' | 'elif' | 'def' | \
> 'class' | 'print' | 'del' | 'raise' | 'exec' | 'in' | 'is' | 'from' | \
> 'pass' | 'import' | 'global' | 'assert' | 'return' | 'break' | \
> 'continue' | 'try' | 'except' | 'not' | 'lambda' | 'finally'
> and use this elsewhere in the rules:
> funcdef: 'def' unres_name parameters ':' suite
> trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' unres_name
> Then you'd have to fix compile.c of course, but only in two places (I
> think?).
I tried this before, a week or two ago, but it was too much of a pain. The
nodes get tossed around no end, and tracking down where they are STR()'d and
TYPE()'d is, well, annoying ;P I tried to hack around it by making STR() and
CHILD() do some magic, but it didn't quite work. I kind of gave up and
decided it had to be done in the metagrammar, which drove me insane last
night ;-) and then decided to 'prototype' it first.
Then again, maybe I missed something. I might try it again. It would
definately be the better solution ;)
--
Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4