On Mon, 28 Mar 2016 01:43 am, BartC wrote:
[... talk about function and procedures ...]
> Well, that could be done in Python (not so usefully because you can't
> take account of such info until a call is attempted), but that's not
> what I'm talking about, which is simply allowing:
>
> fn(...)
>
> whether fn has an explicit return or not, and not allowing:
>
> fn # and other kinds of expression
>
> unless some keyword is used. (I've no idea what that might be; all the
> best ones are taken. But I've already said a keyword can be emulated via
> a dummy function call.)
I think that the only suggestion that might, *just barely*, work in Python
is forbidding the evaluation of a single name as a syntax error. Any other
expression would have to still be allowed.
Advantage:
- catches various errors, such as forgetting to call
procedure-like functions:
main # oops, meant main()
or mistyping a keyword:
for x in sequence:
if condition: next # oops, meant continue
Disadvantages:
- makes it less convenient to use the `try: name except NameError` idiom.
- won't do anything about errors like this:
x = y # oops, meant to call y()
a = b # this one is okay though
- it treats a single name as a special case of arbitrary
expressions. What's so special about the single name case
that we should guard against this:
name
but not this?
name.validate
The Zen of Python has something to say about special cases.
import this
Now, I happen to think that using "name.validate" for the side-effects of
the attribute look-up is a terrible idea. But it's legal code, and the
compiler shouldn't make value judgements about good or bad code. You want
value judgements, use a linter.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
