4 ms·

I guess you are trying to imply that those documents cover a formal-enough description of what the execution and data model is. Well, even for the section "name

I guess you are trying to imply that those documents cover a formal-enough description of what the execution and data model is. Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds. Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators? If you create a new python following those documents, it is possible that you will allow a perfectly reasonable behavior that would fail in most other python interpreters.

joshuamorton 5y ago
> Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds https://www.python.org/dev/peps/pep-0263/ https://www.python.org/dev/peps/pep-0263/ Names aren't unique. > Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators? I'm rather curious what you're referring to here, do you mean dict-ordering, or something else?
- ggrrhh_ta 5y ago
  Sorry, but "names aren't unique" does not even begin to define uniqueness - "from ... import X" imports and X; great; should it replace an "X" in a different encoding in the local namespace, or not? I can tell you it has to do with iterators, and maybe someone will comment on what that is.
  - joshuamorton 5y ago
    By names aren't unique, I mean with respect to "encoding", everything is the same. It seems like you're using "encoding" to mean something it doesn't? Do you just mean like "value"? > I can tell you it has to do with iterators, and maybe someone will comment on what that is. This sounds like you don't know what it is.
    - deleted 5y ago
      [deleted]
    - webmaven 5y ago
      > By names aren't unique, I mean with respect to "encoding", everything is the same. It seems like you're using "encoding" to mean something it doesn't? Do you just mean like "value"? I think the GP means character encodings. So the intent here is to ask whether (for example) a foo defined in a ISO 8859-1 encoded file is overidden by a foo imported from a Windows-1256 encoded file.
      - joshuamorton 5y ago
        > I think the GP means character encodings. Then the link I posted answers their question. Names aren't unique in how encodings are handled. Files are decoded and canonicalized as a unicode string. If the identifiers are the same after canonicalization, then yes they are equivalent. If they aren't, then they aren't.
        webmaven 5y ago
        Ah, I misunderstood what you meant by "aren't unique". I would have phrased that as "names aren't treated differently", or something similar.
  - ggrrhh_ta 5y ago
    I mean... I had not even yet heard the talk that others have pointed you to (from Armin Ronacher); after having gone several times down the rabbit hole of looking at what the interpreter is doing in specific scenarios (and I like lots of things, at the language level, that python does, the terseness and expresiveness that it brings) I also think that python is a very complex language under a soft-looking skin.
    - pjmlp 5y ago
      I follow Python since 1.6, and occasionally use it for portable scripting when on UNIX platforms (PowerShell on Win), and many aren't really aware that Python is Ada/C++ level of complexity, even if on the first contact seems like the new BASIC. Besides the nuances of how everything is executed, there are occasionally breaking changes between minor language revisions. You cannot just pick up a random Python script and be sure it still behaves the same way across all minor revisions.

joshuamorton 5y ago

> Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds https://www.python.org/dev/peps/pep-0263/ https://www.python.org/dev/peps/pep-0263/ Names aren't unique. > Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators? I'm rather curious what you're referring to here, do you mean dict-ordering, or something else?

ggrrhh_ta 5y ago
Sorry, but "names aren't unique" does not even begin to define uniqueness - "from ... import X" imports and X; great; should it replace an "X" in a different encoding in the local namespace, or not? I can tell you it has to do with iterators, and maybe someone will comment on what that is.
- joshuamorton 5y ago
  By names aren't unique, I mean with respect to "encoding", everything is the same. It seems like you're using "encoding" to mean something it doesn't? Do you just mean like "value"? > I can tell you it has to do with iterators, and maybe someone will comment on what that is. This sounds like you don't know what it is.
  - deleted 5y ago
    [deleted]
  - webmaven 5y ago
    > By names aren't unique, I mean with respect to "encoding", everything is the same. It seems like you're using "encoding" to mean something it doesn't? Do you just mean like "value"? I think the GP means character encodings. So the intent here is to ask whether (for example) a foo defined in a ISO 8859-1 encoded file is overidden by a foo imported from a Windows-1256 encoded file.
    - joshuamorton 5y ago
      > I think the GP means character encodings. Then the link I posted answers their question. Names aren't unique in how encodings are handled. Files are decoded and canonicalized as a unicode string. If the identifiers are the same after canonicalization, then yes they are equivalent. If they aren't, then they aren't.
      - webmaven 5y ago
        Ah, I misunderstood what you meant by "aren't unique". I would have phrased that as "names aren't treated differently", or something similar.
- ggrrhh_ta 5y ago
  I mean... I had not even yet heard the talk that others have pointed you to (from Armin Ronacher); after having gone several times down the rabbit hole of looking at what the interpreter is doing in specific scenarios (and I like lots of things, at the language level, that python does, the terseness and expresiveness that it brings) I also think that python is a very complex language under a soft-looking skin.
  - pjmlp 5y ago
    I follow Python since 1.6, and occasionally use it for portable scripting when on UNIX platforms (PowerShell on Win), and many aren't really aware that Python is Ada/C++ level of complexity, even if on the first contact seems like the new BASIC. Besides the nuances of how everything is executed, there are occasionally breaking changes between minor language revisions. You cannot just pick up a random Python script and be sure it still behaves the same way across all minor revisions.