[Python-ideas] Statement local functions and classes (aka PEP 3150 is dead, say 'Hi!' to PEP 403)

[Nick Coghlan]

On Thu, Oct 13, 2011 at 7:02 PM, Aaron DeVore <aaron.devore at gmail.com> wrote:
> A clean way to have multiple function could be an issue. Perhaps add a
> syntax to refer to either the first function (@) or a named
> function(@x)? I can't think of a great syntax to group the function
> definitions, though.

One of the key things I realised after reflecting on both Ruby's
blocks and Python's own property descriptor is that it's *OK* to only
support a single function in this construct. There's a wide range of
common use cases where the ability to provide a full capability one
shot function would be quite helpful, especially when it comes to
callback based programming. Even in threaded programming, giving each
thread it's own copy of a function may be a convenient alternative to
using synchronisation locks.

Actually, here's an interesting example based on quickly firing up a
worker thread:

postdef t = threading.Thread(target=def); t.start()
def pointless():
    """A pointless worker thread that does nothing except serve as an example"""
    print("Starting")
    time.sleep(3)
    print("Ending")

>> 1. Leave classes out of it, at least for now. We did that with
>> decorators, and I think it's a reasonable approach to follow.
>
> -1. This sounds useful for classes. I'm not sure what, but it still
> sounds useful.

We need more than that to justify keeping classes in the mix - if we
can't think of clear and compelling use cases, then it's better to
omit the feature for now and see if we really want to include it
later.

>> 2. The initial version should be an alternative to decorator syntax,
>> not an addition to it. That is, you wouldn't be able to mix the first
>> incarnation of a block prefix with ordinary decorators.
>
> That would kill off usage of some handy decorators like functools.wraps:
>
>  :some_func(@)
>  @wraps(other_func)
>  def f(b):
>      # function body

No it wouldn't, they'd just need to be called explicitly:

    postdef some_func(wraps(other_func)(def))
    def f(b):
        # function body

As with classes, I'm tempted to call "YAGNI" (You Ain't Gonna Need It)
on this aspect of the initial specification.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia