None as a keyword / class methods
[The following passed the Ping test, so I'm posting it here] If None becomes a keyword, I would like to ask whether it could be used to signal that a method is a class method, as opposed to an instance method: class Ping: def __init__(self, arg): ...as usual... def method(self, arg): ...no change... def classMethod(None, arg): ...equivalent of C++ 'static'... p = Ping("thinks this is cool") # as always p.method("who am I to argue?") # as always Ping.classMethod("hey, cool!") # no 'self' p.classMethod("hey, cool!") # also selfless I'd also like to ask (separately) that assignment to None be defined as a no-op, so that programmers can write: year, month, None, None, None, None, weekday, None, None = gmtime(time()) instead of having to create throw-away variables to fill in slots in tuples that they don't care about. I think both behaviors are readable; the first provides genuinely new functionality, while I often found the second handy when I was doing logic programming. Greg
gvwilson@nevex.com wrote:
(snip) As a point of jargon, please lets call this thing a "static method" (or an instance function, or something) rather than a "class method". The distinction between "class methods" and "static methods" has been discussed at length in the types sig (over a year ago). If this proposal goes forward and the name "class method" is used, I'll have to argue strenuously, and I really don't want to do that. :] So, if you can live with the term "static method", you could save us alot of trouble by just saying "static method". Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
gvwilson@nevex.com wrote:
Thanks a great name. Let's go with penguin. :) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Mark Hammond wrote:
me 2, äh 1.5... The assignment no-op seems to be ok. Having None as a place holder for static methods creates the problem that we loose compatibility with ordinary functions. What I would propose instead is: make the parameter name "self" mandatory for methods, and turn everything else into a static method. This does not change function semantics, but just the way the method binding works.
[Although I do believe "static method" is a better name than "penguin" :-]
pynguin -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home
Hi, Christian; thanks for your mail.
In my experience, significant omissions (i.e. something being important because it is *not* there) often give beginners trouble. For example, in C++, you can't tell whether: int foo::bar(int bah) { return 0; } belongs to instances, or to the class as a whole, without referring back to the header file [1]. To quote the immortal Jeremy Hylton: Pythonic design rules #2: Explicit is better than implicit. Also, people often ask why 'self' is required as a method argument in Python, when it is not in C++ or Java; this proposal would (retroactively) answer that question... Greg [1] I know this isn't a problem in Java or Python; I'm just using it as an illustration.
Yo, gvwilson@nevex.com wrote:
Sure. I am explicitly *not* using self if I want no self. :-)
You prefer to use the explicit keyword None? How would you then deal with def outside(None, blah): pass # stuff I believe one answer about the explicit "self" is that it should be simple and compatible with ordinary functions. Guido had just to add the semantics that in methods the first parameter automatically binds to the instance. The None gives me a bit of trouble, but not much. What I would like to spell is ordinary functions (as it is now) functions which are instance methods (with the immortal self) functions which are static methods ??? functions which are class methods !!! Static methods can work either with the "1st param==None" rule or with the "1st paramname!=self" rule or whatever. But how would you do class methods, which IMHO should have their class passed in as first parameter? Do you see a clean syntax for this? I thought of some weirdness like def meth(self, ... def static(self=None, ... # eek def classm(self=class, ... # ahem but this breaks the rule of default argument order. ciao - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home
"gvwilson" == <gvwilson@nevex.com> writes:
gvwilson> belongs to instances, or to the class as a whole, gvwilson> without referring back to the header file [1]. To quote gvwilson> the immortal Jeremy Hylton: Not to take anything away from Jeremy, who has contributed some wonderfully Pythonic quotes of his own, but this one is taken from Tim Peters' Zen of Python http://www.python.org/doc/Humor.html#zen timbot-is-the-only-one-who's-gonna-outlive-his-current-chip-set- around-here-ly y'rs, -Barry
"GVW" == gvwilson <gvwilson@nevex.com> writes:
GVW> To quote the immortal Jeremy Hylton: GVW> Pythonic design rules #2: GVW> Explicit is better than implicit. I wish I could take credit for that :-). Tim Peters posted a list of 20 Pythonic theses to comp.lang.python under the title "The Python Way." I'll collect them all here in hopes of future readers mistaking me for Tim again <wink>. Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! See http://x27.deja.com/getdoc.xp?AN=485548918&CONTEXT=953844380.1254555688&hitnum=9 for the full post. to-be-immortal-i'd-need-to-be-a-bot-ly y'rs Jeremy
On Thu, 23 Mar 2000 gvwilson@nevex.com wrote:
[...] Ack! I've been reduced to a class with just three methods. Oh well, i never really considered it a such a bad thing to be called "simple-minded". :)
def classMethod(None, arg): ...equivalent of C++ 'static'...
Yeah, i agree with Jim; you might as well call this a "static method" as opposed to a "class method". I like the way "None" is explicitly stated here, so there's no confusion about what the method does. (Without it, there's the question of whether the first argument will get thrown in, or what...) Hmm... i guess this also means one should ask what def function(None, arg): ... does outside a class definition. I suppose that should simply be illegal.
For what it's worth, i sometimes use "_" for this purpose (shades of Prolog!) but i can't make much of an argument for its readability... -- ?!ng I never dreamt that i would get to be The creature that i always meant to be But i thought, in spite of dreams, You'd be sitting somewhere here with me.
gvwilson@nevex.com writes:
p.classMethod("hey, cool!") # also selfless
This is the example that I haven't seen before (I'm not on the types-sig, so it may have been presented there), and I think this is what makes it interesting; a method in a module isn't quite sufficient here, since a subclass can override or extend the penguin this way. (Er, if we *do* go with penguin, does this mean it only works on Linux? ;) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
Hi! gvwilson@nevex.com:
You can already do this today with 1.5.2, if you use a 'del None' statement: Python 1.5.2 (#1, Jul 23 1999, 06:38:16) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
if None will become a keyword in Py3K this pyidiom should better be written as year, month, None, None, None, None, ... = ... if sys.version[0] == '1': del None or try: del None except SyntaxError: pass # Wow running Py3K here! I wonder, how much existinng code the None --> keyword change would brake. Regards, Peter
"PF" == Peter Funk <pf@artcom-gmbh.de> writes:
| try: | del None | except SyntaxError: | pass # Wow running Py3K here! I know how to break your Py3K code: stick None=None some where higher up :) PF> I wonder, how much existinng code the None --> keyword change PF> would brake. Me too. -Barry
Barry A. Warsaw writes:
I can't conceive of anyone using None as a function name or a variable name, except through a bug or thinking that 'None, useful, None = 1,2,3' works. Even though None isn't a fixed constant, it might as well be. How much C code have you see lately that starts with int function(void *NULL) ? Being able to do "None = 2" also smacks a bit of those legendary Fortran compilers that let you accidentally change 2 into 4. +1 on this change for Py3K, and I doubt it would cause breakage even if introduced into 1.x. -- A.M. Kuchling http://starship.python.net/crew/amk/ Principally I played pedants, idiots, old fathers, and drunkards. As you see, I had a narrow escape from becoming a professor. -- Robertson Davies, "Shakespeare over the Port"
AMK> +1 on this change for Py3K, and I doubt it would cause breakage AMK> even if introduced into 1.x. Or if it did, it's probably code that's marginally broken already... -- Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/
Hi!
Andrew M. Kuchling:
I agree. urban legend: Once upon a time someone found the following neat snippet of C source hidden in some header file of a very very huge software, after he has spend some nights trying to figure out, why some simple edits he made in order to make the code more readable broke the system: #ifdef TRUE /* eat this: you arrogant Quiche Eaters */ #undef TRUE #undef FALSE #define TRUE (0) #define FALSE (1) #endif Obviously the poor guy would have found this particular small piece of evil code much earlier, if he had simply 'grep'ed for comments... there were not so many in this system. ;-)
We'll see: those "Real Programmers" never die. Fortunately they prefer Perl over Python. <0.5 grin> Regards, Peter
Hi Barry!
Barry A. Warsaw:
I know how to break your Py3K code: stick None=None some where higher up :)
Hmm.... I must admit, that I don't understand your argument. In Python <= 1.5.2 'del None' works fine, iff it follows any assignment to None in the same scope regardless, whether there has been a None=None in the surrounding scope or in the same scope before this. Since something like 'del for' or 'del import' raises a SyntaxError exception in Py152, I expect 'del None' to raise the same exception in Py3K, after None has become a keyword. Right? Regards, Peter
Hi Peter!
"PF" == Peter Funk <pf@artcom-gmbh.de> writes:
PF> Since something like 'del for' or 'del import' raises a PF> SyntaxError exception in Py152, I expect 'del None' to raise PF> the same exception in Py3K, after None has become a keyword. PF> Right? I misread your example the first time through, but it still doesn't quite parse on my second read. -------------------- snip snip -------------------- pyvers = '2k' try: del import except SyntaxError: pyvers = '3k' -------------------- snip snip -------------------- % python /tmp/foo.py File "/tmp/foo.py", line 3 del import ^ SyntaxError: invalid syntax -------------------- snip snip -------------------- See, you can't catch that SyntaxError because it doesn't happen at run-time. Maybe you meant to wrap the try suite in an exec? Here's a code sample that ought to work with 1.5.2 and the mythical Py3K-with-a-None-keyword. -------------------- snip snip -------------------- pyvers = '2k' try: exec "del None" except SyntaxError: pyvers = '3k' except NameError: pass print pyvers -------------------- snip snip -------------------- Cheers, -Barry
On Thu, 23 Mar 2000 bwarsaw@cnri.reston.va.us wrote:
See, you can't catch that SyntaxError because it doesn't happen at run-time. Maybe you meant to wrap the try suite in an exec? Here's a
Huh. Guess i should have read barry's re-response before i posted mine: Desperately desiring to redeem myself, and contribute something to the discussion, i'll settle the class/static method naming quandry with the obvious alternative:
p.classMethod("hey, cool!") # also selfless
These should be called buddha methods - no self, samadhi, one with everything, etc. There, now i feel better. :-) Ken klm@digicool.com A Zen monk walks up to a hotdog vendor and says "make me one with everything." Ha. But that's not all. He gets the hot dog and pays with a ten. After several moments waiting, he says to the vendor, "i was expecting change", and the vendor say, "you of all people should know, change comes from inside." That's all.
On Thu, 23 Mar 2000 pf@artcom-gmbh.de wrote:
Huh. Does anyone really think we're going to catch SyntaxError at runtime, ever? Seems like the code fragment above wouldn't work in the first place. But i suppose, with most of a millennium to emerge, py3k could have more fundamental changes than i could even imagine...-) Ken klm@digicool.com
Hi!
Ken Manheimer:
Ouuppps... Unfortunately I had no chance to test this with Py3K before making a fool of myself by posting this silly example. Now I understand what Barry meant. So if None really becomes a keyword in Py3K we can be sure to catch all those imaginary 'del None' statements very quickly. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
gvwilson@nevex.com wrote:
+1 Idea is good, but I'm not really happy with any of the the proposed terminology...Python doesn't really have static anything. I would vote at the same time to make self a keyword and signal if the first argument is not one of None or self. Even now, one of my most common Python mistakes is in forgetting self. I expect it happens to anyone who shifts between other languages and Python. Why does None have an upper case "N"? Maybe the keyword version should be lower-case... -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "I and my companions suffer from a disease of the heart that can only be cured with gold", Hernan Cortes
"gvwilson" == <gvwilson@nevex.com> writes:
gvwilson> If None becomes a keyword, I would like to ask whether gvwilson> it could be used to signal that a method is a class gvwilson> method, as opposed to an instance method: It still seems mildly weird that None would be a special kind of keyword, one that has a value and is used in ways that no other keyword is used. Greg gives an example, and here's a few more: def baddaboom(x, y, z=None): ... if z is None: ... try substituting `else' for `None' in these examples. ;) Putting that issue aside, Greg's suggestion for static method definitions is interesting. class Ping: # would this be a SyntaxError? def __init__(None, arg): ... def staticMethod(None, arg): ... p = Ping() Ping.staticMethod(p, 7) # TypeError Ping.staticMethod(7) # This is fine p.staticMethod(7) # So's this Ping.staticMethod(p) # and this !! -Barry
"GVW" == gvwilson <gvwilson@nevex.com> writes:
GVW> I'd also like to ask (separately) that assignment to None be GVW> defined as a no-op, so that programmers can write: GVW> year, month, None, None, None, None, weekday, None, None = GVW> gmtime(time()) GVW> instead of having to create throw-away variables to fill in GVW> slots in tuples that they don't care about. I think both GVW> behaviors are readable; the first provides genuinely new GVW> functionality, while I often found the second handy when I was GVW> doing logic programming. -1 on this proposal Pythonic design rule #8: Special cases aren't special enough to break the rules. I think it's confusing to have assignment mean pop the top of the stack for the special case that the name is None. If Py3K makes None a keyword, then it would also be the only keyword that can be used in an assignment. Finally, we'd need to explain to the rare newbie who used None as variable name why they assigned 12 to None but that it's value was its name when it was later referenced. (Think 'print None'.) When I need to ignore some of the return values, I use the name nil. year, month, nil, nil, nil, nil, weekday, nil, nil = gmtime(time()) I think that's just as clear, only a whisker less efficient, and requires no special cases. Heck, it's even less typing <0.5 wink>. Jeremy
On Thu, 23 Mar 2000 gvwilson@nevex.com wrote:
If None becomes a keyword, I would like to ask whether it could be used to signal that a method is a class method, as opposed to an instance method:
I'd like to know what you mean by "class" method. (I do know C++ and Java, so I have some idea...). Specifically, my question is: how does a class method access class variables? They can't be totally unqualified (because that's very unpythonic). If they are qualified by the class's name, I see it as a very mild improvement on the current situation. You could suggest, for example, to qualify class variables by "class" (so you'd do things like: class.x = 1), but I'm not sure I like it. On the whole, I think it is a much bigger issue on how be denote class methods. Also, one slight problem with your method of denoting class methods: currently, it is possible to add instance method at run time to a class by something like class C: pass def foo(self): pass C.foo = foo In your suggestion, how do you view the possiblity of adding class methods to a class? (Note that "foo", above, is also perfectly usable as a plain function). I want to note that Edward suggested denotation by a seperate namespace: C.foo = foo # foo is an instance method C.__methods__.foo = foo # foo is a class method The biggest problem with that suggestion is that it doesn't address the common case of defining it textually inside the class definition.
Currently, I use "_" for that purpose, after I heard the idea from Fredrik Lundh. -- Moshe Zadka <mzadka@geocities.com>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com
I don't like overloading the word 'class' this way, as it makes it difficult to distinguish a parent's 'foo' member and a child's 'foo' member: class Parent: foo = 3 ...other stuff... class Child(Parent): foo = 9 def test(): print class.foo # obviously 9, but how to get 3? I think that using the class's name instead of 'self' will be easy to explain, will look like it belongs in the language, will be unlikely to lead to errors, and will handle multiple inheritance with ease: class Child(Parent): foo = 9 def test(): print Child.foo # 9 print Parent.foo # 3
Hm, I hadn't thought of this... :-(
I do the same thing when I need to; I just thought that making assignment to "None" special would formalize this in a readable way.
...sorry to jump in on the middle of this one, but. A while back I put a lot of thought into how to support class methods and class attributes. I feel that I solved the problem in a fairly complete way though the solution does have some warts. Here's an example:
Is anyone still with me? The crux of the problem is that in the current python class/instance implementation, classes dont have attributes of their own. All of those things that look like class attributes are really there as defaults for the instances. To support true class attributes a new name space must be invented. Since I wanted class objects to look like any other object, I chose to move the "instance defaults" name space under the underscore attribute. This allows the class's unqualified namespace to refer to its own attributes. Clear as mud, right? In case you are wondering, yes, the code above is a working example. I released it a while back as the 'objectmodule' and just updated it to work with Python-1.5.2. The update has yet to be released. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...Will hack for sushi...
This looks like it would break a lot of code. How do you refer to a superclass method? It seems that ClassName.methodName would refer to the class method, not to the unbound instance method. Also, moving the default instance attributes to a different namespace seems to be a semantic change that could change lots of things. I am still in favor of saying "Python has no class methods -- use module-global functions for that". Between the module, the class and the instance, there are enough namespaces -- we don't need another one. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido@python.org> wrote,
This looks like it would break a lot of code.
Only if it were to replace the current implementation. Perhaps I inadvertly made that suggestion. It was not my intention. Another way to look at my post is to say that it was intended to point out why we cant have class methods in the current implementation... it's a name space issue.
Right. To get at the unbound instance methods you must go through the 'unbound accessor' which is accessed via the underscore. If you wanted to chain to a superclass method it would look like this: class child(parent): def do_it(self, x): z = parent._.do_it(self, x) return z
I agree... and that's why I wouldnt suggest doing it to the current class/instance implementation. However, for those who insist on having class attributes and methods I think it would be cool to settle on a standard "syntax".
I am still in favor of saying "Python has no class methods -- use module-global functions for that".
Or use a class/instance implementation provided via an extension module rather than the built-in one. The class named 'base' shown in my example is a class designed for that purpose.
Between the module, the class and the instance, there are enough namespaces -- we don't need another one.
The topic comes up often enough to make me think some might disagree. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...So much code, so little time...
gvwilson@nevex.com wrote:
(snip) As a point of jargon, please lets call this thing a "static method" (or an instance function, or something) rather than a "class method". The distinction between "class methods" and "static methods" has been discussed at length in the types sig (over a year ago). If this proposal goes forward and the name "class method" is used, I'll have to argue strenuously, and I really don't want to do that. :] So, if you can live with the term "static method", you could save us alot of trouble by just saying "static method". Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
gvwilson@nevex.com wrote:
Thanks a great name. Let's go with penguin. :) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Mark Hammond wrote:
me 2, äh 1.5... The assignment no-op seems to be ok. Having None as a place holder for static methods creates the problem that we loose compatibility with ordinary functions. What I would propose instead is: make the parameter name "self" mandatory for methods, and turn everything else into a static method. This does not change function semantics, but just the way the method binding works.
[Although I do believe "static method" is a better name than "penguin" :-]
pynguin -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home
Hi, Christian; thanks for your mail.
In my experience, significant omissions (i.e. something being important because it is *not* there) often give beginners trouble. For example, in C++, you can't tell whether: int foo::bar(int bah) { return 0; } belongs to instances, or to the class as a whole, without referring back to the header file [1]. To quote the immortal Jeremy Hylton: Pythonic design rules #2: Explicit is better than implicit. Also, people often ask why 'self' is required as a method argument in Python, when it is not in C++ or Java; this proposal would (retroactively) answer that question... Greg [1] I know this isn't a problem in Java or Python; I'm just using it as an illustration.
Yo, gvwilson@nevex.com wrote:
Sure. I am explicitly *not* using self if I want no self. :-)
You prefer to use the explicit keyword None? How would you then deal with def outside(None, blah): pass # stuff I believe one answer about the explicit "self" is that it should be simple and compatible with ordinary functions. Guido had just to add the semantics that in methods the first parameter automatically binds to the instance. The None gives me a bit of trouble, but not much. What I would like to spell is ordinary functions (as it is now) functions which are instance methods (with the immortal self) functions which are static methods ??? functions which are class methods !!! Static methods can work either with the "1st param==None" rule or with the "1st paramname!=self" rule or whatever. But how would you do class methods, which IMHO should have their class passed in as first parameter? Do you see a clean syntax for this? I thought of some weirdness like def meth(self, ... def static(self=None, ... # eek def classm(self=class, ... # ahem but this breaks the rule of default argument order. ciao - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home
"gvwilson" == <gvwilson@nevex.com> writes:
gvwilson> belongs to instances, or to the class as a whole, gvwilson> without referring back to the header file [1]. To quote gvwilson> the immortal Jeremy Hylton: Not to take anything away from Jeremy, who has contributed some wonderfully Pythonic quotes of his own, but this one is taken from Tim Peters' Zen of Python http://www.python.org/doc/Humor.html#zen timbot-is-the-only-one-who's-gonna-outlive-his-current-chip-set- around-here-ly y'rs, -Barry
"GVW" == gvwilson <gvwilson@nevex.com> writes:
GVW> To quote the immortal Jeremy Hylton: GVW> Pythonic design rules #2: GVW> Explicit is better than implicit. I wish I could take credit for that :-). Tim Peters posted a list of 20 Pythonic theses to comp.lang.python under the title "The Python Way." I'll collect them all here in hopes of future readers mistaking me for Tim again <wink>. Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! See http://x27.deja.com/getdoc.xp?AN=485548918&CONTEXT=953844380.1254555688&hitnum=9 for the full post. to-be-immortal-i'd-need-to-be-a-bot-ly y'rs Jeremy
On Thu, 23 Mar 2000 gvwilson@nevex.com wrote:
[...] Ack! I've been reduced to a class with just three methods. Oh well, i never really considered it a such a bad thing to be called "simple-minded". :)
def classMethod(None, arg): ...equivalent of C++ 'static'...
Yeah, i agree with Jim; you might as well call this a "static method" as opposed to a "class method". I like the way "None" is explicitly stated here, so there's no confusion about what the method does. (Without it, there's the question of whether the first argument will get thrown in, or what...) Hmm... i guess this also means one should ask what def function(None, arg): ... does outside a class definition. I suppose that should simply be illegal.
For what it's worth, i sometimes use "_" for this purpose (shades of Prolog!) but i can't make much of an argument for its readability... -- ?!ng I never dreamt that i would get to be The creature that i always meant to be But i thought, in spite of dreams, You'd be sitting somewhere here with me.
gvwilson@nevex.com writes:
p.classMethod("hey, cool!") # also selfless
This is the example that I haven't seen before (I'm not on the types-sig, so it may have been presented there), and I think this is what makes it interesting; a method in a module isn't quite sufficient here, since a subclass can override or extend the penguin this way. (Er, if we *do* go with penguin, does this mean it only works on Linux? ;) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
Hi! gvwilson@nevex.com:
You can already do this today with 1.5.2, if you use a 'del None' statement: Python 1.5.2 (#1, Jul 23 1999, 06:38:16) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
if None will become a keyword in Py3K this pyidiom should better be written as year, month, None, None, None, None, ... = ... if sys.version[0] == '1': del None or try: del None except SyntaxError: pass # Wow running Py3K here! I wonder, how much existinng code the None --> keyword change would brake. Regards, Peter
"PF" == Peter Funk <pf@artcom-gmbh.de> writes:
| try: | del None | except SyntaxError: | pass # Wow running Py3K here! I know how to break your Py3K code: stick None=None some where higher up :) PF> I wonder, how much existinng code the None --> keyword change PF> would brake. Me too. -Barry
Barry A. Warsaw writes:
I can't conceive of anyone using None as a function name or a variable name, except through a bug or thinking that 'None, useful, None = 1,2,3' works. Even though None isn't a fixed constant, it might as well be. How much C code have you see lately that starts with int function(void *NULL) ? Being able to do "None = 2" also smacks a bit of those legendary Fortran compilers that let you accidentally change 2 into 4. +1 on this change for Py3K, and I doubt it would cause breakage even if introduced into 1.x. -- A.M. Kuchling http://starship.python.net/crew/amk/ Principally I played pedants, idiots, old fathers, and drunkards. As you see, I had a narrow escape from becoming a professor. -- Robertson Davies, "Shakespeare over the Port"
AMK> +1 on this change for Py3K, and I doubt it would cause breakage AMK> even if introduced into 1.x. Or if it did, it's probably code that's marginally broken already... -- Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/
Hi!
Andrew M. Kuchling:
I agree. urban legend: Once upon a time someone found the following neat snippet of C source hidden in some header file of a very very huge software, after he has spend some nights trying to figure out, why some simple edits he made in order to make the code more readable broke the system: #ifdef TRUE /* eat this: you arrogant Quiche Eaters */ #undef TRUE #undef FALSE #define TRUE (0) #define FALSE (1) #endif Obviously the poor guy would have found this particular small piece of evil code much earlier, if he had simply 'grep'ed for comments... there were not so many in this system. ;-)
We'll see: those "Real Programmers" never die. Fortunately they prefer Perl over Python. <0.5 grin> Regards, Peter
Hi Barry!
Barry A. Warsaw:
I know how to break your Py3K code: stick None=None some where higher up :)
Hmm.... I must admit, that I don't understand your argument. In Python <= 1.5.2 'del None' works fine, iff it follows any assignment to None in the same scope regardless, whether there has been a None=None in the surrounding scope or in the same scope before this. Since something like 'del for' or 'del import' raises a SyntaxError exception in Py152, I expect 'del None' to raise the same exception in Py3K, after None has become a keyword. Right? Regards, Peter
Hi Peter!
"PF" == Peter Funk <pf@artcom-gmbh.de> writes:
PF> Since something like 'del for' or 'del import' raises a PF> SyntaxError exception in Py152, I expect 'del None' to raise PF> the same exception in Py3K, after None has become a keyword. PF> Right? I misread your example the first time through, but it still doesn't quite parse on my second read. -------------------- snip snip -------------------- pyvers = '2k' try: del import except SyntaxError: pyvers = '3k' -------------------- snip snip -------------------- % python /tmp/foo.py File "/tmp/foo.py", line 3 del import ^ SyntaxError: invalid syntax -------------------- snip snip -------------------- See, you can't catch that SyntaxError because it doesn't happen at run-time. Maybe you meant to wrap the try suite in an exec? Here's a code sample that ought to work with 1.5.2 and the mythical Py3K-with-a-None-keyword. -------------------- snip snip -------------------- pyvers = '2k' try: exec "del None" except SyntaxError: pyvers = '3k' except NameError: pass print pyvers -------------------- snip snip -------------------- Cheers, -Barry
On Thu, 23 Mar 2000 bwarsaw@cnri.reston.va.us wrote:
See, you can't catch that SyntaxError because it doesn't happen at run-time. Maybe you meant to wrap the try suite in an exec? Here's a
Huh. Guess i should have read barry's re-response before i posted mine: Desperately desiring to redeem myself, and contribute something to the discussion, i'll settle the class/static method naming quandry with the obvious alternative:
p.classMethod("hey, cool!") # also selfless
These should be called buddha methods - no self, samadhi, one with everything, etc. There, now i feel better. :-) Ken klm@digicool.com A Zen monk walks up to a hotdog vendor and says "make me one with everything." Ha. But that's not all. He gets the hot dog and pays with a ten. After several moments waiting, he says to the vendor, "i was expecting change", and the vendor say, "you of all people should know, change comes from inside." That's all.
On Thu, 23 Mar 2000 pf@artcom-gmbh.de wrote:
Huh. Does anyone really think we're going to catch SyntaxError at runtime, ever? Seems like the code fragment above wouldn't work in the first place. But i suppose, with most of a millennium to emerge, py3k could have more fundamental changes than i could even imagine...-) Ken klm@digicool.com
Hi!
Ken Manheimer:
Ouuppps... Unfortunately I had no chance to test this with Py3K before making a fool of myself by posting this silly example. Now I understand what Barry meant. So if None really becomes a keyword in Py3K we can be sure to catch all those imaginary 'del None' statements very quickly. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
gvwilson@nevex.com wrote:
+1 Idea is good, but I'm not really happy with any of the the proposed terminology...Python doesn't really have static anything. I would vote at the same time to make self a keyword and signal if the first argument is not one of None or self. Even now, one of my most common Python mistakes is in forgetting self. I expect it happens to anyone who shifts between other languages and Python. Why does None have an upper case "N"? Maybe the keyword version should be lower-case... -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "I and my companions suffer from a disease of the heart that can only be cured with gold", Hernan Cortes
"gvwilson" == <gvwilson@nevex.com> writes:
gvwilson> If None becomes a keyword, I would like to ask whether gvwilson> it could be used to signal that a method is a class gvwilson> method, as opposed to an instance method: It still seems mildly weird that None would be a special kind of keyword, one that has a value and is used in ways that no other keyword is used. Greg gives an example, and here's a few more: def baddaboom(x, y, z=None): ... if z is None: ... try substituting `else' for `None' in these examples. ;) Putting that issue aside, Greg's suggestion for static method definitions is interesting. class Ping: # would this be a SyntaxError? def __init__(None, arg): ... def staticMethod(None, arg): ... p = Ping() Ping.staticMethod(p, 7) # TypeError Ping.staticMethod(7) # This is fine p.staticMethod(7) # So's this Ping.staticMethod(p) # and this !! -Barry
"GVW" == gvwilson <gvwilson@nevex.com> writes:
GVW> I'd also like to ask (separately) that assignment to None be GVW> defined as a no-op, so that programmers can write: GVW> year, month, None, None, None, None, weekday, None, None = GVW> gmtime(time()) GVW> instead of having to create throw-away variables to fill in GVW> slots in tuples that they don't care about. I think both GVW> behaviors are readable; the first provides genuinely new GVW> functionality, while I often found the second handy when I was GVW> doing logic programming. -1 on this proposal Pythonic design rule #8: Special cases aren't special enough to break the rules. I think it's confusing to have assignment mean pop the top of the stack for the special case that the name is None. If Py3K makes None a keyword, then it would also be the only keyword that can be used in an assignment. Finally, we'd need to explain to the rare newbie who used None as variable name why they assigned 12 to None but that it's value was its name when it was later referenced. (Think 'print None'.) When I need to ignore some of the return values, I use the name nil. year, month, nil, nil, nil, nil, weekday, nil, nil = gmtime(time()) I think that's just as clear, only a whisker less efficient, and requires no special cases. Heck, it's even less typing <0.5 wink>. Jeremy
On Thu, 23 Mar 2000 gvwilson@nevex.com wrote:
If None becomes a keyword, I would like to ask whether it could be used to signal that a method is a class method, as opposed to an instance method:
I'd like to know what you mean by "class" method. (I do know C++ and Java, so I have some idea...). Specifically, my question is: how does a class method access class variables? They can't be totally unqualified (because that's very unpythonic). If they are qualified by the class's name, I see it as a very mild improvement on the current situation. You could suggest, for example, to qualify class variables by "class" (so you'd do things like: class.x = 1), but I'm not sure I like it. On the whole, I think it is a much bigger issue on how be denote class methods. Also, one slight problem with your method of denoting class methods: currently, it is possible to add instance method at run time to a class by something like class C: pass def foo(self): pass C.foo = foo In your suggestion, how do you view the possiblity of adding class methods to a class? (Note that "foo", above, is also perfectly usable as a plain function). I want to note that Edward suggested denotation by a seperate namespace: C.foo = foo # foo is an instance method C.__methods__.foo = foo # foo is a class method The biggest problem with that suggestion is that it doesn't address the common case of defining it textually inside the class definition.
Currently, I use "_" for that purpose, after I heard the idea from Fredrik Lundh. -- Moshe Zadka <mzadka@geocities.com>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com
I don't like overloading the word 'class' this way, as it makes it difficult to distinguish a parent's 'foo' member and a child's 'foo' member: class Parent: foo = 3 ...other stuff... class Child(Parent): foo = 9 def test(): print class.foo # obviously 9, but how to get 3? I think that using the class's name instead of 'self' will be easy to explain, will look like it belongs in the language, will be unlikely to lead to errors, and will handle multiple inheritance with ease: class Child(Parent): foo = 9 def test(): print Child.foo # 9 print Parent.foo # 3
Hm, I hadn't thought of this... :-(
I do the same thing when I need to; I just thought that making assignment to "None" special would formalize this in a readable way.
...sorry to jump in on the middle of this one, but. A while back I put a lot of thought into how to support class methods and class attributes. I feel that I solved the problem in a fairly complete way though the solution does have some warts. Here's an example:
Is anyone still with me? The crux of the problem is that in the current python class/instance implementation, classes dont have attributes of their own. All of those things that look like class attributes are really there as defaults for the instances. To support true class attributes a new name space must be invented. Since I wanted class objects to look like any other object, I chose to move the "instance defaults" name space under the underscore attribute. This allows the class's unqualified namespace to refer to its own attributes. Clear as mud, right? In case you are wondering, yes, the code above is a working example. I released it a while back as the 'objectmodule' and just updated it to work with Python-1.5.2. The update has yet to be released. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...Will hack for sushi...
This looks like it would break a lot of code. How do you refer to a superclass method? It seems that ClassName.methodName would refer to the class method, not to the unbound instance method. Also, moving the default instance attributes to a different namespace seems to be a semantic change that could change lots of things. I am still in favor of saying "Python has no class methods -- use module-global functions for that". Between the module, the class and the instance, there are enough namespaces -- we don't need another one. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido@python.org> wrote,
This looks like it would break a lot of code.
Only if it were to replace the current implementation. Perhaps I inadvertly made that suggestion. It was not my intention. Another way to look at my post is to say that it was intended to point out why we cant have class methods in the current implementation... it's a name space issue.
Right. To get at the unbound instance methods you must go through the 'unbound accessor' which is accessed via the underscore. If you wanted to chain to a superclass method it would look like this: class child(parent): def do_it(self, x): z = parent._.do_it(self, x) return z
I agree... and that's why I wouldnt suggest doing it to the current class/instance implementation. However, for those who insist on having class attributes and methods I think it would be cool to settle on a standard "syntax".
I am still in favor of saying "Python has no class methods -- use module-global functions for that".
Or use a class/instance implementation provided via an extension module rather than the built-in one. The class named 'base' shown in my example is a class designed for that purpose.
Between the module, the class and the instance, there are enough namespaces -- we don't need another one.
The topic comes up often enough to make me think some might disagree. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...So much code, so little time...
participants (18)
-
Andrew M. Kuchling -
Barry A. Warsaw -
bwarsaw＠cnri.reston.va.us
-
Christian Tismer -
Donald Beaudry -
Fred L. Drake, Jr. -
Guido van Rossum -
gvwilson＠nevex.com -
Jeremy Hylton -
Jeremy Hylton -
Jim Fulton -
Ka-Ping Yee -
Ken Manheimer -
Mark Hammond -
Moshe Zadka -
Paul Prescod -
pf＠artcom-gmbh.de -
Skip Montanaro