Re: [Python-ideas] Implementing a set of operation (+, /, - *) on dict consistent with linearAlgebrae

[Kyle Lahnakoski]

Julien,

Personally, I would be able to use the module you are proposing to
accumulate arbitrarily-named measures. I can not think of a use case for
division, but it would be nice for completion.  I have made my own
library that implements a small part of what you propose [1].

I was looking through the pstats.py [2] source code; and I thought it
could benefit from vector operations.  I have seen other code that
collect measures have the same redundant pattern.  Maybe some fancy
regex can identify other += code sequences that would benefit.  If you
make a module, and show how it can simplify pstats.py, maybe you have a
winner? 

[1] "vector" addition? -
https://github.com/klahnakoski/mo-dots/blob/dev/tests/test_dot.py#L610

[2] pstats.py source code -
https://github.com/python/cpython/blob/3.7/Lib/pstats.py#L156


On 2018-10-30 11:31, julien tayon wrote:
> Hello :)
>
> the idea is described here:
> http://jul.github.io/cv/pres.html#printable
>
> Summary of the idea :
>
> Take a linear algebrae book, and implements all the rules as a TDD.
> https://github.com/jul/archery/blob/master/consistent_algebrae.py
>
> make it works based on abstract base class and sets of Mixins.
> https://archery.readthedocs.io/en/latest/
>
> And see if we can make cos/__abs__/dot and if it gives naively the intended
> results ? (spoiler: yes)
>
> Making it work with dict, and "other" dictionary like counter by using
> ineritance
> https://archery.readthedocs.io/en/latest/#advanced-usage
>
> My idea is : wouldn't it be nice if we introduced geometries as sets of
> mixins for objects ?
> (Hilbertian algebrae could be nice too, and we could make MutableMapping
> behave like bra/kets).
>
> So I was proposing a soft discussion on : could we agree that it would be
> nice to consider operation overloading as a whole set of behaviours that
> could profit from being consistent in a categorized way ? (like the + of []
> could be the + of "RecordAlgebrae")
> Meaning we could define sets of "expected behaviour consistent interaction
> between operators" as we defined the abc and call them algebrae?
>
> I offer the LinearAlgebrae Mixins as a POC, and was thinking of creating a
> unittest to qualify if an object is following the rules of linear algebrae.
>
> What are your opinions ?
> I don't actually see a lot of use case except it was funny to build. But
> maybe it can be of use.
>
>
> Cordialement
>
> -- 
> Julien
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Allow Context Managers to Support Suspended Execution

[David Allemang]

I do not think there is currently a good way for Context Managers to
support suspended execution, as in await or yield. Both of these
instructions cause the interpreter to leave the with block, yet no
indication of this (temporary) exit or subsequent re-entrance is given
to the context manager. If the intent of a Context Manager is to say
"no matter how this block is entered or exited, the context will be
correctly maintained", then this needs to be possible.

I would propose magic methods __suspend__ and __resume__ as companions
to the existing __enter__ and __exit__ methods (and their async
variants). __suspend__, if present, would be called upon suspending
execution on an await or yield statement, and __resume__, if present,
would be called when execution is resumed. If __suspend__ or
__resume__ are not present then nothing should be done, so that the
behavior of existing context managers is preserved.

Here is an example demonstrating the issue with await:
https://gist.github.com/allemangD/bba8dc2d059310623f752ebf65bb6cdc
and one with yield:
https://gist.github.com/allemangD/f2534f16d3a0c642c2cdc02c544e854f

The context manager used is clearly not thread-safe, and I'm not
actually sure how to approach a thread-safe implementation with the
proposed __suspend__ and __resume__ - but I don't believe that
introducing these new methods would create any issues that aren't
already present with __enter__ and __exit__.

It's worth noting that the context manager used in those examples is,
essentially, identical contextlib's redirect_stdout and decimal's
localcontext managers. Any context manager such as these which modify
global state or the behavior of global functions would benefit from
this. It may also make sense to, for example, have the __suspend__
method on file objects flush buffers without closing the file, similar
to their current __exit__ behavior, but I'm unsure what impact this
would have on performance.

It is important, though, that yield and await not use __enter__ or
__exit__, as not all context-managers are reusable. I'm unsure  what
the best term would be to describe this type of context, as the
documentation for contextlib already gives a different definition for
"reentrant" - I would then call them "suspendable" contexts. It would
make sense to have an @suspendable decorator, probably in contextlib,
to indicate that a context manager can use __enter__ and __exit__
methods rather than __suspend__ and __resume__. All it would need to
do is define __suspend__ to call __enter__() and __resume__ to call
__exit__(None, None, None).

It is also important, since __suspend__ and __resume__ would be called
after a context is entered but before it is exited, that __suspend__
not accept any parameters and that __resume__ not use its return
value. __suspend__ could not be triggered by an exception, only by a
yield or await, and __resume__ could not have its return value named
with as.

Thanks,

David
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Michael Selik]

On Wed, Oct 31, 2018 at 12:31 PM Chris Angelico  wrote:

> What is being asked for here (if I'm not misreading) is a relatively simple
> enhancement to a method on a built-in type (or a small handful of
> types). If that garners reasonable support, the next step wouldn't be
> a PEP, it'd just go straight to a tracker issue and a pull request.
>
> For myself, I'm +0 on adding default=. It'd be a minor convenience on
> a very small number of cases. But it wouldn't bother me at all so it
> wouldn't be a problem if it were to land.
>

If the consensus is to add a default keyword parameter for the rest of the
get/pop methods on built-in types, it'd be reasonable to write an addendum
to PEP 463 that mentions what is being established as the Pythonic
interface: When a method can raise IndexError or KeyError, the method
should provide an optional default which suppresses the error.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Chris Angelico]

On Thu, Nov 1, 2018 at 6:25 AM Robert Vanden Eynde  wrote:
>
> Oooh, PEP463, you're reason with I switch to LBYL or write studpid try except 
> functions so much times.
>
> Oh and also the local assignement "let/where/statement" :D
>
> x = (y+1 where y = 3.14) because x = [y+1 for y in [3.14]][0] is an overkill 
> and ugly.
>
> Should I write a PEP even though I know it's going to be rejected because the 
> mailing list was not really into it ?
>

There's nothing wrong with writing PEPs that have a low likelihood of
being accepted. In fact, some PEPs have specifically been written with
the purpose of rejecting them - creating a sort of FAQ document ("this
has been proposed many times, here's the arguments in favour of it,
and it's rejected because X and Y").

That said, though, you may well not need to go to that effort. What is
being asked for here (if I'm not misreading) is a relatively simple
enhancement to a method on a built-in type (or a small handful of
types). If that garners reasonable support, the next step wouldn't be
a PEP, it'd just go straight to a tracker issue and a pull request.

For myself, I'm +0 on adding default=. It'd be a minor convenience on
a very small number of cases. But it wouldn't bother me at all so it
wouldn't be a problem if it were to land.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Implementing a set of operation (+, /, - *) on dict consistent with linearAlgebrae

[Robert Vanden Eynde]

And with libraries like pip install funcoperators or pip install infix, you
can even write it infix :D

from funcoperators import infix
@infix
def superop(d1, sc):
return {k: (v *superopp* sc) for k, v in d1.items()}

print({'a': 8} *superop* 5)


Le mer. 31 oct. 2018 à 18:35, Vladimir Filipović  a
écrit :

> Julien, would I be correct if I summarized the changes you have in
> mind like this:
>
> for dictionaries d1 and d2,
> non-Mapping ("scalar") sc,
> binary operation ⊛,
> and unary operation 퓊 (such as negation or abs()):
>
> d1 ⊛ sc == {k: (v ⊛ sc) for k, v in d1.items()}
> sc ⊛ d1 == {k: (sc ⊛ v) for k, v in d1.items()}
> 퓊(d1) == {k: 퓊(v) for k, v in d1.items()}
> d1 ⊛ d2 == {k: (d1[k] ⊛ d2[k]) for k in d1.keys() & d2.keys()}
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Robert Vanden Eynde]

Oooh, PEP463, you're reason with I switch to LBYL or write studpid try
except functions so much times.

Oh and also the local assignement "let/where/statement" :D

x = (y+1 where y = 3.14) because x = [y+1 for y in [3.14]][0] is an
overkill and ugly.

Should I write a PEP even though I know it's going to be rejected because
the mailing list was not really into it ?

Le mer. 31 oct. 2018 à 18:37, Michael Selik  a écrit :

> On Wed, Oct 31, 2018 at 10:17 AM Eric Fahlgren 
> wrote:
>
>> On Wed, Oct 31, 2018 at 2:42 AM Chris Angelico  wrote:
>>
>>> https://www.python.org/dev/peps/pep-0463/ wants to say hi.
>>>
>>
>> That was exactly my reaction, too, and usually is whenever one of these
>> "add a default" or similar ideas pops up.  463 should be re-examined, I was
>> very hopeful when it went through the wringer the first time, but alas it
>> was not to be.
>>
>
> I'll add my vote to re-examining PEP 463.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Michael Selik]

On Wed, Oct 31, 2018 at 10:17 AM Eric Fahlgren 
wrote:

> On Wed, Oct 31, 2018 at 2:42 AM Chris Angelico  wrote:
>
>> https://www.python.org/dev/peps/pep-0463/ wants to say hi.
>>
>
> That was exactly my reaction, too, and usually is whenever one of these
> "add a default" or similar ideas pops up.  463 should be re-examined, I was
> very hopeful when it went through the wringer the first time, but alas it
> was not to be.
>

I'll add my vote to re-examining PEP 463.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Implementing a set of operation (+, /, - *) on dict consistent with linearAlgebrae

[Vladimir Filipović]

Julien, would I be correct if I summarized the changes you have in
mind like this:

for dictionaries d1 and d2,
non-Mapping ("scalar") sc,
binary operation ⊛,
and unary operation 퓊 (such as negation or abs()):

d1 ⊛ sc == {k: (v ⊛ sc) for k, v in d1.items()}
sc ⊛ d1 == {k: (sc ⊛ v) for k, v in d1.items()}
퓊(d1) == {k: 퓊(v) for k, v in d1.items()}
d1 ⊛ d2 == {k: (d1[k] ⊛ d2[k]) for k in d1.keys() & d2.keys()}
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Eric Fahlgren]

On Wed, Oct 31, 2018 at 2:42 AM Chris Angelico  wrote:

>
> https://www.python.org/dev/peps/pep-0463/ wants to say hi.
>
>
That was exactly my reaction, too, and usually is whenever one of these
"add a default" or similar ideas pops up.  463 should be re-examined, I was
very hopeful when it went through the wringer the first time, but alas it
was not to be.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Steven D'Aprano]

On Wed, Oct 31, 2018 at 09:31:37PM +1100, Chris Angelico wrote:

> > I don't think I would agree with a broad rule "anything that raises can
> > return a default value" -- I don't think it makes sense to have, let's
> > say, len(obj, default=2). But on a case-by-case basis, it works for me.
> 
> And that's exactly why a broad rule of "anything that raises can be
> wrapped in a catcher" does make sense. Hence it may not be the same
> thing, but it is an alternative solution that doesn't require
> specifically angling for consistency.

True. I'm not arguing against the earlier PEP, I was in favour of it 
too. But even if we had exception-catching expressions, it would still 
make sense to add a default value to list.pop and perhaps a list.get 
method too.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Antoine Pitrou]

On Wed, 31 Oct 2018 00:44:55 +0100
"Giampaolo Rodola'" 
wrote:
> Sorry in advance if this has been proposed in the past but I couldn't find
> anything on python-ideas:
> 
> >>> l = []
> >>> l.pop(default=1)  
> 1
> 
> FWIW my use case consists in reading entries from /proc/diskstats where
> lines can have a variable number of fields depending on the kernel version:
> https://github.com/giampaolo/psutil/issues/1354#issuecomment-434495870
> https://github.com/giampaolo/psutil/blob/d8b05151e65f9348aff9b58da977abd8cacb2127/psutil/_pslinux.py#L1068
> As such it would be convenient to set missing fields to 0 as "reads =
> fields.pop(default=0)" instead of catching IndexError every time. Extra:
> for consistency set.pop() should probably have the same.
> 
> Thoughts?

+1 from me.  dict.pop() already has an optional default.  This is a
straight-forward improvement to the API and no Python programmer will
be surprised.

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Michel Desmoulin]

+1 one this.

And a list.get method has well, with a default value.

Le 31/10/2018 à 00:44, Giampaolo Rodola' a écrit :

Sorry in advance if this has been proposed in the past but I couldn't
find anything on python-ideas:

 >>> l = []
 >>> l.pop(default=1)
1

FWIW my use case consists in reading entries from /proc/diskstats where
lines can have a variable number of fields depending on the kernel version:
https://github.com/giampaolo/psutil/issues/1354#issuecomment-434495870
https://github.com/giampaolo/psutil/blob/d8b05151e65f9348aff9b58da977abd8cacb2127/psutil/_pslinux.py#L1068
As such it would be convenient to set missing fields to 0 as "reads =
fields.pop(default=0)" instead of catching IndexError every time. Extra:
for consistency set.pop() should probably have the same.

Thoughts?

--
Giampaolo - http://grodola.blogspot.com


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Antoine Pitrou]

On Wed, 31 Oct 2018 02:25:25 +0200
Serhiy Storchaka 
wrote:
> 31.10.18 01:44, Giampaolo Rodola' пише:
> > Sorry in advance if this has been proposed in the past but I couldn't 
> > find anything on python-ideas:
> >   
> >  >>> l = []
> >  >>> l.pop(default=1)  
> > 1
> > 
> > FWIW my use case consists in reading entries from /proc/diskstats where 
> > lines can have a variable number of fields depending on the kernel version:
> > https://github.com/giampaolo/psutil/issues/1354#issuecomment-434495870
> > https://github.com/giampaolo/psutil/blob/d8b05151e65f9348aff9b58da977abd8cacb2127/psutil/_pslinux.py#L1068
> > As such it would be convenient to set missing fields to 0 as "reads = 
> > fields.pop(default=0)" instead of catching IndexError every time. Extra: 
> > for consistency set.pop() should probably have the same.
> > 
> > Thoughts?  
> 
> It is just
> 
>  l.pop() if l else default
> 
> or
> 
>  (l or [default]).pop()

l.pop(default=...) has the potential to be multi-thread-safe, while
your alternatives haven't.

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Chris Angelico]

On Wed, Oct 31, 2018 at 9:14 PM Steven D'Aprano  wrote:
>
> On Wed, Oct 31, 2018 at 08:41:28PM +1100, Chris Angelico wrote:
> > On Wed, Oct 31, 2018 at 8:24 PM Nicolas Rolin  
> > wrote:
> > >
> > >
> > > As a user I always found a bit disurbing that dict pop method have a 
> > > default while list and set doesn't.
> > > While it is way more computationally easy to check wether a list or a set 
> > > is empty that to check if a key is in a dict, it still create a signature 
> > > difference for no real reason (having a default to a built-in in python 
> > > is pretty standard).
> > > It would be nice if every built-in/method of built-in type that returns a 
> > > value and raise in some case have access to a default instead of raise, 
> > > and not having to check the doc to see if it supports a default.
> > >
> >
> > https://www.python.org/dev/peps/pep-0463/ wants to say hi.
>
>
> PEP 463 is too busy crying bitter tears in the corner after being
> rejected to say "Hi".
>
> I don't think this is the same thing: PEP 464 is about being able to
> catch arbitrary exceptions in arbitrary expressions in an ad-hoc manner.
> Nicholas' suggestion is about making a consistent strategy of avoiding
> the need to catch exceptions.
>
> I don't think I would agree with a broad rule "anything that raises can
> return a default value" -- I don't think it makes sense to have, let's
> say, len(obj, default=2). But on a case-by-case basis, it works for me.

And that's exactly why a broad rule of "anything that raises can be
wrapped in a catcher" does make sense. Hence it may not be the same
thing, but it is an alternative solution that doesn't require
specifically angling for consistency.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Steven D'Aprano]

On Wed, Oct 31, 2018 at 08:41:28PM +1100, Chris Angelico wrote:
> On Wed, Oct 31, 2018 at 8:24 PM Nicolas Rolin  wrote:
> >
> >
> > As a user I always found a bit disurbing that dict pop method have a 
> > default while list and set doesn't.
> > While it is way more computationally easy to check wether a list or a set 
> > is empty that to check if a key is in a dict, it still create a signature 
> > difference for no real reason (having a default to a built-in in python is 
> > pretty standard).
> > It would be nice if every built-in/method of built-in type that returns a 
> > value and raise in some case have access to a default instead of raise, and 
> > not having to check the doc to see if it supports a default.
> >
> 
> https://www.python.org/dev/peps/pep-0463/ wants to say hi.


PEP 463 is too busy crying bitter tears in the corner after being 
rejected to say "Hi".

I don't think this is the same thing: PEP 464 is about being able to 
catch arbitrary exceptions in arbitrary expressions in an ad-hoc manner. 
Nicholas' suggestion is about making a consistent strategy of avoiding 
the need to catch exceptions.

I don't think I would agree with a broad rule "anything that raises can 
return a default value" -- I don't think it makes sense to have, let's 
say, len(obj, default=2). But on a case-by-case basis, it works for me.

If this were Ruby, and we could monkey-patch the built-in types, my 
reasoning would go something like this:

- if I have to write "L.pop() if L else default", I should write 
  it in place;

- the third time I write it in any one module, I ought to factor
  it out into a helper function;

- the third time I write the helper function, I ought to just
  monkey-patch the built-in and be done with it.


I haven't been counting, but I'm pretty sure I've written "get(L, 
index, default)" and "pop(L, index, default)" helpers at least three 
times now. Possibly even three times each :-)

In Python, of course, we can't add methods to built-ins. But I 
think this functionality makes good sense, especially once we remember 
that pop takes an optional index. Spot the bug in this:

L.pop(idx) if len(L) > idx else default



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Chris Angelico]

On Wed, Oct 31, 2018 at 8:24 PM Nicolas Rolin  wrote:
>
>
> As a user I always found a bit disurbing that dict pop method have a default 
> while list and set doesn't.
> While it is way more computationally easy to check wether a list or a set is 
> empty that to check if a key is in a dict, it still create a signature 
> difference for no real reason (having a default to a built-in in python is 
> pretty standard).
> It would be nice if every built-in/method of built-in type that returns a 
> value and raise in some case have access to a default instead of raise, and 
> not having to check the doc to see if it supports a default.
>

https://www.python.org/dev/peps/pep-0463/ wants to say hi.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Robert Vanden Eynde]

I think the same way about set.pop, list.pop.

About .index I agree adding default= would make sense but that's not
exactly the same thing as the others.

Do we have somewhere else a place where a linear search already accepts a
default= kwarg ?

def index(self, x):
   for i,y in enumerate(self):
   if x == y:
  return i
   raise ValueError

We do have "next", the default version of .index is currently implentable
as :

next((i for i, y in enumerate(self) if x == y), -1)

If I want -1 for default.

Le mer. 31 oct. 2018 à 10:23, Nicolas Rolin  a
écrit :

>
> As a user I always found a bit disurbing that dict pop method have a
> default while list and set doesn't.
> While it is way more computationally easy to check wether a list or a set
> is empty that to check if a key is in a dict, it still create a signature
> difference for no real reason (having a default to a built-in in python is
> pretty standard).
> It would be nice if every built-in/method of built-in type that returns a
> value and raise in some case have access to a default instead of raise, and
> not having to check the doc to see if it supports a default.
>
> We could for exemple ask ourselves wether or not list.index should have a
> default, as it is a method that we explecitely excpect to return a value
> and might just raise instead.
>
> 2018-10-31 2:08 GMT+01:00 Steven D'Aprano :
>
>> On Wed, Oct 31, 2018 at 02:25:25AM +0200, Serhiy Storchaka wrote:
>> > 31.10.18 01:44, Giampaolo Rodola' пише:
>> > >Sorry in advance if this has been proposed in the past but I couldn't
>> > >find anything on python-ideas:
>> > >
>> > > >>> l = []
>> > > >>> l.pop(default=1)
>> > >1
>> [...]
>>
>> > It is just
>> >
>> > l.pop() if l else default
>>
>> It might *do* the same thing, but it doesn't communicate the
>> programmer's intention as well.
>>
>> {}.pop('key', default) could be written using LBYL too, but the
>> intention is much clearer given an explicit default argument.
>>
>> The only advantage of the "if l" version is that if the default is
>> expensive to calculate, we can short-circuit it.
>>
>>
>> > or
>> >
>> > (l or [default]).pop()
>>
>> That's clever, but it is also wasteful, building a single-item list only
>> to immediately pop the item out of it and throw the list away.
>>
>> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "l.pop() if l else None"
>> 1000 loops, best of 3: 0.0739 usec per loop
>>
>> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "(l or [None]).pop()"
>> 100 loops, best of 3: 0.421 usec per loop
>>
>>
>>
>> --
>> Steve
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> --
>
> --
> *Nicolas Rolin* | Data Scientist
> + 33 631992617 - nicolas.ro...@tiime.fr 
>
>
> *15 rue Auber, **75009 Paris*
> *www.tiime.fr *
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Ron Reiter]

I think l.pop() if l else None is good enough. I think it's pretty obvious
that a developer means "Pop the list if the list is not empty, and return
None if the list is empty ".

- Ron


[image: Facebook]  [image: Twitter]
 [image: LinkedIn]



On Wed, Oct 31, 2018 at 11:24 AM Nicolas Rolin 
wrote:

>
> As a user I always found a bit disurbing that dict pop method have a
> default while list and set doesn't.
> While it is way more computationally easy to check wether a list or a set
> is empty that to check if a key is in a dict, it still create a signature
> difference for no real reason (having a default to a built-in in python is
> pretty standard).
> It would be nice if every built-in/method of built-in type that returns a
> value and raise in some case have access to a default instead of raise, and
> not having to check the doc to see if it supports a default.
>
> We could for exemple ask ourselves wether or not list.index should have a
> default, as it is a method that we explecitely excpect to return a value
> and might just raise instead.
>
> 2018-10-31 2:08 GMT+01:00 Steven D'Aprano :
>
>> On Wed, Oct 31, 2018 at 02:25:25AM +0200, Serhiy Storchaka wrote:
>> > 31.10.18 01:44, Giampaolo Rodola' пише:
>> > >Sorry in advance if this has been proposed in the past but I couldn't
>> > >find anything on python-ideas:
>> > >
>> > > >>> l = []
>> > > >>> l.pop(default=1)
>> > >1
>> [...]
>>
>> > It is just
>> >
>> > l.pop() if l else default
>>
>> It might *do* the same thing, but it doesn't communicate the
>> programmer's intention as well.
>>
>> {}.pop('key', default) could be written using LBYL too, but the
>> intention is much clearer given an explicit default argument.
>>
>> The only advantage of the "if l" version is that if the default is
>> expensive to calculate, we can short-circuit it.
>>
>>
>> > or
>> >
>> > (l or [default]).pop()
>>
>> That's clever, but it is also wasteful, building a single-item list only
>> to immediately pop the item out of it and throw the list away.
>>
>> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "l.pop() if l else None"
>> 1000 loops, best of 3: 0.0739 usec per loop
>>
>> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "(l or [None]).pop()"
>> 100 loops, best of 3: 0.421 usec per loop
>>
>>
>>
>> --
>> Steve
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> --
>
> --
> *Nicolas Rolin* | Data Scientist
> + 33 631992617 - nicolas.ro...@tiime.fr 
>
>
> *15 rue Auber, **75009 Paris*
> *www.tiime.fr *
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Nicolas Rolin]

As a user I always found a bit disurbing that dict pop method have a
default while list and set doesn't.
While it is way more computationally easy to check wether a list or a set
is empty that to check if a key is in a dict, it still create a signature
difference for no real reason (having a default to a built-in in python is
pretty standard).
It would be nice if every built-in/method of built-in type that returns a
value and raise in some case have access to a default instead of raise, and
not having to check the doc to see if it supports a default.

We could for exemple ask ourselves wether or not list.index should have a
default, as it is a method that we explecitely excpect to return a value
and might just raise instead.

2018-10-31 2:08 GMT+01:00 Steven D'Aprano :

> On Wed, Oct 31, 2018 at 02:25:25AM +0200, Serhiy Storchaka wrote:
> > 31.10.18 01:44, Giampaolo Rodola' пише:
> > >Sorry in advance if this has been proposed in the past but I couldn't
> > >find anything on python-ideas:
> > >
> > > >>> l = []
> > > >>> l.pop(default=1)
> > >1
> [...]
>
> > It is just
> >
> > l.pop() if l else default
>
> It might *do* the same thing, but it doesn't communicate the
> programmer's intention as well.
>
> {}.pop('key', default) could be written using LBYL too, but the
> intention is much clearer given an explicit default argument.
>
> The only advantage of the "if l" version is that if the default is
> expensive to calculate, we can short-circuit it.
>
>
> > or
> >
> > (l or [default]).pop()
>
> That's clever, but it is also wasteful, building a single-item list only
> to immediately pop the item out of it and throw the list away.
>
> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "l.pop() if l else None"
> 1000 loops, best of 3: 0.0739 usec per loop
>
> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "(l or [None]).pop()"
> 100 loops, best of 3: 0.421 usec per loop
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 

--
*Nicolas Rolin* | Data Scientist
+ 33 631992617 - nicolas.ro...@tiime.fr 


*15 rue Auber, **75009 Paris*
*www.tiime.fr *
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/