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
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 async/await, it looks to me like
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 abstract modelling
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 more threads). Anything else we do (whe
On 6 October 2016 at 17:45, Greg Ewing wrote:
> Saying that 'await' is good for you because it
> makes the suspension points visible seems to me
> a rationalisation after the fact. It was something
> that emerged from the implementation, not a
> prior design requirement.
I'd say it emerged from m
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 it
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 emty.
> That's quite
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.
(
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,
> > and return True if all
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 == [1
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
> > tuple, it will cause subt
On Thu, Oct 06, 2016 at 04:45:01PM +0300, 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 emty.
On 10/06/2016 06:45 AM, 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 emty.
That's quite popula
On Fri, Oct 7, 2016 at 2:23 AM, Steven D'Aprano wrote:
> +0.3 to adding it the standard library.
>
> +0.1 to adding it to built-ins
>
> -0.1 on adding it to built-ins under the name "equal", as that will
> confuse too many people.
I'll go further: -0.5 on adding to built-ins. +0.5 on adding it to
2016-10-06 13:50 GMT+02:00 Nick Coghlan :
> The shadow thread idea will hopefully prove successful in addressing
> the last major rough spot in the UX, which is the ability to easily
> integrate asynchronous components into an otherwise synchronous
> application.
>
That's my opinion as well. If I
On 2016-10-06 1:15 AM, Stephen J. Turnbull wrote:
These may be hard to explain, and I know you, Yury, and Guido are very
busy. But it's frustrating for all to see this go around in a circle:
"it's like it is because it has to be that way, so that's the way it is".
To add to what Nick said.
I
Interestingly, this just showed up on Python List:
On 10/06/2016 05:09 AM, Frank Millman wrote:
I have used itertools.groupby before, and I love it. I used it
to process a csv file and 'break' on change of a particular
field. It worked very well.
Now I want to use it to process a database ta
Seems like itertools recipes already have "all_equal" function. What do you
think about moving it from recipes to itertools? I suggest a C
implementation with optimisations for builtin collections.
2016-10-06 18:42 GMT+03:00 Chris Angelico :
> On Fri, Oct 7, 2016 at 2:23 AM, Steven D'Aprano
> wr
The name might be a little confusing; it can be understood as comparing two
sequences, so passing two sequences may seem reasonable to a reviewer.
Elazar
בתאריך יום ה׳, 6 באוק' 2016, 20:15, מאת Filipp Bakanov :
> Seems like itertools recipes already have "all_equal" function. What do
> you thin
On 06/10/2016 15:43, Sjoerd Job Postmus wrote:
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 ac
On 2016-10-06 03:27, Nick Coghlan wrote:
It's not a question that's up for debate - as a point of factual
history, Python's runtime model is anchored in the C runtime model,
and this pervades the entire language design. Simply wishing that
Python's core runtime design was other than it is doesn't
On 6 October 2016 at 18:09, Filipp Bakanov wrote:
> Seems like itertools recipes already have "all_equal" function. What do you
> think about moving it from recipes to itertools? I suggest a C
> implementation with optimisations for builtin collections.
Interestingly, the recipe given there was n
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. Gev
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.
___
Python
Nick Coghlan wrote:
The pay-off that CPython gets from this is that we get to delegate
99.9% of the work for supporting different CPU architectures to C
compiler developers, and we get a lot of capabilities "for free" when
it comes to stack management.
One of the main benefits is that it's very
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,
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 exactl
On Thu, Oct 6, 2016 at 4:12 PM, Greg Ewing wrote:
> 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 su
28 matches
Mail list logo
