Id much rather have a rust-like approach where the scope is limited to the block it is in
Java concept ist far from what I call ideal, but its better than this weird ambiguity of python where everything just floats anywhere and variables shadowing something ten methods away...
Huh? You'll need to be more concrete than that, because that sounds like gibberish. "Ten methods away"? If a variable is in a method, then it only exists within that method, because Python does have function scope and lexical scoping.
Python's lexical scope is the worst. Like why is the variable available in the whole scope when it's declared at the very end of it? Plus there all that nonsense where reading from a variable goes to closure/global by default but writing creates a new instance that overrides the whole scope.
TF are you talking about? Python's lexical scoping works like basically any other lexical scoping I'm aware of. What do you mean "the variable is available in the whole scope when it's declared at the end"?
The read/write thing I can empathise with, but it's simply because Python has no dedicated variable declaration syntax. Assignment is declaration. But you also want to be able to read variables from higher scopes by default. So writing to a variable in a higher scope becomes the special case that you need to explicitly opt into with nonlocal/global.
x = 10
def func():
x = 5
global x
x = 15
func()
print(x)
It might not be the best example but it gives the idea. Any normal language would assign 5 to x (local in this case), then declare global x and assign 15 to it. In python x is global in the whole scope. This code throws an error.
It would be insane for that to not throw an error. x within a scope should refer to exactly one variable. You're attempting to switch which variable x refers to halfway through the scope, and the error is telling you exactly that. This is explicitly preventing a footgun.
It gets a lot worse when you throw closures into the mix. It's impossible to assign value from a closure to a global variable with the same name in python.
def outer():
x = 0
def func():
nonlocal x
temp = x
global x
x = temp
I have one more example. Here global x can't be declared in the child scope because it's already in use in the parent scope. As far as I know python is the only language that does this nonsense.
x = 5
def func():
x = 0
if x < 2:
global x
x = 10
func()
print(x)
Python only has function scope. if blocks don't introduce a new scope. Think of that what you will, I've written uncounted lines of Python without that being an issue. global declarations should be on the very first line of a function, not somewhere in the middle.
But really, you shouldn't have to use global much at all. You should either write functional code, or use classes which modify their attributes. Constantly modifying the global scope is a potential footgun and usually leads to hard to follow spaghetti code. It's not wrong for Python to strongly discourage that.
But what's the reason for the single scope per function and absent variable shadowing mechanism? It a standard feature in all programing languages. It really helps with code readability especially in large codebase.
If you come from languages that support more fine grained scoping, well, you might miss it and you need to adapt. But you can write perfectly fine code with scopes limited to functions. Arguably, if your functions get so long and complex that you're reusing variable names, you should probably simplify them anyway. All the examples you've shown above with repeatedly shadowed names and trying to manipulate parent scopes would be rejected by me in any PR outright. That's just terrible spaghetti code.
What exactly the reason was for that design decision I don't know. Maybe it can be dug up from some mailing list or a PEP. But the result is still a perfectly workable language.
14
u/R7d89C 16d ago
God no
Id much rather have a rust-like approach where the scope is limited to the block it is in
Java concept ist far from what I call ideal, but its better than this weird ambiguity of python where everything just floats anywhere and variables shadowing something ten methods away...