Re: Not found in the documentation
On 2021-04-28 08:16:19 -0700, elas tica wrote: > Peter J. Holzer a écrit : > > > Is the "is not" operator a token? > > Yes. See chapter 2.3.1. Sorry. I obviously read what I expected to read here, not what you actually wrote. "is not" ist of course not a token. It is two tokens: "is" and "not". How would one even get the idea that "is not" could be a single token? This isn't Fortran or Apple Basic. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- 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
Am 29.04.21 um 08:54 schrieb elas tica:
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')
# --
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]"""
Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
On Wed, 28 Apr 2021 at 22:18, Dennis Lee Bieber wrote: > The old range() returned a list, and said list could (in your example) > contain 42. The current range() (equivalent to former xrange() ) is not a > container as retrieving values consumes them from the range. A nitpick -- retrieving values from a range doesn't consume them: ``` >>> r = range(10) >>> r range(0, 10) >>> list(r) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> list(r) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> r[0] 0 >>> r[3] 3 >>> list(r) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] ``` range objects are iterables, not iterators. We can see the consuming behaviour I think you are referring to by calling iter(): ``` >>> i = iter(r) >>> next(i) 0 >>> list(i) [1, 2, 3, 4, 5, 6, 7, 8, 9] ``` -- Matt Wheeler http://funkyh.at -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
On Thu, Apr 29, 2021 at 4:56 PM elas tica wrote:
>
> 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.
> ..
>
Are they really? Need more context here. The backslash escapes the
newline, and then you have an additional space character after that,
so it still ends the word. What's the bug here?
ChrisA
--
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
On Thu, Apr 29, 2021 at 5:16 AM elas tica wrote: > > > 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? ;) The one you were referring to. The one that was in the quoted text. The one that this subthread is about. Are you deliberately being obtuse? > > 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. And by the definition you quoted - that some objects contain references to other objects - the only containment is a range's endpoints. > But this discussion is undecidable since the Python Language Reference > doesn't provide a decent definition of a container. And yet, the definition you're complaining about is easily able to answer these exact questions. > > 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) Before that, people had to use common sense, now there's a documented answer. I'm not seeing a huge problem, but to the extent that it was a problem, it has been solved. > - what is a container ? what does mean "contains references" ? is a string a > container or not and where the docs explains the answer? Are you able to put an object reference inside a string? If not, it is not a container. Is a string object able to keep other objects alive by retaining references to them? No. It's right in the piece that you quoted: some objects contain references to *other objects*. > - what is exactly a token? are "is not" or "not in " tokens? I'm not sure, because it depends on the parser, and different language implementations can use different parsers. To what extent does it make a difference? Where in the docs does something refer to "token" in a way that needs to disambiguate this? > > 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? > A, now I get it. You're one of those people who hates on every change that happens, because some other change didn't happen. Good. Go post on Twitter, you'll fit in just fine. ChrisA -- 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
On Thu, Apr 29, 2021 at 1:21 AM elas tica 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, 100) 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
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
On 2021-04-27 06:42:38 -0700, elas tica wrote: > > 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. The style is certainly less formal that that of - for example - the C standard. However, every text written in a natural language is to some extent informal and open to interpretation. So the real question is: Is the text unambiguous enough so that the intended target audience can agree on the answer to any question? The fact that there exist several Python implementations seems to support that, although I don't know how compatible those actually are and the existence of a reference implementation certainly helps. Everything else is a matter of personal taste. > 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! 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. > 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. > Is the "is not" operator a token? Yes. See chapter 2.3.1. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- 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
On Tue, Apr 27, 2021 at 12:52 PM elas tica wrote: > > > 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. > The general rule of thumb that I use is: The *Library Reference* section of the Python docs contains info that cover 90% of use-cases and questions. (note built-in types are a section in the library reference, despite being built-in to the interpreter and not really part of the standard library, but this makes sense if you consider the library reference to be more 'friendly' documentation that tries to balance verbosity and covering every corner case explicitly against readability and approachability. This could be considered a 'conversational' style, but that style is generally considered a feature in the library reference section. 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. In this case, subjectively, I (and I think Chris agrees here) feel that python's behavior with calling str() is suitably non-surprising (especially when compared to almost every other modern language) that being described in the language reference seems entirely reasonable. 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 :). Steve > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
On Tue, Apr 27, 2021 at 9:51 PM elas tica wrote: > > > > 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. Is there an actual problem here, or are you just looking for something to pick a hole in? Are you asking if a hypothetical alternate Python implementation is allowed to have int(16) return "0x10" ? Common sense should be a thing. Use it. ChrisA -- 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
On Tue, Apr 27, 2021 at 6:11 PM elas tica wrote: > > > > 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 > Hmm, that's a bit of a trap. CPython has source code, but the Python language specification is not the CPython source code. There is definitely value in having certain behaviours documented, as it allows other Python implementations to know what's part of the language definition and what's an implementation detail of CPython. 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. ChrisA -- 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
On 27/04/2021 11:24 am, elas tica wrote: 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 : Try ... >>> help(int) and any other built-in type __str__(self) str(self) (END) not very informative. -- Signed email is an absolute defence against phishing. This email has been signed with my private key. If you import my public key you can automatically decrypt my signature and be sure it came from me. Just ask and I'll send it to you. Your email software can handle signing. OpenPGP_signature Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
On 4/26/2021 7:24 PM, elas tica wrote: 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" ... Python has this thing called interactive mode that makes it possible to discover answers even faster than looking in the docs (which can get out of date when things change, as they have for floats). str(12345) '12345' repr(12345) '12345' str(1+1*j) Traceback (most recent call last): File "", line 1, in if True: NameError: name 'j' is not defined str(1+1j) '(1+1j)' repr(1+1j) '(1+1j)' str(.999) '1.0' str(0xff34) '65332' -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
I agree. I would be useful for it to be documented elsewhere, especially in docstrings. I wonder if this is/was a conscious decision to keep Python runtime smaller? Paul On Mon, 2021-04-26 at 18:24 -0700, elas tica wrote: > 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
Re: Not found in the documentation
On 2021-04-26 at 18:24:18 -0700, elas tica wrote: > [...] I was expecting to find [a description of what str returns for > various types] 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 [...] Assuming that PSL is the Python Standard Library, https://docs.python.org/3/library/functions.html#func-str says: [...] str(object) returns object.__str__(), which is the “informal” or nicely printable string representation of object [...] IMO, an exhaustive list of exactly what that means for every type, even the built in types, is unnecessary, and could create maintenance or compatibility issues. Is there a reason you need that information? What would you do with it if you had it? Completely speculatively on my part, would repr (https://docs.python.org/3/library/functions.html#repr) meet your need(s) better than str? -- 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
Re: Not found in the documentation
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. > * Leading zeros, possibly excepting a single zero before a >decimal point, are not shown. > * Trailing zeros, possibly excepting a single zero after a >decimal point, are not shown. > * A sign is shown only when the number is negative. Paul On Mon, 2021-04-26 at 16:24 -0700, elas tica wrote: > > 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
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
