Josiah Carlson wrote:
Greg Ewing <[EMAIL PROTECTED]> wrote:
Josiah Carlson wrote:
Since PEP 310 was already mentioned, can we just say that the discussion
can be boiled down to different ways of spelling __enter__/__exit__ from
PEP 310?
It's not quite the same thing. PEP 310 suggests a mechanism
with a fixed control flow -- do something on entry, do the
code block, do something on exit. A general block-passing
mechanism would give complete control to the function as
to when and how to call the block.
I would like to ask a question. Does Python want or need Ruby code
blocks? I ask because that is what is being offered to cure what ails
us. Don't get me wrong, I'm sure code blocks can solve quite a few
problems (and is used as such in Ruby), but I'm not convinced that it is
the solution for Python.
Any manual on Ruby will invariably discuss code blocks as one of the
most powerful features Ruby has to offer. Sounds great. Sounds like a
great big sledgehammer that can be used to do a bunch of things...so
what is currently being proposed as a use for them, and what can't they
do (that would be really nice)?
They are being offered, right now, as a setup and finalization mechanism.
Essentially a way of allowing people to wrap their own blocks of code in
custom try/finally code, or whatever their minds can think up. Ok,
__enter__/__exit__ offers that. What else?
If you were to pass your generator as a code block, then you could
finalize a generator [1], and even raise exceptions in your code block,
but it still wouldn't allow one to pass exceptions into a currently
running generator (a long standing problem such that if we could, then
we would get generator finalization for free [2]).
What else? Let's dig back into the python-dev archives...
http://mail.python.org/pipermail/python-dev/2003-February/032739.html
Guido:
- synchronized-like, where the block should connect to its environment
- property-like, where the block should introduce a new scope, and the
caller should be able to inspect or control that scope's namespace
The synchronized-like thing is the custom try/finally, aka
__enter__/__exit__ as specified in PEP 310.
The property-like thing was perhaps to be an easier way to generate
properties, which fairly quickly fell to the wayside in discussion,
seemingly because people didn't see a need to add thunks for this.
Later XML DOM parsing came into the discussion, and was quickly
dismissed as being not possible due to the Python parser's limited
lookahead.
Someone else mentioned that thunks could be used to generate a switch
statement, but no elaboration was done, and no PEP was actually written
(switch has also had its own PEP, and even talk of a peephole
optimization for certain if/elif/else blocks to be made into dictionary
lookups...)
So where has all this reading gotten me? To the point that I believe
previous discussion had concluded that Ruby-style code blocks have
little use in Python. *shrug*
well, I think some people desire a more streamlined way of writing code
like:
def f(...)
...
def g(...)
...
x = h(...,f,g)
[property, setting up callbacks etc are cases of this]
were f,g etc definitions would appear inline and the whole has a
statement flavor; because this is Python a form that does not involve a
lot parantheses would be nice. Of course if the functions then are
allowed to change the surrounding bindings this could be used for
resource release issues etc.
Notice that decorators basically support a special case of this.
But yes, apart for the issue of rebinding (and if one wants non-local
returns), this is stricly about sugar.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
