[Python-Dev] Re: PEP 654 except* formatting

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

[Python-Dev] Re: Accepting PEP 654.

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

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

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: >>

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

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

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

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

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

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

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

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

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

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

[Python-Dev] Re: aiter/anext review request

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

[Python-Dev] Re: aiter/anext review request

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

[Python-Dev] Re: aiter/anext review request

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, Jul 17, 2020 at 3:54 PM Guido van Rossum wrote: > > On Fri, Jul 17, 2020 at 1:45 PM Yury Selivanov > wrote: >> >> I've built the reference implementation and I'm experimenting with the >> new syntax in the edgedb codebase. It seems to have plenty of places >

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

I've built the reference implementation and I'm experimenting with the new syntax in the edgedb codebase. It seems to have plenty of places where pattern matching adds clarity. I'll see if I find particularly interesting examples of that to share. So far I'm +1 on the proposal, and I like the

Re: [Python-Dev] Lost sight

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

Re: [Python-Dev] Documenting the private C API (was Re: Questions about signal handling.)

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

Re: [Python-Dev] Documenting the private C API (was Re: Questions about signal handling.)

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

Re: [Python-Dev] Questions about signal handling.

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 >

Re: [Python-Dev] Questions about signal handling.

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

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

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

Re: [Python-Dev] Late Python 3.7.1 changes to fix the C locale coercion (PEP 538) implementation

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-PyObject

Re: [Python-Dev] Late Python 3.7.1 changes to fix the C locale coercion (PEP 538) implementation

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

Re: [Python-Dev] Use of Cython

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

Re: [Python-Dev] Use of Cython

tion 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.2018 um 19:34: &

Re: [Python-Dev] Use of Cython

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

Re: [Python-Dev] Finding Guido's replacement

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

Re: [Python-Dev] Finding Guido's replacement

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.

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

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 >

Re: [Python-Dev] Examples for PEP 572

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 snip

Re: [Python-Dev] Examples for PEP 572

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

Re: [Python-Dev] A more flexible task creation

On Thu, Jun 14, 2018 at 12:40 PM Tin Tvrtković wrote: > > Hi, > > I've been using asyncio a lot lately and have encountered this problem > several times. Imagine you want to do a lot of queries against a database, > spawning 1 tasks in parallel will probably cause a lot of them to fail. >

Re: [Python-Dev] A more flexible task creation

On Wed, Jun 13, 2018 at 4:47 PM Michel Desmoulin wrote: > > I was working on a concurrency limiting code for asyncio, so the user > may submit as many tasks as one wants, but only a max number of tasks > will be submitted to the event loop at the same time. What does that "concurrency limiting

Re: [Python-Dev] Idea: reduce GC threshold in development mode (-X dev)

On Fri, Jun 8, 2018 at 9:24 AM Ronald Oussoren wrote: [..] > Wouldn’t it be enough to visit just the the newly tracked object in > PyObject_GC_Track with a visitor function that does something minimal to > verify that the object value is sane, for example by checking >

Re: [Python-Dev] Why not using "except: (...) raise" to cleanup on error?

On Mon, Jun 4, 2018 at 3:38 PM Victor Stinner wrote: > > 2018-06-04 18:45 GMT+02:00 Guido van Rossum : > > It is currently a general convention in asyncio to only catch Exception, not > > BaseException. I consider this a flaw and we should fix it, but it's > > unfortunately not so easy -- the

Re: [Python-Dev] Why not using "except: (...) raise" to cleanup on error?

On Mon, Jun 4, 2018 at 12:50 PM Chris Angelico wrote: > > On Tue, Jun 5, 2018 at 2:11 AM, Victor Stinner wrote: [..] > > For me, it's fine to catch any exception using "except:" if the block > > contains "raise", typical pattern to cleanup a resource in case of > > error. Otherwise, there is a

Re: [Python-Dev] Why not using "except: (...) raise" to cleanup on error?

> It is currently a general convention in asyncio to only catch Exception, not > BaseException. I consider this a flaw and we should fix it, but it's > unfortunately not so easy -- the tests will fail if you replace all > occurrences of Exception with BaseException, and it is not always clear

Re: [Python-Dev] Reminder: Please elaborate commit messages

On Tue, May 22, 2018 at 8:52 AM Victor Stinner wrote: > Usually, I don't open a new bug to fix or enhance a test. So I > wouldn't say that it's mandatory. It's really on a case by case basis. > It seems like test_asyncio failures are a hot topic these days :-) > It's one of

Re: [Python-Dev] please help triage VSTS failures

On Fri, May 18, 2018 at 4:15 PM Steve Dower wrote: [..] > The asyncio instability is apparently really hard to fix. There were 2-3 people looking into it yesterday on one of the other systems, but apparently we haven’t solved it yet (my guess is lingering state from a

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, Apr 30, 2018 at 1:03 PM Chris Angelico wrote: > > That's a weird argument, Chris :-) > > > > If `f(x)` has no meaningful name, then *what* is the result of the > > comprehension? Perhaps some meaningless data? ;) > f(x) might have side effects. Can you give a

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, Apr 30, 2018 at 11:32 AM Chris Angelico wrote: > On Tue, May 1, 2018 at 12:30 AM, Mark Shannon wrote: > > List comprehensions > > --- > > The PEP uses the term "simplifying" when it really means "shortening". > > One example is > > stuff

Re: [Python-Dev] Review of Pull Request 5974 please

Reviewed. This seems to be an omission that needs to fixed, thanks for the PR! Almost good to go in 3.8. As for 3.7, this isn't a bug fix it's up to Ned if he wants to accept it. Yury On Sun, Apr 29, 2018 at 8:02 AM Anthony Flury via Python-Dev < python-dev@python.org> wrote: > All, > Can

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, Apr 25, 2018 at 8:22 PM Chris Angelico wrote: [..] > > my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf)) > > > > To my eye this is an anti-pattern. One line of code was saved, but the > > other line becomes less readable. The fact that 'buf' can

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, Apr 25, 2018 at 5:58 PM Guido van Rossum wrote: [..] > It was meant dismissive. With Chris, I am tired of every core dev starting their own thread about how PEP 572 threatens readability or doesn't reach the bar for new syntax (etc.). These arguments are entirely

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 12:03 PM, Ethan Furman wrote: [..] > But I do write this: > > def wrapper(func, some_value): > value_I_want = process(some_value) > def wrapped(*args, **kwds): > if value_I_want == 42: > ... But this pattern is more rare than

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:58 AM, Chris Angelico <ros...@gmail.com> wrote: > On Wed, Apr 25, 2018 at 1:49 AM, Yury Selivanov <yselivanov...@gmail.com> > wrote: >> On Tue, Apr 24, 2018 at 11:34 AM, Steven D'Aprano <st...@pearwood.info> >> wrote: [..] >&

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:51 AM, Ethan Furman wrote: >> When I compare to variables from outer scopes they *usually* are on >> the *right* side of '=='. > > > You mean something like > > if 2 == x: > > ? I never write code like that, and I haven't seen it, either. Hm. I

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:34 AM, Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, Apr 24, 2018 at 11:05:57AM -0400, Yury Selivanov wrote: > >> Well, `my_func(a=(b:=foo))` or `my_func(b:=foo)` are also barely >> readable to my eye. > > There's no advantage to us

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:28 AM, Chris Angelico wrote: > On re-thinking this, I think the distinction IS possible, but (a) only > in function/class scope, not at global; and (b) would be defined in > terms of lexical position, not run-time. For instance: > > def f(): > (a

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:27 AM, Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, Apr 24, 2018 at 11:03:35AM -0400, Yury Selivanov wrote: > >> My point was that when you see lots of '=' and ':=' used at the >> statement level, one might try to write "if x

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:31 AM, Nick Coghlan wrote: > On 25 April 2018 at 00:54, Eric Snow wrote: >> Regardless, your 3 rules would benefit either syntax. Nick may have a >> point that the rules might be an excessive burden, but I don't think

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:15 AM, Steven D'Aprano wrote: [..] >> >> 3. Most importantly: it is *not* allowed to mask names in the current >> >> local scope. > > That means you can't rebind existing variables. That means you can't > rebind to the same variable in a loop. No,

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:07 AM, Chris Angelico wrote: [..] > x = 1 > if (x = 2): ... > > This, according to your proposal, raises SyntaxError - not because a > comparison was wanted and an assignment was made, but because the name > already had a value. And, even worse, this

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:54 AM, Anthony Flury via Python-Dev wrote: [..] > As discussed previously by others on this exact proposals, you now have the > issue of confusion when using keyword arguments : *my_func(a = b)* : > clearly that is a call to `my_func' where

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote: [..] >>> 3. Most importantly: it is *not* allowed to mask names in the current >>> local scope. >> >> While I agree this would be unambiguous to a computer, I think for >> most humans it would be experienced as a confusing

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:56 AM, Chris Angelico wrote: [..] >> A lot of other questions arise though. PEP 572 proposes: >> >> a = 1 # assignment >> a := 1 # also assignment >> (a := 1) # also assignment >> (a = 1) # error, why? > > Your third example is just the same as

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:07 AM, Nick Coghlan wrote: >> "=" is always an assignment. >> "==" is always an equality check. > > That's not the distinction I meant, I meant the difficulty of > explaining the discrepancies in this list: > > a = 1 # Assignment > (a = 1) # Also

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 24 April 2018 at 23:38, Yury Selivanov <yselivanov...@gmail.com> wrote: >> I propose to use the following syntax for assignment expressions: >> >> ( NAME = expr ) >>

[Python-Dev] assignment expressions: an alternative proposal

I propose to use the following syntax for assignment expressions: ( NAME = expr ) I know that it was proposed before and this idea was rejected, because accidentally using '=' in place of '==' is a pain point in C/C++/JavaScript. That said, I believe we can still use this syntax as long as

Re: [Python-Dev] PEP 572: Assignment Expressions

Hi Chris, Thank you for working on this PEP! Inline assignments is a long requested feature and this seems to be the first serious attempt at adding it. That said I'm very -1 on the idea. 1. I switch between Python / JavaScript / C frequently (although I code in Python 70% of my time.) C and

Re: [Python-Dev] How is the GitHub workflow working for people?

On Wed, Feb 21, 2018 at 10:27 PM, Guido van Rossum wrote: [..] > I honestly expect that running either with close-to-default flags on stdlib > code would be a nightmare, and I wouldn't want *any* directives for either > one to appear in stdlib code, ever. It would be great to

Re: [Python-Dev] How is the GitHub workflow working for people?

FWIW I'm extremely happy with the current workflow. The recent improvements to @miss-islington (kudos to Mariatta!) allowing her to auto-backport PRs and commit them is a big time saver. I can only suggest a couple improvements: 1. Make our bots check the code style—fully enforce PEP 8, lint the

Re: [Python-Dev] Dataclasses and correct hashability

On Fri, Feb 2, 2018 at 10:51 AM, Paul Moore wrote: [..] > To put it another way, using your words above, "The moment you want to > use a dataclass a a dict key, or put it in a set, you need it to be > *immutable*" (not hashable, unless you really know what you're doing). Can

Re: [Python-Dev] Is static typing still optional?

On Mon, Jan 29, 2018 at 1:36 AM Nick Coghlan wrote: > [...] > Currently the answers are: > > - A: not hashable > - B: hashable (by identity) # Wat? > - C: hashable (by field hash) > - D: hashable (by identity) # Wat? > - E: hashable (by field hash) > - F: hashable (by field

Re: [Python-Dev] Merging the implementation of PEP 563

I looked at the PR and I think the code is fine. Yury On Thu, Jan 25, 2018 at 4:39 PM, Victor Stinner wrote: > Hi, > > If nobody is available to review your PR, I suggest to push it anyway, > to get it merged before the feature freeze. The code can be reviewed > later.

Re: [Python-Dev] Intention to accept PEP 567 (Context Variables)

Yay! Thank you, Guido! Yury On Mon, Jan 22, 2018 at 6:52 PM, Guido van Rossum wrote: > Yury, > > I am hereby *accepting* the latest version of PEP 567[1]. Congrats! > > --Guido > > [1] >

Re: [Python-Dev] PEP 567 v3

On Wed, Jan 17, 2018 at 8:53 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Wed, Jan 17, 2018 at 2:24 PM, Guido van Rossum <gvanros...@gmail.com> > wrote: >> Perhaps you can update the PEP with a summary of the rejected ideas from >> this thread?

Re: [Python-Dev] PEP 567 v3

On Wed, Jan 17, 2018 at 2:24 PM, Guido van Rossum wrote: > Perhaps you can update the PEP with a summary of the rejected ideas from > this thread? The Rejected Ideas section of the PEP is now updated with the below: Token.reset() instead of ContextVar.reset()

Re: [Python-Dev] PEP 567 v3

On Wed, Jan 17, 2018 at 6:03 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Tue, 16 Jan 2018 17:18:06 -0800 > Nathaniel Smith <n...@pobox.com> wrote: >> On Tue, Jan 16, 2018 at 5:06 PM, Yury Selivanov <yselivanov...@gmail.com> >> wrote: >> >

Re: [Python-Dev] PEP 567 v3

On Tue, Jan 16, 2018 at 8:27 PM, Nathaniel Smith wrote: [..] > token = cvar.set(...) > token.reset() I see the point, but I think that having the 'reset' method defined on the ContextVar class is easier to grasp. It also feels natural that a pair of set/reset methods is defined

Re: [Python-Dev] PEP 567 v3

On Tue, Jan 16, 2018 at 7:45 PM, Guido van Rossum <gu...@python.org> wrote: > On Tue, Jan 16, 2018 at 4:37 PM, Antoine Pitrou <solip...@pitrou.net> wrote: >> >> On Tue, 16 Jan 2018 17:44:14 -0500 >> Yury Selivanov <yselivanov...@gmail.com> wrote: >&g

Re: [Python-Dev] PEP 567 v3

Thanks, Victor! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 567 v3

On Tue, Jan 16, 2018 at 6:53 PM, Guido van Rossum wrote: > On Tue, Jan 16, 2018 at 3:26 PM, Victor Stinner [..] >> I don't think that it's worth it to prevent misuage of reset(). IMHO >> it's fine if calling reset() twice reverts the variable state

[Python-Dev] PEP 567 v3

: Yury Selivanov <y...@magic.io> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 12-Dec-2017 Python-Version: 3.7 Post-History: 12-Dec-2017, 28-Dec-2017, 16-Jan-2018 Abstract This PEP proposes a new ``contextvars`` module and a set of new CPython C APIs to s

Re: [Python-Dev] PEP 567 pre v3

On Thu, Jan 11, 2018 at 10:35 AM, Chris Jerdonek wrote: > On Mon, Jan 8, 2018 at 11:02 PM, Nathaniel Smith wrote: >> Right now, the set of valid states for a ContextVar are: it can hold >> any Python object, or it can be undefined. However, the only way

Re: [Python-Dev] PEP 567 pre v3

On Thu, Jan 11, 2018 at 10:39 AM, Ethan Furman <et...@stoneleaf.us> wrote: > On 01/10/2018 10:23 PM, Yury Selivanov wrote: [..] >> Therefore I'm still in favour of keeping the current PEP 567 >> behaviour. > > > To be clear: We'll now be able to specify a default

Re: [Python-Dev] PEP 567 pre v3

On Thu, Jan 11, 2018 at 4:44 AM, Nathaniel Smith wrote: [..] > It may have gotten lost in that email, but my actual favorite approach > is that we make the signatures: > > ContextVar(name, *, initial_value) # or even (*, name, initial_value) > ContextVar.get() >

Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568

Wasn't PEP 555 rejected by Guido? What's the point of this post? Yury On Wed, Jan 10, 2018 at 4:08 AM Koos Zevenhoven wrote: > Hi all, > > I feel like I should write some thoughts regarding the "context" > discussion, related to the various PEPs. > > I like PEP 567 (+ 567 ?)

Re: [Python-Dev] PEP 567 pre v3

com> wrote: > 2018-01-09 12:41 GMT+01:00 Yury Selivanov <yselivanov...@gmail.com>: > > But I'd be -1 on making all ContextVars have a None default > > (effectively have a "ContextVar.get(default=None)" signature. This > > would be a very loose semantics in

Re: [Python-Dev] PEP 567 pre v3

On Tue, Jan 9, 2018 at 11:02 AM, Nathaniel Smith <n...@pobox.com> wrote: > On Mon, Jan 8, 2018 at 11:34 AM, Yury Selivanov <yselivanov...@gmail.com> > wrote: >> 1. Proposal: ContextVar has default set to None. >> >> From the typing point of view that woul

Re: [Python-Dev] PEP 567 v2

> On Jan 9, 2018, at 11:18 AM, Nathaniel Smith wrote: > >> On Thu, Jan 4, 2018 at 9:42 PM, Guido van Rossum wrote: >>> On Thu, Jan 4, 2018 at 7:58 PM, Nathaniel Smith wrote: >>> This does make me think that I should write up a short PEP for

[Python-Dev] PEP 567 pre v3

Hi, Thanks to everybody participating in the PEP 567 discussion! I want to summarize a few topics to make sure that we are all on the same page (and maybe provoke more discussion). 1. Proposal: ContextVar has default set to None. >From the typing point of view that would mean that if a

Re: [Python-Dev] PEP 567 v2

I think we can expose the default property. If it's not set we can return MISSING. Yury Sent from my iPhone > On Jan 3, 2018, at 1:04 PM, Victor Stinner wrote: > > Le 3 janv. 2018 06:38, "Guido van Rossum" a écrit : > But is there a common use

Re: [Python-Dev] PEP 567 v2

> On Jan 3, 2018, at 12:26 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > > Le 3 janv. 2018 06:05, "Yury Selivanov" <yselivanov...@gmail.com> a écrit : > tuples in Python are immutable, but you can have a tuple with a dict as its > single elem

Re: [Python-Dev] PEP 567 v2

I don't want to expose a SetContext operation because of, again, potential incompatibility with PEP 550, where generators expect to fully control push/pop context operation. Second, Context.run is 100% enough for *any* async framework to add support for PEP 567. And because the PEP is focused

Re: [Python-Dev] PEP 567 v2

On Wed, Jan 3, 2018 at 3:04 AM Victor Stinner wrote: > What is the behaviour of ContextVar.reset(token) if the token was created > from a different variable? Raise an exception? > > token = var1.set("value") > var2.reset(token) > > The PEP states that Token.var only

Re: [Python-Dev] PEP 567 v2

On Wed, Jan 3, 2018 at 2:36 AM Victor Stinner wrote: > > I would really like to invite more people to review this PEP! I expect > I'll be accepting it in the next two weeks, but it needs to go through more > rigorous review. > > I read again the PEP and I am still very

Re: [Python-Dev] PEP 567 v2

On Thu, Dec 28, 2017 at 4:51 AM, Victor Stinner wrote: > Hi, > > I like the new version of the PEP using "read only mapping" and > copy_context(). It's easier to understand. Thanks, Victor! > > I'm ok with seeing a context as a mapping, but I am confused about a

Re: [Python-Dev] PEP 567 v2

On Thu, Dec 28, 2017 at 5:28 AM, Chris Jerdonek wrote: > I have a couple basic questions around how this API could be used in > practice. Both of my questions are for the Python API as applied to Tasks in > asyncio. > > 1) Would this API support looking up the value of a

[Python-Dev] PEP 567 v2

it is really doing. 4. Few clarifications/edits here and there to address earlier feedback. Yury PEP: 567 Title: Context Variables Version: $Revision$ Last-Modified: $Date$ Author: Yury Selivanov <y...@magic.io> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 12-Dec-2017

Re: [Python-Dev] PEP 567 -- Context Variables

On Mon, Dec 18, 2017 at 6:00 PM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 13 December 2017 at 22:35, Yury Selivanov <yselivanov...@gmail.com> > wrote: >> >> [..] >> >> A new standard library module ``contextvars`` is added >> > >>

Re: [Python-Dev] PEP 567 -- Context Variables

> 3. The connection pool has a queue, and creates a task for each connection to > serve requests from that queue. Naively, each task could inherit the context > of the request that caused it to be created, but the task would outlive the > request and go on to serve other requests. The

Re: [Python-Dev] PEP 567 -- Context Variables

Hi Ben, On Sun, Dec 17, 2017 at 10:38 AM, Ben Darnell <b...@bendarnell.com> wrote: > On Tue, Dec 12, 2017 at 12:34 PM Yury Selivanov <yselivanov...@gmail.com> > wrote: >> >> Hi, >> >> This is a new proposal to implement context storage in Python. &g

Re: [Python-Dev] Make __class_getitem__ a class method

On Fri, Dec 15, 2017 at 12:45 PM, Serhiy Storchaka <storch...@gmail.com> wrote: > 15.12.17 18:47, Yury Selivanov пише: >> >> Shouldn't we optimize the usability for pure-Python first, and then for C >> API? >> >> Right now we have the '__new__' magic method,

Re: [Python-Dev] Make __class_getitem__ a class method

Shouldn't we optimize the usability for pure-Python first, and then for C API? Right now we have the '__new__' magic method, which isn't a @classmethod. Making '__class_getitem__' a @classmethod will confuse regular Python users. For example: class Foo: def __new__(cls, ...): pass

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

> I don't see any problems with implementing this on types defined in C. This > isn't harder than implementing __sizeof__ or pickling support, and NumPy > classes already have implemented both. Maybe Yury forgot about METH_STATIC > and METH_CLASS? I just tested __class_getitem__ defined via

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

On Thu, Dec 14, 2017 at 9:00 PM, Guido van Rossum wrote: > In the light of Antoine's and Stephan's feedback I think this can be > reconsidered -- while I want to take a cautious stance about resource > consumption I don't want to stand in the way of progress. I've created an

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

On Thu, Dec 14, 2017 at 7:03 PM, Guido van Rossum wrote: > A slot is pretty expensive, as *every* class in existence will be another 8 > bytes larger (and possibly more due to malloc rounding). So unless we find > that there's a significant performance benefit I think we should

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

Ivan, Guido, Would it be possible to add a slot so that types defined in C can implement __class_getitem__? static PyClassMethodDef class_methods = { foo_class_getitem /* cm_class_getitem */ } static PyTypeObject Foo = { .tp_class_methods = class_methods } Yury On Mon, Dec 4, 2017

Re: [Python-Dev] PEP 567 -- Context Variables

omments in-line below. > > -eric > > On Tue, Dec 12, 2017 at 10:33 AM, Yury Selivanov > <yselivanov...@gmail.com> wrote: >> This is a new proposal to implement context storage in Python. > > +1 > > This is something I've had on my back burner for years. G

Re: [Python-Dev] PEP 567 -- Context Variables

On Tue, Dec 12, 2017 at 10:36 PM, Guido van Rossum wrote: > Some more feedback: > >> This proposal builds directly upon concepts originally introduced >> in :pep:`550`. > > The phrase "builds upon" typically implies that the other resource must be > read and understood first. I

Re: [Python-Dev] PEP 567 -- Context Variables

On Tue, Dec 12, 2017 at 9:55 PM, Guido van Rossum <gu...@python.org> wrote: > On Tue, Dec 12, 2017 at 5:35 PM, Yury Selivanov <yselivanov...@gmail.com> > wrote: >> >> On Tue, Dec 12, 2017 at 6:49 PM, Victor Stinner >> <victor.stin...@gmail.com> wrote:

  1   2   3   4   5   6   >