[Python-ideas] Re: Add builtin function for min(max())
On Sun, Jul 05, 2020 at 12:18:54PM +0900, Stephen J. Turnbull wrote: > The problem with making this a builtin is that I don't think that > "clamp" is an unlikely identifier. Doesn't matter -- we can shadow builtins, it's just a name, not a keyword. Lots of code in the wild uses str, len, id, chr, etc as variable names. I think more importantly, clamp is not important enough to be a builtin. But I wouldn't object to it being builtin if others think it is (and you can convince the Steering Council). > Which suggests the question: Is there a commonly used equivalent for > complex numbers? Naturally :-) 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, so that you don't (e.g.) drag your object outside of the document, or position it somewhere off screen where it is impossible for the user to click on. (There was, or is, an annoying bug in OpenOffice that would occasionally reposition the coordinates of objects to some ludicrous position way off screen where they couldn't be reached.) Now admittedly screen and window coordinates are generally integer values, but the concept applies to floating point coordinates too: if you have a need to clamp a point to within a rectangular region, applying clamp() to the real and imaginary components will do the job. > > 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. It > is true that type theorists consider x in Reals and y in [0,1] to be > different types, so "y = coerce(x) # to unit interval" could match > that concept, but somehow that doesn't work for me. That may just be > me, the majority of native speakers may disagree. No, I agree. In computing, coerce nearly always means to coerce to a type, not to coerce to some range of values. There are two standard terms for this function: clamp and clip, depending on whether you view the operation as squashing the value into a range or cutting off the bits that don't fit. I prefer clamp but could live with clip. -- Steven ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FJWV2UETOBRSDUT7NI3WSJB6GDOOTOPZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
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 know that. Dan ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NPZYIKVZLMXDTMK5335EOV4EZ3UNYNX5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: exception instance call should raise exception
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 level. > > and raise should be deprecated. Proposals that are given without justification should be rejected without justification: "No they shouldn't." If you feel like giving reasons for these changes other than "because I, Soni, say so", then I will consider the merits of those reasons before agreeing or disagreeing with the proposal. -- Steven ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HVPWMQYT3KZ6QNJMRBYYOTTY7VJ4IDIL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] exception instance call should raise exception
ValueError()() should be the same as raise ValueError() but with an extra call level. and raise should be deprecated. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3CY2XFVWPQBD7F7EGOGOSNJDKL5GOSMX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Else assert statement
-1. Assertions are ignored when Python is run with -O, so we definitely
don't want to encourage relying on asserts to ensure users pass the correct
value. But even if that wasn't an issue, I consider the `else:
ValueError()` to be significantly more readable.
Otherwise, the alternative offered by Steve Barnes of using a dict for the
input options works well when you have a large number of possible inputs
with entirely different behaviors. Although I'd say for anything with
around 5 or less options, the `else: ValueError()` makes more sense for its
simplicity.
On Thu, Jul 2, 2020 at 7:43 PM Artemis wrote:
> Often, I know that a variable should have one of a set of values, and I
> want to determine which one, with an if/elif/else clause. This looks
> something like this:
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> elif foo == 3:
> # do c
> else:
> raise ValueError('foo must be 1, 2 or 3')
> ```
> Sometimes, I just do
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> else:
> # do c
> ```
> But this is less readable and allows errors to slip past. My proposal is
> to allow the following syntax:
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> else foo == 3:
> # do c
> ```
> Or perhaps the more readable version:
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> else assert foo == 3:
> # do c
> ```
> Both of these options are backward compatible, since currently nothing is
> allowed between the `else` and the `:`.
> This would be roughly equivalent to
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> else:
> assert foo == 3
> # do c
> ```
> But shorter and more readable, since it puts the assertion at the same
> levels as the others. Thoughts?
> ___
> 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 archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZKAQK7YTOR2GVVFZFVO3U22WYJHVC3KE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3DFZ24QV36BG644KGTQZWPFNYDK7CJRO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
Federico Salerno writes: > I feel clip fits best with the idea of a collection to... clip. True, but you can (for this purpose) think of a scalar as a singleton. Still, I think "clamp" is by far the best of the bunch (though I don't see a need for this function in the stdlib, and definitely not a builtin). The problem with making this a builtin is that I don't think that "clamp" is an unlikely identifier. In particular, I guess clamping the volume of a track in audio processing is a common operation. "clip" is much worse, as it's used in all of audio, image, and video processing, and I can imagine it as a place for keeping deleted or copied objects. math.clamp wouldn't be totally objectionable. Which suggests the question: Is there a commonly used equivalent for complex numbers? > As far as other options go, I agree with Mr D'Aprano's objection to > `minmax`, Definitely out. > 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. It is true that type theorists consider x in Reals and y in [0,1] to be different types, so "y = coerce(x) # to unit interval" could match that concept, but somehow that doesn't work for me. That may just be me, the majority of native speakers may disagree. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7AWYMMZSTP7IE7PCO3MNZVWYRG6Y4NN6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On Sat, Jul 4, 2020, at 15:57, 2qdxy4rzwzuui...@potatochowder.com wrote:
> > Simplifying the signature, in Python we have:
> >
> > def min(*iterable):
> > iterator = iter(iterable)
> > minimum = next(iterable)
> > for item in iterator:
> > if item < minimum:
> > minimum = item
> > return minimum
> >
> > Due to this, min(0, float('nan')) == 0 and same for max. I would hence
> > expect clamp to behave similarly.
>
> Yuck: We also have min(float('nan'), 0) == float('nan').
>
> I'm not sure what I'd expect a hypothetical clamp function to do.
> Someone with actual use cases will have more insight.
IEEE 754-2019 defines minimum and maximum functions that return NaN in all
cases, and apply a strict ordering to signed zero... however, there is also a
minimumNumber and maximumNumber which returns the number if the other operand
is NaN [the asymmetric behavior depending on the order of the operands isn't
allowed by either]
it might be worthwhile to define a "min2" etc that applies the rules for one of
these functions when both arguments are floats [and possibly when one argument
is a float and the other is any numeric type], and then define min(*iterable)
as:
def min(*iterable):
iterator = iter(iterable)
minimum = next(iterable)
for item in iterator:
minimum = min2(minimum, item)
return minimum
I can't find anything about a clamp-like function in IEEE.
It may be worth surveying what other implementations do... to start with:
- Rust has a clamp function that returns NaN if the given number is NaN, and
"panics" if either boundary is NaN.
- Numpy's clip function effectively accepts NaN or None boundaries as "don't
care"
- - This appears to be implemented as min(max(x, a), b), with min and max
themselves having the asymmetric behavior.
- C++'s clamp function seems to be undefined if any of the operands are NaN
- - T must meet the requirements of LessThanComparable in order to use
overloads (1).
- - However, if NaNs are avoided, T can a be floating-point type.
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/HUJFXYVWWZRNQVM7SAJY2MS3TFFC5P3Y/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
On Sat, Jul 4, 2020, at 14:27, William Pickard wrote: > There is only 2 ways an extension is distributed to people in the > Python universe: > As a SOURCE CODE distribution OR a COMPILED BINARY distribution. > > Wheels are generally the "compiled" distribution, these are also > generally built for a specific runtime + python version. > For Python 3.10 wheels, these would already be compiled against the > precompiled header. > > For source distributions, they require "building" before being > deployed, for Python 3.10, this will include the precompiled header. My point was that I still don't understand what the benefit of the precompiled header is, if extensions still have to distribute source to get the benefit of it. This is why I assumed you *didn't* think extensions would have to distribute source. So, how is it better than a normal header? If the point of an opaque PyObject isn't to allow the same compiled distribution of an extension to be used with different versions of python that have different implementations of PyObject then... well, what *is* the point? Why not just recompile normally, with the textual header? > I'm aiming at least to not increase the API overhead for when invoking > stuff like "Py_TYPE", "Py_INCREF", "Py_DECREF", etc. > Py_INCREF and Py_DECREF are the worst offenders as they are generally > HIGHLY INVOKED functions and are also the functions that are ALWAYS > INLINE OPTIMIZED away by modern compilers. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2D7UMEJBQ6IQTT7CWG6FHKX73GJBCYTS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On Sat, Jul 04, 2020 at 11:54:47AM -0700, Christopher Barker wrote:
> Hmm.
>
>
> Since NaN is neither greater than nor less that anything, it seems the only
> correct answer to any
> Min,max,clamp involving a NaN is NaN.
If you want NAN-poisoning behaviour it is easy for you to add it
yourself as a wrapper function, without it costing any more than it
would cost to have that behaviour baked into the function. You get to
choose if you want to handle floats only, or Decimals, or both, what to
do with signalling NANs, or whether to bother at all. If you know your
bounds are not NANs, why test for them at all?
But if you bake special NAN poisoning behaviour in to the function,
nobody can escape it. Everyone has to test for NANs, whether they need
to or not, and worse, if they want non-poisoned behaviour, they have to
test for NANs *twice*, once to over-ride the builtin behaviour, and then
a second time when they call the function.
When we have a choice of behaviours and no absolutely clear right or
wrong choice, we should choose the behaviour that inconveniences people
the least.
The beauty of the implementation I give is that the behaviour with NANs
follows automatically, without needing to test for them. NAN poisoning
requires testing for NANs, and that is not so easy to get right:
py> math.isnan(2**1)
Traceback (most recent call last):
File "", line 1, in
OverflowError: int too large to convert to float
py> math.isnan(Decimal('sNAN'))
Traceback (most recent call last):
File "", line 1, in
ValueError: cannot convert signaling NaN to float
You want everyone to pay the cost of testing for NANs, even if they
don't want or need to. I say, let only those who need to test for NANs
actually test for NANs.
Why is this a debate we need to have?
In practice, the most common use-case for clamp will be to call it
multiple times against different values but with the same bounds:
# Not likely to be this
for value in values:
lower = something_different_each_time()
upper = something_different_each_time()
do_something(clamp(value, lower, upper))
# Most commonly this:
for value in values:
do_something(clamp(value, lower, upper))
If you care about the remote possibility of the bounds being NANs, and
want to return NAN instead, hoist the test outside of the call:
# TODO: Need to catch OverflowError, maybe ValueError
# maybe even TypeError?
if math.isnan(lower) or math.isnan(upper):
for value in values:
do_something(NAN)
else:
for value in values:
do_something(clamp(value, lower, upper))
and you only pay the cost once. Don't make everyone pay it over and over
and over again when the bounds are known to not be NANs.
--
Steven
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/7RK5TSYDI6N4OUJ4SOSKWEYPHAPQFIFA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On 5/07/20 7:33 am, Henk-Jaap Wagenaar wrote:
min(0, float('nan')) == 0 and same for max. I would hence
expect clamp to behave similarly.
But min(float('nan'), 0) == nan.
I don't think you can conclude anything from either of
these about how clamp() *should* behave in the presence
of nans, since they're accidents of implementation.
--
Greg
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/CZG7SMEUN4DM3IKH6CCWHRTSJSJ4WLPD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?
On Sat, 4 Jul 2020 at 16:51, Serhiy Storchaka wrote: > 30.06.20 18:58, Joao S. O. Bueno пише: > > I ended up writting an __eq__ - and in the process I found it is not > > _that_ straightforward due > > to having to check subclasses types when comparing. > > (given Base sequence A, child class B(A), class C(A) and class B1(B) - > > Instances of B and B1 can be > > equal, but instances of B and C should always be different) - or in > > Python, inside __eq__ : > > if not issubclass(type(other), type(self)) and not > > issubclass(type(self), type(other)): > > return False > > It would be more correct to return NotImplemented. > > Also, it is enough to test isinstance(other, type(self)) because > other.__eq__(self) be called first if the type of other is a subclass of > the type of self. > Ah - yes. Half the logic is already on the __eq__ semantics - thanks. Well, I am updating that on my code right now. Anyway I am not seeing anyone opposing this going into col...abc.Sequence - Maybe it is ok for a BPO? (yes, there is this consideration I had, and also Guido, that it would create new behavior in classes that already exist, but I saw no way that could break code not specially crafted to break with this change.) ___ > 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 archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/K2P4ZWF6FIRPCRKUH7IHZHMC7E3HVJER/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KMG42UKBB3PCVLK6BTW6OQRJWPESLJJI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On 2020-07-04 at 20:33:36 +0100,
Regarding "[Python-ideas] Re: Add builtin function for min(max()),"
Henk-Jaap Wagenaar wrote:
> On Sat, 4 Jul 2020 at 19:58, Christopher Barker wrote:
>
> > Hmm.
> >
> >
> > Since NaN is neither greater than nor less that anything, it seems the
> > only correct answer to any
> > Min,max,clamp involving a NaN is NaN.
> >
> >
> Simplifying the signature, in Python we have:
>
> def min(*iterable):
> iterator = iter(iterable)
> minimum = next(iterable)
> for item in iterator:
> if item < minimum:
> minimum = item
> return minimum
>
> Due to this, min(0, float('nan')) == 0 and same for max. I would hence
> expect clamp to behave similarly.
Yuck: We also have min(float('nan'), 0) == float('nan').
I'm not sure what I'd expect a hypothetical clamp function to do.
Someone with actual use cases will have more insight.
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/K4STFFKEJG7RTF2UTGWI3ILZ3UVQMOPO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?
30.06.20 18:58, Joao S. O. Bueno пише: I ended up writting an __eq__ - and in the process I found it is not _that_ straightforward due to having to check subclasses types when comparing. (given Base sequence A, child class B(A), class C(A) and class B1(B) - Instances of B and B1 can be equal, but instances of B and C should always be different) - or in Python, inside __eq__ : if not issubclass(type(other), type(self)) and not issubclass(type(self), type(other)): return False It would be more correct to return NotImplemented. Also, it is enough to test isinstance(other, type(self)) because other.__eq__(self) be called first if the type of other is a subclass of the type of self. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/K2P4ZWF6FIRPCRKUH7IHZHMC7E3HVJER/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On Sat, 4 Jul 2020 at 19:58, Christopher Barker wrote:
> Hmm.
>
>
> Since NaN is neither greater than nor less that anything, it seems the
> only correct answer to any
> Min,max,clamp involving a NaN is NaN.
>
>
Simplifying the signature, in Python we have:
def min(*iterable):
iterator = iter(iterable)
minimum = next(iterable)
for item in iterator:
if item < minimum:
minimum = item
return minimum
Due to this, min(0, float('nan')) == 0 and same for max. I would hence
expect clamp to behave similarly.
As a side note, the documentation actually underspecifies as in these kind
of situations the iterable overall does not have a well-defined "minimum"
(in a mathematical sense it simply does not have one):
- how you look at the list (forward or backwards)
- how you approach the comparison (item < minimum or not(minimum <= item))
change the behaviour:
- max({0}, {0, 2}, {0, 1}, {1}) = {0, 2} v.s. {0, 1} when you reverse the
iterable
- min(0, float('nan')) = 0 v.s. float('nan') when you change the comparison
Should this be clarified/specified in the docs?
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/DS6TRZDASYQLE43LW4G74LJ3D7XBWWZW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
Hmm.
Since NaN is neither greater than nor less that anything, it seems the only
correct answer to any
Min,max,clamp involving a NaN is NaN.
-CHB
On Sat, Jul 4, 2020 at 9:15 AM Ben Rudiak-Gould wrote:
> On Fri, Jul 3, 2020 at 5:07 PM Steven D'Aprano
> wrote:
> > As I recall, there was some positive support but it ran out of steam
> > because nobody could agree on how to handle NANs even though the
> > IEEE-754 standard tells us how to handle them *wink*
> >
> > See my responses at the time re NANs here:
> >
> > https://mail.python.org/pipermail/python-ideas/2016-August/041439.html
> >
> > https://mail.python.org/pipermail/python-ideas/2016-August/041400.html
> >
> > https://mail.python.org/pipermail/python-ideas/2016-August/041396.html
> >
> > Bottom line is that passing a NAN as the lower or upper bound should
> > treat it as equivalent to "unbounded", that is, equivalent to ±∞.
>
> That's not what the standard says. It's sorta connected to a personal
> opinion of Kahan's expressed in some work-in-progress lecture notes
> that you linked in the last message:
>
> https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
>
> 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 as max{y, x} but almost no
> implementations do that when x is NaN . There are good reasons to define
> max{NaN, 5} := max{5, NaN} := 5 though many would disagree.
>
> It's clear that he's not referring to standard behavior here and I'm
> not convinced that even he believes very strongly that min and max
> should behave that way.
>
> NaN means "there may be a correct answer but I don't know what it is."
> For example, evaluating (x**2+3*x+1)/(x+2) at x = -2 yields NaN. The
> correct answer to the problem that yielded this formula is probably
> -1, but because of the way floating point hardware works, it has no
> way of figuring that out. Likewise, the final result of a computation
> involving the square root of a negative real may be well defined, and
> may even be real, but the hardware can't compute it, so it "computes"
> NaN instead.
>
> It's definitely true that if plugging in any finite or infinite number
> whatsoever in place of a NaN will yield the same result, then that
> should be the result when you plug in a NaN. For example, clamp(x,
> NaN, x) should be x for every x (even NaN), and clamp(y, NaN, x) where
> y > x should be a ValueError (or however invalid bounds are treated).
>
> But, e.g., clamp(m, x, M) where m < x could yield any value between m
> and x, or a ValueError, depending on the value of M. So, if M is NaN,
> there is no way to know what the correct answer should be. Therefore
> (in my opinion) it should return NaN.
>
> There's a case for making clamp(m, x, NaN) where m >= x return m
> rather than NaN since there's no other *value* it could be (it could
> be an exception though).
> ___
> 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 archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/PHH7EYAWJBKJCCMPU4KCROKDC3BYACWD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KWA5SDRF7DQIXVNM2V5Z5YFRVWVEHNYJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
There is only 2 ways an extension is distributed to people in the Python universe: As a SOURCE CODE distribution OR a COMPILED BINARY distribution. Wheels are generally the "compiled" distribution, these are also generally built for a specific runtime + python version. For Python 3.10 wheels, these would already be compiled against the precompiled header. For source distributions, they require "building" before being deployed, for Python 3.10, this will include the precompiled header. I'm aiming at least to not increase the API overhead for when invoking stuff like "Py_TYPE", "Py_INCREF", "Py_DECREF", etc. Py_INCREF and Py_DECREF are the worst offenders as they are generally HIGHLY INVOKED functions and are also the functions that are ALWAYS INLINE OPTIMIZED away by modern compilers. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UZ4ASVDVZYPTYBS2ZUIVQDHIWCB5FGVX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
My understanding of how tp_bases/tp_base is utilized is that it takes the best type object to fill tp_base. But thinking about it now, another issue about offsets that is derived from CPython as it stands. C based types + objects aren't inheritance friendly as it stands, more specifically, they're only really usable as the LAST base type in a base tuple, this offset system can be redone to make it more friendly, but as it stands, it mimics the existing behaviour fluently. The one-way conversion is only if you discard the initial "PyObject *" stack variable as it contains the runtime type of the object. This is a problem for if the runtime type is not the C based type object BUT a PEP accepted for Python 3.9 lays the framework that solves this issue. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LUVVHOVSSTBSQUB24H7COH3ZWV23KO65/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
On Sat, Jul 4, 2020, at 13:22, William Pickard wrote: > Oh and the other question: > > Yes, a conversion function will be required to utilize the value of the > offset member, the conversion is sadly a one way affair BUT CPython's C > API is handy enough that a sacrificial 'PyObject *' stack variable can > exist, most compilers may end up just optimizing the variable away > anyhow. hmm... If only single inheritance is still allowed, there's no reason you couldn't support the other direction by subtracting the offset. Supporting multiple inheritance [of two different base classes that both define structures, anyway - something that's not currently allowed in cpython, but might be interesting to add support for] would require knowing the runtime type of the object, but I don't think your code is currently doing anything to support that case. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RNLTR3A6GVZIOM7JJM7FLXJ3TK4OVLJW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
On Sat, Jul 4, 2020, at 13:19, William Pickard wrote:
> A precompiled header is a combination of a plain header with a
> companion special file (.pch/.gch).
> The companion file is generated from a source file that is designated
> as the Precompiled Header creator ('/Yc' on MSVC).
>
> Every other source file is told to use the special file ('/Yu' on
> MSVC), the source file compilation will fail if the special file is
> missing.
>
> CPython/third party runtimes will only need to ship this special file
> with the compiled code, the only downside is a burden of checking the
> checksum of the file before it's used in a compile process.
But this file can only be used *with the source code* of extension libraries,
so shipping this file isn't any better than shipping an ordinary text-based
header file (which is, obviously, already done).
You seem to believe that the pch/gch file can be used somehow to adapt
already-compiled extension libraries to each implementation. I do not think
this is true at all, certainly it doesn't seem to be implied by anything in the
documentation at https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html .
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZSEWKVKR2AIMWQM3TL33NF4NRUJRXLFP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
Oh and the other question: Yes, a conversion function will be required to utilize the value of the offset member, the conversion is sadly a one way affair BUT CPython's C API is handy enough that a sacrificial 'PyObject *' stack variable can exist, most compilers may end up just optimizing the variable away anyhow. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OABYGETW3SKI3MJQEYF22EDJ4HEYYV2G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?
On Sat, Jul 4, 2020, at 12:30, Joao S. O. Bueno wrote: > As far as types are concerned, the `__eq__` should worry about it - > just Sequences that are > a subtype of other, or the other being a subtype of one, should be able > to compare equal > (As happens with lists and tuples as well: subclasses of both will > compare equal to base lists and tuples > with the same content.). As will two different subclasses of list. Should we try to replicate this behavior as well (i.e. determine the the "base sequence type" somehow, so that two subclasses of the same one can be compared and others cannot)? This is something that we have to get right the first time; equality comparisons can't be made more permissive later since they simply return False rather than being an error... otherwise I might be advocating to "fix" list and tuple. > The code for that is on my first reply to Guido, above: > if not issubclass(type(other), type(self)) and not > issubclass(type(self), type(other)): > return False > > I am actually using that on the file that motivated me sending the > first e-mail here -as it > makes sense in that project. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IICSIZM4ASSEGNMZW6D56HN4YKIPVSPM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
A precompiled header is a combination of a plain header with a companion
special file (.pch/.gch).
The companion file is generated from a source file that is designated as the
Precompiled Header creator ('/Yc' on MSVC).
Every other source file is told to use the special file ('/Yu' on MSVC), the
source file compilation will fail if the special file is missing.
CPython/third party runtimes will only need to ship this special file with the
compiled code, the only downside is a burden of checking the checksum of the
file before it's used in a compile process.
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BUTGSQ5K6QU57LOXTK3SD2MLTHS4SNEF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
On Sat, Jul 4, 2020, at 12:48, William Pickard wrote: > For backwards compatibility, PyTypeObject will eventually have the > flag: Py_TPFLAG_OMIT_PYOBJECT_SIZE, but from what I can tell, > eventually all extensions should be using PyType_FromSpec/it's variants. Er... I don't mean how do they create the PyType. I mean how do they create the actual data type they use? https://docs.python.org/3/extending/newtypes_tutorial.html#adding-data-and-methods-to-the-basic-example What does the definition of CustomObject look like? How do I access the "number" member, given a PyObject *? Can I still cast the PyObject * to CustomObject *, or do I have to go through some conversion function? > I'm now leaning towards replacing the Static Library with a precompiled > header (Those will not users from building DLLs as they're just a plain > headers compiled to machine code used differently from obj files, I > BELIEVE at least, haven't tested inlinability yet). My understanding is that you can't combine the precompiled header with a dll or even obj file, you have to combine it with source code, which means requiring a precompiled header prevents extension libraries from being shipped as binaries. Requiring modules to be rebuilt from source code to support any changed definition of PyObject, as far as I can tell, defeats the entire purpose of making it opaque. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LDJEKJ2F4W6GLT623R27NIPGI5AZYQNL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
For backwards compatibility, PyTypeObject will eventually have the flag: Py_TPFLAG_OMIT_PYOBJECT_SIZE, but from what I can tell, eventually all extensions should be using PyType_FromSpec/it's variants. the members I added are internal use only with external public API for extension users to grab their type's data structure (example: PyTupleObject for tuples') as well a properly allocation memory to the type. PyTypeObject.tp_obj_size is a member that holds the total size of the type's object structure (includes the size of it's immediate base type's structure), this will allow Python to properly allocate the correct amount of memory to contain the data. PyTypeObject.to_obj_offset is a member that holds the offset from the 'PyObject *' pointer to that type's internal data structure. A Python PEP has added the term "defining class" for C types that can make utilizing this member simpler, but it's scope will need to be expanded to include all possible C method definitions (It currently only supports fastcall). I am planning on replacing the two members with a private struct called "struct _type_memdata" to simplify readability of code using the members. I'm now leaning towards replacing the Static Library with a precompiled header (Those will not users from building DLLs as they're just a plain headers compiled to machine code used differently from obj files, I BELIEVE at least, haven't tested inlinability yet). ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PFWGH6FXGG3LAFCQTFFKPRB7SFNFVWFC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
On Sat, Jul 4, 2020, at 11:59, William Pickard wrote: > CPython PR #21262, GitHub username is Wildcard65. ok looking at that code, I'm not sure I understand how it addresses the PyObject_HEAD thing, unless there's something I'm not seeing I'll ask directly - how would an extension library define a type, and how would it access its own data at the end of objects of that type? I'm also skeptical that a static library would provide any savings vs treating the functions like every other function in the api... a precompiled header might, but while I don't fully understand how precompiled headers are used, I don't *think* it would allow extension libraries to ship as a dll/so file as they currently can. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NJNKZ4473AHEUD52YZ7Y5DAFJS7TOXVL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?
On Sat, 4 Jul 2020 at 12:51, Random832 wrote: > On Fri, Jul 3, 2020, at 03:57, Wes Turner wrote: > > Can a Sequence be infinite? If so, an equality test of two > > nonterminating sequences would be a nonterminating operation. > > I think not - an infinite sequence would make len, contains, and reversed > ill-defined (it also wouldn't allow certain kinds of slices) > > > Do Sized and *Reversible* imply that a sequence terminates? > > Could __len__ return inf? > > __len__ must return an integer. > > > Perhaps `Ordered` is a requisite condition for defining a comparator > > for Sequences. > > `OrderedSequence`? > > > > Are there unordered Sequences for which a default `__eq__` / `__cmp__` > > (et. al) would be wrong or inappropriate? > > I don't think so [index as a mixin implies being ordered, i think]... the > bigger problem is the one I mentioned earlier, that allowing comparison > between sequences of different types is inconsistent with tuple and list. > As far as types are concerned, the `__eq__` should worry about it - just Sequences that are a subtype of other, or the other being a subtype of one, should be able to compare equal (As happens with lists and tuples as well: subclasses of both will compare equal to base lists and tuples with the same content.). The code for that is on my first reply to Guido, above: if not issubclass(type(other), type(self)) and not issubclass(type(self), type(other)): return False I am actually using that on the file that motivated me sending the first e-mail here -as it makes sense in that project. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IVQHP3XAHTNCVAOJQ3BCYXCZU5ZJS4QK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On Fri, Jul 3, 2020 at 5:07 PM Steven D'Aprano wrote:
> As I recall, there was some positive support but it ran out of steam
> because nobody could agree on how to handle NANs even though the
> IEEE-754 standard tells us how to handle them *wink*
>
> See my responses at the time re NANs here:
>
> https://mail.python.org/pipermail/python-ideas/2016-August/041439.html
>
> https://mail.python.org/pipermail/python-ideas/2016-August/041400.html
>
> https://mail.python.org/pipermail/python-ideas/2016-August/041396.html
>
> Bottom line is that passing a NAN as the lower or upper bound should
> treat it as equivalent to "unbounded", that is, equivalent to ±∞.
That's not what the standard says. It's sorta connected to a personal
opinion of Kahan's expressed in some work-in-progress lecture notes
that you linked in the last message:
https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
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 as max{y, x} but almost no implementations
>do that when x is NaN . There are good reasons to define max{NaN, 5} := max{5,
>NaN} := 5 though many would disagree.
It's clear that he's not referring to standard behavior here and I'm
not convinced that even he believes very strongly that min and max
should behave that way.
NaN means "there may be a correct answer but I don't know what it is."
For example, evaluating (x**2+3*x+1)/(x+2) at x = -2 yields NaN. The
correct answer to the problem that yielded this formula is probably
-1, but because of the way floating point hardware works, it has no
way of figuring that out. Likewise, the final result of a computation
involving the square root of a negative real may be well defined, and
may even be real, but the hardware can't compute it, so it "computes"
NaN instead.
It's definitely true that if plugging in any finite or infinite number
whatsoever in place of a NaN will yield the same result, then that
should be the result when you plug in a NaN. For example, clamp(x,
NaN, x) should be x for every x (even NaN), and clamp(y, NaN, x) where
y > x should be a ValueError (or however invalid bounds are treated).
But, e.g., clamp(m, x, M) where m < x could yield any value between m
and x, or a ValueError, depending on the value of M. So, if M is NaN,
there is no way to know what the correct answer should be. Therefore
(in my opinion) it should return NaN.
There's a case for making clamp(m, x, NaN) where m >= x return m
rather than NaN since there's no other *value* it could be (it could
be an exception though).
___
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 archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PHH7EYAWJBKJCCMPU4KCROKDC3BYACWD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On Sat, Jul 4, 2020 at 8:29 AM Federico Salerno wrote: > On 04/07/2020 02:50, Christopher Barker wrote: > > FWIW, numpy calls it "clip" > > I feel clip fits best with the idea of a collection to... clip. `clamp()` > would work with scalars, for which the word clip might not be clear at a > glance. While I have no strong feelings in favour of clamp, I do think it > would be better than clip (but maybe it's just my experience with CSS > speaking). As far as other options go, I agree with Mr D'Aprano's objection > to `minmax`, and I'd like to toss a possible `coerce` (similarly used in > Kotlin) into the hat. Maybe someone has better names in mind? I'm going to back `clamp()` as that's what it's commonly referred to in game dev circles. It's one of those functions that everyone in game dev either memorizes the max(min()) pattern, writes their own, or is blessed with a framework that provides it. I agree with Dan that if I saw `coerce` I'd assume type coercion. One benefit to `minmax` is that for those who have a good autocomplete, it'll come up with either version of the `min(max())` pattern and suggest a better usage if that's what they're after. Largely, I think discoverability is a design constraint worth considering, and clamp and minmax both have benefits in that regard. (clamp being a common name for the scalar operation, and minmax for search similarity to the existing functions.) Piper Thunstrom My public key is available at https://keybase.io/pathunstrom Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/STFLRLIB7ULXNXLB2MI6JESOFUR3NYWV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Best approach for opaque PyObject
CPython PR #21262, GitHub username is Wildcard65. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Q2YHDFTKHEPJ4M5WL7BDHHAWTVKPQJ3M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?
On Fri, Jul 3, 2020, at 03:57, Wes Turner wrote: > Can a Sequence be infinite? If so, an equality test of two > nonterminating sequences would be a nonterminating operation. I think not - an infinite sequence would make len, contains, and reversed ill-defined (it also wouldn't allow certain kinds of slices) > Do Sized and *Reversible* imply that a sequence terminates? > Could __len__ return inf? __len__ must return an integer. > Perhaps `Ordered` is a requisite condition for defining a comparator > for Sequences. > `OrderedSequence`? > > Are there unordered Sequences for which a default `__eq__` / `__cmp__` > (et. al) would be wrong or inappropriate? I don't think so [index as a mixin implies being ordered, i think]... the bigger problem is the one I mentioned earlier, that allowing comparison between sequences of different types is inconsistent with tuple and list. ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LMR7PSLJHSYQFMMWEAW337G3YBXC437U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On Saturday, July 4, 2020, at 03:16 -0500, Federico Salerno wrote: On 04/07/2020 02:50, Christopher Barker wrote: FWIW, numpy calls it "clip" I feel clip fits best with the idea of a collection to... clip. `clamp()` would work with scalars, for which the word clip might not be clear at a glance. While I have no strong feelings in favour of clamp, I do think it would be better than clip (but maybe it's just my experience with CSS speaking). As far as other options go, I agree with Mr D'Aprano's objection to `minmax`, and I'd like to toss a possible `coerce` (similarly used in Kotlin) into the hat. Maybe someone has better names in mind? Coerce makes me think of types¹ rather than values. YMMV. ¹ https://en.wikipedia.org/wiki/Type_conversion -- “Whoever undertakes to set himself up as a judge of Truth and Knowledge is shipwrecked by the laughter of the gods.” – Albert Einstein Dan Sommers, http://www.tombstonezero.net/dan ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IEOUDGICPLMF5B374A3ITUKSRAIKBE62/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On 04/07/2020 02:01, MRAB wrote: Should it raise an exception if minimum > maximum? If it doesn't, then you'll get a different answer depending on whether it's `min(max(value, minimum), maximum)` or `max(min(value, maximum), minimum)`. Yes, I'd expect ValueError if min > max or max < min. On 04/07/2020 02:03, Steven D'Aprano wrote: Bottom line is that passing a NAN as the lower or upper bound should treat it as equivalent to "unbounded", that is, equivalent to ±∞. The beauty of that is that it can be implemented without explicitly testing for NANs, which involves unnecessary conversions to float, and may even raise an exception. Here is the version I use: ... Features: * uses None as a convenient alias for unbounded; * treats NANs according to the standard; * requires no explicit conversion to float or testing for NANs; * so this will work with Fractions and Decimals. I'm not opposed to this but wouldn't the programmer expect it to behave much like a shorthand of the existing min() + max()? Should these two then be modified to exhibit the same behaviour? I'd find it inconsistent if clamp() did but min() and max() didn't. On 04/07/2020 02:50, Christopher Barker wrote: FWIW, numpy calls it "clip" I feel clip fits best with the idea of a collection to... clip. `clamp()` would work with scalars, for which the word clip might not be clear at a glance. While I have no strong feelings in favour of clamp, I do think it would be better than clip (but maybe it's just my experience with CSS speaking). As far as other options go, I agree with Mr D'Aprano's objection to `minmax`, and I'd like to toss a possible `coerce` (similarly used in Kotlin) into the hat. Maybe someone has better names in mind? ___ 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 archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DE64IZNX7OZGNRX6YLFDHBPYO6CBBIGB/ Code of Conduct: http://python.org/psf/codeofconduct/
