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

24.08.21 05:10, Will Bradley пише: > 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

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

On Wed, Aug 25, 2021 at 5:39 PM Finn Mason wrote: > Or the NaNs could be treated as zeros and a warning raised: > Absolutely not! NaN in no way means zero, ever. We should never provide a known incorrect result. > I do feel there should be a catchable warning but not an outright > exception, a

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

> I'd like to know how your idea is different from PEP 3124. Could you please explain? TBH I hadn't heard of PEP 3124 until this thread, so hopefully I'm not getting something wrong.  But my understanding is that the `@overload` decorator from PEP 3124 (i) requires all of the functions it decorate

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

> You may also be interested in a package I wrote for doing this kind of thing: > https://pypi.org/project/signature-dispatch/ After reading about this project, I'm interested in the idea of callable modules in Python. However, that's another issue for another day and another person. On Wed, Au

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

>> Don't know if this is already a PEP, but I'd love to see something like this >> < https://www.codementor.io/@arpitbhayani/overload-functions-in-python-13e32ahzqt > >> in >> Python— a decorator @overload that creates multiple copies of >> functions/methods based on their arguments' types. (This i

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

Perhaps a warning could be raised but the NaNs are ignored. For example: Input: statistics.mean([4, 2, float('nan')]) Output: [warning blah blah blah] 3 Or the NaNs could be treated as zeros and a warning raised: Input: statistics.mean([4, 2, float('nan')]) Output: [warning blah blah blah] 2 I

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

Yay, it's over! (I can't believe it got this much attention.) On Wed, Aug 25, 2021, 3:19 PM Tim Hoffmann via Python-ideas < python-ideas@python.org> wrote: > Ok, I have no problem ignoring PEP-8 where it's not applicable. I've > brought this topic up, because I thought there could be a improvemen

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

On 8/23/21 10:21 PM, Steven D'Aprano wrote: > 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 decora

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

Ok, I have no problem ignoring PEP-8 where it's not applicable. I've brought this topic up, because I thought there could be a improvement either in PEP-8 and/or by adding something to the language. I still do think that, but I accept that the problem it solves is not considered relevant enough

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

I agree with Guido. The only problem here is third-party libraries that don't use bool() to indicate emptiness. If you need to support those, use len(). But this doesn't mean a change to the standard library, because those third-party libraries are, well, third-party. We don't need a more explicit

[Python-ideas] Re: Queue and bool() -- an oversight? [was: We should have an explicit concept of emptiness for collections]

On 8/24/21 10:26 PM, Guido van Rossum wrote: > On Tue, Aug 24, 2021 at 22:19 Christopher Barker wrote: >> On Tue, Aug 24, 2021 at 9:58 PM David Mertz, Ph.D. wrote: >>> Sorry, I should have been more explicit. The several kinds of queues can all >>> "contain" items, but do not respond to len(). >>

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

My conclusion is that you should ignore PEP 8 for your use case and write “if len(a) == 0”. On Wed, Aug 25, 2021 at 06:13 Tim Hoffmann via Python-ideas < python-ideas@python.org> wrote: > Guido van Rossum wrote: > > So then the next question is, what's the use case? What code are people > > writi

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

On Wed, 25 Aug 2021 at 14:13, Tim Hoffmann via Python-ideas wrote: > > Guido van Rossum wrote: > > 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 a

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

On Wed, 25 Aug 2021 at 14:00, Tim Hoffmann via Python-ideas wrote: > > I can agree that "len(c) == 0" should mean "c is empty" for all practical > purposes (and numpy and pandas conform with that). OK > But "bool(c)" should mean "c is empty" is an arbitrary additional constraint. > For some ty

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

Guido van Rossum wrote: > 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) nev

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

Paul Moore wrote: > > **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. > > I will note that if we take things to extremes,

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

On Tue, 24 Aug 2021 at 23:06, Tim Hoffmann via Python-ideas 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