On Mon, Sep 14, 2020 at 12:16:54PM +1000, Chris Angelico wrote:
> (How often do people even use "x is True"?)
Alas, that is a common idiom. For example:
https://stackoverflow.com/questions/50816182/pep-8-comparison-to-true-should-be-if-cond-is-true-or-if-cond
It's possibly less common than it
On Sat, Sep 12, 2020 at 05:48:30PM -0700, Paul Bryan wrote:
> I meant to ask, why is nan not comparable? Even:
>
> >>> math.nan == math.nan
> False
It is worth explaining why the IEEE-754 standards committee agreed to
make NANs unequal to everything.
"It is not possible to specify a
Hence why I said 'would', 'if' etc. And it was brought up/suggested, having
singletons. It does naturally flow from having a built-in (much like having
singletons for booleans does):
sugggesting that one reason that they were made keywords is that it's
> useful for them to be singletons, which is
>From "[Python-ideas] JSON encoder protocol (was Re: adding support for a
"raw output" in JSON serializer)"
https://mail.python.org/archives/list/python-ideas@python.org/message/5C4UHZJJ5O6CNMZADHMRSDL6FHT23FD3/
> - There's JSON5; which supports comments, trailing commas, IEEE 754
±Infinity and
On Mon, Sep 14, 2020 at 11:05 AM Cade Brown wrote:
> This would become relevant, if, say Python 4.0 migrated 'inf' and 'nan' to
> builtin names (like True and False). If that happened, a 'nan' singleton
> wouldn't make sense unless you had 2**53 of them, so code like:
>
> >>> x is nan
>
>
On Mon, Sep 14, 2020 at 10:52 AM David Mertz wrote:
>
> Yes, that is a design flaw in the stdlib. There ought to be an opt-in switch
> for accepting/producing those special values, not the current opt-out for
> strictness... And the misnamed parameter is 'allow_nan' whereas it also
>
Yes, that is a design flaw in the stdlib. There ought to be an opt-in
switch for accepting/producing those special values, not the current
opt-out for strictness... And the misnamed parameter is 'allow_nan' whereas
it also configures 'Infinity'.
On Sun, Sep 13, 2020, 3:16 PM Matthias Bussonnier <
Oh, well, but stdlib json already emit (and parse) invalid json by default...
$ ipython
Python 3.8.3 (default, May 19 2020, 13:54:14)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.15.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import json
In [2]:
I never said it was, he specifically said as an aside for a book he was
writing. He said he hadn't heard of code using it, so I provided an example
You are talking about an *internal implementation detail* in the C code
> of the Javascript engine, not a Javascript language feature. There is no
>
On Sat, Sep 12, 2020 at 08:16:36PM -0400, Cade Brown wrote:
> As per tagged nans, check for JavaScript tagged NaN optimization.
> Essentially, the tag of the NaN (i.e. the mantissa) is interpreted as a
> pointer. Obviously, this is a very advanced use case, probably not worth
> Python guaranteeing
The immediate use case I can think of this for is to make it possible to
just do:
__len__ = instancemethod(operator.attrgetter('_length'))
__hash__ = instancemethod(operator.attrgetter('_cached_hash'))
and stuff like that. Mostly just a minor performance optimization to avoid
the overhead of
On Sun, Sep 13, 2020 at 8:10 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> As Steven points out, it's an overflow, and IEEE *but not Python* is
> clear about that. In fact, none of the actual infinities I've tried
> (1.0 / 0.0 and math.tan(math.pi / 2.0)) result in
On 2020-09-13 11:57, Christopher Barker wrote:
On Sun, Sep 13, 2020 at 7:58 AM Stephen J. Turnbull
mailto:turnbull.stephen...@u.tsukuba.ac.jp>> wrote:
> encoding=None: this is the important one -- json is always UTF-8
yes?
Standard JSON is always UTF-8. Nevertheless, I'm quite
On Sun, Sep 13, 2020 at 8:59 AM Christopher Barker
wrote:
> On Sun, Sep 13, 2020 at 7:58 AM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> > encoding=None: this is the important one -- json is always UTF-8 yes?
>>
>> Standard JSON is always UTF-8. Nevertheless, I'm
On Sun, Sep 13, 2020 at 7:58 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > encoding=None: this is the important one -- json is always UTF-8 yes?
>
> Standard JSON is always UTF-8. Nevertheless, I'm quite sure that
> there's a ton of Japanese in Shift JIS, including
Hi Ranga,
I think I understand what you're after, but this really looks like
something you can solve yourself in several ways (e.g. just creating
classes that override one method) so I don't think it's worth changing the
argparse module to support this directly.
--Guido
On Thu, Sep 10, 2020 at
Cade Brown writes:
> When I read "1e1000" or such a number it doesn't strike me as
> infinite
As Steven points out, it's an overflow, and IEEE *but not Python* is
clear about that. In fact, none of the actual infinities I've tried
(1.0 / 0.0 and math.tan(math.pi / 2.0)) result in values of
Christopher Barker writes:
> But why are they keywords? In Py2, True and False were just identifiers-
> they were made keywords in py3.
>
> I’m suggesting that one reason that they were made keywords is that
> it's useful for them to be singletons, which is much harder to do
> (or at least
Christopher Barker writes:
> encoding=None: this is the important one -- json is always UTF-8 yes?
Standard JSON is always UTF-8. Nevertheless, I'm quite sure that
there's a ton of Japanese in Shift JIS, including some produced by
default in Python on Windows. I'll bet the same is true of GBK
19 matches
Mail list logo
