On Wed, Jun 28, 2017 at 9:14 PM, Greg Ewing wrote:
> 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
>> gen
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
dat
On 29 June 2017 at 05:14, Nathaniel Smith wrote:
> What about modules that want to raise ImportError to indicate that they
> aren't available on the current system, perhaps because some of their
> dependencies are missing? For example, 'import ssl' should raise an
> ImportError if 'ssl.py' is pres
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__ are entered.
>
>
> Seems to me
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
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 woul
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 w
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 packag
On Tuesday, June 27, 2017, Wes Turner wrote:
>
>
> On Monday, June 26, 2017, Wes Turner > wrote:
>
>>
>>
>> On Sunday, June 25, 2017, Wes Turner wrote:
>>
>>>
>>>
>>> On Sunday, June 25, 2017, Danilo J. S. Bellini
>>> wrote:
>>>
On Sun, Jun 25, 2017 at 3:06 PM, lucas via Python-ideas <
>>
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 exception_guard(ImportError):
> import mys
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
> replacement, if yo
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, itera
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 'statement.__why__()
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 name
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
On Wed, Jun 28, 2017 at 12:25:12PM +1000, Nick Coghlan wrote:
[...]
> So while I prefer "contextlib.convert_exception" as the name (rather
> than the "exception_guard" Steven used in his recipe), I'd definitely
> be open to a bugs.python.org RFE and a PR against contextlib to add
> such a construc
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 was wondering what t
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__ are entered.
>
>
> Seems to me
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()
>>>
>>> this is simply *wrong*:
>>>
>>> lock.acquire()
>>> try:
>>>
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 RuntimeError: # catches shallo
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
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()
>> finally:
>> lock.release()
>>
>> where
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:
> do_something()
Technically bot
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 don
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 you can be sure that th
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 AttributeError
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 cou
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 plannin
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 corpus.
>
> Indeed. I don't recall *ever
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 existing itertools.chain
30 matches
Mail list logo
