Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #104956 > unrolled thread

Case Statements

Back to article view | Back to comp.lang.python

Contents

  Case Statements jj0gen0info@gmail.com - 2016-03-15 13:46 -0700
    Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 23:11 +0000
    Re: Case Statements jj0gen0info@gmail.com - 2016-03-15 16:47 -0700
      Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 23:58 +0000
      Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 00:51 +0000
        Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 01:05 +0000
    Re: Case Statements jj0gen0info@gmail.com - 2016-03-15 18:55 -0700
      Re: Case Statements "Mario R. Osorio" <nimbiotics@gmail.com> - 2016-03-15 21:06 -0700
        Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 10:34 +0000
          Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-16 23:56 +1100
      Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 04:26 +0000
        Re: Case Statements Christian Gollwitzer <auriocus@gmx.de> - 2016-03-16 09:13 +0100
          Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 08:47 +0000
          Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 11:16 +0200
          Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-16 10:35 +0100
          Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 09:51 +0000
            Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 19:41 +0000
              Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 22:30 +0000
          Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-16 11:52 +0100
          Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 11:07 +0000
            Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 11:16 +0000
              Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 11:33 +0000
              Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 14:21 +0200
                Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 12:53 +0000
                  Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 16:31 +0200
                    Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 15:00 +0000
                      Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 19:07 +0200
                Re: Case Statements Rustom Mody <rustompmody@gmail.com> - 2016-03-20 01:01 -0700
                  Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-20 08:29 +0000
          Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-16 14:38 +0100
          Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 14:02 +0000
          Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 21:27 +0200
            Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 09:22 +0100
              Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-17 10:57 +0200
                Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 10:12 +0100
          Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 11:19 +1100
            Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 12:54 +1100
              Re: Case Statements Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-17 18:45 +1300
                Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 17:30 +1100
                  Re: Case Statements Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-18 18:59 +1300
                Re: Case Statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-17 17:29 +1100
                  Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 17:48 +1100
                    Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 21:53 +1100
                      Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 22:49 +1100
              Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 10:23 +0100
              Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 20:55 +1100
            Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 09:36 +0100
          Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 09:38 +0100
    Re: Case Statements l0r0m0a0i0l@gmail.com - 2016-03-16 06:15 -0700
      Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 00:27 +1100
        Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 14:00 +0000
      Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 13:59 +0000
    Re: Case Statements l0r0m0a0i0l@gmail.com - 2016-03-16 07:21 -0700
      Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 16:33 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#105005

On 16/03/2016 11:07, Mark Lawrence wrote:

> I don't want to discourage you too much, but I think that adding a
> switch statement comes *very* low on the list of improvements we would
> like to make in Python 3.5.
>
> We should probably focus on speed ...

OK, you're coming round...

> but I still very much doubt
> we'll be adding a switch statement -- it's a "sexy" language design
> issue

That's the first time I've heard a language feature common in C 
described as sexy.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#105006

On 16/03/2016 11:16, BartC wrote:
> On 16/03/2016 11:07, Mark Lawrence wrote:
>
>> I don't want to discourage you too much, but I think that adding a
>> switch statement comes *very* low on the list of improvements we would
>> like to make in Python 3.5.
>>
>> We should probably focus on speed ...
>
> OK, you're coming round...
>

No, those were the words of the BDFL, not me.  Further, please do not 
deliberately cut words to change the context. The original said quite 
clearly "We should probably focus on speed (or aspects of it, like 
startup)...".

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#105013

BartC <bc@freeuk.com>:

> On 16/03/2016 11:07, Mark Lawrence wrote:
>> but I still very much doubt we'll be adding a switch statement --
>> it's a "sexy" language design issue
>
> That's the first time I've heard a language feature common in C
> described as sexy.

Scheme has a "switch" statement (a "case" form). However, it is slightly
better equipped for it than Python:

 * Scheme has an atom type ("symbol"). It corresponds to interned
   strings and is supposed to be compared by reference.

 * Scheme has defined three equality operators: "eq?", "eqv?" and
   "equal?". Python only has two: "is" (~ "eq?") and "==" (~ "equal?").
   The "case" form makes use of the operator "eqv?" that is missing from
   Python ("eqv?" compares numbers numerically but is otherwise the same
   as "eq?").


Marko

[toc] | [prev] | [next] | [standalone]

#105015

On 16/03/2016 12:21, Marko Rauhamaa wrote:
> BartC <bc@freeuk.com>:

>> That's the first time I've heard a language feature common in C
>> described as sexy.
>
> Scheme has a "switch" statement (a "case" form). However, it is slightly
> better equipped for it than Python:
>
>   * Scheme has an atom type ("symbol"). It corresponds to interned
>     strings and is supposed to be compared by reference.
>
>   * Scheme has defined three equality operators: "eq?", "eqv?" and
>     "equal?". Python only has two: "is" (~ "eq?") and "==" (~ "equal?").
>     The "case" form makes use of the operator "eqv?" that is missing from
>     Python ("eqv?" compares numbers numerically but is otherwise the same
>     as "eq?").
>

Yes, a few scripting languages can do interesting things with switch or 
case statements. Perl for example (where I think it is created out other 
language features, but it looks a regular part of the syntax).

Even Ruby has one. It doesn't do anything 'sexy' with it, but it does 
have this:

  case
  when this
     ....
  when that
     ....
  when other
     ...
  end

which is exactly equivalent to if this... elif that... (when the tests 
are ordered), with one difference:

Each test starts with "when", instead of "if" for the first and "elif" 
for subsequent ones. That makes it easier to reorder tests, temporarily 
comment out the first test, copy a test from elsewhere, insert a new 
first test (you get the idea).

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#105035

BartC <bc@freeuk.com>:

> Yes, a few scripting languages can do interesting things with switch or
> case statements. Perl for example (where I think it is created out other
> language features, but it looks a regular part of the syntax).
>
> Even Ruby has one. It doesn't do anything 'sexy' with it, but it does
> have this:
>
>  case
>  when this
>     ....
>  when that
>     ....
>  when other
>     ...
>  end

That's a different topic.

> which is exactly equivalent to if this... elif that... (when the tests
> are ordered), with one difference:
>
> Each test starts with "when", instead of "if" for the first and "elif"
> for subsequent ones. That makes it easier to reorder tests, temporarily
> comment out the first test, copy a test from elsewhere, insert a new
> first test (you get the idea).

That is no different from a chained if/elif.

Scheme has this:

   (case (* 2 3)
     ((2 3 5 7)
      'prime)
     ((1 4 6 8 9)
      'composite)
     (else
      'unknown))

It has something better than C even:

   (case (die10)
     ((1 3 5 7 9)
      => (lambda (n)
           n))
     (else
      => (lambda (n)
           (/ n 2))))

which maps 1, 3, 5, 7 and 9 onto themselves but halves 2, 4, 6, 8 and
10.

As for a chained if/elif, Scheme as "cond:"

   (cond
    ((windy?)
     (fly-kite))
    ((shining? sun)
     (go-out))
    ((raining?)
     (play-soccer))
    (else
     (read-book)))

which also has a "=>" variant:

   (cond
    ((best-selling-book (this-year))
     => (lambda (book)
          (read book)))
    (else
     (play wii pes08)))


Marko

PS What is a "scripting language?"

[toc] | [prev] | [next] | [standalone]

#105042

On 16/03/2016 14:31, Marko Rauhamaa wrote:
> BartC <bc@freeuk.com>:

>> Even Ruby has one.

>>   case
>>   when this
>>      ....
>>   when that

> That's a different topic.

Yes but, if Ruby has it, why shouldn't Python? (Aren't they rivals or 
something?)

>> which is exactly equivalent to if this... elif that... (when the tests
>> are ordered), with one difference:

> That is no different from a chained if/elif.

That's what I said, but it's an interesting, more symmetric alternative.

> Scheme has this:

>     (case (die10)
>       ((1 3 5 7 9)
>        => (lambda (n)
>             n))
>       (else
>        => (lambda (n)
>             (/ n 2))))
>
> which maps 1, 3, 5, 7 and 9 onto themselves but halves 2, 4, 6, 8 and
> 10.

I don't get this; what does the lambda do here? Why not just yield 
either n or n/2?

> As for a chained if/elif, Scheme as "cond:"

>     (cond
>      ((windy?)
>       (fly-kite))
>      ((shining? sun)
>       (go-out))
>      ((raining?)
>       (play-soccer))
>      (else
>       (read-book)))

Which is like my Ruby case example. Simple and to the point. (Not sure 
of the significance of ?)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#105055

BartC <bc@freeuk.com>:

> On 16/03/2016 14:31, Marko Rauhamaa wrote:
>> Scheme has this:
>
>>     (case (die10)
>>       ((1 3 5 7 9)
>>        => (lambda (n)
>>             n))
>>       (else
>>        => (lambda (n)
>>             (/ n 2))))
>>
>> which maps 1, 3, 5, 7 and 9 onto themselves but halves 2, 4, 6, 8 and
>> 10.
>
> I don't get this; what does the lambda do here? Why not just yield
> either n or n/2?

Scheme is all about lambdas. They are everywhere. The margin of this
posting is too small for me to explain it.

>> As for a chained if/elif, Scheme as "cond:"
>
>>     (cond
>>      ((windy?)
>>       (fly-kite))
>>      ((shining? sun)
>>       (go-out))
>>      ((raining?)
>>       (play-soccer))
>>      (else
>>       (read-book)))
>
> Which is like my Ruby case example. Simple and to the point. (Not sure
> of the significance of ?)

Scheme identifiers can contain punctuation characters. Functions that
return a boolean are conventionally given names that end in a question
mark. Functions that modify their arguments are conventionally given
names that end in an exclamation point.


Marko

[toc] | [prev] | [next] | [standalone]

#105296

On Wednesday, March 16, 2016 at 5:51:21 PM UTC+5:30, Marko Rauhamaa wrote:
> BartC :
> 
> > On 16/03/2016 11:07, Mark Lawrence wrote:
> >> but I still very much doubt we'll be adding a switch statement --
> >> it's a "sexy" language design issue
> >
> > That's the first time I've heard a language feature common in C
> > described as sexy.
> 
> Scheme has a "switch" statement (a "case" form). However, it is slightly
> better equipped for it than Python:
> 
>  * Scheme has an atom type ("symbol"). It corresponds to interned
>    strings and is supposed to be compared by reference.
> 
>  * Scheme has defined three equality operators: "eq?", "eqv?" and
>    "equal?". Python only has two: "is" (~ "eq?") and "==" (~ "equal?").
>    The "case" form makes use of the operator "eqv?" that is missing from
>    Python ("eqv?" compares numbers numerically but is otherwise the same
>    as "eq?").
> 
> 
> Marko

I think it needs to be mentioned:
Almost every modern functional language has pattern matching
And pattern matching is really case statements on steroids

https://www.vex.net/~trebla/haskell/crossroad.xhtml

From those of us who regularly use functional programming, its important
to say that the things that get big press -- lambdas, monads etc -- are probably
less significant than things like pattern matching that dont

A smattering of languages that support it:

Erlang: http://erlang.org/doc/reference_manual/functions.html
Scala: https://kerflyn.wordpress.com/2011/02/14/playing-with-scalas-pattern-matching/
SML: http://www.cs.cornell.edu/courses/cs312/2004fa/lectures/lecture3.htm
Clojure : https://github.com/clojure/core.match

Scheme is an odd case: Does not have it builtin but writing a macro for that is 
an entertaining exercise

[toc] | [prev] | [next] | [standalone]

#105297

On 20/03/2016 08:01, Rustom Mody wrote:
> On Wednesday, March 16, 2016 at 5:51:21 PM UTC+5:30, Marko Rauhamaa wrote:
>> BartC :
>>
>>> On 16/03/2016 11:07, Mark Lawrence wrote:
>>>> but I still very much doubt we'll be adding a switch statement --
>>>> it's a "sexy" language design issue
>>>

I did *NOT* write the above, that was me quoting the BDFL from 
https://mail.python.org/pipermail/python-ideas/2014-April/027667.html.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#105024

Op 16-03-16 om 12:07 schreef Mark Lawrence:
> On 16/03/2016 10:52, Antoon Pardon wrote:
>> Op 16-03-16 om 10:51 schreef Mark Lawrence:
>>> On 16/03/2016 09:35, Antoon Pardon wrote:
>>>> Op 16-03-16 om 09:47 schreef Mark Lawrence:
>>>>>
>>>>>>
>>>>>> Same with switch. You can use a hash table etc. to simulate
>>>>>> switches,
>>>>>> but only if the codeblocks are independent. Otherwise, if-elif
>>>>>> chains
>>>>>> are the way to go. Command line parsing is a case where switch
>>>>>> statements are often used, e.g. in shell scripts.
>>>>>
>>>>> I've seen at least six different ways of simulating switches, so
>>>>> those
>>>>> people who want them, can have them.  if-elif chains are not
>>>>> likely to
>>>>> kill any Python programmer.
>>>>>
>>>>> I have no interest what other languages use switch/case statements
>>>>> for, as we've on the PYTHON mailing list.
>>>>
>>>> There once were multiple ways to simulate a conditional expression.
>>>> And it was generally thought that using if else statements instead
>>>> of a conditional expression was unlikely to kill any Python
>>>> programmer.
>>>>
>>>> But then one of the core developers was bitten by a nasty bug because
>>>> he was using one of those constructs that simulated a conditional
>>>> expression and soon enough Python had a conditional expression.
>>>>
>>>> So I guess those who would like a case statement in Python can
>>>> only hope a core developer gets bitten by a nasty bug while using
>>>> one of those ways of simulating switches.
>>>>
>>>
>>> So that core developers can waste their time putting something into
>>> the language that we've done without for 25 years, yes, that strikes
>>> me as extremely worthwhile.
>>
>> Do you think python should stop progressing? Because all progress
>> python wil make, will be done by putting something in the language
>> we've done without for 25 years.
>>
>> That we have done without doesn't contradict it can be useful to have.
>>
>
> Raise the item on the python-ideas mailing list for the umpteenth time
> then, and see how far you get.

I don't care enough. I do care about people using valid arguments.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#105032

On 16/03/2016 13:38, Antoon Pardon wrote:
> Op 16-03-16 om 12:07 schreef Mark Lawrence:
>>
>> Raise the item on the python-ideas mailing list for the umpteenth time
>> then, and see how far you get.
>
> I don't care enough. I do care about people using valid arguments.
>

Arguments have been made for and against.  When the PEPs were rejected 
are you saying that the arguments for acceptance were actually stronger 
than the arguments for rejection?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#105060

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> Look at decorators. They don't provide functionality we wouldn't have
> without them. So we don't actually need them. Do you argue that
> introducing them wasn't progress?

I do.


Marko

[toc] | [prev] | [next] | [standalone]

#105071

Op 16-03-16 om 20:27 schreef Marko Rauhamaa:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>
>> Look at decorators. They don't provide functionality we wouldn't have
>> without them. So we don't actually need them. Do you argue that
>> introducing them wasn't progress?
> I do.

Way to miss the point. Sure there will be people for which this particular
example doesn't work. The point is, that often enough progress in python
is not about introducing something new that is "actually needed" but about
making functionality that is already available more easily accessible.

I am sure you can find your own examples if you search for them.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#105077

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> Op 16-03-16 om 20:27 schreef Marko Rauhamaa:
>> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>>> Look at decorators. They don't provide functionality we wouldn't have
>>> without them. So we don't actually need them. Do you argue that
>>> introducing them wasn't progress?
>> I do.
>
> Way to miss the point.

Just answering your question.

> I am sure you can find your own examples if you search for them.

To your point, I have disliked Python's dunderitis. However, yesterday
Steven made me doubt my doubts by demonstrating a very promising
pipelining idea that makes use of __ror__. My imagination is running
wild with the possibilities.


Marko

[toc] | [prev] | [next] | [standalone]

#105078

Op 17-03-16 om 09:57 schreef Marko Rauhamaa:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>
>> Op 16-03-16 om 20:27 schreef Marko Rauhamaa:
>>> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>>>> Look at decorators. They don't provide functionality we wouldn't have
>>>> without them. So we don't actually need them. Do you argue that
>>>> introducing them wasn't progress?
>>> I do.
>> Way to miss the point.
> Just answering your question.

Just answering the question --- without regard for the context and the
purpose of the question --- sure is a way to miss the point.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#105064

On Thu, 17 Mar 2016 10:14 am, Chris Angelico wrote:

> On Thu, Mar 17, 2016 at 5:31 AM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> It can be yes. Look at decorators. They don't provide functionality
>> we wouldn't have without them.
> 
> Really? Okay, try implementing this without decorators:
 
[...]
> @monkeypatch
> class Foo:
[...]


I think Antoon is referring to decorator *syntax*, not the concept of
decorators in general. Decorator syntax is just syntactic sugar for:


class Foo:
    ...

Foo = monkeypatch(Foo)

which has been valid all the way back to Python 1.0.

Given first class functions and types, plus closures, I can't imagine how
you could fail to have decorators. Regardless of what monkeypatch actually
does internally, it takes a class as argument, and returns a new or
modified class. If you can create new classes on the fly, or modify them,
then you can implement decorator functionality, but without the convenience
of decorator syntax.

Indeed, Python started providing built-in decorators (such as classmethod
and staticmethod) as early as 2.2, but didn't gain the @ decorator syntax
until 2.4 for functions:

https://www.python.org/dev/peps/pep-0318/

and 2.6 for classes. The availability of a nice syntax to transform
functions and classes has, as Bruce Eckel predicted, transformed the Python
ecosystem, and decorators are now extensively used in libraries and
frameworks:

    The reason I think decorators will have such a big impact is
    because this little bit of syntax sugar changes the way you
    think about programming. Indeed, it brings the idea of 
    "applying code to other code" (i.e.: macros) into mainstream 
    thinking by formalizing it as a language construct.

http://www.artima.com/weblogs/viewpost.jsp?thread=240808



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#105066

On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote:

> Yes... in theory. But try rewriting my example to avoid decorator
> syntax. It won't work, because of this line:
> 
>     orig = globals()[cls.__name__]

That's a nasty, dirty piece of code, and I hope you are thoroughly ashamed
of having written it :-)

> It depends on the decorator being run before the name actually gets
> bound - which means the previous class is available to the decorator.
> You can't do that without decorator syntax, or messing around with
> multiple names.


I wouldn't want to rely on it working with decorator syntax either. Even if
it does now, I'm not sure that's a language guarantee.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#105067

Steven D'Aprano wrote:
> On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote:
> 
>>    orig = globals()[cls.__name__]
> 
> I wouldn't want to rely on it working with decorator syntax either. Even if
> it does now, I'm not sure that's a language guarantee.

The following idiom relies on similar behaviour:

     @property
     def x(self):
         return self._x

     @x.setter
     def x(self, value):
         self._x = value

That's taken from the official docs, so I don't think
this is likely to change any time soon.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#105068

On Thu, Mar 17, 2016 at 4:45 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Steven D'Aprano wrote:
>>
>> On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote:
>>
>>>    orig = globals()[cls.__name__]
>>
>>
>> I wouldn't want to rely on it working with decorator syntax either. Even
>> if
>> it does now, I'm not sure that's a language guarantee.
>
>
> The following idiom relies on similar behaviour:
>
>     @property
>     def x(self):
>         return self._x
>
>     @x.setter
>     def x(self, value):
>         self._x = value
>
> That's taken from the official docs, so I don't think
> this is likely to change any time soon.

Ooh, didn't think of that. So maybe it's a language guarantee that
hasn't been written down somewhere, and the "func = deco(func)"
version is a known-imperfect-equivalent, same as "for x in iter: yield
x" is an imperfect equivalent for "yield from iter".

It would be possible to support @x.setter by simply guaranteeing that
the decorator expression is evaluated prior to the function creation:

_tmp = x.setter # but without using an actual name
def x(self, value):
    self._x = value
x = _tmp(x)

But I doubt the language needs to go to this level of finickiness. In
fact, all it really needs is an acknowledgement that there are corner
cases:

http://bugs.python.org/issue26576

ChrisA

[toc] | [prev] | [next] | [standalone]

#105181

Chris Angelico wrote:
> So maybe it's a language guarantee that
> hasn't been written down somewhere,

The Language Reference says:

   [the decorator] is invoked with the function object as the only argument.
   The returned value is bound to the function name instead of the function
   object.

The "instead" there seems to imply that the name is *not*
bound to the original function object. But it could perhaps
be made clearer.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web