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
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
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
On Sun, Mar 15, 2009 at 10:50 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
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
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 practise for
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
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?
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 is
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
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 thought it
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 that
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 they're ugly).
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 would
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
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
Nick Coghlan wrote:
It actually wouldn't be a bad place to put a create a temporary file
and rename it to name when closing it helper class.
I'm not sure it would be a good idea to make that
behaviour automatic on closing. If anything goes
wrong while writing the file, you *don't* want the
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 they're
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 -
Ok. In that use case, however, it is completely irrelevant whether the
tempfile module calls fsync. After it has generated the non-conflicting
filename, it's done.
I agree, but my comment was that it would be nice if better fsync
support (if added) could be done in such a way that it
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 there are
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.
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
On Mon, Mar 16, 2009 at 1:00 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
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
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. Closer would
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
27 matches
Mail list logo
