A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-April/052740.html below:

[Python-Dev] anonymous blocks

[Python-Dev] anonymous blocksGuido van Rossum gvanrossum at gmail.com
Tue Apr 19 23:28:16 CEST 2005
> Why not have the block automatically be inserted into acquire's argument
> list?  It would probably get annoying to have to define inner functions
> like that every time one simply wants to use arguments.

But the number of *uses* would be much larger than the number of
"block decorators" you'd be coding. If you find yourself writing new
block decorators all the time that's probably a sign you're too much
in love with the feature. :-)

> For example:
> 
> def acquire(block, aLock):
>          aLock.acquire()
>          try:
>                  block()
>          finally:
>                  aLock.release()
> 
> @acquire(myLock):
>         code
>         code
>         code
> 
> Of course, augmenting the argument list in that way would be different
> than the behavior of decorators as they are now.

I don't like implicit modifications of argument lists other than by
method calls. It's okay for method calls because in the x.foo(a) <==>
foo(x, a) equivalence, x is really close to the beginning of the
argument list.

And your proposal would preclude parameterless block decorators (or
turn them into an ugly special case), which I think might be quite
useful:

@forever:
    infinite loop body

@ignore:
    not executed at all

@require:
    assertions go here

and so on.

(In essence, we're inventing the opposite of "barewords" in Perl here, right?)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4