[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On Mon, Aug 23, 2021 at 12:13 AM David Mertz, Ph.D. wrote: > Everyone in this thread should absolutely read Lewis Caroll's delightful > and "What the Tortoise Said to Achilles." It's a very short 3-page story > that addressed exactly this topic in 1895... even before Guido's Time > Machine. > >

[Python-ideas] Additional Unpacking Generalizations for assignment

Hello developers. I like star expression. It would be even better if we could extend the idea of PEP448 to provide the following syntax at the time of assignment. ``` python a, b, d, **_ = **{"a":0, " b":1, "c":2}, d=3 ``` Ideally, it would be nice to be able to provide the same syntax when call

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

In all seriousness this is an actual problem with numpy/pandas arrays where: ``` Python 3.8.10 (default, Jun 2 2021, 10:49:15) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> numpy.array([1, 2, 3]) array([1, 2, 3]) >>> bool(numpy.a

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

here's another fun one "A False midnight": https://lwn.net/Articles/590299/ https://bugs.python.org/issue13936#msg212771 ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.p

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On Mon, Aug 23, 2021 at 11:56 PM Thomas Grainger wrote: > > here's another fun one "A False midnight": https://lwn.net/Articles/590299/ > https://bugs.python.org/issue13936#msg212771 > That was a consequence of a time value being an integer, and thus zero (midnight) was false. It was changed, bu

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On Mon, 2021-08-23 at 13:51 +, Thomas Grainger wrote: > In all seriousness this is an actual problem with numpy/pandas arrays > where: > > line 1537, in __nonzero__ >     raise ValueError( > ValueError: The truth value of a DataFrame is ambiguous. Use a.empty, > a.bool(), a.item(), a.any()

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On Mon, Aug 23, 2021 at 01:51:17PM -, Thomas Grainger wrote: > In all seriousness this is an actual problem with numpy/pandas arrays where: Indeed. Third-party classes can do anything they like. It is a shame that numpy's API made the decision that they did, but I don't think it is very com

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

Steven D'Aprano wrote: > I don't think it is very common to use numpy arrays in a context where > they are expected to duck-type as collections. Maybe not "numpy arrays duck-type as collections", but it is very common that arrays and sequences are used interchangably. Numpy has created the term

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

> This is a shortcoming of the language. this could be fixed if the built-in bool checked to see if the value was a numpy.array or a pandas.DataFrame and automatically called `array.size > 0` or `df.empty` ___ Python-ideas mailing list -- python-ideas

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On 8/23/21 1:15 PM, Tim Hoffmann via Python-ideas wrote: > If you want to write a function that accepts array-like `values`, you have to change > a check `if values` to `if len(values) == 0`. That works for both but is against the > PEP8 recommendation. This is a shortcoming of the language. N

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

> What's the problem being solved by isempty? Are there any situations > that couldn't be solved by either running a type checker, or by using > len instead of bool? I agree that determining the type is possible most of the time, either by type hints or a static analyzer. Using len is possible, w

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

Ethan Furman wrote: > It seems to me that the appropriate fix is for numpy to have an "is_empty()" > function that knows how to deal with arrays > and array-like structures, not force every container to grow a new method. Yes, numpy could and probably should have an "is_empty()" method. However,

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On 8/23/21 2:06 PM, Tim Hoffmann via Python-ideas wrote: > On a technical level, everything can be solved with the current language capabilities. The > main advantage is clearer semantics (explicit is better / readability counts) Note the explicit and readability are often at odds with each oth

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On 8/23/21 2:31 PM, Tim Hoffmann via Python-ideas wrote: > Ethan Furman wrote: >> It seems to me that the appropriate fix is for numpy to have an "is_empty()" function >> that knows how to deal with arrays and array-like structures, not force every container >> to grow a new method. > > Yes, nu

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On 2021-08-23 at 21:06:46 -, Tim Hoffmann via Python-ideas wrote: > - Re bool: As experienced python users we are used to translate `if > not users` to "if users is empty" or "if we have no users", but it > *is* less explicit than `if users.is_empty()`. I mentally translate "if not users" to

[Python-ideas] Add explicit method overloading to STL

Don't know if this is already a PEP, but I'd love to see something like this in Python— a decorator @overload that creates multiple copies of functions/methods based on their arguments' types. (This is much narrower i

[Python-ideas] Re: Add explicit method overloading to STL

On Mon, Aug 23, 2021 at 09:10:49PM -0500, Will Bradley wrote: > Don't know if this is already a PEP, but I'd love to see something like this > > in > Python— a decorator @overload that creates multiple copies of > fun

[Python-ideas] NAN handling in statistics functions

At the moment, the handling of NANs in the statistics module is implementation dependent. In practice, that *usually* means that if your data has a NAN in it, the result you get will probably be a NAN. >>> statistics.mean([1, 2, float('nan'), 4]) nan But there are unfortunate exceptions

[Python-ideas] Re: NAN handling in statistics functions

We had this discussion about a year and a half ago, in which I strongly advocated exactly this keyword argument to median*(). As before, I don't care about the default if there is an option. I don't even really care about the exception case, but don't object to it. On Mon, Aug 23, 2021 at 11:55

[Python-ideas] Re: NAN handling in statistics functions

Note that numpy has a set of nan* functions that ignore NaNs. I’m not suggesting that here, but it is prior art to be considered, and I do like that it explicitly is ignoring NaNs. > - raise an exception > > - return NAN > > - ignore it (filter out NANs) > > Does anyone have any strong feeling

[Python-ideas] Re: NAN handling in statistics functions

Urgh. That's a nasty dilemma. I propose that the default should be return NAN, since that's what you'd expect if you did the super-naive arithmetic version (e.g. mean(x, y, z) = (x+y+z)/3). On Mon, Aug 23, 2021 at 8:55 PM Steven D'Aprano wrote: > At the moment, the handling of NANs in the statis

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On Mon, Aug 23, 2021 at 6:54 AM Thomas Grainger wrote: > here's another fun one "A False midnight": > https://lwn.net/Articles/590299/ > https://bugs.python.org/issue13936#msg212771 This is a great example of the problem of the assumption of zero as representing false. I’ve always been ambival

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On Tue, Aug 24, 2021 at 3:27 PM Christopher Barker wrote: > > On Mon, Aug 23, 2021 at 6:54 AM Thomas Grainger wrote: >> >> here's another fun one "A False midnight": https://lwn.net/Articles/590299/ >> https://bugs.python.org/issue13936#msg212771 > > > This is a great example of the problem of t

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On Mon, Aug 23, 2021 at 10:26:47PM -0700, Christopher Barker wrote: > On Mon, Aug 23, 2021 at 6:54 AM Thomas Grainger wrote: > > > here's another fun one "A False midnight": > > https://lwn.net/Articles/590299/ > > https://bugs.python.org/issue13936#msg212771 > > > This is a great example of th

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

Ethan Furman wrote: > On 8/23/21 2:31 PM, Tim Hoffmann via Python-ideas wrote: > > Ethan Furman wrote: > > > It seems to me that the appropriate fix is for numpy to have an > > > "is_empty()" function > > that knows how to deal with arrays and array-like structures, not force > > every container

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

On Tue, Aug 24, 2021 at 4:31 PM Steven D'Aprano wrote: > ... midnight is not the annihilating element (zero). Unless you're Cinderella, of course. > We conventionally represent clock times as numbers, but they're more > akin to ordinal data. They have an order, but you can't do arithmetic on > t