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
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:
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
>> >
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
>
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
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
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
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
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
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,
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:
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
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:
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
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
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
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
> 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
> 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.
>
>
21 matches
Mail list logo