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
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.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
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 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
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 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 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 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
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 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
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 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: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 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 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: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 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 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 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 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 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 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 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 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
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 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
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
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 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
30 matches
Mail list logo
