[BUG] Redeclaring variable in pure python mode is not raising error
See original GitHub issueDescribe the bug
Redeclaring variable in pure python mode is behaving not consistently with cython code. E.g. in cython following code raises error:
def foo():
cdef float a = 3.0
cdef int a = 1
print(a)
Error compiling Cython file:
------------------------------------------------------------
...
# cdef int a = 1
# cdef int a = 2.0
def foo():
cdef float a = 3.0
cdef int a = 1
^
------------------------------------------------------------
bug.pyx:8:13: 'a' redeclared
Code to reproduce the behaviour:
def foo():
a: cython.float = 3.0
a: cython.int = 1
print(a)
$ python
Python 3.9.12 (main, May 8 2022, 18:05:13)
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import bug
>>> bug.foo()
1.0
>>>
Expected behaviour
There are two possible solutions:
- compiling code will fail with error as in cython code
- code prints value
1
Environment
OS: macOS Python version 3.9.12 Cython version master
Additional context
No response
Issue Analytics
- State:
- Created a year ago
- Comments:8 (5 by maintainers)
Top Results From Across the Web
(@cython.cfunc + Type Annotation) Fragility #2529 - GitHub
Going through some of pandas' cython modules to try to make code valid-python where possible, I'm seeing cythonize-time errors.
Read more >Programming FAQ — Python 3.11.1 documentation
How do I share global variables across modules? What are the “best practices” for using import in a module? Why are default values...
Read more >Why does incorrect assignment to a global variable raise ...
According to Python's documentation, the interpreter will first notice an assignment for a variable named a in the scope of f() (no matter ......
Read more >Pure Python Mode — Cython 3.0.0a11 documentation
In pure mode, you are more or less restricted to code that can be expressed (or at least emulated) in Python, plus static...
Read more >Recent Bug Fixes by Version - Gurobi Optimization
getAttr() returning bogus results instead of raising an exception when called ... bug in IIS for SOS variables with negative upper bounds; Fixed...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
PEP 526 has this to say on the matter:
So, in Python, this is a warning at best.
However, when you run Cython on typed code, you are not just saying, “please compile this Python code for me”, you are also explicitly enabling static typing. I think that explicit step of a user from “run this Python code with type annotations ignored at runtime” to “compile this Python code with static typing” is enough of a reason to let Cython reject contradicting type declarations with a compile error. This should not just be a warning, even if Cython does not completely understand the annotation yet.
If we encounter conflicting type annotations in user code, it seems more likely (to me) that it’s a bug than intention. Intuitively, if you want different types for a variable, then why do you use the same variable name in the first place? The differently typed cases are probably really referring to different things that are worth having different names.
I personally prefer @scoder solution.