[Michele Simionato]
Is there in the plans any facility to copy functions? Currently I am
doing
def copyfunc(func):
Creates an independent copy of a function.
c = func.func_code
nc = new.code(c.co_argcount, c.co_nlocals, c.co_stacksize,
c.co_flags,
c.co_code,
Ron Adam wrote:
There seems to be some confusion as to weather or
not 'for's will do finalizing. So I was trying to stress I think
regular 'for' loops should not finalize. They should probably give an
error if an object with an try-finally in them or an __exit__ method.
But if the
Ron Adam [EMAIL PROTECTED] wrote:
The argument over whether blocks should loop, I believe has been had;
they should. The various use cases involve multi-part transactions and
such.
I think so now too, I had thought as Nick does earlier this week that
the non-looping version was
Nick Coghlan ncoghlan at gmail.com wrote:
Josiah Carlson wrote:
This has the benefit that an arbitrary block of code can be named,
and a named TerminateBlock used to exit it.
... I suspect any such implementation is going to need to use
exceptions for the guts of the flow control, even if
Greg Ewing wrote:
Ron Adam wrote:
There seems to be some confusion as to weather or
not 'for's will do finalizing. So I was trying to stress I think
regular 'for' loops should not finalize. They should probably give an
error if an object with an try-finally in them or an __exit__ method.
Jim Jewett [EMAIL PROTECTED] wrote:
Nick Coghlan ncoghlan at gmail.com wrote:
Josiah Carlson wrote:
This has the benefit that an arbitrary block of code can be named,
and a named TerminateBlock used to exit it.
... I suspect any such implementation is going to need to use
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] wrote:
There's also the possibility to use conditional looping based on the
value returned from the generator.
do VAR from EXPR if VAR==CONST:
BLOCK
This is a bit verbose, but it
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] wrote:
Yes, so just do [VAR from] EXPR1:
Regardless of the 'finalization' syntax, I'm talking about the fact that
including extra 'if EXPR' or 'while EXPR' is not going to be an option.
Yes, I meant for the syntax to be the shorter form,
M.-A. Lemburg wrote:
On sre character classes: I don't think that these provide
a good approach to XML lexical classes - custom functions
or methods or maybe even a codec mapping the characters
to their XML lexical class are much more efficient in
practice.
That isn't my experience:
Raymond Hettinger wrote:
[Nick Coghlan]
The number of good use cases for a looping block statement currently
stands at
exactly 1 (auto_retry). Every other use case suggested (locking,
opening,
suppressing, etc) involves factoring out try statement boiler plate
that
is far
easier to
Ron Adam wrote:
That's sort of why I'm against changing 'for', and for adding
the new loop/block. I see it as a loop with a higher level of
abstraction. A new tool to be used in new ways, but I want to keep my
old dependable tools too.
But if there's too much overlap in functionality
Josiah Carlson wrote:
2. Standard for/while loops should not be finalized in a timely fashion,
because testing for the proper methods would necessarily slow down large
amounts of current Python, so should be left to the garbage collector.
I'm not convinced about that. If implemented properly,
Apologies if this has been discovered and rejected already; I've had
to skip most of the discussions but this though won't leave my head...
So PEP 310 proposes this:
with VAR = EXPR:
BLOCK
translated to
VAR = EXPR\
if hasattr(VAR, __enter__):
13 matches
Mail list logo
