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 3 of 3 — ← Prev page 1 2 [3]

#105069

On Thursday 17 March 2016 16:45, Gregory Ewing 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.


I don't think that property is a similar situation. I think what happens 
here is that the first call to property sets:

# @property def x...
x = property(x)

Then the second decorator does:

# @x.setter def x...
x = x.setter(x)

which replaces x with a brand new property object.

What happens if you use different names?

@property
def x(self):
    pass

@x.setter
def y(self, arg):
    pass


Now you have two different properties:

py> x
<property object at 0xb756eb1c>
py> y
<property object at 0xb756ef04>


Both x and y's getter points to the same function (our original def x):

py> y.fget
<function x at 0xb7564a04>
py> x.fget
<function x at 0xb7564a04>


But x's setter is None, while y has a valid setter:

py> x.fset is None
True
py> y.fset
<function y at 0xb7582ca4>


I don't think that either x or y will misbehave, but the behaviour will 
certainly be surprising if you're not expecting it.

I think the documentation in Python 2.7 is misleading. help(x.setter) says:

setter(...)
    Descriptor to change the setter on a property.

which is, I believe, a lie. It doesn't "change the setter" (modify the 
property object in place), but returns a new property object. Here's my 
pseudo-code for what I think property.setter does:

class property:
    def setter(self, func):
        return property(self.fget, func, self.fdel, self.__doc__)



As far as I can tell, none of this behaviour relies on the decorator being 
called before the name of the decorated thing is bound.




-- 
Steve

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

#105070

On Thu, Mar 17, 2016 at 5:29 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I don't think that property is a similar situation. I think what happens
> here is that the first call to property sets:
>
> # @property def x...
> x = property(x)
>
> Then the second decorator does:
>
> # @x.setter def x...
> x = x.setter(x)
>
> which replaces x with a brand new property object.

Okay. Let's try this.

>>> class Demo:
...     @property
...     def x(self):
...         print("Getting x")
...         return 42
...     @x.setter
...     def x(self, value):
...         print("Setting x to", value)
...
>>> d = Demo()
>>> d.x
Getting x
42
>>> d.x = 1
Setting x to 1


Decorators work. Now let's try NOT using decorators.

>>> class Demo:
...     def x(self):
...         print("Getting x")
...         return 42
...     x = property(x)
...     def x(self, value):
...         print("Setting x to", value)
...     x = x.setter(x)
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 8, in Demo
AttributeError: 'function' object has no attribute 'setter'


Since the 'def' line bound the undecorated function to the name 'x',
the decoration underneath *fails*. The only way this could work would
be with a temporary name for either the new function or the decorator:

>>> class Demo:
...     def x(self):
...         print("Getting x")
...         return 42
...     x = property(x)
...     decorator = x.setter
...     def x(self, value):
...         print("Setting x to", value)
...     x = decorator(x)
...     del decorator
...
>>> d = Demo()
>>> d.x
Getting x
42
>>> d.x = 1
Setting x to 1

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.

Note, by the way, that I am not in any way criticising the *behaviour*
here. I don't think anything needs to be changed as regards
functionality. And it's not even that big an issue as regards
documentation. It's mainly just an esoteric curiosity.

ChrisA

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

#105082

On Thu, 17 Mar 2016 05:48 pm, Chris Angelico wrote:

> On Thu, Mar 17, 2016 at 5:29 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> I don't think that property is a similar situation. I think what happens
>> here is that the first call to property sets:
>>
>> # @property def x...
>> x = property(x)
>>
>> Then the second decorator does:
>>
>> # @x.setter def x...
>> x = x.setter(x)
>>
>> which replaces x with a brand new property object.

A slight hitch, as you (Chris) has just identified:

By the time i go to call "x.setter", x has been replaced by "def x". Easily
fixed:

def x(self):
    ...

t = x = property(x)

def x(self, value):
    ...

x = t.setter(x)


> 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.


>>>> class Demo:
> ...     def x(self):
> ...         print("Getting x")
> ...         return 42
> ...     x = property(x)
> ...     def x(self, value):
> ...         print("Setting x to", value)

Oops, there's the problem. "def x" re-binds the property object, as so this
line:

> ...     x = x.setter(x)

fails.

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)


> Since the 'def' line bound the undecorated function to the name 'x',
> the decoration underneath *fails*. The only way this could work would
> be with a temporary name for either the new function or the decorator:

Right! We seem to be repeating each other each other each other each other
each other each other.


> 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 :-)


> Note, by the way, that I am not in any way criticising the *behaviour*
> here. I don't think anything needs to be changed as regards
> functionality. And it's not even that big an issue as regards
> documentation. It's mainly just an esoteric curiosity.

I agree with that. It's an interesting corner case in the application of
decorators.




-- 
Steven

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

#105086

On Thu, Mar 17, 2016 at 9:53 PM, Steven D'Aprano <steve@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__

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

#105079

Op 17-03-16 om 03:02 schreef Chris Angelico:
> On Thu, Mar 17, 2016 at 12:54 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>
>> 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.
> That's the thing, though. It's not a guarantee, yet it does work in
> every Python interpreter that I tried it in.

That depends on what you mean by work. This failes:

def monkeypatch(cls):
    orig = globals()[cls.__name__]
    print("Monkeypatch",id(cls),"into",id(orig))
    for attr in dir(cls):
        if not attr.startswith("_"):
            setattr(orig,attr,getattr(cls,attr))
    return orig

def main():
	class Foo:
		def method1(self):
			print("I am method 1")

	print("Foo is currently",id(Foo))
	some_object = Foo()

	@monkeypatch
	class Foo:
		def method2(self):
			print("I am method 2")

	print("Foo is now",id(Foo))

	some_object.method1()
	some_object.method2()

main()

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

#105080

On Thu, Mar 17, 2016 at 8:23 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Op 17-03-16 om 03:02 schreef Chris Angelico:
>> On Thu, Mar 17, 2016 at 12:54 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>>
>>> 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.
>> That's the thing, though. It's not a guarantee, yet it does work in
>> every Python interpreter that I tried it in.
>
> That depends on what you mean by work. This failes:
> [doing the same thing in a function]

Very true; I could have messed around with getframe, but most classes
are global, and it keeps things simple.

ChrisA

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

#105075

Op 17-03-16 om 01:31 schreef Chris Angelico:
> On Thu, Mar 17, 2016 at 11:19 AM, Steven D'Aprano <steve@pearwood.info> wrote:
>> 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.
>>
> Yes... in theory. But try rewriting my example to avoid decorator
> syntax. It won't work, because of this line:
>
>     orig = globals()[cls.__name__]
>
> 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.

So? That is an implementation detail. With a new features, functionality
can now be accessible in a way it was not before the feature. It still doesn't
add new functionality, which in this case was just transferring methods from
one class to an other.

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

#105076

Op 17-03-16 om 00:14 schreef Chris Angelico:
> def monkeypatch(cls):
>     orig = globals()[cls.__name__]
>     print("Monkeypatch",id(cls),"into",id(orig))
>     for attr in dir(cls):
>         if not attr.startswith("_"):
>             setattr(orig,attr,getattr(cls,attr))
>     return orig
>
> class Foo:
>     def method1(self):
>         print("I am method 1")
>
> print("Foo is currently",id(Foo))
> some_object = Foo()
>
> @monkeypatch
> class Foo:
>     def method2(self):
>         print("I am method 2")
>
> print("Foo is now",id(Foo))
>
> some_object.method1()
> some_object.method2()

This seems close enough as far as I am concerned.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

def monkeypatch(cls, orig):
    print("Monkeypatch",id(cls),"into",id(orig))
    for attr in dir(cls):
        if not attr.startswith("_"):
            setattr(orig,attr,getattr(cls,attr))
    return orig

class Foo:
    def method1(self):
        print("I am method 1")

print("Foo is currently",id(Foo))
some_object = Foo()

class Foo2:
    def method2(self):
        print("I am method 2")

monkeypatch(Foo2, Foo)

print("Foo is now",id(Foo))

some_object.method1()
some_object.method2()

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

#105020

What hath I wrought?

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

#105022

On Thu, 17 Mar 2016 12:15 am, l0r0m0a0i0l@gmail.com wrote:

> What hath I wrought?


Dr Ray Stantz: Fire and brimstone coming down from the skies! Rivers and
seas boiling!

Dr Egon Spengler: Forty years of darkness! Earthquakes, volcanoes...

Winston Zeddemore: The dead rising from the grave!

Dr Peter Venkman: Human sacrifice, dogs and cats living together... mass
hysteria! 



-- 
Steven

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

#105030

On 16/03/2016 13:27, Steven D'Aprano wrote:
> On Thu, 17 Mar 2016 12:15 am, l0r0m0a0i0l@gmail.com wrote:
>
>> What hath I wrought?
>
>
> Dr Ray Stantz: Fire and brimstone coming down from the skies! Rivers and
> seas boiling!
>
> Dr Egon Spengler: Forty years of darkness! Earthquakes, volcanoes...
>
> Winston Zeddemore: The dead rising from the grave!
>
> Dr Peter Venkman: Human sacrifice, dogs and cats living together... mass
> hysteria!
>

Much like the Marty Feldman weather forecast for the UK then :)

-- 
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]

#105029

On 16/03/2016 13:15, l0r0m0a0i0l@gmail.com wrote:
> What hath I wrought?
>

The Comfy Chair :)

-- 
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]

#105033

Gratified to see that with all this back-and-forth this thread still has a sense of humor.  Perhaps, we can all just agree to disagree? :)

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

#105036

l0r0m0a0i0l@gmail.com:

> Gratified to see that with all this back-and-forth this thread still
> has a sense of humor. Perhaps, we can all just agree to disagree? :)

I might agree with you if you tell me what we disagree about.


Marko

[toc] | [prev] | [standalone]

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

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

csiph-web