5 ms·

Because Python doesn't have block scoping, only function scoping.

bzbarsky 9y ago
Yes, my point is that function scoping can hardly be described as "makes sense all the time". Especially given that variable declarations in python are _very_ implicit, without even the "var" that will indicate to you that you're messing with your function scope in JavaScript.
- empthought 9y ago
  > Yes, my point is that function scoping can hardly be described as "makes sense all the time". Block and function scoping both "make sense all the time." Whether or not you personally are accustomed to a language's design decisions does not have any bearing on whether or not those decisions "make sense." In the particular case you cited, of course it is natural that `foo` is in scope outside of the loop; it appears in a line outside of the loop. This is trivially evident in the indentation.
  - bzbarsky 9y ago
    The context is that we're talking about people picking up the language for the first time, coming from other languages. What matters is whether the scoping rules make sense to such people. For that, it matters whether they're coming from another function-scoped language (or are familiar with one), and whether they're used to having their variable declarations being obvious or not. For me, when I was first learning Python, this scoping issue was a significant pain point. This is obviously an anecdote, not data, but again for purposes of "people first coming to the language" it's relevant. Obviously once one has worked in Python for a while one internalizes things like this, just like one internalizes various things in other languages that are obvious pain points for beginners.
    - empthought 9y ago
      Python is and always has been designed to be an introductory programming language, so your criticism does not apply in the case of this design intent. More people learn Python first than learn another language first. Having seen beginning programmers learn Python, I can say this is an utter nonissue to them. For the case of experienced programmers, the behavior is consistent and simple. In what way does this not "make sense?" Does Haskell's normal order evaluation not "make sense?" Does Ruby's optional parentheses for method calls not "make sense?" Does a regular expression literal syntax not "make sense?" Does JSX not "make sense?" Do public/protected/private modifiers in Java not "make sense?" Stop confusing a match to your personal comfort zone for actual quality or fitness-for-purpose.
      - bzbarsky 9y ago
        > the behavior is consistent and simple Let's look at our example again: for foo in bar: pass # Why is "foo" in scope here??? Well, the answer could be "it's not". It depends on whether bar actually produced anything to assign to foo. Doing a "print(foo)" after that loop might print something, or it might throw a NameError. Now I understand why that happens (in terms of what the loop actually desugars into), and you understand why it happens. But it's not as consistent and simple as you're trying to make it out to be. You have to really understand what a for-in loop is doing under the hood to explain the behavior. You seem to feel that I'm attacking Python or something. I'm not. It's a nice language to work in, with a lot to recommend it. But it's not a language I'd choose as a poster child for scope and namespace making sense all the time unless you really dig into what's going on "under the hood". > Does Haskell's normal order evaluation not "make sense?" No opinion, really; not enough intimate familiarity with the problem space to have one. > Does Ruby's optional parentheses for method calls not "make sense?" Again, no opinion. > Does a regular expression literal syntax not "make sense?" It depends on the regexp. If your regexp is simple enough, it's fine. In far too many cases you end up with a write-only monstrosity. Also, you say "syntax" as if there were only one; there are multiple and some make more sense than others. > Does JSX not "make sense?" Again, no opinion. > Do public/protected/private modifiers in Java not "make sense?" It depends on how they're used. > Stop confusing a match to your personal comfort zone for actual quality or fitness-for-purpose. Stop confusing "doesn't always make sense" for "doesn't make sense" (totally different statements, there), and the former statement for a statement about quality of fitness-for-purpose. Lots of things are considered high-quality and fit for purpose while still having flaws. Possibly flaws that could not have been avoided without sacrificing other goals. But determining that requires first admitting that the flaws exist and then evaluating them. If we either pretend that the flaws don't exist, or that flaws existing is somehow an indicator that the entire system is unfit for purpose, it's hard to think productively about the design of the next system.

Yes, my point is that function scoping can hardly be described as "makes sense all the time". Especially given that variable declarations in python are _very_ implicit, without even the "var" that will indicate to you that you're messing with your function scope in JavaScript.

empthought 9y ago
> Yes, my point is that function scoping can hardly be described as "makes sense all the time". Block and function scoping both "make sense all the time." Whether or not you personally are accustomed to a language's design decisions does not have any bearing on whether or not those decisions "make sense." In the particular case you cited, of course it is natural that `foo` is in scope outside of the loop; it appears in a line outside of the loop. This is trivially evident in the indentation.
- bzbarsky 9y ago
  The context is that we're talking about people picking up the language for the first time, coming from other languages. What matters is whether the scoping rules make sense to such people. For that, it matters whether they're coming from another function-scoped language (or are familiar with one), and whether they're used to having their variable declarations being obvious or not. For me, when I was first learning Python, this scoping issue was a significant pain point. This is obviously an anecdote, not data, but again for purposes of "people first coming to the language" it's relevant. Obviously once one has worked in Python for a while one internalizes things like this, just like one internalizes various things in other languages that are obvious pain points for beginners.
  - empthought 9y ago
    Python is and always has been designed to be an introductory programming language, so your criticism does not apply in the case of this design intent. More people learn Python first than learn another language first. Having seen beginning programmers learn Python, I can say this is an utter nonissue to them. For the case of experienced programmers, the behavior is consistent and simple. In what way does this not "make sense?" Does Haskell's normal order evaluation not "make sense?" Does Ruby's optional parentheses for method calls not "make sense?" Does a regular expression literal syntax not "make sense?" Does JSX not "make sense?" Do public/protected/private modifiers in Java not "make sense?" Stop confusing a match to your personal comfort zone for actual quality or fitness-for-purpose.
    - bzbarsky 9y ago
      > the behavior is consistent and simple Let's look at our example again: for foo in bar: pass # Why is "foo" in scope here??? Well, the answer could be "it's not". It depends on whether bar actually produced anything to assign to foo. Doing a "print(foo)" after that loop might print something, or it might throw a NameError. Now I understand why that happens (in terms of what the loop actually desugars into), and you understand why it happens. But it's not as consistent and simple as you're trying to make it out to be. You have to really understand what a for-in loop is doing under the hood to explain the behavior. You seem to feel that I'm attacking Python or something. I'm not. It's a nice language to work in, with a lot to recommend it. But it's not a language I'd choose as a poster child for scope and namespace making sense all the time unless you really dig into what's going on "under the hood". > Does Haskell's normal order evaluation not "make sense?" No opinion, really; not enough intimate familiarity with the problem space to have one. > Does Ruby's optional parentheses for method calls not "make sense?" Again, no opinion. > Does a regular expression literal syntax not "make sense?" It depends on the regexp. If your regexp is simple enough, it's fine. In far too many cases you end up with a write-only monstrosity. Also, you say "syntax" as if there were only one; there are multiple and some make more sense than others. > Does JSX not "make sense?" Again, no opinion. > Do public/protected/private modifiers in Java not "make sense?" It depends on how they're used. > Stop confusing a match to your personal comfort zone for actual quality or fitness-for-purpose. Stop confusing "doesn't always make sense" for "doesn't make sense" (totally different statements, there), and the former statement for a statement about quality of fitness-for-purpose. Lots of things are considered high-quality and fit for purpose while still having flaws. Possibly flaws that could not have been avoided without sacrificing other goals. But determining that requires first admitting that the flaws exist and then evaluating them. If we either pretend that the flaws don't exist, or that flaws existing is somehow an indicator that the entire system is unfit for purpose, it's hard to think productively about the design of the next system.