Re: Operator: inappropriate wording?
Le vendredi 4 novembre 2022 à 16:29:34 UTC+1, Chris Angelico a écrit : > Yep. The word "operator" is incorrect when referring to Python's comma > (in contrast to, say, C, where the comma actually *is* an operator); > and from my understanding, the docs have already been updated to fix > this. > > ChrisA Thanks Chris for your response. This problem of an imaginary comma operator was quite clear. The issue I opened is more about the so-called = operator which is not considered as such by the official Python FAQ, at the same place where it was said that comma was not an operator either. By the way, I opened another issue because the dot operator is missing in the list of tokens that are operators and R. Hettinger seems to consider my objection as admissible. The issue is here: https://github.com/python/cpython/issues/99000 It seems that there are some problems with the use of the term operator in the official documentation ;) -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator: inappropriate wording?
Le lundi 31 octobre 2022 à 22:18:57 UTC+1, Chris Angelico a ecrit : > Wording is hard. Just ask the SQL standard whether NULL is a value. > Indeed, but I think our problem here is simpler ;) One could for example omit the incorrect term "operator" while remaining unambiguous. This would give: If the object is a class instance and the attribute reference occurs on both sides of the assignment, the right-hand side expression,... Now, as for the other formulation from the reference document: The second half of the list, the augmented assignment operators, serve lexically as delimiters, but also perform an operation. (link: https://docs.python.org/3/reference/lexical_analysis.html#delimiters) it is incorrect (as explained by the FAQ I quoted in my last post) and the explanations it gives are even more incorrect suggesting that anything that performs an operation is the result of the action of an operator. Under these conditions, we could say that del is an operator and even that return is an operator! I opened an issue on the CPython GitHub repository, here: https://github.com/python/cpython/issues/98814 -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator: inappropriate wording?
Le mercredi 26 octobre 2022 à 22:12:59 UTC+2, Weatherby,Gerard a ecrit : > No. If the docs say in one place a comma is not an operator, they shouldn’t > call it an operator in another place. > > I’ve submitted a pull request https://github.com/python/cpython/pull/98736 -- > we’ll have to see what The Powers That Be think. Thanks for the (merged) pull request about the "comma operator"! I return to the last two quotes in the Reference Document regarding these so-called "assignment operators". The entry in the glossary explains that the comma symbol is not an operator. Well, I just realized that this same entry also explains that the = symbol is not an operator, as you can see by reading the end of their response: The same is true of the various assignment operators (=, += etc). They are not truly operators but syntactic delimiters in assignment statements. (glossary entry link: https://docs.python.org/3/faq/programming.html#what-s-up-with-the-comma-operator-s-precedence) Talking about an assignment operator in Python is even more confusing because, since Python 3.8, there is a real assignment operator, namely the walrus operator. As explained above, the correct expression would be "assignement delimiter" or "assignement statement" or "assignement symbol". By the way, Alex Martelli shares this view, explaining: The "=" operator in Python ... doesn't exist, since '=' is not an operator in Python (just like it isn't, say, in VB). But, OK, you mean "assignment". (source: https://groups.google.com/g/comp.lang.python/c/K6HfK6HANR4/m/OG9QBzFmTR8J) -- https://mail.python.org/mailman/listinfo/python-list
Operator: inappropriate wording?
Quotes from The Python Language Reference, Release 3.10.8: - Note that tuples are not formed by the parentheses, but rather by use of the comma operator (p. 66) - Note: If the object is a class instance and the attribute reference occurs on both sides of the assignment operator (p. 86) - The second half of the list, the augmented assignment operators, serve lexically as delimiters, but also perform an operation (p. 15) Do you agree with this use of the term "operator"? Because there is no such "comma operator" in Python as explained by the official FAQ: https://docs.python.org/3/faq/programming.html#what-s-up-with-the-comma-operator-s-precedence And, =, += and the like are not operators since (a=b), (a+=b), etc have no value. There is no assignment operator instead there exists an assignment statement. The only assignment operator I can figure out is the walrus operator. To confirm, The Python Language Reference gives here: https://docs.python.org/3/reference/lexical_analysis.html#operators the set of tokens considered as operator and the =, += tokens are not listed whereas := is. -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
> > the docs are wrong when they say:
> >
> > ..
> > using a backslash). A backslash is illegal elsewhere on a line outside a
> > string literal.
> > ..
> >
> You're not passing a backslash. Try print(s).
> It would be different with a raw string
>
> s=r"""42 not\
> in [42]"""
>
Good catch Christian. Here the complete corrected code:
# --
from tokenize import tokenize
from io import BytesIO
s = r"""42 not\
in [42]"""
g = tokenize(BytesIO(s.encode('utf-8')).readline)
print(*(g), sep='\n')
# --
outputting now:
..
TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line='')
TokenInfo(type=2 (NUMBER), string='42', start=(1, 0), end=(1, 2), line='42 not
in [42]')
TokenInfo(type=1 (NAME), string='not', start=(1, 3), end=(1, 6), line='42 not
in [42]')
TokenInfo(type=1 (NAME), string='in', start=(1, 7), end=(1, 9), line='42 not in
[42]')
TokenInfo(type=53 (OP), string='[', start=(1, 10), end=(1, 11), line='42 not in
[42]')
TokenInfo(type=2 (NUMBER), string='42', start=(1, 11), end=(1, 13), line='42
not in [42]')
TokenInfo(type=53 (OP), string=']', start=(1, 13), end=(1, 14), line='42 not in
[42]')
TokenInfo(type=4 (NEWLINE), string='', start=(1, 14), end=(1, 15), line='')
TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')
..
but this doesn't seem to change the conclusion.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
Le mercredi 28 avril 2021 à 17:36:32 UTC+2, Chris Angelico a écrit :
> 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.
It was a good suggestion, and the PLR doesn't mention the tokeniser module. It
should, this goes very well with the conversional style it has.
# --
from tokenize import tokenize
from io import BytesIO
s="""42 not\
in [42]"""
g = tokenize(BytesIO(s.encode('utf-8')).readline)
print(*(g), sep='\n')
# --
outputting:
..
TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line='')
TokenInfo(type=2 (NUMBER), string='42', start=(1, 0), end=(1, 2), line='42 not
in [42]')
TokenInfo(type=1 (NAME), string='not', start=(1, 3), end=(1, 6), line='42 not
in [42]')
TokenInfo(type=1 (NAME), string='in', start=(1, 7), end=(1, 9), line='42 not in
[42]')
TokenInfo(type=53 (OP), string='[', start=(1, 10), end=(1, 11), line='42 not in
[42]')
TokenInfo(type=2 (NUMBER), string='42', start=(1, 11), end=(1, 13), line='42
not in [42]')
TokenInfo(type=53 (OP), string=']', start=(1, 13), end=(1, 14), line='42 not in
[42]')
TokenInfo(type=4 (NEWLINE), string='', start=(1, 14), end=(1, 15), line='')
TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')
..
So "not in" is not a token and the docs are wrong when they say:
..
using a backslash). A backslash is illegal elsewhere on a line outside a string
literal.
..
--
https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
Le mercredi 28 avril 2021 à 17:36:32 UTC+2, Chris Angelico a écrit : > > 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. Which definition? ;) > 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, 100) requires a reference to the "one > million" integer, even though it is not actually part of the range). The problem with range is different because we all know that a range object doesn't hold (= contain) the int's (except the endpoints and the step) we can iterate on, instead a range object computes on the fly the int's it holds. On the contrary, the string "2021" holds the digits, even "2021"*10**6 does. But this discussion is undecidable since the Python Language Reference doesn't provide a decent definition of a container. > What are you actually trying to prove here? What > problem are you solving? Or is this just nitpicking for the sake of > it? I was only looking for basic definitions, unfortunately the official docs are not able to provide : - what is the str value of an int? (we have to wait until Python 3.8.6 docs to get the response) - what is a container ? what does mean "contains references" ? is a string a container or not and where the docs explains the answer? - what is exactly a token? are "is not" or "not in " tokens? > the language definition. CPython, for instance, is in process of > completely rewriting its parser, and what about rewriting and *redesigning* the docs? Is there even a discussion about this? Nobody complains? -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
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 ? 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 ? > > You said that LR is designed to be much more formally defined, and > > favors correctness and completeness. Good, so can you answer this > > question after reading the LR : what is a "token"? Did't find a > > definition. > There is an indirect definition right at the start of chapter 3: "Input > to the parser is a stream of tokens, generated by the lexical analyzer." > So a token is what the unit of output of the lexer. This is the > definition. The rest of the chapter defines the details. As you know, the devil is in the details ;) A bunch of properties doesn't make a definition. What do we need is a characteristic property (necessary and sufficient). > > 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). -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
Le mardi 27 avril 2021 à 01:44:04 UTC+2, Paul Bryan a écrit : > From > https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy > > : > > > The string representations of the numeric classes, computed > > by__repr__() and __str__(), have the following properties: > > * They are valid numeric literals which, when passed to their > > class constructor, produce an object having the value of the > > original numeric. > > * The representation is in base 10, when possible. I realize that these basic informations have been very recently added to the Language Reference document as they are missing from the 3.8.5 version (July 2020) as you can check here: https://docs.python.org/release/3.8.5/reference/datamodel.html#index-8 -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
> The *Language Reference* is designed to be much more formally defined, and > favors correctness and completeness over being easy to access by less > technical readers. > Not really my opinion. Language Reference (LR) style is still written in a conversational style, giving examples instead of definition. Typically consider this paragraph from the LR: begin excerpt --- The value of some objects can change. Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable. (The value of an immutable container object that contains a reference to a mutable object can change when the latter’s value is changed; however the container is still considered immutable, because the collection of objects it contains cannot be changed. So, immutability is not strictly the same as having an unchangeable value, it is more subtle.) An object’s mutability is determined by its type; for instance, numbers, strings and tuples are immutable, while dictionaries and lists are mutable. end excerpt --- The explanations inside the parenthensis is a by-the-way explanation, a mark of conversional style not to say tutorial style. Before parenthensis, we are talking about value of **any kind** of object and changeability in general. Now, the parenthensis is refering to immutable container as an illustration. The same for last sentence : "for instance ..." The problem is that the documentation doesn't define what the value of an object is, what means changing the value. The documentation doesn't explain **how** mutability is determined by the type of the object. By the way, how the docs define a container? Answer: "Some objects contain references to other objects; these are called containers". So to summarize : "a container contains", what a great definition! You said that LR is designed to be much more formally defined, and favors correctness and completeness. Good, so can you answer this question after reading the LR : what is a "token"? Did't find a definition. Is the "is not" operator a token? > There's an argument to be made that the description of the expected > __str__() behavior of ints is not easy to find within section 3 of the > language reference, and I imagine that a reasonable proposed change to this > wording would be considered favourably. (python is accepting pull requests > when they pass review :). > A drop in the ocean, sorry but Python docs are irrecoverable. -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
> However, in this case, the general information in the docs is > absolutely sufficient, and the basic principle that the repr should > (where possible) be a valid literal should explain what's needed. This is a subjective statement. Recall: explicit is better implicit. Alas, many parts of the Python docs are written in a conversational style, full of implicit and fuzzy meanings. -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
> Python has this thing called interactive mode that makes it possible to > discover answers even faster than looking in the docs To go further : Python has this thing called source code that makes it possible to discover answers even faster than looking in the docs -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
Le mardi 27 avril 2021 à 01:44:04 UTC+2, Paul Bryan a écrit : > From > https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy > > : > Thanks for the reference. I was expecting to find this information in the Built-in Types section from the PSL documentation. The representation returned by str over a complex number is not stated. The same for fraction objects. All the docstrinds are meaningless, showing : __str__(self) str(self) (END) not very informative. -- https://mail.python.org/mailman/listinfo/python-list
Not found in the documentation
Python documentation doesn't seem to mention anywhere what is the str value of an int: is it right? the same for float, Fraction, complex, etc? Not worth to be documented? Perphaps str(42) returns "forty two" or "XLII" or "101010" ... -- https://mail.python.org/mailman/listinfo/python-list
