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".
> > 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
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
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 --
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
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
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
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
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
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
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
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:
> > *
> 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
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
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
> 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
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
> 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
--
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
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
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
>
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
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
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
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
25 matches
Mail list logo
