> On 04 Oct 2016, at 18:40, Sven R. Kunze wrote:
>
> On 04.10.2016 09:50, Stephen J. Turnbull wrote:
>> As I understand the main point, Sven and Rene don't believe that [the
>> kind of] async code [they want to write] should need any keywords;
>> just start the event loop and invoke functions, a
On 5 October 2016 at 02:15, Guido van Rossum wrote:
> Honestly it feels like many things can go wrong with this API model,
> esp. you haven't answered what should happen when a method of
> SomeClass (either a synchronous one or an async one) calls
> run_in_foreground() on something -- or, more lik
On 10/04/2016 09:40 AM, Sven R. Kunze wrote:
As a result of past discussions, I wrote the module "xfork"
which basically does this "golang goroutine" stuff. It's just
a thin wrapper around "futures" but it allows to avoid that
what René and Anthony objects about.
Looks cool! Thanks!
--
~E
On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote:
>
> Extra newlines are cheap. Writing
>
The cost is paid in newlines *and* extra levels of indentation.
Why isn't it the programmer that is writing the code the best person to decide
what is best?
-Ken
__
On 2016-10-04 4:52 PM, Nathan Goldbaum wrote:
Hi all,
Recently pypy received a patch that improves the error message one gets
when 'self' is missing in a method's signature:
https://mail.python.org/pipermail/pypy-dev/2016-September/014678.html
Here are the commits that implement the change in
Hi all,
Recently pypy received a patch that improves the error message one gets
when 'self' is missing in a method's signature:
https://mail.python.org/pipermail/pypy-dev/2016-September/014678.html
Here are the commits that implement the change in pypy:
https://bitbucket.org/pypy/pypy/commits/a
On Tue, Oct 4, 2016 at 2:22 PM, Random832 wrote:
> On Wed, Sep 28, 2016, at 23:36, Chris Angelico wrote:
>> On Thu, Sep 29, 2016 at 12:04 PM, Steven D'Aprano
>> wrote:
>> > (Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows
>> > is Ctrl-Z + Return. Can that be standardized t
On Wed, Oct 5, 2016 at 3:40 AM, Sven R. Kunze wrote:
> I don't think that's actually what I wanted here. One simple keyword should
> have sufficed just like golang did. So, the developer gets a way to decide
> whether or not he needs it blocking or nonblocking **when using a
> function**. He doesn
On 04.10.2016 09:50, Stephen J. Turnbull wrote:
As I understand the main point, Sven and Rene don't believe that [the
kind of] async code [they want to write] should need any keywords;
just start the event loop and invoke functions, and that somehow
automatically DTRTs.
[reading my name second t
On 04.10.2016 13:30, Nick Coghlan wrote:
What it *doesn't* do, and what you need greenlet for, is making that
common interface look like you're using plain old synchronous C
threads.
If folks really want to do that, that's fine - they just need to add
gevent/greenlet as a dependency, just as the
On Tue, Oct 4, 2016 at 4:30 AM, Nick Coghlan wrote:
> class SomeClass(object):
> def some_sync_method(self):
> return 42
> async def some_async_method(self):
> await asyncio.sleep(3)
> return 42
>
> o = auto_schedule(SomeClass()) # Indicatin
On Tue, Oct 04, 2016 at 01:31:22PM +1000, Nick Coghlan wrote:
> By contrast, eliminating the vertical whitespace without actually
> reducing the level of nesting is merely hiding the readability problem
> without actually addressing it.
+1
Extra newlines are cheap. Writing
for x in expressi
On Wed, Oct 5, 2016 at 2:42 AM, David Mertz wrote:
> On Oct 4, 2016 6:20 AM, "Random832" wrote:
>> > for item in items if item is not None:
>> > ...
>> > else:
>> > # ???
>
>>
>> I think it's obvious that it would be on the outermost construct (i.e.
>> the one that would s
On Oct 4, 2016 6:20 AM, "Random832" wrote:
> > for item in items if item is not None:
> > ...
> > else:
> > # ???
>
> I think it's obvious that it would be on the outermost construct (i.e.
> the one that would still be at the same indentation level fully
> expanded).
I th
In my mind, these proposed complications of the 'for' loop would
*introduce* inconsistency, NOT reduce it.
It's simple to remember that suites nest statements while comprehensions
are expressions on single (logical) lines. Adding more edge cases to blue
the distinction makes cognitive load higher.
On Mon, Oct 3, 2016 at 10:37 PM, Rene Nejsum wrote:
> Ideally I think a language (would love it to be Python) should
> permit many (millions) of what we know as coroutines and then have as many
> threads as the CPU have cores to execute this coroutines, but I do not thing
> you as a programmer sho
On 04.10.2016 15:20, Random832 wrote:
The *real* question is what "break" should do. I think it should
likewise break from the outermost for-loop (but "continue" should still
continue the innermost one), but this does mean that it's not
mechanically identical to the "equivalent" nested loops [it
On Wed, Sep 28, 2016, at 23:36, Chris Angelico wrote:
> On Thu, Sep 29, 2016 at 12:04 PM, Steven D'Aprano
> wrote:
> > (Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows
> > is Ctrl-Z + Return. Can that be standardized to Ctrl-D everywhere?)
>
> Sadly, I suspect not. If you'
On 4 October 2016 at 23:20, Random832 wrote:
> On Tue, Oct 4, 2016, at 07:37, Nick Coghlan wrote:
>> And when you add the "else" clause that's supported by both "for" and
>> "if", what does that mean in the abbreviated form?
>>
>> for item in items if item is not None:
>> ...
>> el
On Tue, Oct 4, 2016, at 07:37, Nick Coghlan wrote:
> And when you add the "else" clause that's supported by both "for" and
> "if", what does that mean in the abbreviated form?
>
> for item in items if item is not None:
> ...
> else:
> # ???
>
> Or is the implicit proposal
Something else that may look confusing can be a break statement; in a
for i in range(5) for j in range(5) for k in range(5):
...
break
does it break the inner "k" loop, going to the next "j" (as it would happen
with 3 nested loops), or does it end the whole for statement? Similar
question w
On 4 October 2016 at 21:32, Arek Bulski wrote:
> I had a bug where nan floats failed to compare equal because there seems to
> be more than one nan value and comparison seems to be binary based.
"NaN != NaN" is part of the definition of IEEE 754 floats:
https://en.wikipedia.org/wiki/NaN#Floating
On 4 October 2016 at 14:32, Ken Kundert wrote:
> For example, it was suggested that one could simplify a multi-level loop by
> moving the multiple levels of for loop into a separate function that acts as
> generator. And that is a nice idea, but when writing it, the writing of the
> generator func
I had a bug where nan floats failed to compare equal because there seems
to be more than one nan value and comparison seems to be binary based.
How about we make float eq test if both are math. Isnan?
-- Arkadiusz Bulski --
___
Python-ideas mailing lis
On 4 October 2016 at 17:50, Stephen J. Turnbull
wrote:
> Nick Coghlan writes:
>
> > What's not well-defined are the interfaces for calling into
> > asynchronous code from synchronous code.
>
> I don't understand the relevance to the content of the thread.
Given the schedule_coroutine/run_in_for
On 4 October 2016 at 08:56, Stephen J. Turnbull
wrote:
> These are my opinions; I don't claim any authority for them. I just
> don't find the proposed syntax as obvious and unambiguous as you do,
> and would like to explain why that is so.
>
> Ken Kundert writes:
>
> > In my experience it is exc
These are my opinions; I don't claim any authority for them. I just
don't find the proposed syntax as obvious and unambiguous as you do,
and would like to explain why that is so.
Ken Kundert writes:
> In my experience it is exceptions and inconsistencies that consume 'working
> memory in the b
Nick Coghlan writes:
> What's not well-defined are the interfaces for calling into
> asynchronous code from synchronous code.
I don't understand the relevance to the content of the thread.
As I understand the main point, Sven and Rene don't believe that [the
kind of] async code [they want to w
> On 04 Oct 2016, at 07:26, Chris Angelico wrote:
>
> On Tue, Oct 4, 2016 at 4:25 PM, Rene Nejsum wrote:
>>> On 04 Oct 2016, at 02:09, Stephen J. Turnbull
>>> wrote:
>>>
>>> Rene Nejsum writes:
I believe that you should be able to code concurrent code, without
being to explicit abo
> On 03 Oct 2016, at 23:32, Greg Ewing wrote:
>
> Yann Kaiser wrote:
>> The way I see it, the great thing about async/await as opposed to threading
>> is that it is explicit about when execution will "take a break" from your
>> function or resume into it.
>
> Another thing is that async/await
30 matches
Mail list logo