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

2017-12-12 Thread Dima Tisnek
My 2c: TL;DR PEP specifies implementation in some detail, but doesn't show how proposed change can or should be used. get()/set(value)/delete() methods: Python provides syntax sugar for these, let's use it. (dict: d["k"]/d["k] = value/del d["k"]; attrs: obj.k/obj.k = value/del obj.k; inheriting

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

2017-12-12 Thread Yury Selivanov
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 don't think that we

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

2017-12-12 Thread Guido van Rossum
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 don't think that we should require PEP 550 for understanding of PEP 567. Maybe "This pro

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

2017-12-12 Thread Yury Selivanov
On Tue, Dec 12, 2017 at 9:55 PM, Guido van Rossum wrote: > On Tue, Dec 12, 2017 at 5:35 PM, Yury Selivanov > wrote: >> >> On Tue, Dec 12, 2017 at 6:49 PM, Victor Stinner >> wrote: >> > I like the overall idea and I prefer this PEP over PEP 550 since it's >> > shorter and easier to read :-) >> >

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

2017-12-12 Thread Guido van Rossum
On Tue, Dec 12, 2017 at 5:35 PM, Yury Selivanov wrote: > On Tue, Dec 12, 2017 at 6:49 PM, Victor Stinner > wrote: > > I like the overall idea and I prefer this PEP over PEP 550 since it's > > shorter and easier to read :-) > > > > Question: Is there an API to list all context variables? > > Cont

Re: [Python-Dev] [python/peps] PEP 567 review and copyedits (#503)

2017-12-12 Thread Yury Selivanov
On Tue, Dec 12, 2017 at 9:07 PM, Chris Angelico wrote: > Redirecting comments from the PR to the ML. Everything that was > tightly bound to the PR has been dropped. > > On Wed, Dec 13, 2017 at 12:15 PM, Yury Selivanov > wrote: >> Most of your questions should be asked on python-dev. I'll answer t

Re: [Python-Dev] [python/peps] PEP 567 review and copyedits (#503)

2017-12-12 Thread Chris Angelico
Redirecting comments from the PR to the ML. Everything that was tightly bound to the PR has been dropped. On Wed, Dec 13, 2017 at 12:15 PM, Yury Selivanov wrote: > Most of your questions should be asked on python-dev. I'll answer them here, > but if you have any follow-ups, please raise the on t

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

2017-12-12 Thread Yury Selivanov
Hi Victor, On Tue, Dec 12, 2017 at 6:49 PM, Victor Stinner wrote: > Hi Yury, > > I like the overall idea and I prefer this PEP over PEP 550 since it's > shorter and easier to read :-) > > Question: Is there an API to list all context variables? Context implements abc.Mapping, so 'get_context().k

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-12-12 Thread Victor Stinner
2017-12-13 0:24 GMT+01:00 Guido van Rossum : > Considered disagreement is acceptable. Sure, I'm fine with that ;-) > Nick, congrats with PEP 565! Please update the PEP to mark it as approved > with a link to this message as the resolution, and let's get the > implementation into 3.7a4! Nick wrot

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

2017-12-12 Thread Victor Stinner
Hi Yury, I like the overall idea and I prefer this PEP over PEP 550 since it's shorter and easier to read :-) Question: Is there an API to list all context variables? Would it be possible to have a very summary of the changes in the PEP? I propose: """ * Added contextvars module with ContextVar

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-12-12 Thread Guido van Rossum
OK, in that case I'll just pronounce approval right here. Considered disagreement is acceptable. Nick, congrats with PEP 565! Please update the PEP to mark it as approved with a link to this message as the resolution, and let's get the implementation into 3.7a4! On Tue, Dec 12, 2017 at 2:58 PM, V

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-12-12 Thread Victor Stinner
Hi, 2017-12-12 21:21 GMT+01:00 Guido van Rossum : > I'm still hoping to accept this PEP, but I don't have time to wrap my head > around -Xdev ("devmode"?) which appears to be Victor's latest pet project. > Should PEP 565 be changed to copy with devmode's behavior, or the other way > around, or sho

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-12-12 Thread Guido van Rossum
Nick and Victor, I'm still hoping to accept this PEP, but I don't have time to wrap my head around -Xdev ("devmode"?) which appears to be Victor's latest pet project. Should PEP 565 be changed to copy with devmode's behavior, or the other way around, or should they just ignore each other? It is no

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-12 Thread Chris Angelico
On Wed, Dec 13, 2017 at 6:03 AM, Guido van Rossum wrote: > And I'll never approve syntax to make it easier to just ignore all > exceptions without looking at them. Well, I certainly wouldn't advocate "except Exception: -1", but the syntax is the same as "except KeyError: -1" which is less unreaso

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-12 Thread Guido van Rossum
And I'll never approve syntax to make it easier to just ignore all exceptions without looking at them. On Tue, Dec 12, 2017 at 12:48 AM, Chris Angelico wrote: > On Tue, Dec 12, 2017 at 7:39 PM, Michel Desmoulin > wrote: > > > > > > Le 29/11/2017 à 19:02, Barry Warsaw a écrit : > >> On Nov 29, 2

[Python-Dev] PEP 567 -- Context Variables

2017-12-12 Thread Yury Selivanov
Hi, This is a new proposal to implement context storage in Python. It's a successor of PEP 550 and builds on some of its API ideas and datastructures. Contrary to PEP 550 though, this proposal only focuses on adding new APIs and implementing support for it in asyncio. There are no changes to th

Re: [Python-Dev] Support of the Android platform

2017-12-12 Thread Victor Stinner
2017-12-12 15:02 GMT+01:00 Antoine Pitrou : > It sounds reasonable to me, as long as someone is monitoring their > results (that would probably be you). There is now the buildbot-status where failures are reported. Trust me, I like making a lot of noise when something is broken :-) FYI I'm trying

Re: [Python-Dev] Support of the Android platform

2017-12-12 Thread Antoine Pitrou
On Tue, 12 Dec 2017 10:50:53 +0100 Xavier de Gaye wrote: > On 12/11/2017 04:14 PM, Victor Stinner wrote: > > I'm asking for precise hardware specifications since Red Hat may be > > able to provide one through the https://osci.io/ program. > > Is it acceptable to run the arm buildbots only on

Re: [Python-Dev] Support of the Android platform

2017-12-12 Thread Xavier de Gaye
On 12/11/2017 04:14 PM, Victor Stinner wrote: > I'm asking for precise hardware specifications since Red Hat may be > able to provide one through the https://osci.io/ program. Is it acceptable to run the arm buildbots only on a weekly basis ? For all the architectures (x86_64, armv7 and arm64),

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

2017-12-12 Thread Eric V. Smith
On 12/11/2017 9:25 PM, Nick Coghlan wrote: On 11 Dec. 2017 12:26 pm, "Eric V. Smith" > wrote: I see a couple of options: 1a: Use a default type annotation, if one is not is supplied. typing.Any would presumably make the most sense. 1b: Use None if not

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-12 Thread Chris Angelico
On Tue, Dec 12, 2017 at 7:39 PM, Michel Desmoulin wrote: > > > Le 29/11/2017 à 19:02, Barry Warsaw a écrit : >> On Nov 29, 2017, at 12:40, David Mertz wrote: >> >>> I think some syntax could be possible to only "catch" some exceptions and >>> let others propagate. Maybe: >>> >>>val = name.s

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-12 Thread Michel Desmoulin
Le 29/11/2017 à 19:02, Barry Warsaw a écrit : > On Nov 29, 2017, at 12:40, David Mertz wrote: > >> I think some syntax could be possible to only "catch" some exceptions and >> let others propagate. Maybe: >> >>val = name.strip()[4:].upper() except (AttributeError, KeyError): -1 >> >> I do