Re: How asyncio works? and event loop vs exceptions
On 7/22/2016 8:27 PM, Marco S. via Python-list wrote: I'm developing a web app based on aiohttp, and I find the event loop concept very interesting. I never programmed with it before, but I know that node.js and GUIs are based on it. What I can't understand is how asyncio make it possible to run multiple tasks concurrently, since it's single threaded (if you don't use loop.run_in_executor()). I just tried to imagine that it should act as a cpu scheduler. Is this true? The code for BaseEventLoop is in asyncio.base_events.py. In particular, see def run_forever. Very simplified, def run_forever(): while True: handle_ready_io_events() call_ready_scheduled_functions() > If so, how and when asyncio decide to switch to another task? It does not decide. Asyncio does *cooperative* multi-tasking. This depends on handlers running for a short time and quitting, even if there is more work to do. The OS does *pre-emptive* multi-tasking; it switches processes that are still running. It is possible to add other events into the mix. Adding these lines def tk_update(): root.update() loop.call_later(.01, tk_update) tk_update() to an asyncio program before loop.run_forever and the loop will drive a tkinter gui. A day ago, I experimentally patched IDLE to run off of an asyncio loop instead of the tk loop. Everything I tried worked. See https://bugs.python.org/issue27546. Furthermore I have a question about exceptions in asyncio. I am too ignorant about this to even ask. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
Steven D'Aprano :
> On Sat, 23 Jul 2016 01:33 am, Kent Tong wrote:
>> I'm aware that we can use 'pass' as an empty code block. But why
>> doesn't python allow a code block to be empty and thus eliminate the
>> need for this null statement?
>
> Because it cannot tell the difference between an empty code block and
> failing to indent the code block:
>
> for x in sequence:
> print('loop')
>
> Is that meant to print 'loop' each time around the loop, or just once, at
> the end of the loop?
I don't see an ambiguity: obviously the print call takes place after
finishing the loop.
> There are cases where the interpreter could tell:
>
> if flag:
> else:
>block
>
> Obviously the "if" block is empty. But for consistency, and
> simplicity, the interpreter requires a pass there too.
I wonder if there is any true case of ambiguity. I guess this is all
about an enforced aesthetic principle: GvR doesn't like the looks of an
empty block.
> One less thing to be programmed, one less thing for the user to
> remember. Just require pass any time you have an empty block, rather
> than try to remember where it is required and were it is optional.
Actually, the requirement of a dummy statement is a slight annoyance for
the programmer. After deleting a statement, you must see if you have to
put in a pass statement. And after adding a statement, you may feel the
urge to remove the redundant pass statement.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Sat, Jul 23, 2016 at 9:13 PM, Marko Rauhamaa wrote: >> One less thing to be programmed, one less thing for the user to >> remember. Just require pass any time you have an empty block, rather >> than try to remember where it is required and were it is optional. > > Actually, the requirement of a dummy statement is a slight annoyance for > the programmer. After deleting a statement, you must see if you have to > put in a pass statement. And after adding a statement, you may feel the > urge to remove the redundant pass statement. How often do you actually need empty statements, adding stuff, removing stuff, like that? Possibly there's a code smell here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
Chris Angelico : > On Sat, Jul 23, 2016 at 9:13 PM, Marko Rauhamaa wrote: >>> One less thing to be programmed, one less thing for the user to >>> remember. Just require pass any time you have an empty block, rather >>> than try to remember where it is required and were it is optional. >> >> Actually, the requirement of a dummy statement is a slight annoyance >> for the programmer. After deleting a statement, you must see if you >> have to put in a pass statement. And after adding a statement, you >> may feel the urge to remove the redundant pass statement. > > How often do you actually need empty statements, adding stuff, > removing stuff, like that? Possibly there's a code smell here. Quite often. For example: class ItHitFan(Exception): pass ==> class ItHitFan(Exception): def __init__(self, huh): super().__init__() self.huh = huh Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Sat, 23 Jul 2016 14:13:46 +0300
Marko Rauhamaa wrote:
> > for x in sequence:
> > print('loop')
> >
> > Is that meant to print 'loop' each time around the loop, or just
> > once, at the end of the loop?
>
> I don't see an ambiguity: obviously the print call takes place after
> finishing the loop.
It's ambiguous to the reader what was actually meant. Forcing a "pass"
there shows the reader that the empty block was not a mistake.
Explicit is better than implicit.
> I wonder if there is any true case of ambiguity. I guess this is all
> about an enforced aesthetic principle: GvR doesn't like the looks of
> an empty block.
I don't think that he would be alone.
> Actually, the requirement of a dummy statement is a slight annoyance
> for the programmer. After deleting a statement, you must see if you
> have to put in a pass statement. And after adding a statement, you
> may feel the urge to remove the redundant pass statement.
If you allow empty blocks and you use it I hope that you would add a
comment so that the reader knows that you meant it.
for x in sequence: # this is an empty block
Is that better than "pass"?
--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
--
https://mail.python.org/mailman/listinfo/python-list
Detecting the trivial can be non-trivial (was Why not allow empty code blocks?)
On Saturday, July 23, 2016 at 4:44:00 PM UTC+5:30, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
> > On Sat, 23 Jul 2016 01:33 am, Kent Tong wrote:
> >> I'm aware that we can use 'pass' as an empty code block. But why
> >> doesn't python allow a code block to be empty and thus eliminate the
> >> need for this null statement?
> >
> > Because it cannot tell the difference between an empty code block and
> > failing to indent the code block:
> >
> > for x in sequence:
> > print('loop')
> >
> > Is that meant to print 'loop' each time around the loop, or just once, at
> > the end of the loop?
>
> I don't see an ambiguity: obviously the print call takes place after
> finishing the loop.
>
> > There are cases where the interpreter could tell:
> >
> > if flag:
> > else:
> >block
> >
> > Obviously the "if" block is empty. But for consistency, and
> > simplicity, the interpreter requires a pass there too.
>
> I wonder if there is any true case of ambiguity. I guess this is all
> about an enforced aesthetic principle: GvR doesn't like the looks of an
> empty block.
>
> > One less thing to be programmed, one less thing for the user to
> > remember. Just require pass any time you have an empty block, rather
> > than try to remember where it is required and were it is optional.
>
> Actually, the requirement of a dummy statement is a slight annoyance for
> the programmer. After deleting a statement, you must see if you have to
> put in a pass statement. And after adding a statement, you may feel the
> urge to remove the redundant pass statement.
Tsk Tsk…
The Europeans took 500 years to appreciate that zero is a necessity
https://en.wikipedia.org/wiki/Arabic_numerals#Adoption_in_Europe
Do you seriously suppose that they did not have the asymptotic/limiting case of:
There are 3 apples in the basket
There are 2 apples in the basket
There are 1 apples in the basket
Now you can (and they probably did) replace the ‘1’ by ‘no’
But that’s not a number
You can have nothing there:
There are apples in the basket
Is it visible?
Problem is more evident if we use a ‘base-1’ system
There are XXX apples in the basket
There are XX apples in the basket
There are X apples in the basket
There are apples in the basket
IOW the notion of zero is trivial enough (in hindsight)
First-classing it as a notation is not at all trivial
This question is analogous – maybe almost identical – to the question of
the most trivial automata/regex etc.
For a long time the re → dfa transformation went and was taught the laborious
route:
re → nfa-with-ε-transitions → nfa-without-ε-transitions → dfa
https://en.wikipedia.org/wiki/Thompson's_construction
https://en.wikipedia.org/wiki/Powerset_construction
Now there is a direct, straightforward method which only becomes available
(thinkable) when we have a null regular expression:
https://drona.csa.iisc.ernet.in/~deepakd/fmcs-06/seminars/presentation.pdf
Coming back to zero:
While it is true that European civilization knew of and ignored the zero for
500 years and science-advances happened only after adopting zero, and today
we take it for granted. Still it remains true that zero is a bit anomalous.
Some evidences of this:
Lets say that a numeral is in normal form if it has no leading zeros.
So 0025 normalizes to 25.
Is 0 a normal form?
Likewise: Early versions of Fortran had loops that could not execute zero times:
http://www-pnp.physics.ox.ac.uk/~gronbech/intfor/node18.html
In the same vein «pass» (Dijkstra called it «skip») and «abort» (roughly «raise
Exception» in python-speak) correspond to 1 and 0 in numbers
And IMHO anyone who rejects the search/formalization for the trivial case as a
useless activity is effectively pushing us back to the dark ages.
And if one finds it hard to believe that humans can be incredibly resistant
to learning from mistakes, here's a list of long-lasting errors like rejecting
zero:
http://blog.languager.org/2016/01/how-long.html
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
"D'Arcy J.M. Cain" : > On Sat, 23 Jul 2016 14:13:46 +0300 > Marko Rauhamaa wrote: >> I don't see an ambiguity: obviously the print call takes place after >> finishing the loop. > > It's ambiguous to the reader what was actually meant. Forcing a "pass" > there shows the reader that the empty block was not a mistake. Just let the syntax speak for itself. The code means what the language definition says it means. >> I wonder if there is any true case of ambiguity. I guess this is all >> about an enforced aesthetic principle: GvR doesn't like the looks of >> an empty block. > > I don't think that he would be alone. Then just appeal to that subjective preference instead of some objective necessity. BTW, the standard shell requires a dummy statement in a block even though the block boundaries are clearly marked: while not quit; do done is a syntax error. This works: while not quit; do : done > If you allow empty blocks and you use it I hope that you would add a > comment so that the reader knows that you meant it. Once you learn the idioms of a language, you don't need to comment the obvious. > for x in sequence: # this is an empty block > > Is that better than "pass"? Er, in that hypothetical world, the right answer would be simply: for x in sequence: Note that I'm not arguing for the removal of "pass." I'm just saying it isn't strictly necessary. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Sat, 23 Jul 2016 16:13:58 +0300
Marko Rauhamaa wrote:
> "D'Arcy J.M. Cain" :
> > It's ambiguous to the reader what was actually meant. Forcing a
> > "pass" there shows the reader that the empty block was not a
> > mistake.
>
> Just let the syntax speak for itself. The code means what the language
> definition says it means.
Exactly so given this...
for x in sequence:
print("Something")
If the language allowed that then we know exactly what the programmer
said. What we don't know is what the programmer meant. The above is a
simple and obvious statement but real code is more complicated. Add a
few comments and a little nesting and what used to be obvious isn't.
The interpreter would still know what the programmer said but without
the pass requirement it is easier for it to be not what he meant.
Python has some nice features like this one that protect the programmer
and allow much faster development because there is a safety net. If
you like knives without handles you know where to find Perl.
Gotta go. The metaphor police are at the door.
--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On 23/07/2016 12:34, Chris Angelico wrote: On Sat, Jul 23, 2016 at 9:13 PM, Marko Rauhamaa wrote: One less thing to be programmed, one less thing for the user to remember. Just require pass any time you have an empty block, rather than try to remember where it is required and were it is optional. Actually, the requirement of a dummy statement is a slight annoyance for the programmer. After deleting a statement, you must see if you have to put in a pass statement. And after adding a statement, you may feel the urge to remove the redundant pass statement. How often do you actually need empty statements, adding stuff, removing stuff, like that? Possibly there's a code smell here. All the time? For example when creating a set of empty functions to be populated later, or empty branches of if and so on to be filled in as so you go. Or, for debugging or other reasons, when you need to comment out the contents of a block. Then pass needs to be added. However in the absence of a strong end-of-block indicator and having to infer the end of the block from what may or may not follow, then pass is useful when the block is empty. But I don't think it needed to be mandatory. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: How asyncio works? and event loop vs exceptions
On Fri, Jul 22, 2016 at 6:27 PM, Marco S. via Python-list wrote: > Furthermore I have a question about exceptions in asyncio. If I > understand well how it works, tasks exceptions can be caught only if > you wait for task completion, with yield from, await or > loop.run_until_complete(future). But in this case the coroutine blocks > the execution of the program until it returns. On the contrary you can > execute the coroutine inside an asyncio task and it will be > non-blocking, but in this case exceptions can't be caught in a try > statement. If you don't want to block the current function on the task, then spin off another task to do the error handling. Instead of this: async def do_something(): try: await do_something_else() except DidNothingError as e: handle_error(e) ... Consider this: async def do_something(): get_event_loop().create_task(await_and_handle(do_something_else())) ... async def await_and_handle(awaitable): try: await awaitable except DidNothingError as e: handle_error(e) If you want, you could generalize that further by passing in the exception class and error handler as well: async def do_something(): get_event_loop().create_task(await_and_handle( do_something_else(), DidNothingError, handle_error)) ... async def await_and_handle(awaitable, error_class, handler): try: await awaitable except error_class as e: handler(e) -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On 23/07/2016 14:54, D'Arcy J.M. Cain wrote:
On Sat, 23 Jul 2016 16:13:58 +0300
Marko Rauhamaa wrote:
"D'Arcy J.M. Cain" :
It's ambiguous to the reader what was actually meant. Forcing a
"pass" there shows the reader that the empty block was not a
mistake.
Just let the syntax speak for itself. The code means what the language
definition says it means.
Exactly so given this...
for x in sequence:
print("Something")
If the language allowed that then we know exactly what the programmer
said. What we don't know is what the programmer meant. The above is a
simple and obvious statement but real code is more complicated. Add a
few comments and a little nesting and what used to be obvious isn't.
The interpreter would still know what the programmer said but without
the pass requirement it is easier for it to be not what he meant.
Python has some nice features like this one that protect the programmer
and allow much faster development because there is a safety net. If
you like knives without handles you know where to find Perl.
pass can only do so much. If doesn't help here:
for x in sequence:
print("Something")
print("Something else")
Was the second print meant to be indented as well or not?
Perhaps rather than 'pass', the language ought to have provided an
optional 'end' keyword to mark the end of a block. Then there would be
less speculation about what was meant:
for x in sequence:
print("Something")
end
print("Something else")
(And no speculation at all if 'end' was mandatory. Python already
provides 'else' (and 'except'?) which can do a similar job in some
circumstances.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Sun, Jul 24, 2016 at 12:00 AM, BartC wrote: > On 23/07/2016 12:34, Chris Angelico wrote: >> >> On Sat, Jul 23, 2016 at 9:13 PM, Marko Rauhamaa wrote: One less thing to be programmed, one less thing for the user to remember. Just require pass any time you have an empty block, rather than try to remember where it is required and were it is optional. >>> >>> >>> Actually, the requirement of a dummy statement is a slight annoyance for >>> the programmer. After deleting a statement, you must see if you have to >>> put in a pass statement. And after adding a statement, you may feel the >>> urge to remove the redundant pass statement. >> >> >> How often do you actually need empty statements, adding stuff, >> removing stuff, like that? Possibly there's a code smell here. > > > All the time? No, or I wouldn't have qualified it with the very weak "possibly". > For example when creating a set of empty functions to be populated later, or > empty branches of if and so on to be filled in as so you go. Forget 'pass' - just give each function a docstring. That syntactically defines the block, and it's useful. > Or, for debugging or other reasons, when you need to comment out the > contents of a block. Then pass needs to be added. How often do you comment out an entire block and not its header? I don't remember the last time I did that. It's certainly not so common that adding 'pass' takes up a significant part of a debugging session. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Sun, 24 Jul 2016 12:06 am, BartC wrote:
> pass can only do so much. If doesn't help here:
>
> for x in sequence:
> print("Something")
> print("Something else")
>
> Was the second print meant to be indented as well or not?
True. But once you start wondering about code the programmer *hasn't*
written, you could drive yourself crazy:
...but what if the second print is supposed to follow
an "if" clause, which has been left out...?
*Most* for-loops have non-empty blocks. Only a tiny minority have empty
blocks for any appreciable period of time. (This is not 1970, and we don't
write timing loops like "for x in range(1000): pass".)
*Most* code is correctly indented. So the interpreter should assume that
indentation *is correct*, unless there is a reason to doubt that. What sort
of reasons could there be?
- if the indentation increases when it shouldn't:
print("Hello")
print("World!") # unexpected indent
- if it dedents to a value that doesn't align with a previous block:
for x in sequence:
print(x)
print("dedented") # half-way between current and previous block
- if it doesn't indent when you expect it to:
for x in sequence:
print(x)
Yes, that last one *could* be an empty block. But empty blocks are rare. Its
more likely to be an error. If it's not an error, than the programmer can
just insert a "pass" statement to satisfy the interpreter.
> Perhaps rather than 'pass', the language ought to have provided an
> optional 'end' keyword to mark the end of a block. Then there would be
> less speculation about what was meant:
It can't be optional. If it were optional, we'd be no better off:
for x in sequence:
print(x)
The "end" is missing, but is it missing from the end of the empty block, or
the end of the non-empty block?
for x in sequence:
end
print(x)
for x in sequence:
print(x)
end
In any case, using "end" instead of "pass" is a poor tradeoff. Instead of
needing to use "pass" (say) one time in a thousand when it is needed, you
would need to use "end" 999 times in a thousand when it *isn't* needed.
> for x in sequence:
> print("Something")
> end
> print("Something else")
>
> (And no speculation at all if 'end' was mandatory. Python already
> provides 'else' (and 'except'?) which can do a similar job in some
> circumstances.)
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Is there a way to invoke remote power shell as Admin.
Hi, I am basically trying to solve the following problem http://stackoverflow.com/questions/38540424/open-power-shell-as-admin-on-remote-vm Regards Clove -- https://mail.python.org/mailman/listinfo/python-list
Re: Just starting to learn Python, and encounter a problem
Heuh case 2 : "String1" or "String2" Evaluates to "String1" ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Just starting to learn Python, and encounter a problem
On 2016-07-23 19:18, gst wrote:
Heuh case 2 :
"String1" or "String2"
Evaluates to "String1" ?
Suppose you have:
x or y
If bool(x) returns True, then the result will be x, else the result will
be y.
Example 1:
bool("String1") returns True, therefore the result of:
"String1" or "String2"
is "String1".
Example 2:
bool("") returns False, so the result of:
"" or "String2"
is "String2".
(The empty string "" is considered 'false-y'; all other strings (i.e.
all non-empty strings) are considered 'true-y'.)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Just starting to learn Python, and encounter a problem
On Sun, 24 Jul 2016 04:18 am, gst wrote: > Heuh case 2 : > > "String1" or "String2" > > Evaluates to "String1" ? Correct. What did you expect? Have you read the Fine Manual? https://docs.python.org/3/reference/expressions.html#boolean-operations -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
