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

[Guido van Rossum]

What sort of code would be able to do anything useful with either a
sequence or a queue? Queues aren’t iterable. This seems a case of
hyper-generalization.

On Tue, Aug 24, 2021 at 22:19 Christopher Barker 
wrote:

> Bringing this back on list:
>
> On Tue, Aug 24, 2021 at 9:58 PM David Mertz, Ph.D. 
> wrote:
>
>> Sorry, I should have been more explicit. The several kinda of queues can
>> all "contain" items, but do not respond to len().
>>
>
> yeah, I should have looked more closely at your list
>
> Though i would consider that an oversight, len(a_queue) could be handy.
>
> There is qsize() -- I wonder if there's a reason not to have __len__ do
> the same thing --  O(n) maybe? See Guido's point that there's an assumption
> tha len() will be O(1).
>
> This is an argument for the OP's point -- there is no standard way to
> check emptiness.
>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> 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/EEK7QHRGT2P5WLEOOJCPJQSR6VEDAJVC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/DCHSJADNALHHBLXW45EVXSEFCFCIHJD4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

On Tue, Aug 24, 2021 at 10:12 PM Guido van Rossum  wrote:

> “Container” is a kind of pun, it’s something with a __contains__ method.
> The thing you’re looking for is “Collection”.
>

Hmm, perhaps we should tweak the docs, the section is titled:

"Abstract Base Classes for Containers"

But yes, Collection is what I (and probably the OP) was looking for, in
which case, all Collections support len(), so the way to explicitly check
if they are empty is len(). Nothing to be done here.

I also note that the discussion seems quite stuck.
>

indeed. I'm done :-)

-CHB


--
Christopher Barker, PhD (Chris)

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/4I2FYIUUXTZXSWLWCHDZDCBVCSN4LSZP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

Bringing this back on list:

On Tue, Aug 24, 2021 at 9:58 PM David Mertz, Ph.D. 
wrote:

> Sorry, I should have been more explicit. The several kinda of queues can
> all "contain" items, but do not respond to len().
>

yeah, I should have looked more closely at your list

Though i would consider that an oversight, len(a_queue) could be handy.

There is qsize() -- I wonder if there's a reason not to have __len__ do the
same thing --  O(n) maybe? See Guido's point that there's an assumption tha
len() will be O(1).

This is an argument for the OP's point -- there is no standard way to check
emptiness.

-CHB

-- 
Christopher Barker, PhD (Chris)

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/EEK7QHRGT2P5WLEOOJCPJQSR6VEDAJVC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

“Container” is a kind of pun, it’s something with a __contains__ method.
The thing you’re looking for is “Collection”, which is the base for
sequences, mappings and sets.

I also note that the discussion seems quite stuck.

—Guido

On Tue, Aug 24, 2021 at 21:55 Christopher Barker 
wrote:

> It seems the conversation has confused two related concepts:
>
> 1) The default bool() implementation (Truthiness) -- this is what the OP
> said was recommended by PEP 8: "For sequences, (strings, lists, tuples),
> use the fact that empty sequences are false:" -- there is some debate about
> that whether this is a good recommendation or not, but i don't think that's
> the OPs point. Rather:
>
> 2) That there is no standard way to explicitly test containers for
> "emptiness" - - there is only length, with the assumption that
> len(something) == 0 or not len(something) is a good way to test for
> emptiness.
>
> I still don't see why length is not perfectly adequate, but i wonder if
> there are any  "containers" i.e.things that could be empty, in the std lib
> that don't support length.
>
> Looking in the ABCs, a Container is something that supports `in`, and a
> Sized is something that supports len()-- so in theory, there could be a
> Container that does not have a length. Are there any in the std lib?
>
> Perhaps the ABCs are instructive in another way here -- if we were to add
> a __empty__ or some such dunder, what ABC would require it? Container? or
> yet another one-method ABC?
>
> -CHB
>
>
> On Tue, Aug 24, 2021 at 8:39 PM David Mertz, Ph.D. 
> wrote:
>
>> I wanted to do a survey of various "aggregates" in Python to see if any
>> stand out as making the usual `if stuff: ...` troublesome.  I wrote a
>> little script at
>> https://github.com/DavidMertz/LanguagePractice/blob/main/python/aggregates.py
>> .
>>
>> I'm being deliberately vague about an "aggregate."  It might not be a
>> collection strictly speaking, but it is something that might seems to
>> "contain" values in some sense.  Basically, I think that standard library
>> and built-in stuff behaves per PEP8.  Some other libraries go their own
>> way.  I throw in a linked-list implementation I found on PyPI.  I've never
>> used it beyond this script; but per what it is, it cannot implement `len()`
>> on O(1) (well, it *could* if it does extra bookkeeping; but then it's kinda
>> a different thing).
>>
>> In NumPy land, the np.empty vs. np.zeros case is another oddball.  On my
>> system, my memory happened to have some prior value that wasn't zero; that
>> could vary between runs, in principle.
>>
>> These are the results:
>>
>> Expr: '' | Value: ''
>>   Truth: False | Length: 0
>> Expr: list() | Value: []
>>   Truth: False | Length: 0
>> Expr: tuple() | Value: ()
>>   Truth: False | Length: 0
>> Expr: dict() | Value: {}
>>   Truth: False | Length: 0
>> Expr: set() | Value: set()
>>   Truth: False | Length: 0
>> Expr: bytearray() | Value: bytearray(b'')
>>   Truth: False | Length: 0
>> Expr: bytearray(1) | Value: bytearray(b'\x00')
>>   Truth: True | Length: 1
>> Expr: bytearray([0]) | Value: bytearray(b'\x00')
>>   Truth: True | Length: 1
>> Expr: array.array('i') | Value: array('i')
>>   Truth: False | Length: 0
>> Expr: array.array('i', []) | Value: array('i')
>>   Truth: False | Length: 0
>> Expr: Nothing() | Value: EmptyNamedTuple()
>>   Truth: False | Length: 0
>> Expr: deque() | Value: deque([])
>>   Truth: False | Length: 0
>> Expr: deque([]) | Value: deque([])
>>   Truth: False | Length: 0
>> Expr: ChainMap() | Value: ChainMap({})
>>   Truth: False | Length: 0
>> Expr: queue.Queue() | Value: 
>>   Truth: True | Length: No length
>> Expr: asyncio.Queue() | Value: 
>>   Truth: True | Length: No length
>> Expr: multiprocessing.Queue() | Value: > object at 0x7f0940dd2190>
>>   Truth: True | Length: No length
>> Expr: np.ndarray(1,) | Value: array([5.e-324])
>>   Truth: True | Length: 1
>> Expr: np.ndarray((1,0)) | Value: array([], shape=(1, 0), dtype=float64)
>>   Truth: False | Length: 1
>> Expr: np.empty((1,)) | Value: array([5.e-324])
>>   Truth: True | Length: 1
>> Expr: np.zeros((1,)) | Value: array([0.])
>>   Truth: False | Length: 1
>> Expr: np.zeros((2,)) | Value: array([0., 0.])
>>   Truth: No Truthiness | Length: 2
>> Expr: np.ones((1,)) | Value: array([1.])
>>   Truth: True | Length: 1
>> Expr: np.ones((2,)) | Value: array([1., 1.])
>>   Truth: No Truthiness | Length: 2
>> Expr: pd.Series() | Value: Series([], dtype: float64)
>>   Truth: No Truthiness | Length: 0
>> Expr: pd.DataFrame() | Value: Empty DataFrame
>>   Truth: No Truthiness | Length: 0
>> Expr: xr.DataArray() | Value: 
>>   Truth: True | Length: No length
>> Expr: linkedadt.LinkedList() | Value: > 0x7f08d8d77f40>
>>   Truth: False | Length: 0
>>
>>
>>
>> --
>> Keeping medicines from the bloodstreams of the sick; food
>> from the bellies of the hungry; books from the hands of the
>> uneducated; technology from the underdeveloped; and putting
>> advocates of freedom in prisons.  

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

[Christopher Barker]

On Tue, Aug 24, 2021 at 9:50 PM Guido van Rossum  wrote:

> It was pointed out to me that numpy allows arrays that have no elements
> but a nonzero first dimension. People could disagree about whether that
> should be considered empty.
>
indeed -- you can kinda-sorta map an array to nested lists, e.g, is :

[[],[],[],[]]

an empty list? It has a length of 4, and so does a (4, 0) sized numpy
array. numpy is actually mostly consistent with the std lib in that regard.


> PS. Why is anyone thinking that an array containing all zeros (and at
> least one zero) might be considered empty? That seems a totally different
> kind of test.
>

I think there may have been confusion with boolean Falsiness indicating
emptiness, as it does for Sequences. An array containing all zeros might
well be considered False, though not empty.

Of course, that's why numpy arrays raise a  DeprecationWarning when used
that way.

Another issue with numpy arrays is that they are non resizable, so needing
to check if one is empty is pretty rare -- there is no way that everything
could have been removed, or nothing put in in the first place -- the
emptiness could have, and likely would have been checked before it was
created.

-CHB






>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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/3FKVLFJLVZIARGNIA7VQBJS3V3BAD3O5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD (Chris)

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/6PSLCZSVZWP5UUHW6DAWSMHKSECYTG2Z/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

It seems the conversation has confused two related concepts:

1) The default bool() implementation (Truthiness) -- this is what the OP
said was recommended by PEP 8: "For sequences, (strings, lists, tuples),
use the fact that empty sequences are false:" -- there is some debate about
that whether this is a good recommendation or not, but i don't think that's
the OPs point. Rather:

2) That there is no standard way to explicitly test containers for
"emptiness" - - there is only length, with the assumption that
len(something) == 0 or not len(something) is a good way to test for
emptiness.

I still don't see why length is not perfectly adequate, but i wonder if
there are any  "containers" i.e.things that could be empty, in the std lib
that don't support length.

Looking in the ABCs, a Container is something that supports `in`, and a
Sized is something that supports len()-- so in theory, there could be a
Container that does not have a length. Are there any in the std lib?

Perhaps the ABCs are instructive in another way here -- if we were to add a
__empty__ or some such dunder, what ABC would require it? Container? or yet
another one-method ABC?

-CHB


On Tue, Aug 24, 2021 at 8:39 PM David Mertz, Ph.D. 
wrote:

> I wanted to do a survey of various "aggregates" in Python to see if any
> stand out as making the usual `if stuff: ...` troublesome.  I wrote a
> little script at
> https://github.com/DavidMertz/LanguagePractice/blob/main/python/aggregates.py
> .
>
> I'm being deliberately vague about an "aggregate."  It might not be a
> collection strictly speaking, but it is something that might seems to
> "contain" values in some sense.  Basically, I think that standard library
> and built-in stuff behaves per PEP8.  Some other libraries go their own
> way.  I throw in a linked-list implementation I found on PyPI.  I've never
> used it beyond this script; but per what it is, it cannot implement `len()`
> on O(1) (well, it *could* if it does extra bookkeeping; but then it's kinda
> a different thing).
>
> In NumPy land, the np.empty vs. np.zeros case is another oddball.  On my
> system, my memory happened to have some prior value that wasn't zero; that
> could vary between runs, in principle.
>
> These are the results:
>
> Expr: '' | Value: ''
>   Truth: False | Length: 0
> Expr: list() | Value: []
>   Truth: False | Length: 0
> Expr: tuple() | Value: ()
>   Truth: False | Length: 0
> Expr: dict() | Value: {}
>   Truth: False | Length: 0
> Expr: set() | Value: set()
>   Truth: False | Length: 0
> Expr: bytearray() | Value: bytearray(b'')
>   Truth: False | Length: 0
> Expr: bytearray(1) | Value: bytearray(b'\x00')
>   Truth: True | Length: 1
> Expr: bytearray([0]) | Value: bytearray(b'\x00')
>   Truth: True | Length: 1
> Expr: array.array('i') | Value: array('i')
>   Truth: False | Length: 0
> Expr: array.array('i', []) | Value: array('i')
>   Truth: False | Length: 0
> Expr: Nothing() | Value: EmptyNamedTuple()
>   Truth: False | Length: 0
> Expr: deque() | Value: deque([])
>   Truth: False | Length: 0
> Expr: deque([]) | Value: deque([])
>   Truth: False | Length: 0
> Expr: ChainMap() | Value: ChainMap({})
>   Truth: False | Length: 0
> Expr: queue.Queue() | Value: 
>   Truth: True | Length: No length
> Expr: asyncio.Queue() | Value: 
>   Truth: True | Length: No length
> Expr: multiprocessing.Queue() | Value:  object at 0x7f0940dd2190>
>   Truth: True | Length: No length
> Expr: np.ndarray(1,) | Value: array([5.e-324])
>   Truth: True | Length: 1
> Expr: np.ndarray((1,0)) | Value: array([], shape=(1, 0), dtype=float64)
>   Truth: False | Length: 1
> Expr: np.empty((1,)) | Value: array([5.e-324])
>   Truth: True | Length: 1
> Expr: np.zeros((1,)) | Value: array([0.])
>   Truth: False | Length: 1
> Expr: np.zeros((2,)) | Value: array([0., 0.])
>   Truth: No Truthiness | Length: 2
> Expr: np.ones((1,)) | Value: array([1.])
>   Truth: True | Length: 1
> Expr: np.ones((2,)) | Value: array([1., 1.])
>   Truth: No Truthiness | Length: 2
> Expr: pd.Series() | Value: Series([], dtype: float64)
>   Truth: No Truthiness | Length: 0
> Expr: pd.DataFrame() | Value: Empty DataFrame
>   Truth: No Truthiness | Length: 0
> Expr: xr.DataArray() | Value: 
>   Truth: True | Length: No length
> Expr: linkedadt.LinkedList() | Value:  0x7f08d8d77f40>
>   Truth: False | Length: 0
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> ___
> 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
> 

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

[Guido van Rossum]

On Tue, Aug 24, 2021 at 7:23 PM MRAB  wrote:

> On 2021-08-25 00:48, Guido van Rossum wrote:
> > Hi Tim,
> >
> > I'm sorry if this has been brought up before, but *aside from PEP 8* is
> > there anything wrong with using "if len(a)" for nonempty, or "if not
> > len(a)" for empty?
> >
> What is the cost of 'len'? If it's always O(1), then it's not a problem,
> but if it's not O(1) (counting the items in a tree, for example) and
> you're not interested in how many items there are but only whether
> there's at least one, then...
>

It's a pretty universal assumption that len() is O(1) -- something that
doesn't do that probably shouldn't implement __len__(). (And yeah, there's
probably some tree package around that does implement an O(N) __len__().
People do a lot of silly things though, we can't handle *everything*.)

> It would seem to work for numpy and pandas arrays, and it works for
> > builtin sequences. Also, it has the advantage of being 100% backwards
> > compatible. :-)
> >
> > Surely conforming to PEP 8 shouldn't need an addition to the language or
> > stdlib? Or does it not work?
>

It was pointed out to me that numpy allows arrays that have no elements but
a nonzero first dimension. People could disagree about whether that should
be considered empty.

I'm not sure about Pandas, but IIRC a Dataframe is always a table of rows,
with all rows having the same number of columns. Here I'd say that if
there's at least one row in the table, I'd call it non-empty, even if the
rows have no columns. This conforms to  the emptiness of [()]. It's
possible that there's a common use case in the data science world where
this should be counted as empty, but to me, that would be inconsistent -- a
row with zero columns is still a row. (For numpy arrays my intuition is
less clear, since there's more symmetry between the dimensions.)

So then the next question is, what's the use case? What code are people
writing that may receive either a stdlib container or a numpy array, and
which needs to do something special if there are no elements? Maybe
computing the average? AFAICT Tim Hoffman (the OP) never said.

PS. Why is anyone thinking that an array containing all zeros (and at least
one zero) might be considered empty? That seems a totally different kind of
test.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/3FKVLFJLVZIARGNIA7VQBJS3V3BAD3O5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz, Ph.D.]

I wanted to do a survey of various "aggregates" in Python to see if any
stand out as making the usual `if stuff: ...` troublesome.  I wrote a
little script at
https://github.com/DavidMertz/LanguagePractice/blob/main/python/aggregates.py
.

I'm being deliberately vague about an "aggregate."  It might not be a
collection strictly speaking, but it is something that might seems to
"contain" values in some sense.  Basically, I think that standard library
and built-in stuff behaves per PEP8.  Some other libraries go their own
way.  I throw in a linked-list implementation I found on PyPI.  I've never
used it beyond this script; but per what it is, it cannot implement `len()`
on O(1) (well, it *could* if it does extra bookkeeping; but then it's kinda
a different thing).

In NumPy land, the np.empty vs. np.zeros case is another oddball.  On my
system, my memory happened to have some prior value that wasn't zero; that
could vary between runs, in principle.

These are the results:

Expr: '' | Value: ''
  Truth: False | Length: 0
Expr: list() | Value: []
  Truth: False | Length: 0
Expr: tuple() | Value: ()
  Truth: False | Length: 0
Expr: dict() | Value: {}
  Truth: False | Length: 0
Expr: set() | Value: set()
  Truth: False | Length: 0
Expr: bytearray() | Value: bytearray(b'')
  Truth: False | Length: 0
Expr: bytearray(1) | Value: bytearray(b'\x00')
  Truth: True | Length: 1
Expr: bytearray([0]) | Value: bytearray(b'\x00')
  Truth: True | Length: 1
Expr: array.array('i') | Value: array('i')
  Truth: False | Length: 0
Expr: array.array('i', []) | Value: array('i')
  Truth: False | Length: 0
Expr: Nothing() | Value: EmptyNamedTuple()
  Truth: False | Length: 0
Expr: deque() | Value: deque([])
  Truth: False | Length: 0
Expr: deque([]) | Value: deque([])
  Truth: False | Length: 0
Expr: ChainMap() | Value: ChainMap({})
  Truth: False | Length: 0
Expr: queue.Queue() | Value: 
  Truth: True | Length: No length
Expr: asyncio.Queue() | Value: 
  Truth: True | Length: No length
Expr: multiprocessing.Queue() | Value: 
  Truth: True | Length: No length
Expr: np.ndarray(1,) | Value: array([5.e-324])
  Truth: True | Length: 1
Expr: np.ndarray((1,0)) | Value: array([], shape=(1, 0), dtype=float64)
  Truth: False | Length: 1
Expr: np.empty((1,)) | Value: array([5.e-324])
  Truth: True | Length: 1
Expr: np.zeros((1,)) | Value: array([0.])
  Truth: False | Length: 1
Expr: np.zeros((2,)) | Value: array([0., 0.])
  Truth: No Truthiness | Length: 2
Expr: np.ones((1,)) | Value: array([1.])
  Truth: True | Length: 1
Expr: np.ones((2,)) | Value: array([1., 1.])
  Truth: No Truthiness | Length: 2
Expr: pd.Series() | Value: Series([], dtype: float64)
  Truth: No Truthiness | Length: 0
Expr: pd.DataFrame() | Value: Empty DataFrame
  Truth: No Truthiness | Length: 0
Expr: xr.DataArray() | Value: 
  Truth: True | Length: No length
Expr: linkedadt.LinkedList() | Value: 
  Truth: False | Length: 0



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/XIQPNWDNRDGO3NOIY5KUHZ5CMR67TRWS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

On 2021-08-25 00:48, Guido van Rossum wrote:

Hi Tim,

I'm sorry if this has been brought up before, but *aside from PEP 8* is 
there anything wrong with using "if len(a)" for nonempty, or "if not 
len(a)" for empty?


What is the cost of 'len'? If it's always O(1), then it's not a problem, 
but if it's not O(1) (counting the items in a tree, for example) and 
you're not interested in how many items there are but only whether 
there's at least one, then...


It would seem to work for numpy and pandas arrays, and it works for 
builtin sequences. Also, it has the advantage of being 100% backwards 
compatible. :-)


Surely conforming to PEP 8 shouldn't need an addition to the language or 
stdlib? Or does it not work?


On Tue, Aug 24, 2021 at 3:42 PM Tim Hoffmann via Python-ideas 
mailto:python-ideas@python.org>> wrote:


Ethan Furman wrote:
 > On 8/24/21 3:03 PM, Tim Hoffmann via Python-ideas wrote:
 > > **How do you check if a container is empty?**
 > > IMHO the answer should not depend on the container.
 > I think this is the fly in the ointment -- just about everything,
from len() to bool(), to add, to iter() /all/ depend
 > on the container -- even equality depends on the container. 
`and`, `or`, and `not` partially depend on the container

 > (via bool()).  Only `is` is truly independent.

Sorry, I think you got me wrong: The meaning and thus implementation
depends on the type (e.g. each container defines its own __len__()).
However the syntax for querying length that is still uniformly
`len(container)`. Likewise I'd like to have a uniform syntax for
emptiness, and not different syntax for different types (`if not
container` / `if len(array) == 0` / `if dataframe.empty`).


___
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/3GE7A7WQD6327IPE74IQQX5HHL4UWNOA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ben Rudiak-Gould]

On Tue, Aug 24, 2021 at 9:08 AM Jon Kiparsky  wrote:

> > Numbers in general are useful concepts that help us with real-world
> > problems, but it's really hard to pin them down.
>
> Not that hard, really. A number is just a hackenbush game :)
>

RIP Berlekamp, Conway and Guy. They all died within about a year of each
other.
___
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/VULTYS2LPVNN3XCOOWHTQPK7FG47PAZA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] staticmethod with property

[Henry Harutyunyan]

Currently Python does not support using `@staticmethod` decorator along with 
`@property` decorator.
I think that the it currently works is a bit misleading since it will not give 
an error, but gives the following outcome.

```
class Foo:
@staticmethod
@property
def bar():
return "1"
```

```
class Foo:
@property
@staticmethod
def bar():
return "1"
```

In wither of the cases the outcome is the following

```
Foo.bar
>>> 

a = Foo()
a.bar
>>> 
```

Is there any particular reason for this? Any don't we make it work?
___
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/M45PDOVAKJPFI55JUM3QREW3OYMW7NF5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

Hi Tim,

I'm sorry if this has been brought up before, but *aside from PEP 8* is
there anything wrong with using "if len(a)" for nonempty, or "if not
len(a)" for empty?

It would seem to work for numpy and pandas arrays, and it works for builtin
sequences. Also, it has the advantage of being 100% backwards compatible.
:-)

Surely conforming to PEP 8 shouldn't need an addition to the language or
stdlib? Or does it not work?

On Tue, Aug 24, 2021 at 3:42 PM Tim Hoffmann via Python-ideas <
python-ideas@python.org> wrote:

> Ethan Furman wrote:
> > On 8/24/21 3:03 PM, Tim Hoffmann via Python-ideas wrote:
> > > **How do you check if a container is empty?**
> > > IMHO the answer should not depend on the container.
> > I think this is the fly in the ointment -- just about everything, from
> len() to bool(), to add, to iter() /all/ depend
> > on the container -- even equality depends on the container.  `and`,
> `or`, and `not` partially depend on the container
> > (via bool()).  Only `is` is truly independent.
>
> Sorry, I think you got me wrong: The meaning and thus implementation
> depends on the type (e.g. each container defines its own __len__()).
> However the syntax for querying length that is still uniformly
> `len(container)`. Likewise I'd like to have a uniform syntax for emptiness,
> and not different syntax for different types (`if not container` / `if
> len(array) == 0` / `if dataframe.empty`).
> ___
> 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/LRK6HHQKBH2Y4USB7DAJNOUF5NE62ZYD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/5KTHNWMKZBRDQSRO7C4WCX4KG22QWCG2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 8/24/21 4:35 PM, Cameron Simpson wrote:

> If we're chasing rough edges, consider queue.Queue:
>
> >>> from queue import Queue
> >>> Q = Queue()
> >>> Q.empty()
> True
> >>> if Q: print("Q is true")
> ...
> Q is true
>
> I would often like to treat Queues as a container of queued items,
> basicly because I'd like to be able to probe for the presence of queued
> items via the emptiness idiom. But I can't. It does has a .empty()
> method.
>
> I don't even know what my point is here :-(

Perhaps that's it's irritating when containers redefine something vs nothing?  
;-)

--
~Ethan~
___
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/D2SKQUA2BLY7VNM5PEWGSHQQXM3ORTRJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Cameron Simpson]

On 24Aug2021 06:55, tim.hoffm...@mailbox.org  wrote:
>Ethan Furman wrote:
>> > "has element-wise operations" protocol or an is_empty protocol.
>> > I consider emptiness-check a basic concept that should be consistent and 
>> > easy to use across containers.
>
>> Python has an emptiness-check and numpy chose to repurpose it -- that is not 
>> Python's problem nor a shortcoming in Python.
>
>Python does not have an emptiness-check. Empty containers map to False and we 
>suggest in PEP8 to use the False-check as a stand in for the emptiness-check. 
>But logically falsiness and emptiness are two separate things. Numpy (IMHO 
>with good justification) repurposed the False-check, but that left them 
>without  a standard emptiness check.

In my mind PEP8 says that the emptiness check should be expressed as a 
False-check for Pythonic containers. That is a good thing to me. It does 
not mean we've no notion of emptiness, it says that if you've got 
something which can be empty it should be possible to check that by 
doing a False-check. And _that_ implies that for containers, the 
False-check _is_ emptiness. Defined, to me.

Numpy has made a different decision, probably because a heap of 
operators on their arrays map the operator onto the array elements. To 
them, that is useful enough to lose some Python-idiom coherence for the 
wider gain _in that special domain_.

If we're chasing rough edges, consider queue.Queue:

   >>> from queue import Queue
   >>> Q = Queue()
   >>> Q.empty()
   True
   >>> if Q: print("Q is true")
   ...
   Q is true

I would often like to treat Queues as a container of queued items, 
basicly because I'd like to be able to probe for the presence of queued 
items via the emptiness idiom. But I can't. It does has a .empty() 
method.

I don't even know what my point is here :-(

But I am definitely -1 on weaking the bool(container) idiom as a test 
for empty/nonempty, and also for asking every container implementation 
on the planet to grow a new is_empty() method.

Cheers,
Cameron Simpson 
___
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/6V57PGBD4KHWVUKXCKLQFYKEKNRGMWJL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Tim Hoffmann via Python-ideas]

Ethan Furman wrote:
> On 8/24/21 3:03 PM, Tim Hoffmann via Python-ideas wrote:
> > **How do you check if a container is empty?**
> > IMHO the answer should not depend on the container.
> I think this is the fly in the ointment -- just about everything, from len() 
> to bool(), to add, to iter() /all/ depend 
> on the container -- even equality depends on the container.  `and`, `or`, and 
> `not` partially depend on the container 
> (via bool()).  Only `is` is truly independent.

Sorry, I think you got me wrong: The meaning and thus implementation depends on 
the type (e.g. each container defines its own __len__()). However the syntax 
for querying length that is still uniformly `len(container)`. Likewise I'd like 
to have a uniform syntax for emptiness, and not different syntax for different 
types (`if not container` / `if len(array) == 0` / `if dataframe.empty`).
___
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/LRK6HHQKBH2Y4USB7DAJNOUF5NE62ZYD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 8/24/21 3:03 PM, Tim Hoffmann via Python-ideas wrote:

> **How do you check if a container is empty?**
>
> IMHO the answer should not depend on the container.

I think this is the fly in the ointment -- just about everything, from len() to bool(), to add, to iter() /all/ depend 
on the container -- even equality depends on the container.  `and`, `or`, and `not` partially depend on the container 
(via bool()).  Only `is` is truly independent.


> Not a solution:
> 0) The current `if not seq` syntax. "check Falsiness instead of emptiness" is 
a
> simplification, which is not always possible.
>
> Possible solutions:
>
> 1) Always use `if len(seq) == 0`. I think, this would works. But would we 
want to
>write that in PEP-8 instead of `if not seq`? To me, this feels a bit too 
low level.
>
> 2) A protocol would formalize that concept by building respective syntax into 
the
>language. But I concede that it may be overkill.
>
> 3) The simple solution would be to add `is_empty()` methods to all stdlib 
containers
>and encourage third party libs to adopt that convention as well. That 
would give a
>uniform syntax by convention.
>
> Reflecting the discussion in this thread, I now favor variant 3).

And since (3) is a method on the container, it absolutely "depends on the 
container".

--
~Ethan~
___
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/O2QZMKYC6FLKADYKS4UPCINPKJ65DCZV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz, Ph.D.]

Oh, if I'm going to be a smart-ass, I should probably remember that I need
a `not` in there. No need to correct me, I saw it as soon as pressing send.

Nonetheless, this is an unnecessary method or function. Truthiness is
non-emptiness for most purposes. And where it's not, you need something
more specialized to the purpose at hand.

On Tue, Aug 24, 2021, 6:14 PM David Mertz, Ph.D. 
wrote:

> This is easy enough to put in your own toolkit:
>
> >>> is_empty = bool
>
> All done!
>
> On Tue, Aug 24, 2021, 6:04 PM Tim Hoffmann via Python-ideas <
> python-ideas@python.org> wrote:
>
>> I also have the feeling that this is going round in circles. So let me
>> get back to the core question:
>>
>> **How do you check if a container is empty?**
>>
>> IMHO the answer should not depend on the container. While emptiness may
>> mean different things for different types. The check syntax can and should
>> still be uniform.
>>
>> Not a solution:
>> 0) The current `if not seq` syntax. "check Falsiness instead of
>> emptiness" is a simplification, which is not always possible.
>>
>> Possible solutions:
>> 1) Always use `if len(seq) == 0`. I think, this would works. But would we
>> want to write that in PEP-8 instead of `if not seq`? To me, this feels a
>> bit too low level.
>> 2) A protocol would formalize that concept by building respective syntax
>> into the language. But I concede that it may be overkill.
>> 3) The simple solution would be to add `is_empty()` methods to all stdlib
>> containers and encourage third party libs to adopt that convention as well.
>> That would give a uniform syntax by convention.
>>
>> Reflecting the discussion in this thread, I now favor variant 3).
>>
>> Tim
>> ___
>> 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/RNI2JYDY44LDV7LAGNAFT7IJD5CJT2GX/
>> 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/BEABLGBIDHHOYPR5W4DTUJ7JFH7QUI3E/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thomas Grainger]

Right but this doesn't work with bumpy or pandas
___
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/IOW24AEGNSFDFKQEBJG2HZCUYIU2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz, Ph.D.]

This is easy enough to put in your own toolkit:

>>> is_empty = bool

All done!

On Tue, Aug 24, 2021, 6:04 PM Tim Hoffmann via Python-ideas <
python-ideas@python.org> wrote:

> I also have the feeling that this is going round in circles. So let me get
> back to the core question:
>
> **How do you check if a container is empty?**
>
> IMHO the answer should not depend on the container. While emptiness may
> mean different things for different types. The check syntax can and should
> still be uniform.
>
> Not a solution:
> 0) The current `if not seq` syntax. "check Falsiness instead of emptiness"
> is a simplification, which is not always possible.
>
> Possible solutions:
> 1) Always use `if len(seq) == 0`. I think, this would works. But would we
> want to write that in PEP-8 instead of `if not seq`? To me, this feels a
> bit too low level.
> 2) A protocol would formalize that concept by building respective syntax
> into the language. But I concede that it may be overkill.
> 3) The simple solution would be to add `is_empty()` methods to all stdlib
> containers and encourage third party libs to adopt that convention as well.
> That would give a uniform syntax by convention.
>
> Reflecting the discussion in this thread, I now favor variant 3).
>
> Tim
> ___
> 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/RNI2JYDY44LDV7LAGNAFT7IJD5CJT2GX/
> 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/EM3MW27ZLEZYN3RKARZHZKFRWJTZPDU7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Tim Hoffmann via Python-ideas]

I also have the feeling that this is going round in circles. So let me get back 
to the core question:

**How do you check if a container is empty?**

IMHO the answer should not depend on the container. While emptiness may mean 
different things for different types. The check syntax can and should still be 
uniform.

Not a solution:
0) The current `if not seq` syntax. "check Falsiness instead of emptiness" is a 
simplification, which is not always possible.

Possible solutions:
1) Always use `if len(seq) == 0`. I think, this would works. But would we want 
to write that in PEP-8 instead of `if not seq`? To me, this feels a bit too low 
level.
2) A protocol would formalize that concept by building respective syntax into 
the language. But I concede that it may be overkill.
3) The simple solution would be to add `is_empty()` methods to all stdlib 
containers and encourage third party libs to adopt that convention as well. 
That would give a uniform syntax by convention.

Reflecting the discussion in this thread, I now favor variant 3).

Tim
___
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/RNI2JYDY44LDV7LAGNAFT7IJD5CJT2GX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jon Kiparsky]

> Numbers in general are useful concepts that help us with real-world
> problems, but it's really hard to pin them down.

Not that hard, really. A number is just a hackenbush game :)
-jpk
___
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/2WPXU73IYGHKU6CMM4KNBTK2H5SSWCQA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Notation for subscripts: refreshed proposal summary

[Matsuoka Takuo]

Dear Developers,

Some of you may have noticed I updated my proposal on the subject
yesterday. I'm afraid it was too long without a summary, so here is
one. I hope this will be helpful to some people.

Summary of the refreshed proposal
-
(1) Simplify the syntax:
We wouldn't need the notion of expression list any more, and would
be able to use starred expressions at more places.

(2) Simplify the syntax about subscription and slicing:
A simple new rule describes a well expectable interpretation of
natural but currently invalid expressions (mainly those involving
stars) which extends the already given interpretation of already
valid expressions.

(3) There's a difference from PEP 646:
Unlike with PEP 646, we won't have e.g.,

  a[*[y]]

as a valid expression which is _not_ equivalent to

  a[y]


The origianal post (sorry about its length) can be found at

https://mail.python.org/archives/list/python-ideas@python.org/message/BEGGQEU6MG7RYIY7HB4I6VQ23L6TXB6H/

as well as the entire thread at

https://mail.python.org/archives/list/python-ideas@python.org/thread/V2WFMNVJLUBXVQFPNHH4TJNRYNPK2BKJ/#BEGGQEU6MG7RYIY7HB4I6VQ23L6TXB6H

Note:
In the original post, the description of how __getitem__ (etc.) method
would be got was not precise. However, I hope what I wrote makes sense
for most situations.

Best regards,
Takuo Matsuoka
___
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/KF37FMD5K5M2ZVTJO6IS3J6M7HHE4VRU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Definition of a starred expression in the Language Reference

[Matsuoka Takuo]

I have filed this at the issue tracker at

https://bugs.python.org/issue44983

Best regards,
Takuo
___
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/W7TB7MWCLFYXXA6LHXLW4GBKNHDHWKHI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

On Tue, 24 Aug 2021 at 12:07, Tim Hoffmann via Python-ideas
 wrote:
> Just like length is. It's a basic concept and like __bool__ and __len__ it 
> should be upon the objects to specify what empty means.

It feels like these arguments in the abstract are mostly going round
in circles. It's possible something has been mentioned earlier in this
thread, but I don't recall if so - but is there any actual real-world
code that would be substantially improved if we had built into the
language a protocol that users could override in their classes to
explicitly define what "is empty" meant for that class?

Some things to consider:

1. It would have to be a case where neither len(x) == 0 or bool(x) did
the right thing.
2. We can discount classes that maliciously have bizarre behaviour,
I'm asking for *real world* use cases.
3. It would need to have demonstrable benefits over a user-defined
"isempty" function (see below).
4. Use cases that *don't* involve numpy/pandas would be ideal - the
scientific/data science community have deliberately chosen to use
container objects that are incompatible in many ways with "standard"
containers. Those incompatibilities are deeply rooted in the needs and
practices of that ecosystem, and frankly, anyone working with those
objects should be both well aware of, and comfortable with, the amount
of special-casing they need.

To illustrate the third point, we can right now do the following:

from functools import singledispatch

@singledispatch
def isempty(container):
return len(container) == 0

# If you are particularly wedded to special methods, you could even do
#
# @singledispatch
# def isempty(container):
# if hasattr(container, "__isempty__"):
# return container.__isempty()
# return len(container) == 0
#
# But frankly I think this is unnecessary. I may be in a minority here, though.


@isempty.register
def _(arr: numpy.ndarray):
return len(arr.ravel()) == 0

So any protocol built into the language needs to be somehow better than that.

If someone wanted to propose that the above (default) definition of
isempty were added to the stdlib somewhere, so that people could
register specialisations for their own code, then that might be more
plausible - at least it wouldn't have to achieve the extremely high
bar of usefulness to warrant being part of the language itself. I
still don't think it's sufficiently useful to be worth having in the
stdlib, but you're welcome to have a go at making the case...

Paul
___
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/JY37SEXSA5MJV2FLYCVQ23AX4TE5TEVH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Marc-Andre Lemburg]

On 21.08.2021 23:33, Tim Hoffmann via Python-ideas wrote:
> Hi all,
> 
> The Programming Recommendations section in PEP-8 states
> 
> "For sequences, (strings, lists, tuples), use the fact that empty sequences 
> are false:"
> 
>   # Correct:
>   if not seq:
>   if seq:
> 
>   # Wrong:
>   if len(seq):
>   if not len(seq):
> 
> In the talk "When Python Practices Go Wrong" Brandon Rhodes makes a good 
> point against this practice based on "explicit is better than implicit" 
> (https://youtu.be/S0No2zSJmks?t=873). He advertizes using
> 
>   if len(seq):
> 
> While that is as explicit as one can get within the current language, it 
> could still be more explicit: Semantically, we're not interested in the 
> (zero) length of the sequence, but want to know if it is empty.
> 
> 
> **Proposal**
> 
> Therefore, I propose syntax for an explicit empty check
> 
>   if isempty(seq):   (i)
> 
> or
> 
>   if seq.is_empty()  (ii)
> 
> This proposal is mainly motivated by the Zen verses "Explicit is better than 
> implicit" and "Readability counts".

I assume your function would first check that the argument is
a sequence and then check its length to determine emptiness.
That doesn't strike me as more explicit. It's just shorter than
first doing the type check and then testing the length.

For the method case, it's completely up to the object to define
what "empty" means, e.g. could be a car object which is fully
fueled but doesn't have passengers. That's very flexible, but
also requires all sequences to play along, which is hard.

When you write "if not seq: ..." in a Python application, you already
assume that seq is a sequence, so the type check is implicit (you
can make it explicit by adding a type annotation and applying
a type checked; either static or dynamic) and you can assume
that seq is empty if the boolean test returns False.

Now, you can easily add a helper function which implements your
notion of "emptiness" to your applications. The question is:
would it make sense to add this as a builtin.

My take on this is: not really, since it just adds a type
check and not much else. This is not enough to warrant the
added complexity for people learning Python.

You may want to propose adding a new operator.is_empty() function
which does this, though.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Aug 24 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
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/NHD5AA2FK5DF5IHNBHTFJCXTR65DPKS3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Tim Hoffmann via Python-ideas]

Christopher Barker wrote:
> But I see no reason to add a standardized way to check for an empty
> container- again “emptiness” may not be obviously defined either.
> Numpy arrays, (or Pandas Dataframes) are a good example here — there are
> more than one way to think of them as false - but maybe more than one way
> to think of them as empty too:
> Is a shape () (scalar) array empty ?
> Or shape (100, 0) ?
> Or shape (0, 100)
> Or shape (0,0,0,0)
> Or a rank 1 array that’s all zeros? Or all false?
> Anyway, the point is that “emptiness” may be situation specific, just like
> truthiness is.

Just like length is. It's a basic concept and like __bool__ and __len__ it 
should be upon the objects to specify what empty means.

> So explicitly specifying that you are looking for len(container) == 0 is
> more clear than isempty(container) would be, even  if it did exist.

As written in another post here, `len(container) == 0` is on a lower 
abstraction level than `isempty(container)`.
___
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/BGFQYXXQL6Z2Y4GXCOX7OB55RAKQMVFE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Marc-Andre Lemburg]

On 24.08.2021 05:53, Steven D'Aprano wrote:
> 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 to this:
> 
> >>> statistics.median([1, 2, float('nan'), 4])
> nan
> >>> statistics.median([float('nan'), 1, 2, 4])
> 1.5
> 
> I've spoken to users of other statistics packages and languages, such as 
> R, and I cannot find any consensus on what the "right" behaviour should 
> be for NANs except "not that!".
> 
> So I propose that statistics functions gain a keyword only parameter to 
> specify the desired behaviour when a NAN is found:
> 
> - raise an exception
> 
> - return NAN
> 
> - ignore it (filter out NANs)
> 
> which seem to be the three most common preference. (It seems to be 
> split roughly equally between the three.)
> 
> Thoughts? Objections?

Sounds good. This is similar to the errors argument we have
for codecs where users can determine what the behavior should be
in case of an error in processing.

> Does anyone have any strong feelings about what should be the default? 

No strong preference, but if the objective is to continue calculations
as much as possible even in the face of missing values, returning NAN
is the better choice.

Second best would be an exception, IMO, to signal: please be explicit
about what to do about NANs in the calculation. It helps reduce the
needed backtracking when the end result of a calculation
turns out to be NAN.

Filtering out NANs should always be an explicit choice to make.
Ideally such filtering should happen *before* any calculations
get applied. In some cases, it's better to replace NANs with
use case specific default values. In others, removing them is the
right thing to do.

Note that e.g. SQL defaults to ignoring NULLs in aggregate functions
such as AVG(), so there are standard precedents for ignoring NAN values
per default as well. And yes, that default can lead to wrong results
in reports which are hard to detect.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Aug 24 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
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/L5QB4GUPYXNYBFKG43VSGOWVE27Y5BIF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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
> them.

Which puts them in a similar category to degrees Celsius - you can
compare them, but there's no fundamental zero point. (It makes sense
to say "what would the temperature be if it were 3° higher", but not
"what is double this temperature" - not in Celsius.)

> > The fact is that what defines falsiness is use case dependent. Numbers are
> > the best example, zero. A often be a perfectly meaningful number.
>
> Fun fact: not only did the ancient Greek mathematicians not count zero
> as a number, but the Pythagoreans didn't count 1 as a number either.
>
> https://www.britannica.com/topic/number-symbolism/Pythagoreanism

To be fair, that's more a question of "what is a number". If you have
"a thing", is that "a number of things", or are they separate
concepts? We have settled on the idea that "a thing" is a special case
of "a number of things" mathematically, but try going to someone and
saying "I have a number of wives" and seeing whether they think that 1
is a number.

(And if zero is a number, then I also have a number of wives. Oh, and
I have a number of pet cobras, too, so don't trespass on my property.)

> Zero is a perfectly meaningful number, but it is special: it is the
> identity element for addition and subtraction, and the annihilating
> element for multiplication, and it has no inverse in the Reals. Even in
> number systems which allow division by zero, you still end up with weird
> shit like 1/0 = 2/0 = 3/0 ...

Numbers in general are useful concepts that help us with real-world
problems, but it's really hard to pin them down. You can easily
explain what "three apples" looks like, and you can show what "ten
apples" looks like, and from that, you can intuit that the difference
between them is the addition or removal of "seven apples".
Generalizing that gives you a concept of numbers. But what is the
operation that takes you from "three apples" to "three apples"? Well,
obviously, it was removing zero elephants, how are you so dimwitted as
to have not figured that out?!? In that sense, zero is very special,
as it represents NOT doing anything, the LACK of a transition.

(Negative numbers are a lot weirder. I have a cardboard box with three
cats in it, and five cats climb out and run all over the room. Which
clearly means that, if two cats go back into the box, it will be
empty.)

Division by zero has to be interpreted in a particular way. Calculus
lets us look at nonsensical concepts like "instantaneous rate of
change", which can be interpreted as the rise over the run where the
run has zero length. In that sense, "dividing by zero" is really "find
the limit of dividing smaller and smaller rises by their
correspondingly smaller and smaller runs", and is just as meaningful
as any other form of limit-based calculation (eg that 0.99... is
equal to 1). Mathematicians define "equal" and "divide" and "zero" etc
in ways that are meaningful, useful, and not always intuitive. In
programming, we get to do the same thing.

So what IS zero? What does it mean? *IT DEPENDS*. Sometimes it's a
basis point (like midnight, or ice water). Sometimes it's a scalar
(like "zero meters"). Sometimes it indicates an absence. And that's
why naively and blindly using programming concepts will inevitably
trip you up.

Oh, if only Python gave us a way to define our own data types with our
own meanings, and then instruct the language in how to interpret them
as "true" or "false" that would solve all these problems.

ChrisA
___
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/OZNDLPOEO2OXU7GD6BJR5VVVUNFDSWXR/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Tim Hoffmann via Python-ideas]

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
> > to grow a new method.
> > Yes, numpy could and probably should have an "is_empty()" method. However, 
> > defining a
> > method downstream breaks duck typing and maybe even more important authors 
> > have to
> > mentally switch between the two empty-check variants `if users` and `if 
> > users.is_empty()`
> > depending on the context.
> > The context being whether or not you working with numpy?  Is there generic 
> > code that works with both numpy arrays and 
> other non-numpy data?  Do we have any non-numpy examples of this problem?

E.g. SciPy and Matplotlib accept array-like inputs such as lists of numbers. 
They often convert internally to numpy arrays, but speaking for the case of 
Matplotlib, we sometimes need to preseve the original data and/or delay 
conversion, so we have to take extra care when checking inputs.

Pandas has the same Problem. "The truth value of a DataFrame is ambiguous". 
They have introduced a `DataFrame.empty` property.

I suspect the same problem exists for other types like xarray or tensorflow 
tensors, but I did not check.

> > 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.
> > Numpy is not Python, but a specialist third-party package that has made 
> > specialist
> > choices about basic operations -- that does not sound like a shortcoming of 
> > the language.
> > The "specialist choices" ``if len(values) == 0` in Numpy are the best you 
> > can do within
> > the capabilities of the Python language if you want the code to function 
> > with lists and
> > arrays. For Numpy to do better Python would need to either provide the 
> > above mentioned
> > "has element-wise operations" protocol or an is_empty protocol.
> > I consider emptiness-check a basic concept that should be consistent and 
> > easy to use across containers.


> Python has an emptiness-check and numpy chose to repurpose it -- that is not 
> Python's problem nor a shortcoming in Python.

Python does not have an emptiness-check. Empty containers map to False and we 
suggest in PEP8 to use the False-check as a stand in for the emptiness-check. 
But logically falsiness and emptiness are two separate things. Numpy (IMHO with 
good justification) repurposed the False-check, but that left them without  a 
standard emptiness check.

> Suppose we add an `.is_empty()` method, and five years down the road another 
> library repurposes that method, that other 
> library then becomes popular, and we then have two "emptiness" checks that 
> are no longer consistent -- do we then add a 
> third?

I don't think this is a valid argument. We would introduce the concept of 
emptiness. That can happen only once. What empty means for an object is 
determined by the respective library and implemented there, similar to what 
`len` means. There can't be any inconsistency.
___
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/CPW43PRUJ7X4Y3SWMTA26LIPKAECAV55/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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 the problem of the assumption of zero as
> representing false.

That's not really a problem with zero representing false. Its a problem 
with representing time of day as a number where midnight is zero :-)

*Durations* can be represented satisfactorily as a number (at least I 
can't think of any problems off the top of my head) but wall times (the 
number you see when you look at a clock) aren't really *numbers* in any 
real sense. You can't say "3:15pm times 2 is 6:30pm", 1:00am is not the 
multiplicative identity element and midnight is not the annihilating 
element (zero).

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 
them.


> I’ve always been ambivalent about Python’s concept of Truthiness
> (“something or nothing”). If I were to write my own language, I would
> probably require a actual Boolean for, eg, an if statement.

"Please sir, can we have some more Pascal" *wink*

How about short-circuiting `or` and `and` operators?

I'm not judging, just commenting. It surprises me that people who are 
extremely comfortable with duck-typing pretty much any other data type 
often draw the line at duck-typing bools.


> The fact is that what defines falsiness is use case dependent. Numbers are
> the best example, zero. A often be a perfectly meaningful number.

Fun fact: not only did the ancient Greek mathematicians not count zero 
as a number, but the Pythagoreans didn't count 1 as a number either.

https://www.britannica.com/topic/number-symbolism/Pythagoreanism

Zero is a perfectly meaningful number, but it is special: it is the 
identity element for addition and subtraction, and the annihilating 
element for multiplication, and it has no inverse in the Reals. Even in 
number systems which allow division by zero, you still end up with weird 
shit like 1/0 = 2/0 = 3/0 ...


-- 
Steve
___
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/LAJY5WYGZFAYKHBBBRXO66CMVBYCQB7N/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 the assumption of zero as 
> representing false.
>

More a problem with the assumption that midnight is zero. There's
nothing at all wrong with zero being false - if, for instance, you're
looking at a timedelta, a width of zero seconds is an empty time
interval, and that can indeed be false. (Consider: What is the overlap
between segment X and segment Y? Find the intersection between them;
if the intersection has zero width, there is no overlap and the two
time periods do not collide.)

> I’ve always been ambivalent about Python’s concept of Truthiness (“something 
> or nothing”). If I were to write my own language, I would probably require a 
> actual Boolean for, eg, an if statement.
>

That becomes very frustrating. Before you design your own language, I
strongly recommend trying out REXX, C, Python, LPC or Pike,
JavaScript, and SourcePawn, just because they have such distinctly
different type systems. (Obviously you'll have tried some of those
already, but try to complete the set.) And by "try out", I mean spend
a good amount of time coding in them. Get to know what's frustrating
about them. For instance, what does "if 0.0" mean? (Python: False. C:
False. JavaScript: False. Pike: True. REXX: Error. SourcePawn: False,
but can become True if the tag changes. SourcePawn doesn't have types,
it has tags.) Similarly, what is the truth value of an empty array (or
equivalent in each language? (Python: False. C: True. JavaScript:
True. REXX: Concept does not exist. SourcePawn: Error. Pike: True.)
Not one of these languages is fundamentally *wrong*, but they disagree
on what logical choices to make. (Yes, I'm being fairly generous
towards SourcePawn here. Truth be told, it sucks.) If you're going to
make changes from the way Python does things, be sure to have tried a
language that already works that way, and see what the consequences
are.

> The fact is that what defines falsiness is use case dependent. Numbers are 
> the best example, zero. A often be a perfectly meaningful number.
>

Of course it's a perfectly meaningful number, but you won't be saying
"if x:" to figure out whether x is a meaningful number. The question
is, what *else* does it mean? For instance, if you're asking "where in
this string does the letter w first occur?", then 0 is a perfectly
meaningful result, indicating that it's found at the very start of the
string. But that's not about whether it's a number; it's whether it's
a string index.

> Which id why Brandon suggested that testing the length of a sequence was a 
> good way to be explicit about what you mean by false in a particular context.
>

When people say "explicit is better than implicit", they usually mean
"code I like is better than code I don't like". And then they get
(somewhat rightly) lampooned by people like Steven who interpret
"explicit" to mean "using more words to mean nothing", which clearly
violates the Zen.

What ARE you being explicit about? Are you stating the concept "check
if there are any users", or are you stating the concept "take the list
of users, count how many people there are in it, and check if that
number is greater than zero"? The first one is written "if users:" and
the second "if len(users) > 0:". They are BOTH explicit, but they are
stating different things.

The point of a high level programming language is that we can express
abstract concepts. We don't have to hold the interpreter's hand and
say "to figure out how many people are in the list, take the
past-end-of-list pointer, subtract the list base pointer, and divide
by the size of a list element". We say "give me the length of the
list". And one huge advantage is that the interpreter is free to give
you that length in any way it likes (directly storing the length,
using pointer arithmetic, or even iterating over a sparse list and
counting the slots that are occupied).

Only be "more explicit" (in the sense of using lower-level constructs)
if you need to be.

> So explicitly specifying that you are looking for len(container) == 0 is more 
> clear than isempty(container) would be, even  if it did exist.
>

I'm not sure that that's any better. One is asking "how much stuff is
in the container? Zero items?" and the other is asking "is this
container empty?". They're different concepts. They will (usually)
give the same result, but conceptually they're different, and it's not
a scale of "more explicit" to "less explicit".

> With duck typing, you may well not know what type you are dealing with, but 
> you absolutely need to know how you expect  that object to behave in the 
> context of your code. So if having a zero length is meaningful in your code — 
> then only objects with a length will work, which