On Sun, Oct 30, 2016 at 06:26:13AM -0700, David Mertz wrote:
> NaN's *usually* propagate. The NaN domain isn't actually closed under IEEE
> 754.
[...]
> >>> min(1, nan)
> 1
>
> The last one isn't really mandated by IEEE 754, and is weird when you
> consider `min(nan, 1)`.
Python's min() and ma
On Sat, Oct 29, 2016 at 11:44 PM, Stephan Hoyer wrote:
> I'm have more mixed fillings on testing for NaNs. NaNs propagate, so
> explicit testing is rarely needed. Also, in numerical computing we usually
> work with arrays of NaN, so operator.exists() and all this nice syntax
> would not be a subs
On Sat, Oct 29, 2016 at 3:53 AM, Steven D'Aprano
wrote:
> Hmmm. I see your point, but honestly, None *is* special. Even for
> special objects, None is even more special.
As a contributor to and user of many numerical computing libraries in
Python (e.g., NumPy, pandas, Dask, TensorFlow) I also a
On 29 October 2016 at 21:44, Steven D'Aprano wrote:
> On Fri, Oct 28, 2016 at 06:30:05PM +1000, Nick Coghlan wrote:
>
> [...]
>> 1. Do we collectively agree that "existence checking" is a useful
>> general concept that exists in software development and is distinct
>> from the concept of "truth ch
On Oct 28, 2016 3:30 AM, "Nick Coghlan" wrote:
> *snip*
>
> 1. Do we collectively agree that "existence checking" is a useful
> general concept that exists in software development and is distinct
> from the concept of "truth checking"?
I'd hope so!
> 2. Do we collectively agree that the Python e
I certainly like the concept, but I worry that use of __exists__() could
generalize it a bit beyond what you're intending in practice. It seems like
this should only check if an object exists, and that adding the magic
method would only lead to confusion.
-Ryan Birmingham
On 28 October 2016 at 0
On Fri, Oct 28, 2016 at 06:30:05PM +1000, Nick Coghlan wrote:
[...]
> 1. Do we collectively agree that "existence checking" is a useful
> general concept that exists in software development and is distinct
> from the concept of "truth checking"?
Not speaking for "we", only for myself: of course.
On Sat, Oct 29, 2016 at 02:52:42PM +1000, Nick Coghlan wrote:
> On 29 October 2016 at 04:08, Mark Dickinson wrote:
> > On Fri, Oct 28, 2016 at 9:30 AM, Nick Coghlan wrote:
> >> [...] the current practicises of:
> >>
> >> * obj is not None (many different use cases)
> >> * obj is not Ellipsis (in
On Sat, Oct 29, 2016 at 03:03:22PM +1000, Nick Coghlan wrote:
> On 29 October 2016 at 01:46, Ryan Gonzalez wrote:
> > On Oct 28, 2016 3:30 AM, "Nick Coghlan" wrote:
> >> *snip*
> >> 4. Do we collectively agree that "?then" and "?else" would be
> >> reasonable spellings for such operators?
> >
> >
On 29 October 2016 at 07:21, Nick Coghlan wrote:
> A short-circuiting if-else protocol for arbitrary "THEN if COND else
> ELSE" expressions could then look like this:
>
> _condition = COND
> if _condition:
> _then = THEN
> if hasattr(_condition, "__then__"):
> r
On 29 October 2016 at 14:52, Nick Coghlan wrote:
> And that reflects the problem Paul and David highlighted: in any
> *specific* context, there's typically either only one sentinel we want
> to either propagate or else replace with a calculated value, or else
> we want to handle different sentinel
On 29 October 2016 at 01:46, Ryan Gonzalez wrote:
> On Oct 28, 2016 3:30 AM, "Nick Coghlan" wrote:
>> *snip*
>> 4. Do we collectively agree that "?then" and "?else" would be
>> reasonable spellings for such operators?
>
> Personally, I find that kind of ugly. What's wrong with just ? instead of
>
On 29 October 2016 at 04:08, Mark Dickinson wrote:
> On Fri, Oct 28, 2016 at 9:30 AM, Nick Coghlan wrote:
>> [...] the current practicises of:
>>
>> * obj is not None (many different use cases)
>> * obj is not Ellipsis (in multi-dimensional slicing)
>
> Can you elaborate on this one? I don't thin
Hi Nick,
thanks for writing all of this down and composing a PEP.
On 28.10.2016 10:30, Nick Coghlan wrote:
1. Do we collectively agree that "existence checking" is a useful
general concept that exists in software development and is distinct
from the concept of "truth checking"?
Right to your
On Fri, Oct 28, 2016 at 9:30 AM, Nick Coghlan wrote:
> [...] the current practicises of:
>
> * obj is not None (many different use cases)
> * obj is not Ellipsis (in multi-dimensional slicing)
Can you elaborate on this one? I don't think I've ever seen an `is not
Ellipsis` check in real code.
--
On Fri, Oct 28, 2016 at 11:17 AM, Paul Moore wrote:
> On 28 October 2016 at 15:40, Nick Coghlan wrote:
> > I also don't think the idea is sufficiently general to be worthy of
> > dedicated syntax if it's limited specifically to "is not None" checks
> > - None's definitely special, but it's not *
On 28 October 2016 at 15:40, Nick Coghlan wrote:
> I also don't think the idea is sufficiently general to be worthy of
> dedicated syntax if it's limited specifically to "is not None" checks
> - None's definitely special, but it's not *that* special. Unifying
> None, NaN, NotImplemented and Ellips
On 28 October 2016 at 23:35, Ryan Birmingham wrote:
> I certainly like the concept, but I worry that use of __exists__() could
> generalize it a bit beyond what you're intending in practice. It seems like
> this should only check if an object exists, and that adding the magic method
> would only
Hi folks,
After the recent discussions of PEP 505's null-coalescing operator
(and the significant confusion around why anyone would ever want a
feature like that), I was inspired to put together a competing
proposal that focuses more on defining a new "existence checking"
protocol that generalises
19 matches
Mail list logo
