Terry,
On January 21, 2014 at 12:23:31 PM, Terry Reedy (tjre...@udel.edu) wrote:
> > On 1/21/2014 10:59 AM, Yury Selivanov wrote:
> > There is one more, hopefully last, open urgent question with
> the signature
> > object. At the time we were working on the PEP 362, PEP 4
About 21 of those are related to asyncio.
On 2/19/2014, 7:42 AM, Antoine Pitrou wrote:
On Tue, 18 Feb 2014 20:03:31 -0800
Larry Hastings wrote:
Only thirty cherry-picked revisions so far. Gosh, you're making my life
easy, guys,
That's a large number of cherry-picked revisions. How many are a
Thank you for writing this PEP, Chris. I'm impressed by the
quality of this PEP, and how you handled the discussion on
python-ideas.
I initially liked this idea, however, after reading the PEP
in detail, my vote is: -1 on the current syntax; -1 on the
whole idea.
On 2/20/2014, 10:15 PM, Chris An
On 2/21/2014, 7:42 PM, Ethan Furman wrote:
On 02/21/2014 11:04 AM, Yury Selivanov wrote:
On 2/20/2014, 10:15 PM, Chris Angelico wrote:
* list.pop() - no way to return a default
We can fix that in 3.5.
How many are you going to "fix"? How are you going to "fix" the
On 2/21/2014, 10:42 PM, Chris Angelico wrote:
On Sat, Feb 22, 2014 at 6:04 AM, Yury Selivanov wrote:
* seq[index] - no way to handle a bounds error
We can add 'list.get(index, default)' method, similar to
'Mapping.get'. It's far more easier than introducing new
synta
On 2/21/2014, 11:22 PM, Chris Angelico wrote:
I've added a couple of paragraphs to my draft PEP:
https://raw.github.com/Rosuav/ExceptExpr/master/pep-0463.txt
If someone could please commit that version to the official repo? Or I
can submit a diff against the peps repo if that would be easier.
On 2014-03-05, 11:37 AM, Victor Stinner wrote:
[snip]
I tried to write "views" of the traceback (and frames), but
Exception.__traceback__ rejects types other than traceback and
traceback instances cannot be created. It's possible to store the
traceback somewhere else and set Exception.__traceba
On 2014-03-05, 4:54 PM, Nick Coghlan wrote:
On 6 Mar 2014 02:43, "Antoine Pitrou" wrote:
Le 05/03/2014 17:37, Victor Stinner a écrit :
Python 3.4 introduced frame.clear(), but frame.clear() raises an
RuntimeError if the frame is still running. And it doesn't break all
reference cycles.
An o
On 2014-03-06, 8:42 AM, Antoine Pitrou wrote:
Le 05/03/2014 23:53, Nick Coghlan a écrit :
__traceback__ wouldn't change [...]
Uh, really? If you want to suppress all reference cycles, you *have*
to remove __traceback__.
The problem is to make computation of the traceback summary
lightwei
1:32 PM, Guido van Rossum wrote:
But inspect is in the stdlib. Surely changing inspect.py is less
controversial than amending the semantics of frame objects.
On Thu, Mar 6, 2014 at 10:10 AM, Xavier Morel wrote:
On 2014-03-06, at 16:52 , Antoine Pitrou wrote:
Le 06/03/2014 16:03, Yury Selivanov
Congrats Larry and everybody who worked on 3.4!
Yury
On 2014-03-17, 2:29 AM, Larry Hastings wrote:
On behalf of the Python development team, I'm thrilled to announce
the official release of Python 3.4.
Python 3.4 includes a range of improvements of the 3.x series, including
hundreds of smal
Thanks, it's fixed now.
Yury
On 2014-03-28, 10:29 AM, Andrew Svetlov wrote:
And probably the block should be deindented
On Thu, Mar 27, 2014 at 6:48 PM, Antoine Pitrou wrote:
On Thu, 27 Mar 2014 17:12:02 +0100 (CET)
yury.selivanov wrote:
+.. classmethod:: Signature.from_callable(obj)
+
Thank you, Ethan.
Fixed.
On 2014-04-08, 1:57 PM, Ethan Furman wrote:
Sorry, posted to wrong list the first time.
On 04/08/2014 09:33 AM, Ethan Furman wrote:
On 04/08/2014 09:07 AM, yury.selivanov wrote:
http://hg.python.org/cpython/rev/0973d45197cc
>
+The :attr:`__objclass__` is interpreted
Hello Victor,
On 2014-06-11, 10:28 AM, Victor Stinner wrote:
Hi,
I'm working on asyncio and it's difficult to debug code because
@asyncio.coroutine decorator removes the name of the function if the
function is not a generator (if it doesn't use yield from).
I propose to add new gi_name and gi_
On Wed, Jul 4, 2018 at 1:35 PM Ivan Pozdeev via Python-Dev
wrote:
>
> On 04.07.2018 11:54, Serhiy Storchaka wrote:
> >> while total != (total := total + term):
> >> term *= mx2 / (i*(i+1))
> >> i += 2
> >> return total
> >
> > This code looks clever that the original while loop with a bre
On Wed, Jul 4, 2018 at 2:16 PM Tim Peters wrote:
>
> [Yury Selivanov]
> > Wow, I gave up on this example before figuring this out (and I also
>
> > stared at it for a good couple of minutes). Now it makes sense. It's
>
> > funny that this super convoluted
I think I tried a variation of your proposal here
https://mail.python.org/pipermail/python-dev/2018-April/152939.html
and nobody really liked it.
Yury
On Thu, Jul 5, 2018 at 7:44 PM Alexander Belopolsky
wrote:
>
> I wish I had more time to make my case, but with the PEP 572 pronouncement
> immin
On Sun, Jul 22, 2018 at 11:18 PM Chris Angelico wrote:
>
> * Lately, all Guido's actions have been to benefit his employer, not
> the Common Pythonista. We have proof of this from reliable reporting
> sources such as Twitter and social media.
>
This accusation is ridiculous and not appreciated.
On Mon, Jul 23, 2018 at 12:03 PM Antoine Pitrou wrote:
>
> I suspect Chris A. was merely joking, though I'm not sure what the joke
> ultimately is supposed to be about.
>
Ah, right, I stopped reading his email after the quoted line. Well executed.
Yury
>
> --
Yury
__
On Mon, Aug 6, 2018 at 11:49 AM Ronald Oussoren via Python-Dev
wrote:
> I have no strong opinion on using Cython for tests or in the stdlib, other
> than that it is a fairly large dependency. I do think that adding a
> “Cython-lite” tool the CPython distribution would be less ideal, creating a
position to "defend" mypyc or to "promote" it, and I'm not affiliated
with the project at all. I am just excited about yet another tool to
statically compile Python and I'm discussing it only from a
theoretical standpoint.
>
> Yury Selivanov schrieb am 07.08.2
On Tue, Sep 4, 2018 at 2:58 PM Stefan Behnel wrote:
[..]
> Cython has four ways to provide type declarations: cdef statements in
> Cython code, external .pxd files for Python or Cython files, special
> decorators and declaration functions, and PEP-484/526 type annotations.
Great to hear that PEP
Ned, Nick, Victor,
There's an issue with the new PEP 567 (contextvars) C API.
Currently it's designed to expose "PyContext*" and "PyContextVar*"
pointers. I want to change that to "PyObject*" as using non-PyObject
pointers turned out to be a very bad idea (interfacing with Cython is
particularly
On Wed, Sep 19, 2018 at 4:26 PM Ned Deily wrote:
> On Sep 19, 2018, at 13:30, Yury Selivanov wrote:
[..]
> > Currently it's designed to expose "PyContext*" and "PyContextVar*"
> > pointers. I want to change that to "PyObject*" as using non-PyOb
On Sat, Sep 22, 2018 at 3:11 PM Guido van Rossum wrote:
[..]
> Still, I wonder if there's a tweak possible of the globals and locals used
> when exec()'ing the function definitions in dataclasses.py, so that
> get_type_hints() gets the right globals for this use case.
>
> It's really tough to be
On Fri, Sep 21, 2018 at 7:04 PM Eric Snow wrote:
>
> Hi all,
>
> I've got a pretty good sense of how signal handling works in the
> runtime (i.e. via a dance with the eval loop), but still have some
> questions:
>
> 1. Why do we restrict calls to signal.signal() to the main thread?
> 2. Why must s
On Mon, Sep 24, 2018 at 4:19 PM Eric Snow wrote:
[..]
> Is there a good place where this weirdness is documented?
I'll need to look through uvloop & libuv commit log to remember that;
will try to find time tonight/tomorrow.
[..]
> This matters to me because I'd like to use "pending" calls for
>
On Tue, Sep 25, 2018 at 10:04 AM Barry Warsaw wrote:
>
> Is anybody else concerned about the proliferation of undocumented private C
> API functions?
I am concerned about that too. In my opinion having all those
semi-private undocumented C API just contributes to the noise and
artificially infl
On Tue, Sep 25, 2018 at 11:55 AM Barry Warsaw wrote:
>
> On Sep 25, 2018, at 11:28, Victor Stinner wrote:
> >
> > But if we have a separated documented for CPython internals, why not
> > documenting private functions. At least, I would prefer to not put it
> > at the same place an the *public* C
On Tue, Sep 25, 2018 at 3:27 PM Barry Warsaw wrote:
>
> On Sep 25, 2018, at 12:09, Yury Selivanov wrote:
> >
> > My main concern with maintaining a *separate* documentation of
> > internals is that it would make it harder to keep it in sync with the
> > actual impl
Sorry to hear this, Serhiy. Hope you'll get better soon.
Yury
On Sat, Jan 19, 2019 at 5:15 AM Serhiy Storchaka wrote:
>
> I have virtually completely lost the sight of my right eye (and the loss
> is quickly progresses) and the sight of my left eye is weak. That is why
> my activity as a core d
Hi Joshua,
First of all, thanks for working on this! I quickly looked over the PR and
it looks ready to be merged, great work.
I've been oscillating between wanting to have aiter/anext as builtins and
putting them into the operators module for quite a while. On the one hand
asynchronous iteration
On Sat, Mar 20, 2021 at 2:35 PM Guido van Rossum wrote:
>
> However I'm still skeptical about the two-argument version of aiter() (see
> my previous message about this). Do you have any indication that a use case
> for that exists?
>
>
In my experience this isn't a popular feature. Now that I loo
Hi Daniel,
I agree that coding async in C is complicated, I've done a fair share
of that and can attest that the code is not straightforward or easily
maintainable. But in this very case I think we care more about
discoverability of these two functions and the overall developer
experience. Having
Just a few comments to add to Irit's response.
On Sat, Mar 27, 2021 at 11:03 AM Paul Sokolovsky wrote:
[..]
> Bottom line: this seems like a Trio's special-purpose feature, with
> good wishes of becoming the de facto standard.
The bottom line is that Trio nurseries were proven to be a very usefu
Just wanted to elaborate a little bit on StopIteration to add to Irit's reply:
On Mon, Apr 5, 2021 at 9:52 AM Irit Katriel via Python-Dev
wrote:
> On Mon, Apr 5, 2021 at 11:01 AM Nathaniel Smith wrote:
>> - There are a number of places where the Python VM itself catches exceptions
>> and has ha
On Wed, Apr 21, 2021 at 11:50 AM srku...@mail.de wrote:
>
> Removing two concepts and preserving semantics simplifies the matter for
> users. People need less to memorize and less to learn.
>
> Or am I missing something here? Couldn’t we achieve our goal without these
> two new classes?
No, we
On Wed, Apr 28, 2021 at 8:53 PM Nathaniel Smith wrote:
> Looking at the relevant section of the PEP again [1], it notes the
> same fatal flaw with my first suggestion, and then says that the
> multiple-except-executions option should be rejected because users
> have written code like 'except SomeE
Comments inlined:
On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum wrote:
> First of all, we should ping Yury, who implemented `async for` about 6
> years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and
> anext() about 5 months ago (see https://bugs.python.org/issue31861). I've
We have already merged it, the fix is part of the rc2.
yury
On Wed, Sep 8 2021 at 12:48 PM, Brett Cannon wrote:
> On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov
> wrote:
>
>> Comments inlined:
>>
>> On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum wrote:
>>
Ah, that's no problem, both spellings are good. Since I'm replying on
Pyhton-dev, I'll quote my Discord response here:
"Thank you Thomas and the SC. I’ll start working on incorporating
TaskGroups into asyncio in the next few weeks."
Thanks,
Yury
On Fri, Sep 24, 2021 at 3:13 PM, Thomas Wouters
I don't like `except group` or any variant with soft keywords.
I'll list a few reasons here:
1. `try: .. except group:` is a valid syntax today. And it will continue to
be valid syntax. Having both `try: .. except group:` (catch exception
`group`) and `try: .. except group E:` (catch exceptions o
Yes, I don't like the 'local' prefix too. How about '__dictlookup__'?
It's just more self-describing.
Yury
On 2013-09-09, at 2:23 PM, Jan Kaliszewski wrote:
> Is '__locallookup__' a really good name? In Python, *local* -- especially in
> context of *lookups* -- usually associates with locals(
Long story short, I've discovered that asyncio is broken in 3.5.2.
Specifically, there is a callbacks race in `loop.sock_connect` which
can make subsequent `loop.sock_sendall` calls to hang forever. This
thing is very tricky and hard to detect and debug; I had to spend a
few hours investigating wh
On 2016-08-08 3:33 PM, Giampaolo Rodola' wrote:
I wanted to give it a try rewriting this in C but since
@contextmanager has a lot of magic I wanted to ask first whether this
1) is technically possible 2) is desirable.
It is definitely technologically possible. However, the C
implementation
On 2016-08-08 4:18 PM, Guido van Rossum wrote:
I think Nick would be interested in understanding why this is the
case. What does the decorator do that could be so expensive?
From the looks of it it doesn't do anything special. Although with
@contextlib.contextmanager we have to instantiate
On 2016-08-08 6:53 PM, Victor Stinner wrote:
2016-08-09 0:40 GMT+02:00 Guido van Rossum :
tl;dr I found a way to make CPython 3.6 faster and I validated that
there is no performance regression.
But is there a performance improvement?
Sure.
On micro-benchmarks, you can see nice improvements:
On 2016-08-09 9:12 AM, INADA Naoki wrote:
Hi, devs.
I've implemented compact and ordered dictionary [1], which PyPy
implemented in 2015 [2].
Does this mean that keyword arguments will become ordered?
Yury
___
Python-Dev mailing list
Python-Dev@pyt
all open AGs.
The second approach gives event loops more control and allows to
implement APIs to collect open resources gracefully. The only
downside is that it's a bit harder for event loops to work with.
Let's discuss.
PEP: 525
Title: Asynchronous Generators
Version: $Revision$
Last
Hi Rajiv,
On 2016-08-23 10:38 PM, Rajiv Kumar wrote:
Hi Yury,
I was playing with your implementation to gain a better understanding
of the operation of asend() and friends. Since I was explicitly trying
to "manually" advance the generators, I wasn't using asyncio or other
event loop. This me
On 2016-08-24 12:35 PM, Guido van Rossum wrote:
On Wed, Aug 24, 2016 at 8:17 AM, Yury Selivanov
mailto:yselivanov...@gmail.com>> wrote:
On 2016-08-23 10:38 PM, Rajiv Kumar wrote:
I was playing with your implementation to gain a better
understanding of the operat
On 2016-08-24 3:01 PM, Sven R. Kunze wrote:
On 24.08.2016 18:35, Guido van Rossum wrote:
On Wed, Aug 24, 2016 at 8:17 AM, Yury Selivanov
mailto:yselivanov...@gmail.com>> wrote:
On 2016-08-23 10:38 PM, Rajiv Kumar wrote:
I was playing with your implementation to gain a
Hi,
I've spent quite a while thinking and experimenting with PEP 525 trying
to figure out how to make asynchronous generators (AG) finalization
reliable. I've tried to replace the callback for GCed with a callback
to intercept first iteration of AGs. Turns out it's very hard to work
with we
Hi Nathaniel,
On 2016-09-02 2:13 AM, Nathaniel Smith wrote:
On Thu, Sep 1, 2016 at 3:34 PM, Yury Selivanov wrote:
Hi,
I've spent quite a while thinking and experimenting with PEP 525 trying to
figure out how to make asynchronous generators (AG) finalization reliable.
I've tried
Hi Oscar,
I don't think PyPy is in breach of the language spec here. Python made
a decision a long time ago to shun RAII-style implicit cleanup in
favour if with-style explicit cleanup.
The solution to this problem is to move resource management outside of
the generator functions. This is true f
On 2016-08-30 2:20 PM, Guido van Rossum wrote:
I'm happy to present PEP 526 for your collective review:
https://www.python.org/dev/peps/pep-0526/ (HTML)
https://github.com/python/peps/blob/master/pep-0526.txt (source)
There's also an implementation ready:
https://github.com/ilevkivskyi/cpython
On 2016-09-03 12:27 PM, Brett Cannon wrote:
Below is the `co_extra` section of PEP 523 with the update saying that
users are expected to put a tuple in the field for easier simultaneous
use of the field.
Since the `co_extra` discussions do not affect CPython itself I'm
planning on landing t
On 2016-09-03 4:15 PM, Christian Heimes wrote:
On 2016-09-04 00:03, Yury Selivanov wrote:
On 2016-09-03 12:27 PM, Brett Cannon wrote:
Below is the `co_extra` section of PEP 523 with the update saying that
users are expected to put a tuple in the field for easier simultaneous
use of the
On 2016-09-03 4:13 PM, Chris Angelico wrote:
On Sun, Sep 4, 2016 at 8:03 AM, Yury Selivanov wrote:
On 2016-09-03 12:27 PM, Brett Cannon wrote:
Below is the `co_extra` section of PEP 523 with the update saying that
users are expected to put a tuple in the field for easier simultaneous use
of
On 2016-09-03 5:19 PM, Brett Cannon wrote:
On Sat, 3 Sep 2016 at 16:43 Yury Selivanov <mailto:yselivanov...@gmail.com>> wrote:
On 2016-09-03 4:15 PM, Christian Heimes wrote:
> On 2016-09-04 00:03, Yury Selivanov wrote:
>>
>> On 2016-09-03 12:2
But without that new API (basically what Christian proposed) you'd
need
to iterate over the list in order to find the object that belongs to
Pyjion.
Yes.
Yeah, which means the same for my opcode patch... Which unfortunately
will make things slower :(
If we manage t
Hi,
I've updated PEP 525 with a new section about asyncio changes.
Essentially, asyncio event loop will get a new "shutdown_asyncgens"
method that allows to close the loop and all associated AGs with it
reliably.
Only the updated section is pasted below:
asyncio
---
The asyncio event
usly
optimistic and I am grateful to Yury for the care and effort he has
put into it.
--Guido
On Tue, Sep 6, 2016 at 5:10 PM, Yury Selivanov wrote:
Hi,
I've updated PEP 525 with a new section about asyncio changes.
Essentially, asyncio event loop will get a new "shutdown_asyncgens&quo
Some of the functions we have are really intended to be used *only* by
the interpreter itself. For those it would be cool to have them in
private headers (AFAIK we already do this, see dict-common.h for
instance). Other than that, I think that using the underscore
convention is fine.
Yury
Hi,
Elvis and I authored What's New in Python 3.5. We'd like to volunteer
to do the same for 3.6. If there are no objections, we can make the
first editing pass in a couple of weeks.
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://m
Thank you Victor! This is a massive amount of work.
On 2016-10-20 6:56 AM, Victor Stinner wrote:
* I plan to run performance on CPython 2.7, CPython 3.7, PyPy and PyPy
3. Maybe also CPython 3.5 and CPython 3.6 if they don't take too much
resources.
I think it's important to run 3.5 & 3.6 to
I'm trying to fix refleaks in 3.6. So far:
On 2016-11-09 4:02 AM, solip...@pitrou.net wrote:
results for b78574cb00ab on branch "default"
test_ast leaked [98, 98, 98] references, sum=294
test_ast leaked [98, 98, 98] memory blocks, sum=294
test_asyn
On 2016-11-09 10:16 AM, Yury Selivanov wrote:
I'm trying to fix refleaks in 3.6. So far:
On 2016-11-09 4:02 AM, solip...@pitrou.net wrote:
results for b78574cb00ab on branch "default"
test_ast leaked [98, 98, 98] references, s
On 2016-11-19 2:46 PM, Kevin Modzelewski wrote:
Hi Yury, you may be interested in some leak-finding code that wrote for
Pyston. It uses the GC infrastructure to show you objects that were
directly leaked, ignoring indirect leaks -- ie objects that were only
leaked because they were referenced
On 2017-01-05 7:11 PM, INADA Naoki wrote:
bytes.frombuffer(x) is bytes(memoryview(x)) or memoryview(x).tobytes().
There is pitfall: memoryview should be closed.
So b = bytes.frombuffer(x) is:
with memoryview(x) as m:
b = bytes(m)
# or b = m.tobytes()
Thinking more about this, an
On 2017-01-17 11:55 AM, Brett Cannon wrote:
So, how widely can we use "designated initializer"?
Only in Modules (_asyncio uses it already)?
Or almost everywhere (Objects/ and Python/)?
I say everywhere we can (and that also means we should probably update the
xx* files in Modules/).
+1.
Yur
On 2017-03-01 12:42 AM, Nick Coghlan wrote:
Short version:
- there are some reasonable requests for async variants of contextlib APIs
for 3.7
- prompted by Raymond, I'm thinking it actually makes more sense to add
these in a new `asyncio.contextlib` module than it does to add them
directly to
On 2017-03-01 2:16 AM, Nathaniel Smith wrote:
On Tue, Feb 28, 2017 at 9:42 PM, Nick Coghlan wrote:
Short version:
- there are some reasonable requests for async variants of contextlib APIs
for 3.7
- prompted by Raymond, I'm thinking it actually makes more sense to add
these in a new `asyncio
Hi Christian,
On Fri, Aug 18, 2017 at 4:41 AM, Christian Tismer wrote:
> Hi friends,
>
> in the last months, I have developed signature support for
> PySide. The module creates the same signatures as are known
> for plain Python functions.
>
> As a non-trivial addition, the module also handles mu
you,
Yury
PEP: 550
Title: Execution Context
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Aug-2017
Python-Version: 3.7
Post-History: 11-Aug-2017, 15-Aug-2017, 18-Aug-2017
Abstract
This PEP
-1 on using "frame" in PEP 550 terminology. Antoine is right, the API
is not frame-specific, and "frame" in Python has only one meaning.
I can certainly see how "ContextFrame" can be correct if we think
about "frame" as a generic term, but in Python, people will
inadvertently think about a connect
On Mon, Aug 21, 2017 at 3:10 PM, Guido van Rossum wrote:
[..]
> Agreed. However now I am confused as to how the HAMT fits in. Yury says
> somewhere that the HAMT will be used for the EC and then cloning the EC is
> just returning a pointer to the same EC. But even if I interpret that as
> making a
On Sat, Aug 19, 2017 at 4:17 AM, Nick Coghlan wrote:
[..]
>>
>> * Generator's ``.send()`` and ``.throw()`` methods are modified as
>> follows (in pseudo-C)::
>>
>> if gen.__logical_context__ is not NULL:
>> tstate = PyThreadState_Get()
>>
>> tstate.execution_context.push(gen.
On Mon, Aug 21, 2017 at 5:14 PM, Koos Zevenhoven wrote:
[..]
>> This has consequences for the design in the PEP:
>>
>> * what we want to capture at generator creation time is the context
>> where writes will happen, and we also want that to be the innermost
>> context used for lookups
>
>
> I don'
On Mon, Aug 21, 2017 at 5:39 PM, Koos Zevenhoven wrote:
[..]
>> In the current version of the PEP, generators are initialized with an
>> empty LogicalContext. When they are being iterated (started or
>> resumed), their LogicalContext is pushed to the EC. When the
>> iteration is stopped (or paus
On Mon, Aug 21, 2017 at 8:06 PM, Guido van Rossum wrote:
> On Mon, Aug 21, 2017 at 12:50 PM, Yury Selivanov
> wrote:
>>
>> Few important things (using the current PEP 550 terminology):
>>
>> * ExecutionContext is a *dynamic* stack of LogicalContexts.
>&
On Mon, Aug 21, 2017 at 8:06 PM, Guido van Rossum wrote:
[..]
>> > OK, this really needs to be made very clear early in the PEP. Maybe this
>> > final sentence provides the key requirement: changes outside the
>> > generator
>> > should make it into the generator when next() is invoked, unless the
On Tue, Aug 22, 2017 at 2:06 AM, Koos Zevenhoven wrote:
[..]
>> There will be an optimization: if the LC is empty, we will push NULL
>> to the stack, thus avoiding the cost of allocating an object.
>>
> But if LCs are immutable, there needs to be only one empty-LC instance. That
> would avoid spec
I think that "implicit context" is not an accurate description of what
LogicalContext is.
"implicit context" only makes sense when we talk about decimal
context. For instance, in:
Decimal(1) + Decimal(2)
decimal context is implicit. But this is "implicit" from the
standpoint of that code.
On Wed, Aug 23, 2017 at 12:56 PM, Antoine Pitrou wrote:
> On Wed, 23 Aug 2017 12:19:40 -0400
> Yury Selivanov wrote:
>> PEP 550 calls generators and asynchronous tasks as "logical threads",
>> and "logical context" stems directly from that notion.
>
>
On Wed, Aug 23, 2017 at 2:47 PM, Guido van Rossum wrote:
> In favor of ImplicitContext is one point: it is indeed "implicit" if you
> compare it with the "explicit" way of passing state around, which would
> require an extra argument containing the state for any function that uses
> the state *or
> How about ExecutionContext and ContextVars ?
> We are already used to different levels of variables: global, local,
> non-local, class. I think having variables tied to a Context, and having
> search flow back to previous Contexts, would be easy to understand.
Yeah, I had this idea about Con
Hi Jim,
Sorry, I don't answer all questions/points directly. We are working
on a new version of the PEP that will hopefully address most of them.
Some comments inlined below:
On Thu, Aug 24, 2017 at 12:32 AM, Jim J. Jewett wrote:
[..]
> I still don't see how this is different from a ChainMap.
On Thu, Aug 24, 2017 at 9:52 AM, Barry Warsaw wrote:
> Guido van Rossum wrote:
>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>
>> I worry that that's going to lead more people astray thinking this has
>> something to do with contextlib, which it really doesn't (it's much more
>> clo
On Thu, Aug 24, 2017 at 10:05 AM, Jim J. Jewett wrote:
> On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017
> at 12:32 AM, Jim J. Jewett wrote:
>
>> The key requirement for using immutable datastructures is to make
>> "get_execution_context"
On Thu, Aug 24, 2017 at 10:38 AM, Barry Warsaw wrote:
[..]
I'll snip the naming discussion for now, I'm really curious to see
what other people will say.
> A different tack would more closely align with PEP 550’s heritage in
> thread-local storage, calling these things “execution storage”. I t
On Fri, Aug 25, 2017 at 9:23 AM, Nick Coghlan wrote:
[..]
> And while PEP 550 doesn't handle the stream redirection case natively
> (since it doesn't allow for suspend/resume callbacks the way PEP 525
> does), it at least allows for the development of a context-aware
> output stream wrapper API wh
Right, Nick, I missed the part that you want to have a file-like
wrapper stored in sys.std* streams that would redirect lookups/calls
to the relevant real file-object in the current context (correct?)
I has a similar idea when I discovered that PEP 550 can't be used
directly to fix sys.std* stream
On Fri, Aug 25, 2017 at 11:10 AM, Barry Warsaw wrote:
[..]
> It’s ideas like this that do make me think of scopes when talking about
> global state and execution contexts. I understand that the current PEP 550
> invokes an explicit separate namespace, but thinking bigger, if the usual
> patter
, and
will allow us to focus on refining the API.
Yury
PEP: 550
Title: Execution Context
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov ,
Elvis Pranskevichus
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Aug-2017
Python-Version: 3.7
Post
On Sat, Aug 26, 2017 at 7:45 AM, Stefan Krah wrote:
>
> Hi,
>
> thanks, on the whole this is *much* easier to understand.
Thanks!
> I'll add some comments on the decimal examples. The thing is, decimal
> is already quite tricky and people do read PEPs long after they have
> been accepted, so the
On Fri, Aug 25, 2017 at 10:19 PM, Ethan Furman wrote:
> All in all, I like it. Nice job.
Thanks!
>
> On 08/25/2017 03:32 PM, Yury Selivanov wrote:
>
>> A *context variable* is an object representing a value in the
>> execution context. A new context variable is c
On Sat, Aug 26, 2017 at 6:22 AM, Stefan Behnel wrote:
> Hi,
>
> I'm aware that the current implementation is not final, but I already
> adapted the coroutine changes for Cython to allow for some initial
> integration testing with real external (i.e. non-Python coroutine) targets.
> I haven't adapt
On Sat, Aug 26, 2017 at 9:33 AM, Sven R. Kunze wrote:
[..]
> Why not the same interface as thread-local storage? This has been the
> question which bothered me from the beginning of PEP550. I don't understand
> what inventing a new way of access buys us here.
This was covered at length in these t
On Sat, Aug 26, 2017 at 12:56 AM, David Mertz wrote:
> This is now looking really good and I can understands it.
Great!
>
> One question though. Sometimes creation of a context variable is done with a
> name argument, other times not. E.g.
>
> var1 = new_context_var('var1')
> var = new_conte
301 - 400 of 592 matches
Mail list logo
