[Python-ideas] In call grammar, replace primary with possible_call? (was Re: ...quote followed by a left parenthesis...?)

Andrew Barnert abarnert at yahoo.com
Fri Jul 17 04:10:33 CEST 2015


On Jul 16, 2015, at 18:54, Chris Angelico <rosuav at gmail.com> wrote:
> 
> On Fri, Jul 17, 2015 at 11:44 AM, Andrew Barnert via Python-ideas
> <python-ideas at python.org> wrote:
>> To a normal end-user, the things you syntactically call are basically all values (or, if you prefer, all expressions). Calling a value that's not callable is the same error as adding a thing that's not addable or indexing a thing that's not subscriptable, and that's a TypeError. The existing rules makes sense, and fit in with everything else in Python. For example, we don't consider {1}[1] a syntax error even though it's never valid; how is {1}(1) any different?
> 
> There are other odd cases in the grammar, too, though. Try explaining this one:
>>>> x = 1
>>>> x.to_bytes(4,"little")
> b'\x01\x00\x00\x00'
>>>> 1.to_bytes(4,"little")
>  File "<stdin>", line 1
>    1.to_bytes(4,"little")
>             ^
> SyntaxError: invalid syntax
>>>> (1).to_bytes(4,"little")
> b'\x01\x00\x00\x00'

> If the grammar can catch an error, great! If it can't, it'll get dealt
> with at run-time.

This is the exact opposite. It's not the grammar sometimes catching an obvious type error earlier, it's the grammar catching something that's perfectly sensible and preventing us from writing it in the obvious way. It's something we're unfortunately forced to do because attribution syntax and float literal syntax are ambiguous. 

That's not something we'd want to emulate or expand on.

If you really want to catch type errors at compile time, that's exactly what static type checkers (whether embedded in the compiler or not) are for; trying to hack up the grammar to do typing without doing typing is only going to catch a handful of very simple cases that nobody really cares about.

> Syntax errors don't have to be reserved for
> situations that make it impossible to proceed at all.

No, but they should be reserved for syntactic errors, and the syntax should be as simple as possible. Making the rules more complicated and less consistent has a cost (not so much for the implementation, as for the person trying to understand the language and keep it in their head).


More information about the Python-ideas mailing list