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/2004-March/043030.html below:

[Python-Dev] PEP 318 - generality of list; restrictions on elements

[Python-Dev] PEP 318 - generality of list; restrictions on elementsMoore, Paul Paul.Moore at atosorigin.com
Wed Mar 10 11:52:34 EST 2004
From: Aahz
> That still leaves the question for what *is* allowed within the
> brackets.  AFAICT, the options are
>
> * A single identifier (which must be a callable)
>
> * Comma-separated list of identifiers (which must be callables)
>
> * Arbitrary expression (which must produce a sequence of callables)

For completeness, and the one which I understood to be the case,

* Comma-separated list of arbitrary expressions

I still prefer not to state "*must* be callable" and instead note
that they *will* be called. The former leaves open the question of
what will happen if the "must" is violated. The latter is entirely
clear. It gets called - so it fails just as it would if called in any
other context.

> BTW, have we agreed on the order in which decorators will be applied?

Possibly not. I've been assuming the equivalence

    def f(a,b) [d1, d2, d3]:
        ...

<=>

    def f(a,b):
        ...
    f = d1(f)
    f = d2(f)
    f = d3(f)

but I haven't confirmed this against mwh's patch, and you're right that
it should be stated explicitly.

Paul.

PS I'm rapidly going off Guido's def f [...] (...) suggestion. As Just
   pointed out, I dislike even spaces between the function name and the
   argument list, so decorators there really do grate.

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