On Thu, Apr 29, 2021 at 1:21 AM elas tica <elassti...@gmail.com> wrote: > > Peter J. Holzer a écrit : > > > That's why it's called a container. But it also says *what* an object > > must contain to be called a container. You could say that an int object > > contains an integer value and a str object contains a reference to a > > buffer containing the string - but those aren't references to other > > objects, so int and str are not containers. > > This is not how I interpret the wording : a string is a container for > containing > a reference to the characters the string holds. Depends on what you mean > by "reference" and "contain". With the definition given, I cannot decide > if a string or a range object is a container or not. For instance, > can we say that range(100) contains 42 ?
Not by that definition of container. There are two completely different concepts that you are conflating: the low level concept that some objects have references to other objects, and the high level concept that some objects support the "in" operator for containment checks. They are similar, in that many objects use "in" to check the exact same set that they refer to, but they are not the same (for instance, range(1, 10, 1000000) requires a reference to the "one million" integer, even though it is not actually part of the range). > PLR document *states* that tuples, lists, sets are containers but doesn't > mention if a string is a container or not. Nevertheless, str has a > __contains__ > method so if a string is not a container what is the logic ? Same problem. A string would also return True if you ask if it contains any substring (for instance, "test" in "this is a test..." would be True), even though it doesn't show up if you iterate, and the string object most certainly doesn't have a reference to such a substring. > > > Is the "is not" operator a token? > > Yes. See chapter 2.3.1. > > > > 2.3.1 is about keywords : > https://docs.python.org/3/reference/lexical_analysis.html#keywords > not tokens (keywords are tokens but this is not the problem here). > > From 2.1.5 (Python 3.9 LR) > > ............... > A line ending in a backslash cannot carry a comment. A backslash does not > continue a comment. A backslash does > not continue a token except for string literals (i.e., tokens other than > string literals cannot be split across physical lines > using a backslash). A backslash is illegal elsewhere on a line outside a > string literal. > ............... > > Giving the above, if "is not" were a token as you are explaining, the > following code should be invalid syntax : > > # ------------ begin code ------------- > > 42 is\ > not [42] > > # ------------ end code ------------- > > but this code compiles perfectly (there is a whitespace at the beginning of > the second physical line). > In what sense of the word "token" are you asking? The parser? You can play around with the low-level tokenizer with the aptly-named tokenizer module. What are you actually trying to prove here? What problem are you solving? Or is this just nitpicking for the sake of it? If your goal is just to nitpick, please be up-front about it, so we can respond accordingly, with appropriate levels of fastidious precision. Also bear in mind: The language can be tokenized differently by different interpreters, so some of the precise details are not part of the language definition. CPython, for instance, is in process of completely rewriting its parser, and I'm not sure how much of that has affected the language definition yet. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
