
A tiny Python exception oddity - luord
https://aroberge.blogspot.com/2019/12/a-tiny-python-exception-oddity.html?m=1
======
mherdeg
I'm impressed by the humility here from someone who (a) is writing a library
to replace core traceback behavior in pypi; (b) has doubtless read both
cpython and pypi code; (c) nevertheless writes "While I have some general idea
of how the CPython interpreter works, I absolutely do not understand well
enough to claim with absolute certainty how this situation arise".

Jeepers, who WOULD be qualified to explain for sure how this works?

~~~
jedberg
> Jeepers, who WOULD be qualified to explain for sure how this works?

Guido?

------
underdeserver
If 99.999% of Python programmers won't care about this, and there are
approximately 8.2M Python programmers in the world [1], then only 82 people
will care about this. Given the number of upvotes you've covered them all.

[1]
[https://www.google.com/search?q=how+many+python+programmers+...](https://www.google.com/search?q=how+many+python+programmers+are+there+in+the+world)

~~~
aroberge
Thank you. I actually thought I was overestimated the interest. Then again, I
did not think that my blog post would attract the interest of the HackerNews
readers.

------
lilyball
I'm curious why this is reported as a SyntaxError. This doesn't seem like a
syntactical problem to me, but a semantical one.

~~~
lidHanteyk
Python's grammar is so very rich. Many programs are rejected for "syntactic"
reasons if they do not fit into the abstract syntax [0]; I suppose that this
could be some sort of "AbstractSyntaxError", if Python had such a thing.

For some examples:

    
    
        x == not y
    

Rejected by the parser itself.

    
    
        not x = y
    

Accepted by the parser and AST builder, and only rejected by the bytecode
compiler.

    
    
        f(*xs,)
    

Rejected by the parser itself.

    
    
        ...
    

Rejected somewhere between the parser and the AST builder. Valid uses of
Ellipsis are actually special-cased; it is not a standard part of the abstract
syntax.

[0]
[https://github.com/python/cpython/blob/master/Parser/Python....](https://github.com/python/cpython/blob/master/Parser/Python.asdl)

~~~
kccqzy
Why is x == not x rejected by the parser? In many other languages this is
perfectly valid and, depending on the semantics, may allow the compiler that
into false. (Of course this can't generally be the case where operators are
user-overloadable.)

~~~
js2
Because that's how the grammar is defined:

[https://docs.python.org/3.8/reference/grammar.html](https://docs.python.org/3.8/reference/grammar.html)

The RHS of the == (comp_op) has to be an expr. You can force "not x" to be an
expr by parenthesizing it:

    
    
      x == (not x)

~~~
kccqzy
That interesting. On the other hand,

    
    
        not x == x 
    

is totally valid.

------
bratao
I was impressed by the quality of PyPy errors!

------
Wheaties466
I seem like i'm alone in this but I think I would prefer the CPython handling
of this "Syntax Error".

I am not a "Programmer" so having feedback on the original problem line would
be more beneficial than returning the second.

------
_ZeD_
I'm wondering if this case will be handled differently by the new pegen

[https://github.com/gvanrossum/pegen](https://github.com/gvanrossum/pegen)

