Not found in the documentation

[Chris Angelico]

On Thu, Apr 29, 2021 at 1:21 AM elas tica <elasstiika at 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