[Python-ideas] PEP 505 -- None-aware operators

Sorry if I missed the boat, but only just now saw this PEP. Glancing through the PEP, I don't see mentioned anywhere the SQL alternative of having a coalesce() function: https://www.postgresql.org/docs/9.6/static/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL In Python, something like

Re: [Python-ideas] PEP 505 -- None-aware operators

On 14 October 2016 at 14:19, אלעזר <elaz...@gmail.com> wrote: > On Fri, Oct 14, 2016 at 4:14 PM Gustavo Carneiro <gjcarne...@gmail.com> > wrote: > >> Sorry if I missed the boat, but only just now saw this PEP. >> >> Glancing through the PEP, I don't see me

Re: [Python-ideas] Null coalescing operator

On 28 October 2016 at 14:13, Barry Warsaw wrote: > On Oct 27, 2016, at 07:37 PM, Nick Badger wrote: > > >The problem with doing that is that it's ambiguous. There's no way of > >telling which attribute is allowed to coalesce. > > You could of course support exactly the same

Re: [Python-ideas] Null coalescing operator

For what it's worth, I like the C# syntax with question marks. It is probably more risky (breaks more code) to introduce a new keyword than a new symbol as operator. If we have to pick a symbol, it's less confusing if we pick something another language already uses. There is no shame in copying

Re: [Python-ideas] Inline assignments using "given" clauses

On Thu, 10 May 2018 at 16:49, Ed Kellett wrote: > On 2018-05-10 16:10, Guido van Rossum wrote: > > Please no, it's not that easy. I can easily generate a stream of +1s or > -1s > > for any proposal. I'd need well-reasoned explanations and it would have > to > > come

Re: [Python-ideas] Add function readbyte to asyncio.StreamReader

Well, even if it is worth, i.e. your use case is not rare enough, I would suggest at least making it private, readexactly can call this specialised function if nbytes==1: def _readbyte(self): def readexactly(self, num): if num == 1: return self._readbyte() ... the rest stays

Re: [Python-ideas] Executable space protection: NX bit,

I'm not a security expert, but I believe the NX bit is a hardware protection against a specific class of attack: buffer overflow attacks. These attacks are possible because of the lack of safety in the C programming language: it is very easy for a programmer to forget to check the bounds of a

Re: [Python-ideas] Why operators are useful

On Sat, 16 Mar 2019 at 10:33, Steven D'Aprano wrote: > On Fri, Mar 15, 2019 at 10:53:31PM +, MRAB wrote: > > > There was also the suggestion of having both << and >>. > > > > Actually, now that dicts are ordered, that would provide a use-case, > > because you would then be able to choose

[Python-ideas] Re: Add «iterate non-blocking» wrapper to prevent blocking loop too long

On Fri, 14 Jun 2019 at 12:00, Nikita Melentev wrote: > > The problem is that the snippet itself is not very helpful. > > Explain please. > > The good thing is that, if this snippet will be somewhere (asyncio or > docs), then user will not decide by its own about "what is a long running > task",

[Python-ideas] Re: Add «iterate non-blocking» wrapper to prevent blocking loop too long

On Sat, 15 Jun 2019 at 00:26, Greg Ewing wrote: > Gustavo Carneiro wrote: > > 1. If you don't yield in the for loop body, then you are blocking the > > main loop for 1 second; > > > > 2. If you yield in every iteration, you solved the task switch latency > >

Re: [Python-ideas] Break multiple loop levels

On Sun, 12 May 2019 at 18:26, David Mertz wrote: > To be clear in this thread, I don't think I'm really ADVOCATING for a > multi-level break. My comments are simply noting that I personally fairly > often encounter the situation where they would be useful. At the same > time, I worry about

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

I think the "foo | bar" syntax for Union is pretty clear, I like it! The ~foo for Optional is... not that obvious. Not sure it's a win. On Thu, 29 Aug 2019 at 13:49, Philippe Prados wrote: > Hello everybody, > > Scala 3 propose the a new syntax for Union type. See here >

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

On Thu, 29 Aug 2019 at 14:58, Ricky Teachey wrote: > I like this idea. > > >> The ~foo for Optional is... not that obvious. Not sure it's a win. >> >> > I agree. Seems like `foo | None` is just as readable. Assuming that None > would be swapped out for NoneType, of course. > Agreed, `foo |

[Python-ideas] Re: Simpler syntax for async generators

On Sat, 14 Sep 2019 at 16:26, George Fischhof wrote: > Hi All, > > While I was reading the documentation of asyn generators, > which shows the following example: > > > async def ticker(delay, to): > """Yield numbers from 0 to *to* every *delay* seconds.""" > for i in range(to): >

[Python-ideas] Re: Alternate lambda syntax

On Wed, 17 Feb 2021 at 18:30, Ethan Furman wrote: > On 2/17/21 8:47 AM, Random832 wrote: > > On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote: > > >> except a couple of characters. So what currently looks like > >> > >> some_list.sort(key=lambda e: e[3].priority) > >> > >> would

[Python-ideas] Re: Proposal: Python Native bindings for OpenAPI

You may want to take a look at FastAPI[1], it already does more or less what you ask for. There is no need for it to be part of the Python core, it's fine as it is as a package. [1] https://fastapi.tiangolo.com/ On Fri, 6 Aug 2021 at 17:39, Vaideeswaran Ganesan wrote: > OpenAPI

[Python-ideas] Re: Add timeout parameter to Synchronization Primitives in asyncio

Note that you can wrap any of those methods with an asyncio.wait_for(). try: try: await asyncio.wait_for(lock.acquire(), 1.0) except asyncio.TimeoutError: # times out after 1 second print("deadlock!") return do_things_with_lock() finally: lock.release()

[Python-ideas] Re: Add timeout parameter to Synchronization Primitives in asyncio

On Mon, 20 Sept 2021 at 13:15, Chris Angelico wrote: > On Mon, Sep 20, 2021 at 9:48 PM Gustavo Carneiro > wrote: > > > > Note that you can wrap any of those methods with an asyncio.wait_for(). > > > > try: > >try: > >await asyncio.w