Extended Function syntax
It's a bad idea to have to go through all the motions of defining the property on each object creation.
Sorry for typo(no def),should be: class Foo(object): __init__(class): #class section class.v = [] class.myprop: """A computed property on Foo objects.""" def __get__(class_instance): return ... def __set__(class_instance): ... def __delete__(class_instance): ... def class_method(class,a,b): ................ w.s.
It's a bad idea to have to go through all the motions of defining the property on each object creation.
Sorry for typo(no def),should be:
class Foo(object): __init__(class): #class section
I have no idea what you mean by this. This doesn't look like Python at all.
class.v = [] class.myprop: """A computed property on Foo objects.""" def __get__(class_instance): return ... def __set__(class_instance): ... def __delete__(class_instance): ... def class_method(class,a,b): ................
w.s.
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Jan 29, 2003 at 01:32:11AM -0500, Guido van Rossum wrote:
I have no idea what you mean by this. This doesn't look like Python at all.
I guess he meant that a method that has its first argument named "class" is automagically a class method. I strongly object. (Besides, he seems to want a class __init__, which isn't really needed - this is what the class declaration body is for) However this could work: class Foo(object): myprop = property: """A computed property on Foo objects.""" def __get__(self): return ... def __set__(self, value): ... def __delete__(self): ... This would call property() with the results of parsing the indented block. Not sure yet this is a good idea, but it could have many other (possibly good, possibly harmful) uses. []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/
However this could work:
class Foo(object): myprop = property: """A computed property on Foo objects.""" def __get__(self): return ... def __set__(self, value): ... def __delete__(self): ...
This would call property() with the results of parsing the indented block. Not sure yet this is a good idea, but it could have many other (possibly good, possibly harmful) uses.
Funny, I had a vision of something very similar this morning in the shower. :-) The problem is that this is a *very* radical change to the grammar, and I'm not sure I can rigorously define how the switch from "expression parsing mode" to "block parsing mode" should work. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum
However this could work:
class Foo(object): myprop = property: """A computed property on Foo objects.""" def __get__(self): return ... def __set__(self, value): ... def __delete__(self): ...
This would call property() with the results of parsing the indented block. Not sure yet this is a good idea, but it could have many other (possibly good, possibly harmful) uses.
Funny, I had a vision of something very similar this morning in the shower. :-)
The problem is that this is a *very* radical change to the grammar, and I'm not sure I can rigorously define how the switch from "expression parsing mode" to "block parsing mode" should work.
If we have: def f(x) [function_that_takes_f]: pass what about an block-variant: blockdef my_thing [function_that_takes_dict_of_the_block_definition] ...block... so we could write: blockdef myprop [property]: def __get__(self): return ... def __set__(self, value): ... def __delete__(self): ... (replace blockdef with your favorite new keyword...)
From: "Guido van Rossum"
However this could work:
class Foo(object): myprop = property: """A computed property on Foo objects.""" def __get__(self): return ... def __set__(self, value): ... def __delete__(self): ...
This would call property() with the results of parsing the indented block. Not sure yet this is a good idea, but it could have many other (possibly good, possibly harmful) uses.
Funny, I had a vision of something very similar this morning in the shower. :-)
The problem is that this is a *very* radical change to the grammar, and I'm not sure I can rigorously define how the switch from "expression parsing mode" to "block parsing mode" should work.
I would have thought that such a syntax is better left reserved to some hypothetical pep for anonymous blocks (extending lambdas, not that I personally favor/long for them) and not for something along the line of class in terms of synthetizing an object out of a by a block populated namespace. regards.
The problem is that this is a *very* radical change to the grammar, and I'm not sure I can rigorously define how the switch from "expression parsing mode" to "block parsing mode" should work.
I would have thought that such a syntax is better left reserved to some hypothetical pep for anonymous blocks (extending lambdas, not that I personally favor/long for them) and not for something along the line of class in terms of synthetizing an object out of a by a block populated namespace.
Totally agreed. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
Arne Koewing -
Guido van Rossum -
Lalo Martins -
Samuele Pedroni -
Wiktor Sadowski