Case Statements

[Chris Angelico]

On Thu, Mar 17, 2016 at 9:53 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Thu, 17 Mar 2016 05:48 pm, Chris Angelico wrote:
>
>> Okay. Let's try this.
> [...]
>> Decorators work. Now let's try NOT using decorators.
>
> You are still using a decorator. You're just not using @ decorator syntax.

Oops, sorry. That was sloppy wording on my part. What I meant was
"decorator syntax".

The rest of your analysis was equally correct.

> But we can fix it like this:
>
>     def x(self):
>         print("Getting x")
>         return 42
>     x = property(x)
>     def y(self, value):
>         print("Setting x to", value)
>     x = x.setter(y)

Oh... I thought x.setter() needed the name to be the same. Okay, in
that case it's not so hard. Doesn't need the messy temporaries of the
other option.

>> This is how CPython implements this (it evaluates the decoration
>> expressions first, leaving them on the stack, then creates the
>> function, then calls the decorators), but I don't see anywhere that
>> this is guaranteed in the docs either - the only way I know this is
>> current behaviour is from trying it (with dis.dis). The documented
>> equivalence simply doesn't work.
>
> It does work. You just have to be careful to not garbage collect objects
> before you can use them :-)

The "documented equivalence" is what's written here:

https://docs.python.org/3/reference/compound_stmts.html#function
"""
For example, the following code

@f1(arg)
@f2
def func(): pass

is equivalent to

def func(): pass
func = f1(arg)(f2(func))
"""

Saying "is equivalent to" implies a correlation that, in this case, is
imperfect. But to be fair, these kinds of edge cases are (a) only of
interest to language developers and the curious, and (b) exist in
quite a few places in the language. The correspondence between
operators and magic methods [1] has the same flaw; saying that x<y
calls x.__lt__(y) is not entirely accurate, but is much more useful to
people than x.__class__.__lt__(x, y) (or is it "type(x).__lt__(x, y)"?
I can never remember what the differences are between type() and
__class__), so it's correct to use that in the docs. Maybe there needs
to be a collection of "language developer esoteria", primarily for the
benefit of alternate implementations? It could enumerate the ways in
which CPython differs from the plain and simple docs, and say which
ones are important language features and which are implementation
details.

ChrisA

[1] https://docs.python.org/3/reference/datamodel.html#object.__lt__