On Fri, May 4, 2012 at 10:17 PM, Pierre Chanial
wrote:
> Hello,
>
> PEP 377 has been rejected for lack of use cases. Here is one.
>
> I'm writing an MPI-based application and in some cases, when there is less
> work items than processes, I need to create a new communicator excluding the
> processe
Hello,
PEP 377 has been rejected for lack of use cases. Here is one.
I'm writing an MPI-based application and in some cases, when there is less
work items than processes, I need to create a new communicator excluding
the processes that have nothing to do. This new communicator should finally
be f
James Pye wrote:
> The identification of this issue came from an *experiment* attempting to
> create a *single* "daemonized()" CM that would execute the
> with-statement's block in a new child process and, of course, not
> execute it in the parent. At first, I ran into the RuntimeError in the
> par
Greg Ewing wrote:
> Um, no -- it says explicitly right at the very top of
> PEP 343 that it's only about factoring out try/finally
> statements.
>
> There's no way that
>
> try:
> code_block
> finally:
> ...
>
> can fail to enter the code block if you get as far as
> the "try". So it
On Mar 16, 2009, at 3:40 PM, Nick Coghlan wrote:
Not wasted - I prefer having this as a recognised limitation of the
semantics rather than as an accident of the implementation.
Well, I'm glad some good came from the issue report. =)
Who knows, maybe somebody will come up with a real world use
Nick Coghlan wrote:
One of the
premises of PEP 343 was "Got a frequently recurring block of code that
only has one variant sequence of statements somewhere in the middle?
Well, now you can factor that out
Um, no -- it says explicitly right at the very top of
PEP 343 that it's only about factori
Guido van Rossum wrote:
> On Mon, Mar 16, 2009 at 3:19 PM, Nick Coghlan wrote:
>> Guido van Rossum wrote:
Hell, I largely wrote PEP 377 to try to get out of having to document
these semantic problems with the with statement - if I'm having trouble
getting *python-dev* to grasp the p
On Mon, Mar 16, 2009 at 3:19 PM, Nick Coghlan wrote:
> Guido van Rossum wrote:
>>> Hell, I largely wrote PEP 377 to try to get out of having to document
>>> these semantic problems with the with statement - if I'm having trouble
>>> getting *python-dev* to grasp the problem, what hope do other use
Guido van Rossum wrote:
>> Hell, I largely wrote PEP 377 to try to get out of having to document
>> these semantic problems with the with statement - if I'm having trouble
>> getting *python-dev* to grasp the problem, what hope do other users of
>> Python have?
>
> Hell, if you can't come up with
Baptiste Carvello wrote:
> Nick Coghlan a écrit :
>>
>> Implementing __with__ instead would give the CM complete control over
>> whether or not to execute the block.
>>
> please note, however, that this is an important change in the semantics
> of the with statement. As things are today, barring ex
On Mon, Mar 16, 2009 at 2:37 PM, Nick Coghlan wrote:
> Guido van Rossum wrote:
>> Yeah, it really seems pretty much limited to contextlib.nested(). I'd
>> be happy to sacrifice the possibility to *exactly* emulate two nested
>> with-statements.
>
> Then I really haven't explained the problem well
Guido van Rossum wrote:
> Yeah, it really seems pretty much limited to contextlib.nested(). I'd
> be happy to sacrifice the possibility to *exactly* emulate two nested
> with-statements.
Then I really haven't explained the problem well at all. One of the
premises of PEP 343 was "Got a frequently r
Nick Coghlan a écrit :
Implementing __with__ instead would give the CM complete control over
whether or not to execute the block.
please note, however, that this is an important change in the semantics of the
with statement. As things are today, barring exceptional circunstances, the body
of
On Mon, Mar 16, 2009 at 11:26 AM, Steven Bethard
wrote:
> On Mon, Mar 16, 2009 at 11:06 AM, Guido van Rossum wrote:
>> Moreover, since the main use case seems to be fixing a corner case of
>> the nested() context manager, perhaps the effort towards changing the
>> language would be better directe
On Mon, Mar 16, 2009 at 11:06 AM, Guido van Rossum wrote:
> Moreover, since the main use case seems to be fixing a corner case of
> the nested() context manager, perhaps the effort towards changing the
> language would be better directed towards supporting "with a, b:" as a
> shorthand for "with a
Moreover, since the main use case seems to be fixing a corner case of
the nested() context manager, perhaps the effort towards changing the
language would be better directed towards supporting "with a, b:" as a
shorthand for "with a: with b:" .
On Mon, Mar 16, 2009 at 10:01 AM, Guido van Rossum w
I have no right to speak because I haven't read through all the
details of the proposal, but reading this I am very sad that we have
to introduce a whole new exception (and one with special status as
well) in order to fix such a niggly corner case of the context manager
protocol.
Since IIUC the or
Michael Foord wrote:
> Well, StopIteration is still an implementation detail that only
> occasionally bleeds through to actual programming. It says nothing about
> whether using exceptions for non-exceptional circumstances (control
> flow) is good practise. Personally I think it makes the intent of
P.J. Eby wrote:
> At 06:28 AM 3/16/2009 +1000, Nick Coghlan wrote:
>> There are some practical hurdles to that idea (specifically, creating a
>> callable which uses its parent's namespace rather than having its own),
>> but the basic concept seems sound.
>
> Actually, that bit's pretty simple -- t
> Well, StopIteration is still an implementation detail that only
> occasionally bleeds through to actual programming. It says nothing about
> whether using exceptions for non-exceptional circumstances (control
> flow) is good practise. Personally I think it makes the intent of code
> less easy to
P.J. Eby wrote:
> Of course, at that point, what's the difference between:
>
> with foo() as bar:
> baz
>
> and...
>
> �...@foo
> def bar():
> baz
>
> except for being slightly less verbose? (due to missing nonlocal statements,
> etc.)
That's not quite direct translation. Clo
Aahz wrote:
This is pretty much the canonical example showing why control-flow
exceptions are a Good Thing. They're a *structured* goto.
I'm wondering whether what we really want is something
that actually *is* a structured goto. Or something like
a very light-weight exception that doesn't ca
On Mon, Mar 16, 2009 at 1:00 AM, Michael Foord
wrote:
> You didn't include all the code - so impossible to match the exact
> semantics. Breaking out of multiple loops with a return is a cleaner way to
> handle it IMHO.
I don't really see why this is cleaner; they're both just structured
gotos. He
Aahz wrote:
On Sun, Mar 15, 2009, Michael Foord wrote:
It seems to me that we as a development community already made a decision
when we switched to StopIteration as the primary mechanism for halting
``for`` loops.
If was previously IndexError that stopped for loops, so that was not new
;-).
Aahz wrote:
On Sun, Mar 15, 2009, Michael Foord wrote:
Aahz wrote:
On Sun, Mar 15, 2009, Michael Foord wrote:
Note that using exceptions for control flow can be bad for other
implementations of Python. For example exceptions on the .NET
framework are very expensive. (Alt
On Sun, Mar 15, 2009, Michael Foord wrote:
> Aahz wrote:
>> On Sun, Mar 15, 2009, Michael Foord wrote:
>>>
>>> Note that using exceptions for control flow can be bad for other
>>> implementations of Python. For example exceptions on the .NET
>>> framework are very expensive. (Although ther
Aahz wrote:
On Sun, Mar 15, 2009, Michael Foord wrote:
Note that using exceptions for control flow can be bad for other
implementations of Python. For example exceptions on the .NET framework
are very expensive. (Although there are workarounds such as not really
raising the exception -
On Sun, Mar 15, 2009, Michael Foord wrote:
>
> Note that using exceptions for control flow can be bad for other
> implementations of Python. For example exceptions on the .NET framework
> are very expensive. (Although there are workarounds such as not really
> raising the exception - but the
At 06:28 AM 3/16/2009 +1000, Nick Coghlan wrote:
There are some practical hurdles to that idea (specifically, creating a
callable which uses its parent's namespace rather than having its own),
but the basic concept seems sound.
Actually, that bit's pretty simple -- they're just "nonlocal"
vari
Martin v. Löwis wrote:
I'm talking about IronPython on the Microsoft .NET framework - although
it is likely that the same is true of IronPython on Mono.
I see. It would be interesting to find out why this is so much slower -
I cannot believe that it is inherent in the commercial .NET frame
Nick Coghlan wrote:
> Rough spec for the concept:
>
> Implementing __enter__/__exit__ on a CM would work as per PEP 343.
>
> Implementing __with__ instead would give the CM complete control over
> whether or not to execute the block.
>
> The implementation of contextlib.GeneratorContextManager w
Michael Foord wrote:
> Nick Coghlan wrote:
>>> Note that using exceptions for control flow can be bad for other
>>> implementations of Python. For example exceptions on the .NET framework
>>> are very expensive. (Although there are workarounds such as not really
>>> raising the exception - but the
> I'm talking about IronPython on the Microsoft .NET framework - although
> it is likely that the same is true of IronPython on Mono.
I see. It would be interesting to find out why this is so much slower -
I cannot believe that it is inherent in the commercial .NET framework,
but rather expect tha
gl...@divmod.com wrote:
>
> On 12:56 pm, ncogh...@gmail.com wrote:
>> PEP 377 is a proposal to allow context manager __enter__() methods to
>> skip the body of the with statement by raising a specific (new) flow
>> control exception.
>>
>> Since there is a working reference implementation now, I t
Nick Coghlan wrote:
Note that using exceptions for control flow can be bad for other
implementations of Python. For example exceptions on the .NET framework
are very expensive. (Although there are workarounds such as not really
raising the exception - but they're ugly).
Is it that excepti
Michael Foord wrote:
> Brett Cannon wrote:
>> Without knowing what StatementSkipped is (just some singleton? If so
>> why not just used SkipStatement instance that was raised?)
It does get described in the full PEP - it is indeed just a singleton
like NotImplemented. That whole aspect of the PEP i
Martin v. Löwis wrote:
Note that using exceptions for control flow can be bad for other
implementations of Python. For example exceptions on the .NET framework
are very expensive.
Why do you say that? What specific implementation of .NET are you
referring to? What do you mean by "very"?
For Jython, this proposal would not present any problems. Exceptions are in
any event of lower cost than for CPython.
Given that we have now adopted Python bytecode for various scenarios where
we cannot compile to Java bytecode, it would be nice to track any changes in
the VM such as the proposed
> Note that using exceptions for control flow can be bad for other
> implementations of Python. For example exceptions on the .NET framework
> are very expensive.
Why do you say that? What specific implementation of .NET are you
referring to? What do you mean by "very"?
> Isn't it better practis
On 12:56 pm, ncogh...@gmail.com wrote:
PEP 377 is a proposal to allow context manager __enter__() methods to
skip the body of the with statement by raising a specific (new) flow
control exception.
Since there is a working reference implementation now, I thought it was
time to open it up for bro
On Sun, Mar 15, 2009 at 10:50 AM, Michael Foord
wrote:
> Brett Cannon wrote:
>>
>> Without knowing what StatementSkipped is (just some singleton? If so why
>> not just used SkipStatement instance that was raised?) and wondering if we
>> are just going to continue to adding control flow exceptions
Brett Cannon wrote:
Without knowing what StatementSkipped is (just some singleton? If so
why not just used SkipStatement instance that was raised?) and
wondering if we are just going to continue to adding control flow
exceptions that directly inherit from BaseException or some
ControlFlowExcep
Without knowing what StatementSkipped is (just some singleton? If so why not
just used SkipStatement instance that was raised?) and wondering if we are
just going to continue to adding control flow exceptions that directly
inherit from BaseException or some ControlFlowException base class, the
basi
PEP 377 is a proposal to allow context manager __enter__() methods to
skip the body of the with statement by raising a specific (new) flow
control exception.
Since there is a working reference implementation now, I thought it was
time to open it up for broader discussion.
Full PEP attached, or yo
44 matches
Mail list logo
