On 01/11/2018 02:52, David Allemang wrote:
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-
I'm very curious about the idea, but can't come up with any use cases based
just one your explanation. Maybe you could give some examples where this
would be useful? In particular, what are some cases that are really hard to
handle now and how would those cases be improved like this?
On Wed, Oct 3
Check out the decimal example here:
https://www.python.org/dev/peps/pep-0568/ (PEP 568 is deferred, but PEP 567
is implemented in Python 3.7).
Those Contexts aren't context managers, but still there's some thought put
into swapping contexts out at the boundaries of generators.
On Wed, Oct 31, 201
Yep, PEP 567 addresses this for coroutines, so David's first example
is covered; here's a link to the fixed version: [1]
The proposal to add __suspend__ and __resume__ is very similar to PEP
521 which was withdrawn. PEP 568 (which needs to be properly updated)
is the way to go if we want to addre
Yes, so PEP 512 is exactly what I was suggesting. My apologies for not
finding it before sending this.
So, then, PEP 567 solves the issue for coroutines and PEP 568 would solve
it for generators as well?
On Thu, Nov 1, 2018, 11:40 AM Yury Selivanov Yep, PEP 567 addresses this for coroutines, so
31.10.18 13:07, Antoine Pitrou пише:
l.pop(default=...) has the potential to be multi-thread-safe, while
your alternatives haven't.
The multi-thread-safe alternative is:
try:
value = l.pop()
except IndexError:
value = default
___
31.10.18 13:08, Antoine Pitrou пише:
+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.
list.pop() corresponds two dict methods. With argument it corresponds
dict.pop(). But there are differenc
On 10/31/2018 02:29 PM, Chris Angelico wrote:
Exactly how a team of core devs can make unified
decisions is a little up in the air at the moment
I wouldn't worry too much about it. I don't think we have ever made
entirely unified decisions.
--
~Ethan~
__
On Fri, Nov 2, 2018 at 11:12 AM Ethan Furman wrote:
>
> On 10/31/2018 02:29 PM, Chris Angelico wrote:
>
> > Exactly how a team of core devs can make unified
> > decisions is a little up in the air at the moment
>
> I wouldn't worry too much about it. I don't think we have ever made
> entirely uni
Just English Vocabulary, what do you mean by "being in the air at the
moment" ?
Like, that's a subject that a lot of people in here like to talk ?
Yes, to merge or not to merge, but people can UpVote/DownVote can't they ?
:D
Le ven. 2 nov. 2018 à 01:15, Chris Angelico a écrit :
> On Fri, Nov 2,
On Fri, Nov 2, 2018 at 11:19 AM Robert Vanden Eynde
wrote:
>
> Just English Vocabulary, what do you mean by "being in the air at the moment"
> ?
> Like, that's a subject that a lot of people in here like to talk ?
"Up in the air" means uncertain, subject to change.
https://idioms.thefreediction
>
> In this case, the governance model for the Python language is being
> discussed.
>
This was the info I was missing, where is it discussed ? Not only on this
list I assume ^^
> Upvotes and downvotes don't mean anything. [...]
>
Yes, that's why random people wouldn't vote.
But like, voting be
On Fri, Nov 2, 2018 at 11:26 AM Robert Vanden Eynde
wrote:
>>
>> In this case, the governance model for the Python language is being
>> discussed.
>
>
> This was the info I was missing, where is it discussed ? Not only on this
> list I assume ^^
There are a number of PEPs in the 8000s that woul
>
> There are a number of PEPs in the 8000s that would be worth reading.
>
Will read that *à l'occaz*, closing the disgression now ^^
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Cond
I'd like to propose an addition to `dict` but I'm not necessarily proposing
what's written here as the API. When I initially saw the need for this
myself, I hastily wrote it as:
def setdefault_call(a_dict, key, default_func):
try:
return a_dict[key]
except KeyError:
default
On Fri, Nov 2, 2018 at 12:07 PM Alex Shafer wrote:
> Other APIs I've considered for this are a new keyword argument to the
> existing `setdefault()`, or perhaps more radically for Python, a new keyword
> argument to the `dict()` constructor that would get called as an implicit
> default for `se
I use this a lot in my code.
Since `setdefault_call` does not exist, here is how I do it:
d = {}
lookup_d = d.get
provide_d = d.setdefault
for i in range(100): # some large loop
l = (lookup_d(somekey)) or (provide_d(somekey, []))
l.append(somevalue)
I am not arguing for or against `.setdef
Does it make sense to draw some sort of parallel between next(myiterator,
default="whatever") and mylist.pop(default="whatever")? They exhaust the
iterator/list then start emitting the default argument (if provided).
On Thu, Nov 1, 2018 at 2:46 PM Serhiy Storchaka wrote:
> 31.10.18 13:08, Antoin
I had actually managed to miss collections.defaultdict!
I'd like to instead propose that a reference to that be added to the
dict.setdefault docs. I can't imagine I'm the only one that has missed this.
Date: Fri, 2 Nov 2018 12:12:45 +1100
> From: Chris Angelico
> To: python-ideas
> Subject: Re
>
> Does it make sense to draw some sort of parallel between next(myiterator,
> default="whatever") and mylist.pop(default="whatever")? They exhaust the
> iterator/list then start emitting the default argument (if provided).
>
Yep that's what I just did in my previous mail.
"""
I think the same w
The two are less connected than you seem to think.
On Thu, Nov 1, 2018 at 7:08 PM Alex Shafer wrote:
> I had actually managed to miss collections.defaultdict!
>
> I'd like to instead propose that a reference to that be added to the
> dict.setdefault docs. I can't imagine I'm the only one that ha
>
> The two are less connected than you seem to think.
>
Really ? What's the use mainstream use cases for setdefault ?
I was often in the case of Alex.
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-
On Thu, Nov 1, 2018 at 7:23 PM Robert Vanden Eynde
wrote:
> The two are less connected than you seem to think.
>>
>
> Really ? What's the use mainstream use cases for setdefault ?
> I was often in the case of Alex.
>
Well, defaultdict configures a default when an instance is created, while
setde
So it actually sounds like having a dict method for performing write
operations with a factory function would be a semantic improvement.
On Thu, Nov 1, 2018 at 8:50 PM Guido van Rossum wrote:
> On Thu, Nov 1, 2018 at 7:23 PM Robert Vanden Eynde
> wrote:
>
>> The two are less connected than you
On Thu, Nov 01, 2018 at 08:58:28PM -0600, Alex Shafer wrote:
> So it actually sounds like having a dict method for performing write
> operations with a factory function would be a semantic improvement.
As Chris pointed out, that's what __missing__ does.
py> class MyDict(dict):
... def __miss
On Fri, Nov 2, 2018 at 4:45 AM Serhiy Storchaka wrote:
>
> 31.10.18 13:08, Antoine Pitrou пише:
> > +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.
>
> list.pop() corresponds two dict me
26 matches
Mail list logo
