Re: How asyncio works? and event loop vs exceptions
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 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) Really good suggestion, thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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 think your credit card bill last month was big, but infinity is much bigger. Mathematicians deal with numbers which are so unfathomably huge that we can't even talk about them using the ordinary notation we use for ordinary numbers. Take something as unbelievably big as Graham's Number, so big they had to invent specialised notation just to discuss it: http://mathworld.wolfram.com/GrahamsNumber.html http://www.youtube.com/watch?v=XTeJ64KD5cg Let's make it bigger! Square it. No, cube it! Take the factorial! Cube it again! Raise that number to the power of itself! Add one! Compared to infinity, this new number is infinitesimally tiny. Compared to infinity, this new number is barely even there. Compared to infinity, that new number might as well be zero. Given that any actual program has to *exist* in order to be tested, it must be finite in size. Since the observable universe contains "merely" something of the order of 10**89 or so elementary particles (electrons, protons, etc) even with the combinatory explosion of possibilities, the upper bound on the number of test cases will be something like (10**89)**(10**89), which is minuscule compared to Graham's Number, let alone our even Vaster number. Which is so far short of infinity that in one sense we can say that it has barely even taken a single step in the direction of infinity. (Of course I realise you were using "infinite" just as hyperbole. I just couldn't resist bringing Graham's Number into the discussion.) -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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? I don't think I've ever seen any real-life C code that used a pointer to an array, as opposed to a pointer to the first element of the array. (Yes everyone uses T*a (pointer to T) instead of T(*a)[] (pointer to array of T), because, thanks to how C mixes up deferencing and indexing, the former can be accessed as a[i] instead of (*a)[i]. But it's wrong, and leads to errors that the language can't detect. Such as when a points to a single element not a block: define ANY combination such as 'pointer to pointer to array'; you need to access an element using (deref, deref, index), but C also allows (index, deref, deref) or (deref, index, deref), or (index, index, index). Provided the right number of deref/index ops are provided, C can't tell the difference because derefs and index ops are interchangeable! But only one combination is correct. I came across T(*a)[] when translating from a language that handles this properly, into C. In fact I use the translator to convert type-specs from straightforward format into C. Another tool to get around a flaw.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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 have been entire redundant and
unnecessary. You know when the block ends: it ends when one of two things
happen:
- you dedent out a level;
- you reach the end of file;
whichever happens next. Requiring an otherwise pointless end of block
delimiter to protect against your cat walking over your keyboard, or clumsy
programmers who accidentally hit keys and don't notice, is not a virtue. It
doesn't make the language better. It just increases friction when writing
code.
Remember when movies used to finish with "The End"? I wonder what that
was all about? After all you can tell when it's finished when you see
the opening titles of the next movie! Or when the lights come back up in
the cinema ('theater').
If you've ever watched Monty Python (on topic!) and the Holy Grail at
the cinema, you will have appreciated it even more. You just get a black
screen and nothing more happens. People were waiting for several
minutes, eventually starting to get up and leave.
END may seem redundant, but it's just very handy. You know FOR SURE you
are at a particular point, instead of having to infer it from what may
or may not come next, which might not be visible off the bottom of the
screen.
When you're typing plain English paragraphs like this, why don't you end
each sentence with "END"
The period is more the equivalent of C's semicolon. That nearly always
coincides with end-or-line so also lends itself to be inferred, as
horizontally source code tends to be a limited width.
But otherwise free-flowing English text is not a good comparison with a
programming language syntax.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Algorithm for sequencing a collection of dependent equations
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 > None I'm looking for an algorithm/data structure that will me to start with the least dependent expression (t, x, y) and move through the list of expressions in dependency order ending with the expression with the most dependencies. I imagine that spreadsheets have to perform a similar type of analysis to figure out how to recalculate their cells. Suggestions on algorithms and/or data structures (some form of graph?) to support the above goals? Thank you, Malcolm assuming you have no loops then the topological sort is what you need. If you have mutual dependencies then you need to find a set of variables that cuts all the loops and solve for those simultaneously. Unfortunately for a directed graph structure I think the minimal cutset problem is NP complete so good luck with that. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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 work out the other one you need to know operator precedence, but you need to know operator precedence to understand a _lot_ of things. C type _casts_ are slightly harder, since you have to work out where the identifier belongs in a token sequence that has had it removed. But it's usually not hard [look for the sequence "*)", which is otherwise illegal and appears in most complicated type casts]. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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 Your exemplar however is ironic What everyone calls window it calls frame; what everyone calls pane it calls window because its legacy from pre-gui days What everyone calls Alt it calls Meta and shortens it to “M-” because the Sun workstations that have been dead 20 years had a Meta-key And the most annoying bugbear: The whole world uses cua keys: https://en.wikipedia.org/wiki/IBM_Common_User_Access it proudly sticks to what it was doing pre-cua I could go on… -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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 how to move a window with the keyboard, and s/he won't say "Alt-F7"), and some Windows applications make this even worse (Adobe Reader egregiously so - you can't even use Ctrl-Ins to copy to the clipboard, despite all the rest of Windows supporting it). But hey. MOST of the world uses the CUA keys. And yes, Emacs doesn't. For better or for worse, you have to learn Emacs as its own thing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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 world" doesn't. Windows itself lacks quite a few of > the CUA keys (ask a Windows user how to move a window with the > keyboard, and s/he won't say "Alt-F7"), and some Windows applications > make this even worse (Adobe Reader egregiously so - you can't even use > Ctrl-Ins to copy to the clipboard, despite all the rest of Windows > supporting it). Ok I was speaking in-a-manner-of-speaking -- in two ways All means most Cua means the most common cua-keys — C-x C-c C-v of which the first two specially are so deeply embedded into emacs as prefixes for 100s of other functions that its hard to change without significant upheaval > > But hey. MOST of the world uses the CUA keys. And yes, Emacs doesn't. > For better or for worse, you have to learn Emacs as its own thing. Yeah… Just playing around with magit It the tool of choice in emacs world as a git client And in all probability the best git client around So yes emacs is unbeatable and emacs is obsolete And that’s what makes it so annoying — impossible to find a replacement -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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 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 how to move a window with the >> keyboard, and s/he won't say "Alt-F7"), and some Windows applications >> make this even worse (Adobe Reader egregiously so - you can't even use >> Ctrl-Ins to copy to the clipboard, despite all the rest of Windows >> supporting it). > > Ok I was speaking in-a-manner-of-speaking -- in two ways > All means most > Cua means the most common cua-keys — C-x C-c C-v > of which the first two specially are so deeply embedded into emacs as prefixes > for 100s of other functions that its hard to change without significant > upheaval Wrong - CUA's standard keys are Shift-Del, Ctrl-Ins, Shift-Ins for the same operations. The alphabetics are not part of the CUA standard. That said, though, most applications support both - primarily because most GUI widgets are built to support both, and applications are taught to respond to signals like 'paste'. This is one of those cases where building your own is both way more work AND way less useful to people; the same thing often happens when a program decides to be "cute" with its UI and get rid of the title bar and regular frame, painting its own window borders and stuff. It's a lot of work to make that look decent, and then you end up with something that doesn't play nicely with the rest of the system. You'd better have a really good justification for that - and no, "it looks pretty" is NOT that justification. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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
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 current function. TD;LR: I want to peek 1 level up the call stack for this information. A bonus would be a way to have my logger use info vs the current %(module)s, %(funcName)s, and %(lineno)d values. Thank you, Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: Caller's module name, function/method name and line number for output to logging
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 look 2 levels up. 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 current function. TD;LR: I want to peek 1 level up the call stack for this information. A bonus would be a way to have my logger use info vs the current %(module)s, %(funcName)s, and %(lineno)d values. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Caller's module name, function/method name and line number for output to logging
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! That's exactly what I was looking for. Thank you, Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Unittest
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 production? What is the best way of working with unittest? BR Joaquin This email is confidential and may be subject to privilege. If you are not the intended recipient, please do not copy or disclose its content but contact the sender immediately upon receipt. -- https://mail.python.org/mailman/listinfo/python-list
Re: Spot the bug: getoptquestion.py
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 was that the shell getopt on my system ignores leading and trailing spaces. -- 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
Re: Unittest
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 projects and setup their setup.py. On Mon, Jul 25, 2016 at 9:45 AM, 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. > > 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 production? > > What is the best way of working with unittest? > > BR > > Joaquin > > This email is confidential and may be subject to privilege. If you are not > the intended recipient, please do not copy or disclose its content but > contact the sender immediately upon receipt. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Unittest
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 tests in the deployed environment. > 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 production? I would advise not to bother. Prepare the release of the entire source needed to build the distribution, and don't worry about somehow excluding the test suite. > This email is confidential and may be subject to privilege. If you are not > the intended recipient, please do not copy or disclose its content but > contact the sender immediately upon receipt. Please do not use an email system which appends these obnoxious messages in a public forum. Either convince the people who impose that false disclaimer onto your message to stop doing that; or, stop using that system for writing to a public forum. -- \ “Are you pondering what I'm pondering?” “Umm, I think so, Don | `\ Cerebro, but, umm, why would Sophia Loren do a musical?” | _o__) —_Pinky and The Brain_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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: > >> > 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 how to move a window with the > >> keyboard, and s/he won't say "Alt-F7"), and some Windows applications > >> make this even worse (Adobe Reader egregiously so - you can't even use > >> Ctrl-Ins to copy to the clipboard, despite all the rest of Windows > >> supporting it). > > > > Ok I was speaking in-a-manner-of-speaking -- in two ways > > All means most > > Cua means the most common cua-keys — C-x C-c C-v > > of which the first two specially are so deeply embedded into emacs as > > prefixes > > for 100s of other functions that its hard to change without significant > > upheaval > > Wrong - CUA's standard keys are Shift-Del, Ctrl-Ins, Shift-Ins for the > same operations. The alphabetics are not part of the CUA standard. > That said, though, most applications support both - primarily because > most GUI widgets are built to support both, and applications are > taught to respond to signals like 'paste'. You must be right Ironically I learnt the word cua from emacs’ cua-mode which basically make C-c C-x C-v (dont know which others) behave like the rest of the world expects. Trouble is the first two are so deeply enmeshed into emacs that it does a bad job of it. And conventional wisdom in emacs land is to avoid it and get used to the (30+ year old!) emacs standard -- https://mail.python.org/mailman/listinfo/python-list
Re: Unittest
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. They are there when you run IDLE. I like to put if __name__ == '__main__': at the bottom of non-script files. Some people don't like this, but it makes running the tests trivial while editing a file -- whether to make a test pass or to avoid regressions when making 'neutral' changes. 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 production? How would you know that you do not introduce bugs when you change code after testing? When you install Python on Windows, installing the test/ directory is a user option. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Caller's module name, function/method name and line number for output to logging
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 needs to look 2 levels up. > > Perfect! That's exactly what I was looking for. Fine! Then you can avoid the evil hack I came up with many moons ago: https://mail.python.org/pipermail/python-list/2010-March/570941.html ;) -- https://mail.python.org/mailman/listinfo/python-list
