Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

Nathaniel Smith wrote: So what should this async_signals_masked state do when we yield out from under it? If it's a thread-local, then the masking state will "leak" into other async function callstacks (or similar for regular generators), which is pretty bad. But it can't be just frame-local

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

On Wed, Jun 28, 2017 at 6:19 AM, Greg Ewing wrote: > Erik Bray wrote: >> >> At this point a potentially >> waiting SIGINT is handled, resulting in KeyboardInterrupt being raised >> while inside the with statement's suite, and finally block, and hence >> Lock.__exit__

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

Erik Bray wrote: My question would be to make that a language-level requirement of the context manager protocol, or just something CPython does... I think it should be a language-level requirement, otherwise it's not much use. Note that it's different from some existing CPython-only behaviour

Re: [Python-ideas] + operator on generators

On 28.06.2017 20:37, Koos Zevenhoven wrote: Oh, I've been very close to getting one of those. But then I should probably get a pair of glasses too ;). :D ​​That pattern annoys people and negates the benefits of views and generators.​ Sure, that's why I am in favor of this proposal. It

Re: [Python-ideas] Improving Catching Exceptions

On 28.06.2017 21:14, Nathaniel Smith wrote: With PEP 479 there was a different and better way to generate a StopIteration if you wanted one (just 'return'). Here I'm afraid existing projects might actually be relying on the implicit exception leakage in significant numbers :-/ My concern as

Re: [Python-ideas] Improving Catching Exceptions

On 28.06.2017 15:26, Nick Coghlan wrote: 1. In 3.3+ you can just catch ImportError, check "exc.name", and re-raise if it's not for the module you care about I see, didn't know that one. I gave it a try and it's not 100% the behavior I have expected, but one could workaround if the valid

Re: [Python-ideas] Improving Catching Exceptions

On Jun 28, 2017 6:26 AM, "Nick Coghlan" wrote: On 28 June 2017 at 21:48, Sven R. Kunze wrote: > As it was snipped away, let me ask again: > > I don't see how this helps differentiating shallow and nested exceptions > such as: > > try: > with

Re: [Python-ideas] + operator on generators

On Wed, Jun 28, 2017 at 9:01 PM, Sven R. Kunze wrote: > Good man. Today, a colleague of mine showed me a mobile mini-keyboard with > a phone bracket (not even a dock). So, having his 7'' smartphone, he can > work from his vacations and answer emails as well. ;) Cheap notebook >

Re: [Python-ideas] + operator on generators

On 2017-06-28 09:16, Steven D'Aprano wrote: On Tue, Jun 27, 2017 at 01:53:37PM -0700, Mike Miller wrote: > >On 2017-06-25 20:23, Steven D'Aprano wrote: > >I have a counter-proposal: introduce the iterator chaining operator "&": > > > > iterable & iterable --> itertools.chain(iterable,

Re: [Python-ideas] + operator on generators

On 28.06.2017 16:01, Koos Zevenhoven wrote: For a moment, I was wondering what the double emphasis was for, but then I realized you are simply calling `statement.__why__()`​ directly instead of the recommended `spoiler(statement)`. Doing this for years now. Sometimes, when

Re: [Python-ideas] + operator on generators

On Wed, Jun 28, 2017 at 12:47:21PM +1000, Nick Coghlan wrote: > While I haven't been following this thread closely, I'd like to note > that arguing for a "chain()" builtin has the virtue that would just be > arguing for the promotion of the existing itertools.chain function > into the builtin

Re: [Python-ideas] + operator on generators

On Tue, Jun 27, 2017 at 01:53:37PM -0700, Mike Miller wrote: > > On 2017-06-25 20:23, Steven D'Aprano wrote: > >I have a counter-proposal: introduce the iterator chaining operator "&": > > > > iterable & iterable --> itertools.chain(iterable, iterable) > > > > I like this suggestion. Here's

Re: [Python-ideas] + operator on generators

On Wed, Jun 28, 2017 at 3:18 PM, Sven R. Kunze wrote: > On 28.06.2017 14:00, Koos Zevenhoven wrote: > > The programmer needs to be well aware of whether the resulting object is a > Sequence or 'just' a generator. > > > Could you elaborate more on **why**? > > ​For a moment, I

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

On Wed, Jun 28, 2017 at 3:19 PM, Greg Ewing wrote: > Erik Bray wrote: >> >> At this point a potentially >> waiting SIGINT is handled, resulting in KeyboardInterrupt being raised >> while inside the with statement's suite, and finally block, and hence >> Lock.__exit__

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

On Wed, Jun 28, 2017 at 3:09 PM, Erik Bray wrote: > On Wed, Jun 28, 2017 at 2:26 PM, Nick Coghlan wrote: >> On 28 June 2017 at 21:40, Erik Bray wrote: >>> My colleague's contention is that given >>> >>> lock = threading.Lock()

Re: [Python-ideas] Improving Catching Exceptions

On 28 June 2017 at 21:48, Sven R. Kunze wrote: > As it was snipped away, let me ask again: > > I don't see how this helps differentiating shallow and nested exceptions > such as: > > try: > with exception_guard(ImportError): > import myspeciallib > except

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

Erik Bray wrote: At this point a potentially waiting SIGINT is handled, resulting in KeyboardInterrupt being raised while inside the with statement's suite, and finally block, and hence Lock.__exit__ are entered. Seems to me this is the behaviour you *want* in this case, otherwise the lock can

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

On Wed, Jun 28, 2017 at 2:26 PM, Nick Coghlan wrote: > On 28 June 2017 at 21:40, Erik Bray wrote: >> My colleague's contention is that given >> >> lock = threading.Lock() >> >> this is simply *wrong*: >> >> lock.acquire() >> try: >> do_something()

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

On 28 June 2017 at 21:40, Erik Bray wrote: > My colleague's contention is that given > > lock = threading.Lock() > > this is simply *wrong*: > > lock.acquire() > try: > do_something() > finally: > lock.release() > > whereas this is okay: > > with lock: >

Re: [Python-ideas] + operator on generators

On 28.06.2017 14:00, Koos Zevenhoven wrote: The programmer needs to be well aware of whether the resulting object is a Sequence or 'just' a generator. Could you elaborate more on **why**? Regards, Sven PS: I consider this proposal to be like allowing adding floats and ints together. If I

Re: [Python-ideas] + operator on generators

On Wed, Jun 28, 2017 at 11:54 AM, Paul Moore wrote: > Indeed. I don't recall *ever* using itertools.chain myself. ​ In fact, me neither. Or maybe a couple of times. For such a basic task, it feels more natural to write a generator function, or even turn it into a list, if

Re: [Python-ideas] Improving Catching Exceptions

On 28.06.2017 08:00, Nick Coghlan wrote: Right, and I'd like us to keep in mind the KeyError -> AttributeError (and vice-versa) use case as well. Similar to ExitStack, it would be appropriate to make some additions to the "recipes" section in the docs that covered things like "Keep

[Python-ideas] Asynchronous exception handling around with/try statement borders

Hi folks, I normally wouldn't bring something like this up here, except I think that there is possibility of something to be done--a language documentation clarification if nothing else, though possibly an actual code change as well. I've been having an argument with a colleague over the last

Re: [Python-ideas] + operator on generators

On 28.06.2017 11:09, Nick Coghlan wrote: The other thing to look for would be list() and list.extend() calls. I know I use those quite a bit in combination with str.join, where I don't actually *need* a list, it's just currently the most convenient way to accumulate all the components I'm

Re: [Python-ideas] + operator on generators

On 28 June 2017 at 18:54, Paul Moore wrote: > On 28 June 2017 at 05:30, Terry Reedy wrote: >> A counter-argument is that there are other itertools that deserve promotion, >> by usage, even more. But we need to see comparisons from more that one >> limited

Re: [Python-ideas] + operator on generators

On 28 June 2017 at 05:30, Terry Reedy wrote: > On 6/27/2017 10:47 PM, Nick Coghlan wrote: > >> While I haven't been following this thread closely, I'd like to note >> that arguing for a "chain()" builtin has the virtue that would just be >> arguing for the promotion of the

Re: [Python-ideas] + operator on generators

On 28 June 2017 at 14:30, Terry Reedy wrote: > On 6/27/2017 10:47 PM, Nick Coghlan wrote: >> Such an approach has a lot to recommend it: >> >> 1. It has precedent, in that Python 3's map(), filter(), and zip(), >> are essentially Python 2's itertools.imap(), ifilter(), and

Re: [Python-ideas] Improving Catching Exceptions

On 28 June 2017 at 13:16, Chris Angelico wrote: > On Wed, Jun 28, 2017 at 12:25 PM, Nick Coghlan wrote: >> While generator functions now do that implicitly for StopIteration, >> and "raise X from Y" lets people write suitable exception handlers >>