Are all objects in Python equality-comparable? I know that you can delete
__hash__ to make an object unhashable (e.g., dicts). If so, this is a
great addition.
On Saturday, July 4, 2020 at 5:26:45 PM UTC-4, Joao S. O. Bueno wrote:
>
>
>
> On Sat, 4 Jul 2020 at 16:51, Serhiy Storchaka >
On Sun, Jul 5, 2020, 10:25 PM Steven D'Aprano wrote:
> > The standard library *does* seem to have taken pains to avoid
> "finite nans."
>
> I don't know what you mean by "finite nans". By definition, any NAN is not
> considered finite.
>
The scare quotes because I know that's not a real thing.
On Mon, Jul 6, 2020 at 12:36 PM Steven D'Aprano wrote:
> Four years ago, there was strong opposition to giving the bounds default
> values. I think the consensus at the time was that it is okay to
> explicitly provide "unbounded" arguments (whether you spell them as
> infinities, NANs, or None)
On Mon, Jul 06, 2020 at 03:21:04AM +0100, Henk-Jaap Wagenaar wrote:
> I do not agree clamp should be restricted to numeric values. I would expect
> clamp to be agnostic to the specifics of floats/numbers and like sort
> expect it to work for any values as long as they compare (using a dunder).
It
On Sun, Jul 05, 2020 at 09:42:07PM -0400, David Mertz wrote:
> The standard library *does* seem to have taken pains to avoid "finite
> nans."
I don't know what you mean by "finite nans". By definition, any NAN is
not considered finite.
py> math.isfinite(math.nan)
False
Do you mean,
I do not agree clamp should be restricted to numeric values. I would expect
clamp to be agnostic to the specifics of floats/numbers and like sort
expect it to work for any values as long as they compare (using a dunder).
I think having something like min=-math.inf is hence right out in my mind.
If
On Sun, Jul 5, 2020 at 10:04 PM Christopher Barker
wrote:
> Since you brought that up -- I recall a lot of debate about whether NaN's
> should be considered missing values or "poisoning" in the statistics module
> -- there are arguments for both, and neither was clear or obvious. So using
> NaN
On Sun, Jul 5, 2020 at 6:51 PM David Mertz wrote:
>
> will always return x for every finite and infinite value, so it must
>> return x for NANs too.
>>
>
> I strongly agree with Steven here. Also about order-dependence in results
> of min() and max() being disturbing and contrary to IEEE-754.
>
On Sun, Jul 5, 2020 at 6:01 PM Greg Ewing
wrote:
> On 6/07/20 3:55 am, Steven D'Aprano wrote:
> > With that interpretation, a NAN passed as the lower or upper bounds can
> > be seen as another way of saying "no lower bounds" (i.e. negative
> > infinity) or "no upper bounds" (i.e. positive
On Sun, Jul 5, 2020 at 9:38 PM Steven D'Aprano wrote:
> > >I agree with you that `clamp(lower=x, value=NAN, upper= x)` should
> > >return x.
>
> Sorry Greg, on this point at least the IEEE-754 standard is firm: if a
> function will return the same result for every non-NAN argument, then it
>
On Sun, Jul 5, 2020 at 8:57 PM Steven D'Aprano wrote:
> On Sun, Jul 05, 2020 at 12:15:27PM -0400, David Mertz wrote:
> > This is a digression, but does anyone have a nice example IN PYTHON of
> > arriving at a NaN without going through infinity. I think Julia is right
> > and Python is wrong
On Mon, Jul 06, 2020 at 12:59:28PM +1200, Greg Ewing wrote:
> >I agree with you that `clamp(lower=x, value=NAN, upper= x)` should
> >return x.
>
> I don't think I agree with that
Sorry Greg, on this point at least the IEEE-754 standard is firm: if a
function will return the same result for
Sorry, this got lost in the shuffle without being sent, and the
conversation seems to have died down. but since I wrote it ...
On Sat, Jul 4, 2020 at 8:25 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Christopher Barker writes:
>
> > I am really confused here -- I'm
On 6/07/20 3:55 am, Steven D'Aprano wrote:
With that interpretation, a NAN passed as the lower or upper bounds can
be seen as another way of saying "no lower bounds" (i.e. negative
infinity) or "no upper bounds" (i.e. positive infinity), not "some
unknown bounds".
Python already has a value
On Sun, Jul 05, 2020 at 12:15:27PM -0400, David Mertz wrote:
> This is a digression, but does anyone have a nice example IN PYTHON of
> arriving at a NaN without going through infinity. I think Julia is right
> and Python is wrong about '0/0', but as things are, that's not an example.
I wouldn't
On Sun, Jul 05, 2020 at 11:58:58AM -0700, Bruce Leban wrote:
> > People who want NAN poisoning can opt-in by doing a check for NANs
> > themselves, either in a wrapper function, or by testing the bounds
> > *once* ahead of time and then just calling the stdlib `clamp` once they
> > know they
Sorry, that got sent too soon.
On Sun, Jul 5, 2020 at 1:59 PM Christopher Barker
wrote:
> On Sun, Jul 5, 2020 at 6:15 AM MRAB wrote:
>
>> > clamp(value: Number, minimum: Union[Number, Iterable[Number]], maximum:
>> Union[Number, Iterable[Number]])
>> >
>
> What would that return? What if the
On 2020-07-05 14:06, MRAB wrote:
On 2020-07-05 10:09, Federico Salerno wrote:
[snip]
FInally, I'd like to lit another fire: given that `min()` and `max()`
accept an arbitrary amount of arguments, and that the signature that
seems to be preferred for the hypothetical clamp at the moment sees
On 05/07/2020 10:09, Federico Salerno wrote:
On the topic of NaNs: I think in the face of ambiguity, we should
refuse the temptation to guess and raise ValueError when the values
given are not comparable to the point of clearly determining whether
`value` is or isn't within `minimum` and
On Sun, Jul 5, 2020, 3:51 PM Chris Angelico wrote:
> On Mon, Jul 6, 2020 at 2:15 AM David Mertz wrote:
> >
> > This is a digression, but does anyone have a nice example IN PYTHON of
> arriving at a NaN without going through infinity. I think Julia is right
> and Python is wrong about '0/0', but
On Sun, Jul 5, 2020 at 6:15 AM MRAB wrote:
> > clamp(value: Number, minimum: Union[Number, Iterable[Number]], maximum:
> Union[Number, Iterable[Number]])
> >
Ss (
IsA
Zzz
What would that return? What if the iterable were two different
lengths?
If anything, I would accept an iterable for
On Mon, Jul 6, 2020 at 2:15 AM David Mertz wrote:
>
> This is a digression, but does anyone have a nice example IN PYTHON of
> arriving at a NaN without going through infinity. I think Julia is right and
> Python is wrong about '0/0', but as things are, that's not an example.
>
Not sure why
On Sun, Jul 5, 2020 at 8:57 AM Steven D'Aprano wrote:
>
> In the absense of any clear winner, my position is that NAN poisoning
> should be opt-in. We should pick the option which inconveniences people
> who want the other the least .
>
> Let's say the stdlib uses Option 1. The function doesn't
On 05/07/2020 16:15, Steven D'Aprano wrote:
Perhaps you should reconsider your expectations there. They do different
things because they are different functions with different signatures
and different purposes. It isn't even necessary to use min and max in
the implementation of clamp, in fact it
Your original proposal appears to want this behavior:
class BaseException:
def __call__(self):
raise self
That could be expanded to something like:
class BaseException:
def __call__(self, *args):
if not args:
raise self
if len(args) > 1:
This is a digression, but does anyone have a nice example IN PYTHON of
arriving at a NaN without going through infinity. I think Julia is right
and Python is wrong about '0/0', but as things are, that's not an example.
On Sun, Jul 5, 2020, 12:05 PM Chris Angelico wrote:
> On Mon, Jul 6, 2020 at
On 2020-07-05 12:58 p.m., MRAB wrote:
On 2020-07-05 14:10, Soni L. wrote:
On 2020-07-05 10:03 a.m., MRAB wrote:
On 2020-07-05 13:39, Soni L. wrote:
1. saves keywords and 2. can be passed as callables.
since there's no lambda: raise, 2 is a new feature.
How would you re-raise an
On Mon, Jul 6, 2020 at 1:58 AM Steven D'Aprano wrote:
> Python makes it quite hard to get a NAN from the builtins, but other
> languuages do not. Here's Julia:
>
> julia> 0/0
> NaN
>
> So there's at least one NAN which means *there is no correct answer*.
>>> 1e1000-1e1000
nan
ChrisA
On 2020-07-05 15:15, Steven D'Aprano wrote:
[snip]
The only differences I can see are that my implementation of clamp()
supports None as a short-hand for infinity; and that it treats NANs
according to the standard, unlike the builtin min and max, which manage
to provide the worst of both
On 2020-07-05 14:10, Soni L. wrote:
On 2020-07-05 10:03 a.m., MRAB wrote:
On 2020-07-05 13:39, Soni L. wrote:
1. saves keywords and 2. can be passed as callables.
since there's no lambda: raise, 2 is a new feature.
How would you re-raise an exception?
just call it.
Wouldn't that just
On Sat, Jul 04, 2020 at 09:11:34AM -0700, Ben Rudiak-Gould wrote:
Quoting William Kahan, one of the people who designed IEEE-754 and NANs:
> What he says there (on page 9) is
>
> >Some familiar functions have yet to be defined for NaN . For instance
> >max{x, y} should deliver the same result
Steven D'Aprano writes:
> Regarding your observation that dict views behave poorly if they
> have unhashable values, I agree, it is both odd and makes them less
> useful. Possibly at some point between the PEP and the release of
> the feature something changed, or perhaps it's just an
2qdxy4rzwzuui...@potatochowder.com writes:
> On 2020-07-05 at 12:18:54 +0900,
> "Stephen J. Turnbull" wrote:
>
> > Which suggests the question: Is there a commonly used equivalent for
> > complex numbers?
>
> How would that work? Complex numbers are unordered, but I suspect that
> you
On Sat, Jul 04, 2020 at 01:01:15AM +0100, MRAB wrote:
> Should it raise an exception if minimum > maximum?
I think there are only two reasonable answers to this:
- raise an exception if the lower bounds is greater than the
upper bounds ("errors should never pass silently");
- or Do What I
On Sat, Jul 04, 2020 at 10:16:45AM +0200, Federico Salerno wrote:
> Yes, I'd expect ValueError if min > max or max < min.
Is there a difference between those two conditions? *wink*
> On 04/07/2020 02:03, Steven D'Aprano wrote:
> >Bottom line is that passing a NAN as the lower or upper bound
On Sun, Jul 05, 2020 at 10:10:01AM -0300, Soni L. wrote:
> >What would be the replacement for:
> >
> > raise ex from None
> >
> >and so forth?
>
> no idea. just don't use that anymore?
So your plan is to make Python less useful, less powerful, and be unable
to do things that it can do now?
On 2020-07-05 10:03 a.m., MRAB wrote:
On 2020-07-05 13:39, Soni L. wrote:
1. saves keywords and 2. can be passed as callables.
since there's no lambda: raise, 2 is a new feature.
How would you re-raise an exception?
just call it.
What would be the replacement for:
raise ex from
On 2020-07-05 10:09, Federico Salerno wrote:
[snip]
FInally, I'd like to lit another fire: given that `min()` and `max()`
accept an arbitrary amount of arguments, and that the signature that
seems to be preferred for the hypothetical clamp at the moment sees
`value` as the first positional
On 2020-07-05 13:39, Soni L. wrote:
1. saves keywords and 2. can be passed as callables.
since there's no lambda: raise, 2 is a new feature.
How would you re-raise an exception?
What would be the replacement for:
raise ex from None
and so forth?
I prefer the clarity of knowing that
On Sun, Jul 5, 2020 at 2:36 PM Federico Salerno
wrote:
> On the topic of NaNs: I think in the face of ambiguity, we should refuse
> the temptation to guess and raise ValueError when the values given are not
> comparable to the point of clearly determining whether `value` is or isn't
> within
1. saves keywords and 2. can be passed as callables.
since there's no lambda: raise, 2 is a new feature.
On 2020-07-05 1:15 a.m., Steven D'Aprano wrote:
On Sun, Jul 05, 2020 at 12:48:08AM -0300, Soni L. wrote:
> ValueError()() should be the same as raise ValueError() but with an
> extra call
On the topic of NaNs: I think in the face of ambiguity, we should refuse
the temptation to guess and raise ValueError when the values given are
not comparable to the point of clearly determining whether `value` is or
isn't within `minimum` and `maximum` or which of the two bounds it
exceeds.
On 05/07/2020 05:39, Steven D'Aprano wrote:
On Sun, Jul 05, 2020 at 12:18:54PM +0900, Stephen J. Turnbull wrote:
> and I'd like to toss a possible `coerce`
Here my issue is that for me the *target* of a coercion should be a
"single thing", which could be a type, but might also be a scalar.
On Wed, Jul 1, 2020 at 8:37 AM Stestagg wrote:
> 1. ordered collections that have some set-like operators added for
> convenience, (conceptually, if not exactly, class ...(Set, Sequence):) but
> are missing a single method full Sequence interface (__getitem__)
> or
> 2. Sets that happen to
On Sun, Jul 05, 2020 at 06:35:38PM +1200, Greg Ewing wrote:
> All in all, I think "clamp" is the best term for this.
+1
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
On 5/07/20 4:39 pm, Steven D'Aprano wrote:
Complex numbers represent points on a plane; it is very common in
graphical toolkits to need to clamp an object to within some window or
other region of the plane,
But graphical toolkits don't treat points as complex numbers.
The question is whether
46 matches
Mail list logo
