Re: [Python-ideas] if-statement in for-loop

[Ken Kundert]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Improve error message when missing 'self' in method definition

[Yury Selivanov]

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 pypy:

https://bitbucket.org/pypy/pypy/commits/all?search=branch(better-error-missing-self)

I'm curious whether a similar improvement would also be received well in
CPython. In particular, this guides one to the correct solution for a
common programming mistake made by newcomers (and even not-so-newcomers).


+1 on the idea.

Yury

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Improve error message when missing 'self' in method definition

[Nathan Goldbaum]

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/all?search=branch(better-error-missing-self)

I'm curious whether a similar improvement would also be received well in
CPython. In particular, this guides one to the correct solution for a
common programming mistake made by newcomers (and even not-so-newcomers).

Here is a case study that found this was a common source of errors for
newcomers:

http://dl.acm.org/citation.cfm?id=2960327

-Nathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

[eryk sun]

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 to Ctrl-D everywhere?)
>>
>> Sadly, I suspect not. If you're running in the default Windows
>> terminal emulator (the one a normal user will get by invoking
>> cmd.exe), you're running under a lot of restrictions, and I believe
>> one of them is that you can't get Ctrl-D without an enter.
>
> Well, we could read _everything_ in character-at-a-time mode, and
> implement our own line editing. In effect, that's what readline is
> doing.

3.6+ switched to calling ReadConsoleW, which allows using a 32-bit
control mask to indicate which ASCII control codes should terminate a
read. The control character is left in the input string, so it's
possible to define custom behavior for multiple control characters.
Here's a basic ctypes example of how this feature works. In each case,
after calling ReadConsoleW I enter "spam" and then type a control
character to terminate the read.

import sys
import msvcrt
import ctypes

kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
ReadConsoleW = kernel32.ReadConsoleW

CTRL_MASK = 2 ** 32 - 1 # all ctrl codes

hin = msvcrt.get_osfhandle(sys.stdin.fileno())
buf = (ctypes.c_wchar * 10)(*('-' * 10))
pn = (ctypes.c_ulong * 1)()
ctl = (ctypes.c_ulong * 4)(16, 0, CTRL_MASK, 0)

>>> # Ctrl+2 or Ctrl+@ (i.e. NUL)
... ret = ReadConsoleW(hin, buf, 10, pn, ctl); print()
spam
>>> buf[:]
'spam\x00-'

>>> # Ctrl+D
... ret = ReadConsoleW(hin, buf, 10, pn, ctl); print()
spam
>>> buf[:]
'spam\x04-'

>>> # Ctrl+[
... ret = ReadConsoleW(hin, buf, 10, pn, ctl); print()
spam
>>> buf[:]
'spam\x1b-'

This could be used to implement Ctrl+D and Ctrl+L support in
PyOS_Readline. Supporting Ctrl+L to work like GNU readline wouldn't be
a trivial one-liner, but it's doable. It has to clear the screen and
also write the input (except the Ctrl+L) back to the input buffer.

> The main consequence of reading everything in character-at-a-time mode
> is that we'd have to implement everything ourselves, and the line
> editing you get *without* doing it yourself is somewhat nicer on Windows
> than on Linux (it supports cursor movement, inserting characters, and
> history).

Line-input mode also supports F7 for a history popup window to select
a previous command; Ctrl+F to search the screen text; text selection
(e.g. shift+arrows or Ctrl+A); copy/paste via Ctrl+C and Ctrl+V (or
Ctrl+Insert and Shift+Insert); and parameterized input aliases ($1-$9
and $* for parameters).

https://technet.microsoft.com/en-us/library/mt427362
https://technet.microsoft.com/en-us/library/cc753867

>> "Bash on Ubuntu on windows" responds to CTRL+D just fine. I don't really
>> know how it works, but it looks like it is based on the Windows terminal
>> emulator.
>
> It runs inside it, but it's using the "Windows Subsystem for Linux",
> which (I assume) reads character-at-a-time and feeds it to a Unix-like
> terminal driver, (which Bash then has incidentally also put in
> character-at-a-time mode by using readline - to see what you get on WSL
> *without* doing this, try running "cat" under bash.exe)

Let's take a look at how WSL modifies the console's global state.
Here's a simple function to print the console's input and output modes
and codepages, which we can call in the background to monitor the
console state:

def report():
hin = msvcrt.get_osfhandle(0)
hout = msvcrt.get_osfhandle(1)
modeIn = (ctypes.c_ulong * 1)()
modeOut = (ctypes.c_ulong * 1)()
kernel32.GetConsoleMode(hin, modeIn)
kernel32.GetConsoleMode(hout, modeOut)
cpIn = kernel32.GetConsoleCP()
cpOut = kernel32.GetConsoleOutputCP()
print('\nmodeIn=%x, modeOut=%x, cpIn=%d, cpOut=%d' %
  (modeIn[0], modeOut[0], cpIn, cpOut))

def monitor():
report()
t = threading.Timer(10, monitor, ())
t.start()

>>> monitor(); subprocess.call('bash.exe')

modeIn=f7, modeOut=3, cpIn=437, cpOut=437
...
modeIn=2d8, modeOut=f, cpIn=65001, cpOut=65001

See the following page for a description of the mode flags:

https://msdn.microsoft.com/en-us/library/ms686033

The output mode changed from 0x3 to 0xf, enabling

DISABLE_NEWLINE_AUTO_RETURN (0x8)
ENABLE_VIRTUAL_TERMINAL_PROCESSING (0x4)

The input mode changed from 0xf7 to 0x2d8, enabling

ENABLE_VIRTUAL_TERMINAL_INPUT (0x200)
ENABLE_WINDOW_INPUT (0x8, probably for SIGWINCH)

and disabling

ENABLE_INSERT_MODE (0x20)
ENABLE_ECHO_INPUT (0x4)
ENABLE_LINE_INPUT (0x2)
ENABLE_PROCESSED_INPUT (0x1)

So you're correct that it's basically using a 

Re: [Python-ideas] async objects

[Chris Angelico]

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't need to decide it **when writing the function**.

The only way to do that is to write *every* function as async, and
then if you want it blocking, you immediately wait for it. In other
words, you write everything asynchronously.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] async objects

[Sven R. Kunze]

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 folks that don't like the
visibly object-oriented nature of the default unittest and logging
APIs will often opt for third party alternative APIs that share some
of the same underlying infrastructure.


Maybe, this is all a big misunderstanding.

asyncio is incompatible with regular execution flow and it's **always 
blocking**. However, asyncio is perceived by some of us (including me) 
as a shiny alternative to processes and threads but really isn't. I 
remember doing this survey on python-ideas (results here: 
https://srkunze.blogspot.de/2016/02/concurrency-in-python.html) but I 
get the feeling that we still miss something.


My impression is that asyncio shall be used for something completely 
different than dropping off things into a background worker. But looking 
at the cooking example given by Steve Dower (cf. blog post), at other 
explanations, at examples in the PEPs, it just seems to me that his 
analogy could have been made with threads and processes as well.


At its core (the ASYNC part), asyncio is quite similar to threads and 
processes. But its IO-part seem to drive some (design) decisions that 
don't go well with the existing mental model of many developers. Even 
PEP-reviewers are fooled by simple asyncio examples. Why? Because they 
forget to spawn an eventloop. "async def and await" are just useless 
without an eventloop. And maybe that's what's people frustration is 
about. They want the ASYNC part without worrying about the IO part.


Furthermore, adding 2 (TWO) new keywords to a language has such an 
immense impact. Especially when those people are told "the barrier for 
new keywords is quite high!!". So, these new keywords must mean something.



I think what would help here are concrete answers to:

0) Is asyncio a niche feature only be used for better IO?
1) What is the right way of integrating asyncio into existing code?
2) How do we intend to solve the DRY-principle issue?

If the answer is "don't use asyncio", that's a fine result but honestly 
I think it would be just insane to assume that we got all these 
features, all this work and all those duplicated functions all for 
nothing. I can't believe that. So, I am still looking for a reasonable 
use-case of asyncio in our environment.


Cheers,
Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if-statement in for-loop

[Steven D'Aprano]

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 expression:
if condition:
block

is a simple, clean idiom that is easy to understand, avoids a number of 
pitfalls (where do you put the elif or else if you need one?), and only 
costs one extra line and one extra indent. If you have so many indents 
that this is a problem, that's a code smell and you ought to think more 
closely about what you are doing.

There's another variation that saves an indent for the cost of one more 
line:

for x in expression:
if not condition:
continue
block


In contrast, comprehensions are a single expression and are expected to 
usually be written in one line, although that's often hard to do without 
very long lines. They cannot include elif or else clauses, so avoid 
that particular pitfall. But the "very long line" problem shows that 
they are too dense: simple examples look fine:

[x+1 for x in seq if cond]

but in practice, they're often much longer with a much higher density of 
code:

[default if obj is None else obj.method(arg) for (obj, count) in 
zip(values, counts) if count > 1]

Some compromise on the optimal level of readability and code density is 
allowed: that's the price we pay in order to squeeze everything into a 
single expression. But that is not something we ought to copy when we 
have the luxury of a suite of statements.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if-statement in for-loop

[Chris Angelico]

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 still be at the same indentation level fully
>> expanded).
>
> I think it's obvious it would be the innermost construct... Or at least very
> plausible.

My reading of this is that the loop consists of a single filtered
iteration, ergo break/continue/else are as if the loop used a
generator:

# for item in items if item is not None:
for item in (item for item in items if item is not None):

These two would be semantically equivalent, and the first one has the
advantage of not sounding like the Cheshire Cat as Alice entered
'Machinations'.

<< Time to jump in time to jump through time I'm dizzy. >>

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if-statement in for-loop

[David Mertz]

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 think it's obvious it would be the innermost construct... Or at least
very plausible.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] async objects

[Guido van Rossum]

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 should be especially aware of this as you code. (Just
> like GC handles your alloc/free, the runtime should handle your
> “concurrency”)

There's a problem with this model (of using all CPUs to run
coroutines), since when you have two coroutines that can run in
unspecified order but update the same datastructure, the current
coroutine model *promises* that they will not run in parallel -- they
may only alternate running if they use `await`. This promise implies
that you can update the datastructure without worrying about locking
as long as you don't use `await` in the middle. (IOW it's
non-pre-emptive scheduling.)

If you were to change the model to allow multiple coroutines being
executed in parallel on multiple CPUs, such coroutines would have to
use locks locks, and then you have all the problems of threading back
in your coroutines! (There might be other things too, but there's no
wait to avoid a fundamental change in the concurrency model.)
Basically you're asking for Go's concurrency model -- it's nice in
some ways, but asyncio wasn't made to do that, and I'm not planning to
change it (let's wait for a GIL-free Python 4 first).

I'm still trying to figure out my position on the other points of
discussion here -- keep discussing!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if-statement in for-loop

[Sven R. Kunze]

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 would,
however, make it mechanically identical to the "generator and single
loop" form]


To me, a for loop starts with a "for" and ends with a ":". I wouldn't 
mind the ability of more "for"s or "if"s in between. I would skip over 
them anyway while reading. Technically, I agree with you as it matches 
my intuition:


for blaa foo blah bl blubber babble:
break# go outside
continue # go to next item
else:
# no break

Cheers,
Sven

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

[Random832]

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're running in the default Windows
> terminal emulator (the one a normal user will get by invoking
> cmd.exe), you're running under a lot of restrictions, and I believe
> one of them is that you can't get Ctrl-D without an enter.

Well, we could read _everything_ in character-at-a-time mode, and
implement our own line editing. In effect, that's what readline is
doing.

The main consequence of reading everything in character-at-a-time mode
is that we'd have to implement everything ourselves, and the line
editing you get *without* doing it yourself is somewhat nicer on Windows
than on Linux (it supports cursor movement, inserting characters, and
history).

On Wed, Sep 28, 2016, at 23:41, אלעזר wrote:
> "Bash on Ubuntu on windows" responds to CTRL+D just fine. I don't really
> know how it works, but it looks like it is based on the Windows terminal
> emulator.

It runs inside it, but it's using the "Windows Subsystem for Linux",
which (I assume) reads character-at-a-time and feeds it to a Unix-like
terminal driver, (which Bash then has incidentally also put in
character-at-a-time mode by using readline - to see what you get on WSL
*without* doing this, try running "cat" under bash.exe)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if-statement in for-loop

[Nick Coghlan]

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:
>> ...
>> else:
>> # ???
>>
>> Or is the implicit proposal that this form be special cased to
>> disallow the "else" clause?
>
> 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).

But would that interpretation be obvious to folks that aren't yet
aware that you can have "else" clauses on loops? (Folks can be *years*
into using Python before they first encounter that, whether in real
code or in a "Did you know  about Python?" snippet)

> 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 would,
> however, make it mechanically identical to the "generator and single
> loop" form]

Or we could stick with the status quo where limiting the keyword
chaining to the expression form naturally avoids all of these awkward
interactions with other statement level constructs.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if-statement in for-loop

[Random832]

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 that this form be special cased to
> disallow the "else" clause?

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).

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 would,
however, make it mechanically identical to the "generator and single
loop" form]
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Float nan equality

[Nick Coghlan]

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_point

That's why it returns False even if you compare a specific NaN
instance with itself:

>>> x = float("nan")
>>> x == x
False

If you need a kinda-like-NaN value that provides reflexive equality,
then Python's None singleton is a better fit.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if-statement in for-loop

[Nick Coghlan]

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 function represents a speed bump. Whereas writing something like the
> following is simple, compact, quick, and obvious. There is no reason why it
> should not be allowed even though it might not always be the best approach to
> use:
>
> for i in range(5) for j in range(5) for k in range(5):
> ...
>
> And I would really like to be able to write loops of the form:
>
> for item in items if item is not None:
>...
>
> It is something I do all the time, and it would be nice if it did not consume
> two levels on indentation.

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 that this form be special cased to
disallow the "else" clause?

Comprehensions don't have that concern, as they don't support "else"
clauses at all.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Float nan equality

[Arek Bulski]

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 list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if-statement in for-loop

[Paul Moore]

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 exceptions and inconsistencies that consume 'working
>  > memory in the brain of humans'. By eliminating the distinction between list
>  > comprehensions and for loops we would be making the language simpler by
>  > eliminating an inconsistency.
>
> I don't think of a comprehension as a for loop, I think of it as
> setbuilder notation (although of course I realize that since lists are
> sequences it has to be a for loop under the hood).  So the claimed
> inconsistency here doesn't bother me.  I realize it bothers a lot of
> people, but the proposed syntax is not obvious to me (ambiguous and
> inconsistent in its own way).
>
>  > [T]he writing of the generator function represents a speed bump.
>
> It used to be, for me, but it really isn't any more.  Perhaps you
> might get used to it if you tried it.  Harder to argue: the fact that
> Guido and Nick (inter alia) consider it good style to use named
> functions makes that point a hard sell (ie, you don't need to convince
> me, you need to convince them).
>
>  > Whereas writing something like the following is simple, compact,
>  > quick, and obvious. There is no reason why it should not be allowed
>  > even though it might not always be the best approach to use:
>  >
>  > for i in range(5) for j in range(5) for k in range(5):
>  > ...
>
> To me, that is visually ambiguous with
>
> for i in (range(5) for j in (range(5) for k in range(5))):
> ...
>
> although syntactically the genexp requires the parentheses (and in
> fact is almost nonsensical!)  I could easily see myself forgetting the
> parentheses (something I do frequently) when I *do* want to use a
> genexp (something I do frequently), with more or less hilarious
> results.  As already mentioned:
>
> for i, j, k in itertools.product(range(5), range(5), range(5)):
> ...
>
> To me that is much clearer, because it expresses the rectangular shape
> of the i, j, k space.  I would also stumble on
>
> for i in range(5) for j in range(i + 1):
> ...
>
> at least the first few times I saw it.  Based on the English syntax of
> "for" (not to mention the genexp syntax), I would expect
>
> for j in range(i + 1) for i in range(5):
> ...
>
> If itertools.product is the wrong tool, then the loop bodies are
> presumably complex enough to deserve new indent levels.  Note that
> simple filters like non_nil (see below) can easily be used, as long as
> the resulting set is still a product.
>
>  > And I would really like to be able to write loops of the form:
>  >
>  > for item in items if item is not None:
>  >...
>
> def non_nil(items):
> return (item for item in items if item is not None)
>
> for item in non_nil(items):
> ...
>
> I think that's very readable, so the only reason why that 2-line
> function needs to be syntax that I can see is your distaste for
> defining functions, and that of other Python programmers who think
> like you.

Again this is just personal opinion, but I agree 100% with everything
Stephen said.

It *is* a stumbling block to get used to writing generator functions
like non_nil() above, but it's also a worthwhile learning experience.
And yes, it's somewhat inconvenient to do so if you're working in the
standard Python REPL, but designing language features around REPL
usage isn't (IMO) the right choice. And if you really need a better
way of handling that sort of refactoring in an interactive
environment, tools like the Jupyter notebook are probably what you're
looking for.

(Trying to collapse multiple clauses into one line/statement is
something Perl was famous for, and it's in many ways quite an
attractive feature. But IMO it directly contributes to Perl's
reputation for unreadability, because it *does* get used too much,
whether you think it will or not - one person's "nicely compact" is
another person's "obfuscated". So I'm glad that Python's design avoids
encouraging that style - even though I do occasionally remember fondly
my Perl one-liners :-))

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] async objects

[Stephen J. Turnbull]

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 write] should need any keywords;
just start the event loop and invoke functions, and that somehow
automatically DTRTs.  (I.e., AFAICS the intent is to unify generators
and coroutines despite the insistence of Those Who Have Actually
Implemented Stuff that generator != coroutine.)

N.B. As I understand it, although Rene uses the async keyword when
invoking the constructor, this could be just as well done with a
factory function since he speaks of "wrapping" the object.  And his
example is in your "just call it" category: nonblocking synchronous
code.  That doesn't help me understand what he's really trying to do.

His PyWorks project is documented as implementing the "actor" model,
but async is more general than that AFAICS, and on the other hand I
can't see how you can guarantee that a Python function won't modify
global state.  So OK, I can see that a performant implementation of
the actor pattern (don't we have this in multiprocessing somewhere?) 
with a nice API (that's harder :-) and documented restrictions on what
you can do in there might be a candidate for stdlib, but I don't see
how it's related to the "async(io)" series of PEPs, which are
specifically about interleaving arbitrary amounts of suspension in a
Python program (which might manipulate global state, but we want to do
it in a way such that we know that code between suspension points
executes "atomically" from the point of view of other coroutines).

Anthony also objects to the keywords, ie, that he'll need to pepper
his "dual-purpose" code with "async" and "await".  Again, AFAICS that
implies that he doesn't see a need to distinguish async from lazy
(coroutine from generator), since AFAICS you'd break the world if you
changed the semantics of "def foo" to "async def foo".  So if you're
going to write async/await-style code, you're going to have to swallow
the keywords.

Am I just missing something?

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] async objects

[Rene Nejsum]

> 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 about it, but let the runtime handle low-level
 timing, as long as you know your code will execute in the intended
 order.
>>> 
>>> Isn't "concurrent code whose order of execution you know" an oxymoron?
>> 
>> You are right, I should have been more specific. What I ment was that I 
>> don’t need code filled with async/await, I don’t care where it blocks, as 
>> long as it (the specific code block iI am looking at) runs in the order i 
>> wrote it :-)
>> 
> 
> Then you want threads. Easy!

Well, yes and no. I other languages (Java/C#) where I have implemented 
concurrent objects ala PYWORKS it works pretty well, as long as you have less 
than maybe 10.000 threads

But, in Python (CPython2 on multicore CPU) threads does not work! The GIL makes 
it impossible to have for example 100 threads sending messages between each 
other (See the Ring example in PYWORKS), that’s one reason why it would be 
interesting to have some kind of concurrency support built into the Python 
runtime.

Today I see all kinds of tricks and workarounds to get around the GIL. Raging 
from starting several Python interpreters to difficult to read code using yield 
(now async/await), but when you have seen much more elegant support (Go, 
Erlang, maybe even ABCL) you kind of wish this could be added to you own 
favourite language.

br
/Rene

> 
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] async objects

[Rene Nejsum]

> 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 tasks are very lightweight
> compared to OS threads, so you can afford to have a large
> number of them active at once.
> 
> Rene's approach seems to be based on ordinary threads, so
> it would not have this property.

My implementation is, but it should not (have to) be, it only reflects my 
limited ability and time :-)

The programmer should not need to be aware of where concurrency is achieved 
though coroutines or threads, ideally there should be one OS thread per core in 
the CPU running many (millions) of coroutines…

br
/Rene

> 
> -- 
> Greg
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/