Re: How asyncio works? and event loop vs exceptions

2016-07-25 Thread Marco Sulla via Python-list
On 23 July 2016 at 16:06, Ian Kelly wrote: > 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 fr

Re: Why not allow empty code blocks?

2016-07-25 Thread Steven D'Aprano
On Monday 25 July 2016 13:46, Rustom Mody wrote: > The bald fact that tests are finite and the actual search space for cases for > anything remotely non-trivial is infinite is undeniable. I deny it :-P "Infinity" is pretty big. It's *really* big. It's bigger than most people think. You might th

Re: Why not allow empty code blocks?

2016-07-25 Thread BartC
On 25/07/2016 02:04, Gregory Ewing wrote: BartC wrote: (They don't need to be elaborate to start being confusing. Take 'int *a[]' and 'int (*a)[]'; one of these is an array of pointers, the other a pointer to an array. Quite different! But which is which? Where have you seen 'int (*a)[]' used?

Re: Why not allow empty code blocks?

2016-07-25 Thread BartC
On 25/07/2016 03:37, Steven D'Aprano wrote: On Mon, 25 Jul 2016 08:13 am, BartC wrote: A solid end-of-block symbol (as you get with 'else' and 'except' because then you KNOW that's the end of that block) would have been welcome with the Python indent scheme. A solid end-of-block symbol would

Re: Algorithm for sequencing a collection of dependent equations

2016-07-25 Thread Robin Becker
On 22/07/2016 17:01, Malcolm Greene wrote: .. Here's an example of expressions and their full list of dependencies: a = b + b + b + c + c > b, c, d, e, s, t, x b = c + d + e > c, d, e, s, t, x c = s + 3 > s, x d = t + 1 > t e = t + 2 > t s = x + 100 > x t = 10 > None x = 1 > None y = 2

Re: Why not allow empty code blocks?

2016-07-25 Thread Random832
On Sun, Jul 24, 2016, at 18:13, BartC wrote: > (They don't need to be elaborate to start being confusing. Take 'int > *a[]' and 'int (*a)[]'; one of these is an array of pointers, the other > a pointer to an array. Quite different! But which is which? int (*a)[]; === int x[]; where x is (*a). To

Re: Why not allow empty code blocks?

2016-07-25 Thread Rustom Mody
On Monday, July 25, 2016 at 7:15:36 AM UTC+5:30, Ben Finney wrote: > Even tools that have existed for 25 years have benefited from the > intervening time. No-one uses Emacs *as it was 25 years ago* and expects > to be as proficient as someone using Emacs as it is today. As a general comment — fine

Re: Why not allow empty code blocks?

2016-07-25 Thread Chris Angelico
On Tue, Jul 26, 2016 at 2:54 AM, Rustom Mody wrote: > The whole world uses cua keys: > https://en.wikipedia.org/wiki/IBM_Common_User_Access > [emacs] proudly sticks to what it was doing pre-cua Sadly, the "whole world" doesn't. Windows itself lacks quite a few of the CUA keys (ask a Windows user

Re: Why not allow empty code blocks?

2016-07-25 Thread Rustom Mody
On Monday, July 25, 2016 at 10:32:45 PM UTC+5:30, Chris Angelico wrote: > On Tue, Jul 26, 2016 at 2:54 AM, Rustom Mody wrote: > > The whole world uses cua keys: > > https://en.wikipedia.org/wiki/IBM_Common_User_Access > > [emacs] proudly sticks to what it was doing pre-cua > > Sadly, the "whole wo

Re: Why not allow empty code blocks?

2016-07-25 Thread Chris Angelico
On Tue, Jul 26, 2016 at 3:11 AM, Rustom Mody wrote: > On Monday, July 25, 2016 at 10:32:45 PM UTC+5:30, Chris Angelico wrote: >> On Tue, Jul 26, 2016 at 2:54 AM, Rustom Mody wrote: >> > The whole world uses cua keys: >> > https://en.wikipedia.org/wiki/IBM_Common_User_Access >> > [emacs] proudly st

Re: Why not allow empty code blocks?

2016-07-25 Thread BartC
On 25/07/2016 15:36, Random832 wrote: On Sun, Jul 24, 2016, at 18:13, BartC wrote: [About C type specs] I've replied briefly here as this is off-topic now: http://pastebin.com/ZfcHqpXK -- Bartc -- https://mail.python.org/mailman/listinfo/python-list

Caller's module name, function/method name and line number for output to logging

2016-07-25 Thread Malcolm Greene
Is there a technique for accessing a function's *CALLER* module name, function/method name and line number so that this information can be passed to a logging library's logger? I have a routine that detects an error condition, but I want to report the error's context relative to the caller, not the

Re: Caller's module name, function/method name and line number for output to logging

2016-07-25 Thread Terry Reedy
On 7/25/2016 3:16 PM, Malcolm Greene wrote: Is there a technique for accessing a function's *CALLER* module name, function/method name and line number so that this information can be Look in the inspect module for the inspect stack function. Note that when you call the function, it needs to l

Re: Caller's module name, function/method name and line number for output to logging

2016-07-25 Thread Malcolm Greene
Hi Terry, >> Is there a technique for accessing a function's *CALLER* module name, >> function/method name and line number so that this information can be > Look in the inspect module for the inspect stack function. Note that > when you call the function, it needs to look 2 levels up. Perfect!

Unittest

2016-07-25 Thread Joaquin Alzola
Hi Guys I have a question related to unittest. I suppose a SW that is going to live will not have any trace of unittest module along their code. So is it the way to do it to put all unittest in a preproduction environment and then remove all lines relate to unittest once the SW is release into

Re: Spot the bug: getoptquestion.py

2016-07-25 Thread Steven D'Aprano
On Thu, 7 Jul 2016 09:30 pm, Oscar wrote: > Thanks all for the input. I think it all boils down to: "If you don't > want a space in your long_option, don't put a space in there". No, I don't think so. I think we can do better than that: http://bugs.python.org/issue27619 What decided it for me

Re: Unittest

2016-07-25 Thread Brendan Abel
Generally, all your unittests will be inside a "tests" directory that lives outside your package directory. That directory will be excluded when you build or install your project using your setup.py script. Take a look at some popular 3rd party python packages to see how they structure their proj

Re: Unittest

2016-07-25 Thread Ben Finney
Joaquin Alzola writes: > I suppose a SW that is going to live will not have any trace of > unittest module along their code. Many packages are deployed with their unit test suite. The files don't occupy much space, don't interfere with the running of the program, and can be helpful to run the te

Re: Why not allow empty code blocks?

2016-07-25 Thread Rustom Mody
On Monday, July 25, 2016 at 10:56:41 PM UTC+5:30, Chris Angelico wrote: > On Tue, Jul 26, 2016 at 3:11 AM, Rustom Mody wrote: > > On Monday, July 25, 2016 at 10:32:45 PM UTC+5:30, Chris Angelico wrote: > >> On Tue, Jul 26, 2016 at 2:54 AM, Rustom Mody wrote: > >> > The whole world uses cua keys: >

Re: Unittest

2016-07-25 Thread Terry Reedy
On 7/25/2016 12:45 PM, Joaquin Alzola wrote: Hi Guys I have a question related to unittest. I suppose a SW that is going to live will not have any trace of unittest module along their code. In order to test idlelib, I had to a _utest=False (unittest = False) parameter to some functions. The

Re: Caller's module name, function/method name and line number for output to logging

2016-07-25 Thread Peter Otten
Malcolm Greene wrote: > Hi Terry, > >>> Is there a technique for accessing a function's *CALLER* module name, >>> function/method name and line number so that this information can be > >> Look in the inspect module for the inspect stack function. Note that >> when you call the function, it need