opps, forgot to include my test code -- could be handy:
On Fri, Dec 27, 2019 at 11:52 PM Christopher Barker
wrote:
> On Fri, Dec 27, 2019 at 5:39 PM Guido van Rossum wrote:
>
>> Is duck typing float or Decimal worth the bother? Barring that it could
>> be done with some isinstance() checks
On Fri, Dec 27, 2019 at 5:39 PM Guido van Rossum wrote:
> Is duck typing float or Decimal worth the bother? Barring that it could be
> done with some isinstance() checks (in the user code, not in math.isnan()).
>
well, for the topic at hand in another thread -- in the statistics module.
And I
Thanks Steven, for your thoughtful response.
On Thu, Dec 26, 2019 at 5:44 PM Steven D'Aprano wrote:
> However, I am happy to accept that silent failure may not be the ideal
> result for everyone.
I would argue that it is not the ideal result for ANYONE. The only reason
for it is that it's
On Fri, Dec 27, 2019 at 8:14 PM Richard Damon
wrote:
> > It is a well known axiom of computing that returning an *incorrect*
> > result is a very bad thing.
>
> There is also an axiom that you can only expect valid results if you
> meet the operations pre-conditions.
>
sure.
> Sometimes,
On 12/27/19 9:15 PM, Christopher Barker wrote:
I’m going to strongly support David Mertz’s point here:
It is a well known axiom of computing that returning an *incorrect*
result is a very bad thing.
There is also an axiom that you can only expect valid results if you
meet the operations
We have a fundamental issue here:
On the one hand, we like Duck Typing, and it is baked into Python.
On the other hand, we have a "math" module, that started as a wrapper
around the C lib, and to this day is essentially a "float math" module.
Which indeed is very useful, but not compatible with
I’m going to strongly support David Mertz’s point here:
It is a well known axiom of computing that returning an *incorrect* result
is a very bad thing.
What the correct result of the median of a sequence of floats that contains
some NaNs is up for debate. As David points out there are (at
Is duck typing float or Decimal worth the bother? Barring that it could be
done with some isinstance() checks (in the user code, not in math.isnan()).
Otherwise, your only resort is a PEP, like the final comment of that bug
says.
On Fri, Dec 27, 2019 at 18:16 David Mertz wrote:
> Great work! I
Never mind... the cases I mentioned are happy already:
>>> import numpy as np
>>> import torch
>>> import math
>>> math.isnan(np.nan), type(np.nan)
(True, )
>>> np_nan = np.array(np.nan)
>>> math.isnan(np_nan), type(np_nan)
(True, )
>>> torch_nan = torch.Tensor([float('nan')])
>>>
Great work! I had not known if those corners.
Have you tried with NumPy zero-D arrays or PyTorch Values? Both of those
should have sensible answers.
On Fri, Dec 27, 2019, 7:42 PM Steven D'Aprano wrote:
> By the way, it's not as easy as you might think to test whether a value
> is a NAN or not.
By the way, it's not as easy as you might think to test whether a value
is a NAN or not.
There are currently three ways to test whether a value is a NAN. (Four
if you include cmath.isnan.)
1. math.isnan(x) but it can fail in annoying ways.
# No int is a NAN so this should return False
> On Dec 27, 2019, at 09:00, Juancarlo Añez wrote:
>
>for m in re.finditer(pattern, string, flags=flags):
>g = m.groups()
>if len(g) == 1:
>yield g[0]
>elif g:
>yield g
>else:
>yield m.group()
I don’t think this does the
>>> nan1 = float('nan')
>>> nan2 = 1e350 - 1e350
>>> nan3 = 1e400 / 1e399
>>> nan1, nan2, nan3
(nan, nan, nan)
>>> things = [1, 2, 3, nan1, nan2]
>>> nan1 in things, nan3 in things
(True, False)
>>> nan1 == nan1
False
>>> nan1 is nan1
True
The "in" operator might not do what you hope with
The signature could be:
def median(it, exclude=None):
With *exclude* being a value, or collection supporting the *in* operator
On Thu, Dec 26, 2019 at 4:14 PM David Mertz wrote:
> Maybe we can just change the function signature:
>
> statistics.median(it, do_wrong_ass_thing_with_nans=False)
>
27.12.19 18:00, Siddharth Prajosh пише:
Why do we need separate functions for == and != ?
Isn't this supposed to be negation of each other?
Because __eq__ and __ne__ can return not only bool. For example, for
NumPy arrays they return arrays of bools.
On Fri, Dec 27, 2019, 12:05 PM Steven D'Aprano wrote:
> On Fri, Dec 27, 2019 at 02:16:43PM +, Jonathan Fine wrote:
> > Summary: dict.update(self, other) corresponds to 'merge-right'. Perhaps
> add
> > dict.gapfill(self, other), which corresponds to 'merge-left'.
>
I don't understand the
On 12/27/2019 10:37 AM, Marco Sulla via Python-ideas wrote:
Eric Fahlgren wrote:
You apparently did not read the posts, because the point was whether it
raises or returns a default value, not whether it saves one line or ten.
You apparently don't know Python:
Please be more respectful.
```
On Fri, Dec 27, 2019 at 02:16:43PM +, Jonathan Fine wrote:
> Summary: dict.update(self, other) corresponds to 'merge-right'. Perhaps add
> dict.gapfill(self, other), which corresponds to 'merge-left'.
What does "merge-right" mean to you? When I am driving my car, and I see
a sign "merge
These are the implementations I added to my library:
```python
def findalliter(pattern, string, flags=0):
'''
like finditer(), but with return values like findall()
implementation taken from cpython/Modules/_sre.c/findall()
'''
for m in re.finditer(pattern, string,
Hello,
As I remember, __ne__ is implemented by default as *not *__eq__() in the
base for hashable classes. Among the reasons to have a separate __ne__ may
be implementation efficiency. Another is symmetry and completeness.
Read the docs about the minimum a class must to do be:
- hashable
On Fri, Dec 27, 2019 at 03:16:50PM -, Marco Sulla via Python-ideas wrote:
> Steven D'Aprano wrote:
> > On Fri, Dec 27, 2019 at 02:22:48AM -, Marco Sulla via Python-ideas
> > wrote:
> > > It's very common to see:
> > > for i, x in enumerate(sequence):
> > > [...]
> > >
> > > Yes, that
On 12/27/19 10:16 AM, Marco Sulla via Python-ideas wrote:
Steven D'Aprano wrote:
On Fri, Dec 27, 2019 at 02:22:48AM -, Marco Sulla via Python-ideas wrote:
It's very common to see:
for i, x in enumerate(sequence):
[...]
Yes, that is very common, except that "sequence" can be any
Why do we need separate functions for == and != ?
Isn't this supposed to be negation of each other?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Hi folks,
moderator here. No need to respond.
thanks,
--titus
On Fri, Dec 27, 2019 at 03:37:14PM -, Marco Sulla via Python-ideas wrote:
> Eric Fahlgren wrote:
> > You apparently did not read the posts, because the point was whether it
> > raises or returns a default value, not whether it
Eric Fahlgren wrote:
> You apparently did not read the posts, because the point was whether it
> raises or returns a default value, not whether it saves one line or ten.
You apparently don't know Python:
```
next(iterator) # raises an exception if no more elements
next(iterator, _sentinel) #
Excuse me Mr. Fine, can't you simply do `d2.update(c2)`???
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message
On 12/26/19 5:23 PM, Andrew Barnert via Python-ideas wrote:
On Dec 26, 2019, at 12:36, Richard Damon wrote:
On 12/26/19 2:10 PM, Andrew Barnert via Python-ideas wrote:
On Dec 26, 2019, at 10:58, Richard Damon wrote:
Note, that NaN values are somewhat rare in most programs, I think they can
Steven D'Aprano wrote:
> On Fri, Dec 27, 2019 at 02:22:48AM -, Marco Sulla via Python-ideas wrote:
> > It's very common to see:
> > for i, x in enumerate(sequence):
> > [...]
> >
> > Yes, that is very common, except that "sequence" can be any iterable
> with an unpredictable length, or
Hi Jonathan,
On 12/27/19 3:16 PM, Jonathan Fine wrote:
> Summary: dict.update(self, other) corresponds to 'merge-right'. Perhaps add
> dict.gapfill(self, other), which corresponds to 'merge-left'. This post
> defines dict.gapfill, and discusses update and gapfill in the context of
> PEP 584.
IMHO
Summary: dict.update(self, other) corresponds to 'merge-right'. Perhaps add
dict.gapfill(self, other), which corresponds to 'merge-left'. This post
defines dict.gapfill, and discusses update and gapfill in the context of
PEP 584.
PEP 584 suggests adding a merge operator (to be denoted by '|' or
Steven, can you please remember me what operations can return NaN? I remember
for example 0/0 and +Infinity - +Infinity.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
I'm sorry Marco, you seem to have changed the subject line to discuss
the set API and sorting, but then went on to discuss NANs without
mentioning sets or sorting.
Regarding NANs:
Marco said:
> > > This is because NaN, IMHO, it's not the right name
> > > for the entity. A number can't be Not
On Fri, Dec 27, 2019 at 02:22:48AM -, Marco Sulla via Python-ideas wrote:
> It's very common to see:
>
> ```
> for i, x in enumerate(sequence):
> [...]
>
> ```
Yes, that is very common, except that "sequence" can be any iterable
with an unpredictable length, or even an infinite length,
On Thu, Dec 26, 2019 at 7:58 PM Marco Sulla via Python-ideas <
python-ideas@python.org> wrote:
>
> So 200 posts for one line less? I really don't catch the point.
>
You apparently did not read the posts, because the point was whether it
raises or returns a default value, not whether it saves one
34 matches
Mail list logo
