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 -- [email protected]
To unsubscribe send an email to [email protected]
ht
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 hav
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 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. It
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 l
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 `min
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 it'
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 argu
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 No
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? S
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 sho
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 Me
[email protected] 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 k
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 oversigh
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 a
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 c
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 possible
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 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 exceptio
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
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:
Ty
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
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 n
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 "wi
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 value
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 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 `max
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
`v
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 it
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 aren'
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 e
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 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 <
[email protected]> wrote:
> Christopher Barker writes:
>
> > I am really confused here -- I'm sugg
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 ever
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 abou
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
> must
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 infinit
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 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 t
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 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, the
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 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) bu
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. M
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 > wrote:
45 matches
Mail list logo
