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
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
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 kind
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
h
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
> glanc
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:
>
>
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 re
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
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 gra
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 cre
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: subclas
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
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
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 othe
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 var
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
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, th
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
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 = ite
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,
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
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
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, sin
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
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 f
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:
> > min
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
-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
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.py
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."
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
___
Pyth
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
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 th
33 matches
Mail list logo
