[Python-ideas] Re: Need a core developer sponsor for a PEP

On Tue, Sep 17, 2019 at 4:55 PM Philippe Prados wrote: > > Hello, > > I would like to publish a new PEP (see here). > I discussed this idea here. > The PEP1 explains that I must have a sponsor. > > Who can help me ? To clarify: This is the proposal to allow type|type to represent a union, and ~ty

[Python-ideas] Re: Need a core developer sponsor for a PEP

Hi Philippe, Thanks for preparing the PEP! I also think it will improve the readability a lot in code that heavily uses type annotations. I'd suggest you to split this PEP in two: one for Union types and another one for Optional. It will facilitate the discussions and reaching consensus since thes

[Python-ideas] High level interface for loop.run_in_executor?

Hi, I noticed that in 3.7 a lot of high level functions have been added to the asyncio API, but nothing to start blocking functions as non-blocking threads. You still have to call get_event_loop() then await loop.run_in_executor(None, callable). Would an API like this make sense? async def run_t

[Python-ideas] Re: Need a core developer sponsor for a PEP

Since this proposal touches upon type checking I recommend that you take the proposal to typing-sig. That's where most typing-related proposals are discussed. On Mon, Sep 16, 2019 at 11:57 PM Philippe Prados wrote: > Hello, > > I would like to publish a new PEP (see here >

[Python-ideas] Re: Need a core developer sponsor for a PEP

Note that there is a related PEP 585, and the outcome for this one may depend on that PEP. Anyway, I agree this should go to typing-sig list. -- Ivan On Tue, 17 Sep 2019 at 07:58, Philippe Prados wrote: > Hello, > > I would like to publish a new PEP (see here >

[Python-ideas] Re: Need a core developer sponsor for a PEP

On Sep 16, 2019, at 23:54, Philippe Prados wrote: > > Hello, > > I would like to publish a new PEP (see here). > I discussed this idea here. Your PEP is missing any mention of some key issues that came up during the discussion, and I suspect you want to make it more complete before getting a

[Python-ideas] Re: Need a core developer sponsor for a PEP

On Sep 17, 2019, at 08:03, Ivan Levkivskyi wrote: > > Note that there is a related PEP 585, and the outcome for this one may depend > on that PEP. It seems like Phillipe could write two versions. If PEP 585 is accepted, then type.__or__ should not exist, and int|str should only work in annot

[Python-ideas] Dictionary Keys treated as Sets

related to: pep-0584, PEP-0218, and ??? The request is that since dictionary keys can not be duplicated / are unique that they may behave the same as sets - and have the set operators actions and return sets. eg.: aSet = set('a','b','c','bar') aDict = {'a':'aaa', 'b':'baa' , 'foo':fou' } bDict =

[Python-ideas] Re: Dictionary Keys treated as Sets

-1 strongly. This will hide crucial type errors. One could argue that aDict.keys() could behave as a set though. > On 17 Sep 2019, at 17:03, Rupert Spann wrote: > > > related to: pep-0584, PEP-0218, and ??? > > The request is that since dictionary keys can not be duplicated / are unique

[Python-ideas] Re: Dictionary Keys treated as Sets

Hi Rupert Welcome to the list, if this is your first time here. You wrote: > aSet = set('a','b','c','bar') Actually, Python isn't quite like that >>> aSet = set('a','b','c','bar') TypeError: set expected at most 1 arguments, got 4 I think you meant perhaps >>> aSet = set(['a','b','c','bar']) O

[Python-ideas] Re: Dictionary Keys treated as Sets

On Tue, Sep 17, 2019 at 8:19 PM Rupert Spann wrote: > > related to: pep-0584, PEP-0218, and ??? > > The request is that since dictionary keys can not be duplicated / are > unique that they may behave the same as sets - and have the set operators > actions and return sets. > This is a correct ob

[Python-ideas] Re: Dictionary Keys treated as Sets

Am 17.09.19 um 17:03 schrieb Rupert Spann: > > related to:  pep-0584, PEP-0218, and ??? > > The request is that since dictionary keys can not be duplicated / are unique > that they may behave the same as sets - and have the set operators actions and > return sets. > eg.: > > aSet = set('a','b','

[Python-ideas] Re: High level interface for loop.run_in_executor?

Rereading that, I think maybe create_thread() might make more sense, as it would be analog to create_task() with a similar behavior. Cheers, -- Antoine Pietri ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to pyth