Hello, [New to the list. I spent some time exploring the archives, still I'm not really sure of what kind of subjects fit here -- or not. If ever this post, or a further one, is out of topic, just tell me. Also, I'm a self-trained amateur, and neither python nore english is my native language, thus I may use non-standard idioms. ;-)] -1- real-life case (can safely be skipped) I'm writing an application that should allow a user to chose between several wiki languages, including customized versions, on one side; and uses either a subset of xhtml, or simple plain text tables (simulation of DB import/export), as saving/exchange/standard format. To do this, I have a whole lot of configurable "Symbol" sub-types, each representing a common language feature. (I imagine there are tons of more professional approaches, but this is not my point -- I do it for pleasure.) A list of symbols (instances), parsed from a source text, build an abstract, language-independant, image of the text. The types have to take the (wiki-side) configuration into account; I also wish this config to be "switchable" at run-time. An example use of this feature is to "transcode" a wiki source text into another wiki format. The pattern of a symbol type is then: class BlockFormat(Symbol): def config(): <set type attributes> def __init__(self, source, ...): <read instance attributes from source doc> <read/write methods from/into known languages> I /really/ expected this to work. config() obviously was, for me, a type/class method. I intended to call it and its sisters from a module top-level function: def config(): wiki_config.build(config_file_name) for symbol_type in symbol_types: symbol_type.config() As a consequence, I happily discovered both classmethod() and @classmethod.(Actually, I hadn't programmed for a long time, had forgotten some idiomatic "details", and knew about nothing of python >= 2.0, except for the overall new_style_classes pattern.) -2- type/instance attribute pattern (Below is called 'property' a non-callable object attribute, as opposed to 'method'. I do not know if a better, standard, term is used in the python community.) type/class instance property prop self.prop method call f(args) self.f(args) method def def f(args)+X def f(self,args) (where X means either classmethod() or @classmethod) I wondered where the point is before writing down this table. Why (1) I intended my code to work as is (2) we need to add a line of code to define a class method. In order to distinguish an instance property from a type one, the former is simply prefixed with 'self' -- or any placeholder for a potential instance name --, later with the actual instance's name. This pattern fully applies to method call. But is broken for method definition, for any reason I'm unable to guess. I think this explains why I wrote the code above. Now, watching such a table, the additional instruction looks to my eyes like a workaround rather than a feature. Actually, the instance method definition syntax takes the place of the one that may be expected for class methods instead. Lets imagine this slight change: type/class instance property prop self.prop method call f(args) self.f(args) method def def f(args) def self.f(args) <== Doesn't this deliciously fit in the table? Not only the syntax for instance method definition matches the call syntax; but also the whole method pattern matches the one for properties. -3- proposal I am fully conscious that this syntax cannot be introduced: this would have as magic side-effect to transform all instance methods into class methods ;-) I wonder if the following may be considered: Allow prefixing of class attributes (esp. methods) with the classe's name -- even in the classe's own scope: class C(object): C.a = 1 def C.f(): <method body> This syntax presently launches NameError and SyntaxError, which is correct as C is not yet defined, and the second syntax is unknown. But... it would allow a nicer syntax to define class method, and more: this syntax is precisely the one that will later be used to call the method. An alternative may be to prefix a class method defintition with either 'type' or 'class', used as a pseudo keyword: class C(object): def type.f(): <method body> Denis
Below a more compact reformulation and a different point of view on the same topic. === Summary === -0- Inside a type definition are decribed both the type and its potential instances; a syntactic rule is thus needed to distinguish type and instance attributes. -1- A pattern is used to address that point: namely, the rule is to prefix instance attributes with an instance 'pseudonyme', for example "self.a" or "self.f(x)". Which is /very/ good: the pseudonyme simply takes the place of a not-yet-existing-object-name. Right? This pattern is consistent with overall python & OOP syntax, close to 'natural', used both for non-callable attributes and methods; except... -2- For method definition, the following pattern is used: "def f(self,x)"; where "def self.f(x)" would be expected instead, accordind to -1-. Problem #1: as a simple pattern is broken, the code's clarity/legibility is suffers. Is there any advantage to balance that? Note: as the regular pattern does not seem to conflict with any other syntactic feature, can we consider allowing it? -3- As a rather unfortunate side-effect, it happens that the pattern used to define instance methods is precisely the one that could be used for type methods. Problem #2: how do we define them, then? The builtin instancemethod() introduced in python 2.2 is needed only because of this irregularity (**)(***). See below under "proposal" for alternatives. (*) This does not apply when attributes are adressed from outside the type's scope, where ordinary object-name prefixing has to be used, as well as inside methods for type attributes. (**) This applies, of course, to @classmethod. (***) @staticmethod/staticmethod() instead really introduces a new kind of object. As a syntactic feature, its sense is to let python 'know' it. From PEP 318: "[Decorators] are storing additional information on a function object." What is the additional information for a type method? A syntax notation conflict with instance methods. A type method is an ordinary method that we simply could not write down before. PEP 318: Decorators for Functions and Methods http://www.python.org/doc/2.4.4/whatsnew/node6.html === alternative approach === In http://www.python.org/dev/peps/pep-0318/, decorators are also called 'transformators': they return a transformed version of the argument. Decorators can be built-in or user-defined. They allow special versions of a main type of objects -- presently functions or methods. This is in a way similar to sub-typing: method standard/default static further built-in sub-type user-defined sub-type In the case of the standard sub-type, the @standard decorator would be the (mathematical) identity function that returns its parameter unchanged. Which is pointless, needs not beeing implemented, so that the standard sub-type is the default one, i.e. identical to the super-type. Right? An ordinary type method is a method of the standard type. There needs no decorator for it. As types are object, they can hold methods (even functions can...). We may consider type methods as special because, due to the syntactic conflict described above, there was previously no way to express them. Additionally, as classes are mainly regarded as 'real' object generators, they are rather seen as static, so that class methods do not belong to everyday programming. Still, type methods are standard objects: their syntax should be standard. Denis PS: Do you know about a site, list, forum about programming language design? (Answer in private message, please.) Hello, [New to the list. I spent some time exploring the archives, still I'm not really sure of what kind of subjects fit here -- or not. If ever this post, or a further one, is out of topic, just tell me. Also, I'm a self-trained amateur, and neither python nore english is my native language, thus I may use non-standard idioms. ;-)] -1- real-life case (can safely be skipped) I'm writing an application that should allow a user to chose between several wiki languages, including customized versions, on one side; and uses either a subset of xhtml, or simple plain text tables (simulation of DB import/export), as saving/exchange/standard format. To do this, I have a whole lot of configurable "Symbol" sub-types, each representing a common language feature. (I imagine there are tons of more professional approaches, but this is not my point -- I do it for pleasure.) A list of symbols (instances), parsed from a source text, build an abstract, language-independant, image of the text. The types have to take the (wiki-side) configuration into account; I also wish this config to be "switchable" at run-time. An example use of this feature is to "transcode" a wiki source text into another wiki format. The pattern of a symbol type is then: class BlockFormat(Symbol): def config(): <set type attributes> def __init__(self, source, ...): <read instance attributes from source doc> <read/write methods from/into known languages> I /really/ expected this to work. config() obviously was, for me, a type/class method. I intended to call it and its sisters from a module top-level function: def config(): wiki_config.build(config_file_name) for symbol_type in symbol_types: symbol_type.config() As a consequence, I happily discovered both classmethod() and @classmethod.(Actually, I hadn't programmed for a long time, had forgotten some idiomatic "details", and knew about nothing of python >= 2.0, except for the overall new_style_classes pattern.) -2- type/instance attribute pattern (Below is called 'property' a non-callable object attribute, as opposed to 'method'. I do not know if a better, standard, term is used in the python community.) type/class instance property prop self.prop method call f(args) self.f(args) method def def f(args)+X def f(self,args) (where X means either classmethod() or @classmethod) I wondered where the point is before writing down this table. Why (1) I intended my code to work as is (2) we need to add a line of code to define a class method. In order to distinguish an instance property from a type one, the former is simply prefixed with 'self' -- or any placeholder for a potential instance name --, later with the actual instance's name. This pattern fully applies to method call. But is broken for method definition, for any reason I'm unable to guess. I think this explains why I wrote the code above. Now, watching such a table, the additional instruction looks to my eyes like a workaround rather than a feature. Actually, the instance method definition syntax takes the place of the one that may be expected for class methods instead. Lets imagine this slight change: type/class instance property prop self.prop method call f(args) self.f(args) method def def f(args) def self.f(args) <== Doesn't this deliciously fit in the table? Not only the syntax for instance method definition matches the call syntax; but also the whole method pattern matches the one for properties. -3- proposal(s) I am fully conscious that this syntax cannot be introduced: this would have as magic side-effect to transform all instance methods into class methods ;-) I wonder if the following may be considered: Allow prefixing of class attributes (esp. methods) with the classe's name -- even in the classe's own scope: class C(object): C.a = 1 def C.f(): <method body> This syntax presently launches NameError and SyntaxError, which is correct as C is not yet defined, and the second syntax is unknown. But... it would allow a nicer syntax to define class method, and more: this syntax is precisely the one that will later be used to call the method. An alternative may be to prefix a class method defintition with either 'type' or 'class', used as a pseudo keyword: class C(object): def type.f(): <method body> Denis spir a écrit :
Below a more compact reformulation and a different point of view on the same topic. === Summary === -0- Inside a type definition are decribed both the type and its potential instances; a syntactic rule is thus needed to distinguish type and instance attributes. -1- A pattern is used to address that point: namely, the rule is to prefix instance attributes with an instance 'pseudonyme', for example "self.a" or "self.f(x)". Which is /very/ good: the pseudonyme simply takes the place of a not-yet-existing-object-name. Right? This pattern is consistent with overall python & OOP syntax, close to 'natural', used both for non-callable attributes and methods; except... -2- For method definition, the following pattern is used: "def f(self,x)"; where "def self.f(x)" would be expected instead, accordind to -1-. Problem #1: as a simple pattern is broken, the code's clarity/legibility is suffers. Is there any advantage to balance that? Note: as the regular pattern does not seem to conflict with any other syntactic feature, can we consider allowing it? -3- As a rather unfortunate side-effect, it happens that the pattern used to define instance methods is precisely the one that could be used for type methods. Problem #2: how do we define them, then? The builtin instancemethod() introduced in python 2.2 is needed only because of this irregularity (**)(***). See below under "proposal" for alternatives. (*) This does not apply when attributes are adressed from outside the type's scope, where ordinary object-name prefixing has to be used, as well as inside methods for type attributes. (**) This applies, of course, to @classmethod. (***) @staticmethod/staticmethod() instead really introduces a new kind of object. As a syntactic feature, its sense is to let python 'know' it. From PEP 318: "[Decorators] are storing additional information on a function object." What is the additional information for a type method? A syntax notation conflict with instance methods. A type method is an ordinary method that we simply could not write down before. PEP 318: Decorators for Functions and Methods http://www.python.org/doc/2.4.4/whatsnew/node6.html === alternative approach === In http://www.python.org/dev/peps/pep-0318/, decorators are also called 'transformators': they return a transformed version of the argument. Decorators can be built-in or user-defined. They allow special versions of a main type of objects -- presently functions or methods. This is in a way similar to sub-typing: method standard/default static further built-in sub-type user-defined sub-type In the case of the standard sub-type, the @standard decorator would be the (mathematical) identity function that returns its parameter unchanged. Which is pointless, needs not beeing implemented, so that the standard sub-type is the default one, i.e. identical to the super-type. Right? An ordinary type method is a method of the standard type. There needs no decorator for it. As types are object, they can hold methods (even functions can...). We may consider type methods as special because, due to the syntactic conflict described above, there was previously no way to express them. Additionally, as classes are mainly regarded as 'real' object generators, they are rather seen as static, so that class methods do not belong to everyday programming. Still, type methods are standard objects: their syntax should be standard. Denis PS: Do you know about a site, list, forum about programming language design? (Answer in private message, please.) Hello, [New to the list. I spent some time exploring the archives, still I'm not really sure of what kind of subjects fit here -- or not. If ever this post, or a further one, is out of topic, just tell me. Also, I'm a self-trained amateur, and neither python nore english is my native language, thus I may use non-standard idioms. ;-)] -1- real-life case (can safely be skipped) I'm writing an application that should allow a user to chose between several wiki languages, including customized versions, on one side; and uses either a subset of xhtml, or simple plain text tables (simulation of DB import/export), as saving/exchange/standard format. To do this, I have a whole lot of configurable "Symbol" sub-types, each representing a common language feature. (I imagine there are tons of more professional approaches, but this is not my point -- I do it for pleasure.) A list of symbols (instances), parsed from a source text, build an abstract, language-independant, image of the text. The types have to take the (wiki-side) configuration into account; I also wish this config to be "switchable" at run-time. An example use of this feature is to "transcode" a wiki source text into another wiki format. The pattern of a symbol type is then: class BlockFormat(Symbol): def config(): <set type attributes> def __init__(self, source, ...): <read instance attributes from source doc> <read/write methods from/into known languages> I /really/ expected this to work. config() obviously was, for me, a type/class method. I intended to call it and its sisters from a module top-level function: def config(): wiki_config.build(config_file_name) for symbol_type in symbol_types: symbol_type.config() As a consequence, I happily discovered both classmethod() and @classmethod.(Actually, I hadn't programmed for a long time, had forgotten some idiomatic "details", and knew about nothing of python >= 2.0, except for the overall new_style_classes pattern.) -2- type/instance attribute pattern (Below is called 'property' a non-callable object attribute, as opposed to 'method'. I do not know if a better, standard, term is used in the python community.) type/class instance property prop self.prop method call f(args) self.f(args) method def def f(args)+X def f(self,args) (where X means either classmethod() or @classmethod) I wondered where the point is before writing down this table. Why (1) I intended my code to work as is (2) we need to add a line of code to define a class method. In order to distinguish an instance property from a type one, the former is simply prefixed with 'self' -- or any placeholder for a potential instance name --, later with the actual instance's name. This pattern fully applies to method call. But is broken for method definition, for any reason I'm unable to guess. I think this explains why I wrote the code above. Now, watching such a table, the additional instruction looks to my eyes like a workaround rather than a feature. Actually, the instance method definition syntax takes the place of the one that may be expected for class methods instead. Lets imagine this slight change: type/class instance property prop self.prop method call f(args) self.f(args) method def def f(args) def self.f(args) <== Doesn't this deliciously fit in the table? Not only the syntax for instance method definition matches the call syntax; but also the whole method pattern matches the one for properties. -3- proposal(s) I am fully conscious that this syntax cannot be introduced: this would have as magic side-effect to transform all instance methods into class methods ;-) I wonder if the following may be considered: Allow prefixing of class attributes (esp. methods) with the classe's name -- even in the classe's own scope: class C(object): C.a = 1 def C.f(): <method body> This syntax presently launches NameError and SyntaxError, which is correct as C is not yet defined, and the second syntax is unknown. But... it would allow a nicer syntax to define class method, and more: this syntax is precisely the one that will later be used to call the method. An alternative may be to prefix a class method defintition with either 'type' or 'class', used as a pseudo keyword: class C(object): def type.f(): <method body> Denis spir a écrit :
participants (1)
-
spir