5 ms·

Python doesn't have block scope. This can lead to some surprising behaviour: x = -1 for x in range(7): if x == 6: print(x, ': for x inside

Python doesn't have block scope. This can lead to some surprising behaviour: x = -1 for x in range(7): if x == 6: print(x, ': for x inside loop') print(x, ': x in outer') This outputs: 6 : for x inside loop 6 : x in outer For consistency, I think it makes sense for match to behave in a similar way.

deleted 6y ago
[deleted]
CogitoCogito 6y ago
I don't know if I even know what "being consistent" would mean given the example here: https://news.ycombinator.com/item?id=26082225 https://news.ycombinator.com/item?id=26082225 We don't shadow variables when they are re-used in comprehensions for example: >>> i = 4 >>> [i for i in range(10)] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> i 4 Given they're already accepting the oddity of having "case 404:" and "case variable:" mean very different things, I think they should have just gone the whole way and _not_ mutated outside variables. There seems to be little consistent with this addition to the language.
- nemetroid 6y ago
  > We don't shadow variables when they are re-used in comprehensions for example: I think "for example" makes this sound more general than it is. List comprehensions are one of the rare few constructs that introduce a new scope. The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. This is not to say that I agree with the design as a whole. I think they should have went with: case obj.some_value: ... case some_value: # behaves the same way as the previous ... case _ as variable: ... case (variable := _): # an alternative to the previous syntax ... I.e. I think the complete situation is messy, but it's not the variable scoping rules' fault.
  - CogitoCogito 6y ago
    > I think "for example" makes this sound more general than it is. List comprehensions are one of the rare few constructs that introduce a new scope. The rarity of the construct doesn't matter honestly. Are you saying that list comprehensions should _not_ have introduced a new scope because it was unusual? > The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. Syntactically yes, but semantically it is very different and the semantics must be taken into account as well. The example given at the top of this thread (case 404: and case variable:) is enough to convince me that having variable scoping is a brain-dead obvious requirement. > I think the complete situation is messy, but it's not the variable scoping rules' fault. I agree with that statement. I think that improving the design/semantics would be more effective than just adding some more scoping rules in. In fact, I don't think this PEP should have been accepted in this current form at all. But given the current design, block-level scoping is appropriate. Given another design like maybe those you mention might not require that, but I think focusing on the fact that python doesn't have block-level scoping makes no sense. The python language before this PEP is not the same as the one after this PEP. The new one should have block-level scoping in this instance.
  - chriswarbo 6y ago
    > The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. I would argue that a stack of 'case's are a 'lambda' (and in particular a single 'case x: ...' is equivalent), and hence they should have function scoping like 'lambda' does. 'match' is a distraction; it's just a function call written backwards, i.e. `match x: f` is equivalent to `f(x)` (in this case Python happens to require `f` to be implemented using the stack-of-'case's form, but that seems incidental; similar to how 'raise' and 'except' are a general form of control flow, despite Python requiring values to be wrapped in something descended from 'Exception')
- pfalcon 6y ago
  > I think they should have just gone the whole way and _not_ mutated outside variables. There seems to be little consistent with this addition to the language. Interested in block-level scoping in Python? Please post on the python-ideas mailing list. Thanks.
mumblemumble 6y ago
It would make even more sense for Python not to adopt language features that can't be made to behave consistently with the language's existing syntax and semantics without introducing horrendous footguns. I've been programming in dialects of ML for much longer than Python, so I absolutely appreciate the attraction of this feature. But, the opinion I'm coming to as I think more about this is: 1. I *love* pattern matching. 2. But not in Python.
- yawaramin 6y ago
  Exactly. At this point it feels like Python is LARPing at being an ML. Without even block scoping, this is just asking for trouble.
  - pfalcon 6y ago
    Interested in block-level scoping in Python? Please post on the python-ideas mailing list. Thanks.
    - yawaramin 6y ago
      Actually, the opposite. Call me an old crank but I feel like Python should stay Python and not try to (badly) tack on ideas from ML.
    - mumblemumble 6y ago
      No, not interested in block-level scoping in Python. Why on earth would I ask a programming language I rely on for getting important work done to introduce so massive a breaking change as changing its scoping style? "I don't think feature X is a good fit for Python because it interacts poorly with existing Python features Y and Z" is not a tacit statement of support for changing features Y and Z. It's a statement that means exactly what it says. Like I alluded to in my grandparent post, I use other languages that are not Python, and like their features, too. That does not necessarily mean I want all my favorite features from those pulled into Python. Nor do I want my favorite features from Python pulled into other languages. The best analogy I can think of is a college friend once developed this sort of transitive theory of food that went, "If A tastes good with B, and B tastes good with C, then A must taste good with C." This resulted in a number of questionable concoctions, like serving cottage cheese on top of chocolate cake because they both taste good with strawberries.

deleted 6y ago

[deleted]

CogitoCogito 6y ago

I don't know if I even know what "being consistent" would mean given the example here: https://news.ycombinator.com/item?id=26082225 https://news.ycombinator.com/item?id=26082225 We don't shadow variables when they are re-used in comprehensions for example: >>> i = 4 >>> [i for i in range(10)] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> i 4 Given they're already accepting the oddity of having "case 404:" and "case variable:" mean very different things, I think they should have just gone the whole way and _not_ mutated outside variables. There seems to be little consistent with this addition to the language.

nemetroid 6y ago
> We don't shadow variables when they are re-used in comprehensions for example: I think "for example" makes this sound more general than it is. List comprehensions are one of the rare few constructs that introduce a new scope. The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. This is not to say that I agree with the design as a whole. I think they should have went with: case obj.some_value: ... case some_value: # behaves the same way as the previous ... case _ as variable: ... case (variable := _): # an alternative to the previous syntax ... I.e. I think the complete situation is messy, but it's not the variable scoping rules' fault.
- CogitoCogito 6y ago
  > I think "for example" makes this sound more general than it is. List comprehensions are one of the rare few constructs that introduce a new scope. The rarity of the construct doesn't matter honestly. Are you saying that list comprehensions should _not_ have introduced a new scope because it was unusual? > The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. Syntactically yes, but semantically it is very different and the semantics must be taken into account as well. The example given at the top of this thread (case 404: and case variable:) is enough to convince me that having variable scoping is a brain-dead obvious requirement. > I think the complete situation is messy, but it's not the variable scoping rules' fault. I agree with that statement. I think that improving the design/semantics would be more effective than just adding some more scoping rules in. In fact, I don't think this PEP should have been accepted in this current form at all. But given the current design, block-level scoping is appropriate. Given another design like maybe those you mention might not require that, but I think focusing on the fact that python doesn't have block-level scoping makes no sense. The python language before this PEP is not the same as the one after this PEP. The new one should have block-level scoping in this instance.
- chriswarbo 6y ago
  > The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. I would argue that a stack of 'case's are a 'lambda' (and in particular a single 'case x: ...' is equivalent), and hence they should have function scoping like 'lambda' does. 'match' is a distraction; it's just a function call written backwards, i.e. `match x: f` is equivalent to `f(x)` (in this case Python happens to require `f` to be implemented using the stack-of-'case's form, but that seems incidental; similar to how 'raise' and 'except' are a general form of control flow, despite Python requiring values to be wrapped in something descended from 'Exception')
pfalcon 6y ago
> I think they should have just gone the whole way and _not_ mutated outside variables. There seems to be little consistent with this addition to the language. Interested in block-level scoping in Python? Please post on the python-ideas mailing list. Thanks.

mumblemumble 6y ago

It would make even more sense for Python not to adopt language features that can't be made to behave consistently with the language's existing syntax and semantics without introducing horrendous footguns. I've been programming in dialects of ML for much longer than Python, so I absolutely appreciate the attraction of this feature. But, the opinion I'm coming to as I think more about this is: 1. I *love* pattern matching. 2. But not in Python.

yawaramin 6y ago
Exactly. At this point it feels like Python is LARPing at being an ML. Without even block scoping, this is just asking for trouble.
- pfalcon 6y ago
  Interested in block-level scoping in Python? Please post on the python-ideas mailing list. Thanks.
  - yawaramin 6y ago
    Actually, the opposite. Call me an old crank but I feel like Python should stay Python and not try to (badly) tack on ideas from ML.
  - mumblemumble 6y ago
    No, not interested in block-level scoping in Python. Why on earth would I ask a programming language I rely on for getting important work done to introduce so massive a breaking change as changing its scoping style? "I don't think feature X is a good fit for Python because it interacts poorly with existing Python features Y and Z" is not a tacit statement of support for changing features Y and Z. It's a statement that means exactly what it says. Like I alluded to in my grandparent post, I use other languages that are not Python, and like their features, too. That does not necessarily mean I want all my favorite features from those pulled into Python. Nor do I want my favorite features from Python pulled into other languages. The best analogy I can think of is a college friend once developed this sort of transitive theory of food that went, "If A tastes good with B, and B tastes good with C, then A must taste good with C." This resulted in a number of questionable concoctions, like serving cottage cheese on top of chocolate cake because they both taste good with strawberries.