Re: [Python-ideas] async objects

Nathaniel Smith wrote: It wasn't that we created these keywords to solve some implementation problem and then inflicted them on users. I disagree -- looking at the history of how we ended up with async/await, it looks to me like this is exactly what *did* happen. First we had generators. Then

Re: [Python-ideas] async objects

> On 06 Oct 2016, at 07:15, Stephen J. Turnbull > wrote: > > Nick Coghlan writes: > >> Python's core runtime model is the C runtime model: threads (with a >> local stack and access to a global process heap) and processes (which >> contain a heap and one or

Re: [Python-ideas] async objects

On Thu, Oct 6, 2016 at 12:45 AM, Greg Ewing wrote: > Nathaniel Smith wrote: >> >> It wasn't that we created these keywords to solve some >> implementation problem and then inflicted them on users. > > > I disagree -- looking at the history of how we > ended up with

Re: [Python-ideas] async objects

On 6 October 2016 at 05:20, Sven R. Kunze wrote: > On 05.10.2016 18:06, Nick Coghlan wrote: >> >> [runtime matters] > > > I think I understand your point. > > I also hope that others and me could provide you with our perspective. We > see Python not as a C-like runtime but as an

Re: [Python-ideas] Add "equal" builtin function

On 6 October 2016 at 14:45, Filipp Bakanov wrote: > For now there are many usefull builtin functions like "any", "all", etc. I'd > like to propose a new builtin function "equal". It should accept iterable, > and return True if all items in iterable are the same or iterable is

Re: [Python-ideas] async objects

On 6 October 2016 at 15:15, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > Python's core runtime model is the C runtime model: threads (with a > > local stack and access to a global process heap) and processes (which > > contain a heap and one or

[Python-ideas] Add "equal" builtin function

For now there are many usefull builtin functions like "any", "all", etc. I'd like to propose a new builtin function "equal". It should accept iterable, and return True if all items in iterable are the same or iterable is emty. That's quite popular problem, there is a discussion of how to perform

Re: [Python-ideas] async objects

Nathaniel Smith wrote: The core distinguishing feature between async/await and gevent is the visibility of suspension points, so it might as well be the case that async/await is designed for exactly those people who want visible suspension points. They're not quite independent axes, though.

[Python-ideas] str(slice(10)) should return "slice(10)"

Currently str(slice(10)) returns "slice(None, 10, None)" If the start and step are None, consider not emitting them. Similarly slice(None) is rendered slice(None, None, None). When you're printing a lot of slices, it's a lot of extra noise. ___

Re: [Python-ideas] async objects

Nick Coghlan wrote: When a language usage pattern is supported for that long, but folks still don't grok how it might benefit them, you have a UX problem, and one of the ways to address it is to take the existing pattern and give it dedicated syntax, which is exactly what PEP 492 did. However,

Re: [Python-ideas] async objects

Yury Selivanov wrote: To start, no matter how exactly you want to approach this, it would require us to do a *complete rewrite* of CPython internals. This is so complex that we wouldn't be able to even estimate how long it would take us. You could ask the author of Stackless -- he did

Re: [Python-ideas] Add "equal" builtin function

On Thu, Oct 06, 2016 at 03:01:36PM +0100, Paul Moore wrote: > On 6 October 2016 at 14:45, Filipp Bakanov wrote: > > For now there are many usefull builtin functions like "any", "all", etc. I'd > > like to propose a new builtin function "equal". It should accept iterable, > >

Re: [Python-ideas] Add "equal" builtin function

It is a real problem. People are used to write `seq == [1, 2, 3]` and it passes unnoticed (even with type checkers) that if seq changes to e.g. a tuple, it will cause subtle bugs. It is inconvenient to write `len(seq) == 3 and seq == [1, 2, 3]` and people often don't notice the need to write it.

Re: [Python-ideas] Add "equal" builtin function

On Thu, Oct 06, 2016 at 02:45:11PM +, אלעזר wrote: > It is a real problem. People are used to write `seq == [1, 2, 3]` and it > passes unnoticed (even with type checkers) that if seq changes to e.g. a > tuple, it will cause subtle bugs. It is inconvenient to write `len(seq) == > 3 and seq ==

Re: [Python-ideas] Add "equal" builtin function

On Thu, Oct 6, 2016 at 5:53 PM Sjoerd Job Postmus wrote: > On Thu, Oct 06, 2016 at 02:45:11PM +, אלעזר wrote: > > It is a real problem. People are used to write `seq == [1, 2, 3]` and it > > passes unnoticed (even with type checkers) that if seq changes to e.g. a > >