Re: [Python-Dev] default of returning None hurts performance?
Raymond Hettinger wrote: >> I was just wondering if a bytecode for a superinstruction of the common >> sequence: >> >> 6 POP_TOP >> 7 LOAD_CONST 0 (None) >> 10 RETURN_VALUE >> >> might be worth it. > > [Collin Winter] >> I doubt it. You'd save a bit of stack manipulation, but since this >> will only appear at the end of a function, I'd be skeptical that this >> would make any macrobenchmarks (statistically) significantly faster. > > I concur with Collin. And since it appears only at the end of a function, > the optimization doesn't help inner-loops in a function (where most of > the time usually spent). > I fail to understand this crude logic. How often is the inner-loop really going to solely call C code? Any call to Python in an inner-loop is going to suffer this penalty on the order of the number of loop iterations)? -Scott -- Scott Dial [email protected] [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?
Fred Drake wrote: > Every time I've been bitten by the wrong co_filename values (usually > from tracebacks), changing the way marshal creates code objects to use a > values passed in has been the thing that made the most sense to me. > > The feature request that's involved here, getting correct co_filename > values, can be implemented in different ways, sure. This particular > change produces the least impact in the because it *doesn't* change the > mutability of code objects. > > I for one appreciate that, mostly because I'm simply wary of making code > objects mutable in this way having unexpected side effects in some library. "linecache" was the one that immediately popped into mind for me (not saying it is affected, just saying it would be the first place I would like for possible side effects). I think this is one of those situations where something has behaved a certain way for so long that it would be really hard to be confident that we had considered all the possible ramifications of changing it. Modifying marshal to allow Python code to override the stored value instead of making it a free-for-all preserves the post-compile immutability characteristic while still letting Brett make importlib mimic the behaviour of import.c. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runpy.py
Brett Cannon wrote: > On Mon, Aug 31, 2009 at 06:36, Nick Coghlan wrote: >> That said, while actually ditching the C code might cause an argument, >> expanding runpy with Python equivalents of the C level functionality >> (i.e. run script by name, run directory/zipfile by name, '-c' switch, >> and other odds and ends that I'm probably forgetting right now, with all >> associated modifications to sys.argv and the __main__ module attributes) >> should be far less controversial. > > It also has the perk of letting alternative VMs not have to implement > all of that stuff themselves, potentially helping to unify even the > command-line interfaces for all the VMs. I created a tracker item for the idea so I don't forget about it: http://bugs.python.org/issue6816 Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
Raymond Hettinger wrote: >> I was just wondering if a bytecode for a superinstruction of the common >> sequence: >> >> 6 POP_TOP >> 7 LOAD_CONST 0 (None) >> 10 RETURN_VALUE >> >> might be worth it. > > [Collin Winter] >> I doubt it. You'd save a bit of stack manipulation, but since this >> will only appear at the end of a function, I'd be skeptical that this >> would make any macrobenchmarks (statistically) significantly faster. > > I concur with Collin. And since it appears only at the end of a function, > the optimization doesn't help inner-loops in a function (where most of > the time usually spent). > I fail to understand this crude logic. How often is the inner-loop really going to solely call C code? Any call to Python in an inner-loop is going to suffer this penalty on the order of the number of loop iterations)? -Scott -- Scott Dial [email protected] [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] implicit return values
Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit : > "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly. Well, feel free to prefer an unreadable language if you want :) Having implicit return values is certainly not something which follows Python's design principles. Even C abandoned the idea. In any case, this discussion is off-topic for this thread. If you want to discuss the topic further, you can post to python-list or python-ideas (it will most certainly be shot down anyway). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
On Tue, 1 Sep 2009 05:51:49 pm Scott Dial wrote:
> Raymond Hettinger wrote:
> >> I was just wondering if a bytecode for a superinstruction of the
> >> common sequence:
> >>
> >> 6 POP_TOP
> >> 7 LOAD_CONST 0 (None)
> >> 10 RETURN_VALUE
> >>
> >> might be worth it.
> >
> > [Collin Winter]
> >
> >> I doubt it. You'd save a bit of stack manipulation, but since this
> >> will only appear at the end of a function, I'd be skeptical that
> >> this would make any macrobenchmarks (statistically) significantly
> >> faster.
> >
> > I concur with Collin. And since it appears only at the end of a
> > function, the optimization doesn't help inner-loops in a function
> > (where most of the time usually spent).
>
> I fail to understand this crude logic. How often is the inner-loop
> really going to solely call C code? Any call to Python in an
> inner-loop is going to suffer this penalty on the order of the number
> of loop iterations)?
Most functions don't suffer this penalty. Consider the following two
functions:
def g(x):
return x()
def h(x):
x()
Now disassemble:
>>> dis.dis(g)
2 0 LOAD_FAST0 (x)
3 CALL_FUNCTION0
6 RETURN_VALUE
>>> dis.dis(h)
2 0 LOAD_FAST0 (x)
3 CALL_FUNCTION0
6 POP_TOP
7 LOAD_CONST 0 (None)
10 RETURN_VALUE
The first doesn't suffer any such default "return None" penalty, and so
won't gain any performance benefit from optimizing it. It is only the
subset of functions which don't explicitly return anything which will
see any potential benefit. Let me call such functions "procedures" to
avoid confusion with those functions which won't see any benefit.
While procedures may see some benefit, it's a trivial amount, probably
not worth the extra complexity. According to Gregory's tests, the
difference is approximately 2% on a trivial do-nothing function.
According to my tests on my PC, I might hope to save somewhat less than
0.1 microsecond per procedure call as an absolute saving. As a relative
saving though, it will most likely be insignificant: for comparison's
sake, urllib2.Request('http://example.com') takes around 150μs on my
machine, and math.sin(1.1) around 90μs. For any procedure which does
non-trivial amounts of work, saving 0.1μs is insignificant, no matter
how many times it is called inside a loop.
--
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
On 1 Sep 2009, at 03:03 , Gregory P. Smith wrote: On Mon, Aug 31, 2009 at 5:01 PM, Greg Ewing >wrote: Antoine Pitrou wrote: Did your coworker run any timings instead of basing his assumptions on bytecode size? In any case, what are you suggesting -- that the last value returned by a function call in the body should be the default return value? I don't think the unpredictability that would introduce would be a good idea. gads no. we're not shell or perl! don't do that :) "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
On 1 Sep 2009, at 02:01 , Greg Ewing wrote: I don't think the unpredictability that would introduce would be a good idea. I fail to grasp the unpredictability of "the last expression evaluated in the body of a function is its return value". It couldn't work in Python because statements aren't expressions, therefore I think def foo(): if cond: 3 else: 4 would break (given if:else: doesn't return a value, the function couldn't have a return value), but in languages where everything is an expression (where if:else: does return a value) there's nothing unpredictable about it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
2009/8/31 xiaobing jiang : > My idea is: here, the two functions (or maybe classes) should have the > same behavior). > so is this a bug or something I missing ? I think they should both not check their arguments in __init__ to allow for duck typing. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
I fail to understand this crude logic. If a function contains any looping (C or otherwise) or does much in the way of meaningful work, then it's unlikely that the single POP_TOP associated with an implied "return None" is taking much of the total runtime. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] implicit return values
On 1 Sep 2009, at 15:25 , Antoine Pitrou wrote: Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit : "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly. Well, feel free to prefer an unreadable language if you want :) Smalltalk or Haskell are hardly inherently unreadable. And it's not like the Python community never lifts features from such languages, so obviously they do (some at least) things right. it will most certainly be shot down anyway Yep, so there's not much point in bringing it up there. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
On Mon, Aug 31, 2009 at 5:01 PM, Greg Ewing wrote: > Antoine Pitrou wrote: > > Did your coworker run any timings instead of basing his assumptions on >> bytecode >> size? >> > > In any case, what are you suggesting -- that the last value > returned by a function call in the body should be the > default return value? > > I don't think the unpredictability that would introduce > would be a good idea. > Never mind the fact that there is a lot of Python code out there that assumes that functions without an explicit return value, return None. This is pretty fundamental to the Python API. -jake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Whether to call Py_Finalize when exiting from the child process of a fork from a spawned thread
Hi all, I'm working on http://bugs.python.org/issue6642 for unladen swallow (because it happens to bite us in a weird way), and Jeff Yasskin told me to ask python-dev what the proper behavior should be at exit from the child process of a fork from a spawned thread. Right now, it seems that there is an assumption that when exiting the process, control will always return through Py_Main, which in turn calls Py_Finalize, to do things like GC and calling atexit handlers. Normally, if you fork a process from the main thread, this assumption will remain true, because main and Py_Main are still at the bottom of the stack in the child process. However, if you fork from a spawned thread, then the root of the stack will be the thread bootstrap routine for the platform's pythreads implementation. On one hand, you may not want to call the user's atexit handlers multiple times from different processes if they have externally visible effects. On the other hand, people seem to assume that Py_Finalize will be called at process exit to do various cleanups. On the third hand, maybe Python could just clear out all the atexit handlers in the child after a fork. So what should the correct behavior be? Thanks, Reid ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote: > 2009/8/31 xiaobing jiang : >> My idea is: here, the two functions (or maybe classes) should have the >> same behavior). >> so is this a bug or something I missing ? > > I think they should both not check their arguments in __init__ to > allow for duck typing. But what is the point of wrapping something with classmethod or staticmethod that can't be called? It isn't like it is checking explicitly for a function or method, just that it can be called which seems reasonable to me (unless PyCallable_Check() is as off as callable() was). -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Whether to call Py_Finalize when exiting from the child process of a fork from a spawned thread
> On one hand, you may not want to call the user's atexit handlers > multiple times from different processes if they have externally > visible effects. On the other hand, people seem to assume that > Py_Finalize will be called at process exit to do various cleanups. On > the third hand, maybe Python could just clear out all the atexit > handlers in the child after a fork. So what should the correct > behavior be? Standard POSIX fork semantics should be a guidance. IIUC, termination of the last thread is equivalent to calling exit(0) (although return from main() still means that exit is invoked right away, and the return value of main is the exit code - right?). Calling exit means to call all exit handlers. So to match POSIX semantics, we should also call the exit handlers in the child process (along with invoking a final garbage collection etc.) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Whether to call Py_Finalize when exiting from the child process of a fork from a spawned thread
On Tue, Sep 1, 2009 at 2:58 PM, "Martin v. Löwis" wrote: >> On one hand, you may not want to call the user's atexit handlers >> multiple times from different processes if they have externally >> visible effects. On the other hand, people seem to assume that >> Py_Finalize will be called at process exit to do various cleanups. On >> the third hand, maybe Python could just clear out all the atexit >> handlers in the child after a fork. So what should the correct >> behavior be? > > Standard POSIX fork semantics should be a guidance. IIUC, termination > of the last thread is equivalent to calling exit(0) (although return > from main() still means that exit is invoked right away, and the return > value of main is the exit code - right?). Calling exit means to call > all exit handlers. It depends, there is also _exit, which exists solely for the purpose of working around exit handlers being called from a forked child process at exit. Which semantics should Python have? In my opinion, it is more obvious that the user's handlers would be called than not, so I agree with you. Reid ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Whether to call Py_Finalize when exiting from the child process of a fork from a spawned thread
>> Standard POSIX fork semantics should be a guidance. IIUC, termination >> of the last thread is equivalent to calling exit(0) (although return >> from main() still means that exit is invoked right away, and the return >> value of main is the exit code - right?). Calling exit means to call >> all exit handlers. > > It depends, there is also _exit, which exists solely for the purpose > of working around exit handlers being called from a forked child > process at exit. I don't think so. There are other cases where you don't want to run atexit handlers, eg. in a segfault signal handler. _exit has been there "forever", I believe (of course, so did fork()). > Which semantics should Python have? In my opinion, > it is more obvious that the user's handlers would be called than not, > so I agree with you. POSIX says that ending the last thread is equivalent to exit(0), and this is what Python should also do when the last thread ends. This is independent of somebody calling _exit(), which should have the very effect that calling _exit has (i.e. immediate process termination). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
2009/9/1 Brett Cannon : > On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote: >> 2009/8/31 xiaobing jiang : >>> My idea is: here, the two functions (or maybe classes) should have the >>> same behavior). >>> so is this a bug or something I missing ? >> >> I think they should both not check their arguments in __init__ to >> allow for duck typing. > > But what is the point of wrapping something with classmethod or > staticmethod that can't be called? It isn't like it is checking > explicitly for a function or method, just that it can be called which > seems reasonable to me (unless PyCallable_Check() is as off as > callable() was). Well, if checking if tp_call is not NULL is as bad as callable, then yes. I don't see any reason to use staticmethod or classmethod with a non-callable, but to be consistent, I would, given the choice between removing code and adding another type check, perfer to remove a type check. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
Xavier Morel wrote: I fail to grasp the unpredictability of "the last expression evaluated in the body of a function is its return value". It's unpredictable in the sense that if you're writing a function that's not intended to return a value, you're not thinking about what the last call you make in the function returns, so to a first approximation it's just some random value. I often write code that makes use of the fact that falling off the end of a function returns None. This has been a documented part of the Python language from the beginning, and changing it would break a lot of code for no good reason. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] implicit return values
Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit : "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly. IIRC, the default return value of a Smalltalk method is self, not the last thing evaluated. (And no, that's not going to happen in Python either -- the BDFL has rejected similar suggestions on previous occasions.) -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
On Tue, Sep 1, 2009 at 14:54, Benjamin Peterson wrote: > 2009/9/1 Brett Cannon : >> On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote: >>> 2009/8/31 xiaobing jiang : My idea is: here, the two functions (or maybe classes) should have the same behavior). so is this a bug or something I missing ? >>> >>> I think they should both not check their arguments in __init__ to >>> allow for duck typing. >> >> But what is the point of wrapping something with classmethod or >> staticmethod that can't be called? It isn't like it is checking >> explicitly for a function or method, just that it can be called which >> seems reasonable to me (unless PyCallable_Check() is as off as >> callable() was). > > Well, if checking if tp_call is not NULL is as bad as callable, then yes. > > I don't see any reason to use staticmethod or classmethod with a > non-callable, but to be consistent, I would, given the choice between > removing code and adding another type check, perfer to remove a type > check. Fine by me. I guess it will just fail later with a slightly more cryptic exception. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Whether to call Py_Finalize when exiting from the child process of a fork from a spawned thread
Reid Kleckner wrote: On one hand, you may not want to call the user's atexit handlers multiple times from different processes if they have externally visible effects. On the other hand, people seem to assume that Py_Finalize will be called at process exit to do various cleanups. On the third hand, maybe Python could just clear out all the atexit handlers in the child after a fork. So what should the correct behavior be? Seems to me there's no single answer to that, because some kinds of atexit handlers may need to be called in child processes, while others may need *not* to be. Maybe we need a flag when registering an atexit handler to indicate whether it should be kept across forks? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
Brett Cannon wrote: It isn't like it is checking explicitly for a function or method, just that it can be called which seems reasonable to me (unless PyCallable_Check() is as off as callable() was). I think it just checks that there's something in the tp_call slot, which is reasonable -- if it's empty, there's no way that calling the object could ever succeed, so you might as well fail early. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
2009/9/1 Greg Ewing : > Brett Cannon wrote: >> >> It isn't like it is checking >> explicitly for a function or method, just that it can be called which >> seems reasonable to me (unless PyCallable_Check() is as off as >> callable() was). > > I think it just checks that there's something in the > tp_call slot, which is reasonable -- if it's empty, > there's no way that calling the object could ever > succeed, so you might as well fail early. It depends on whether you're keeping the "callable" object around or not. Somebody could add a __call__ method later. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
Benjamin Peterson wrote: It depends on whether you're keeping the "callable" object around or not. Somebody could add a __call__ method later. Good point. Removing the check sounds like the right thing to do, then. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
On Sep 1, 2009, at 2:54 PM, Benjamin Peterson wrote: 2009/9/1 Brett Cannon : On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote: 2009/8/31 xiaobing jiang : My idea is: here, the two functions (or maybe classes) should have the same behavior). so is this a bug or something I missing ? I think they should both not check their arguments in __init__ to allow for duck typing. But what is the point of wrapping something with classmethod or staticmethod that can't be called? It isn't like it is checking explicitly for a function or method, just that it can be called which seems reasonable to me (unless PyCallable_Check() is as off as callable() was). Well, if checking if tp_call is not NULL is as bad as callable, then yes. I don't see any reason to use staticmethod or classmethod with a non-callable, but to be consistent, I would, given the choice between removing code and adding another type check, perfer to remove a type check. Removing the type check is also my preference. Raymond___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
Greg Ewing wrote: Benjamin Peterson wrote: It depends on whether you're keeping the "callable" object around or not. Somebody could add a __call__ method later. Good point. Removing the check sounds like the right thing to do, then. Both classmethod & staticmethod are documented as having a *function* (callable, as I interprete that) as their single argument. Seems reasonable to me. Turning the argument into a function after the fact seems like a really esoteric use case. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote: Greg Ewing wrote: Benjamin Peterson wrote: It depends on whether you're keeping the "callable" object around or not. Somebody could add a __call__ method later. Good point. Removing the check sounds like the right thing to do, then. Both classmethod & staticmethod are documented as having a *function* (callable, as I interprete that) as their single argument. Seems reasonable to me. Turning the argument into a function after the fact seems like a really esoteric use case. The main use case for staticmethod is to prevent __get__ from being called on an object retrieved from a class or an instance. It just happens that the most common types of objects you'd want to do that on are functions. However, if for some reason you intend to make a *descriptor* available as an attribute (via a class default), then wrapping it with staticmethod is the only easy way to do it. For example, if you're writing a class whose instances have an attribute that holds a "property" instance, and you want to provide a class-level default, the simplest way to do it is to wrap the default property instance with staticmethod, so that it's not treated as a property of the class/instance. (Property instances are of course not callable.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
P.J. Eby wrote: At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote: Greg Ewing wrote: Benjamin Peterson wrote: It depends on whether you're keeping the "callable" object around or not. Somebody could add a __call__ method later. Good point. Removing the check sounds like the right thing to do, then. Both classmethod & staticmethod are documented as having a *function* (callable, as I interprete that) as their single argument. Seems reasonable to me. Turning the argument into a function after the fact seems like a really esoteric use case. The main use case for staticmethod is to prevent __get__ from being called on an object retrieved from a class or an instance. It just happens that the most common types of objects you'd want to do that on are functions. If so, then it is mis-named and mis-documented, and it seems to me that there is *a* rationale (not necessarily determinative) for the current difference in implementation. However, if for some reason you intend to make a *descriptor* available as an attribute (via a class default), then wrapping it with staticmethod is the only easy way to do it. For example, if you're writing a class whose instances have an attribute that holds a "property" instance, and you want to provide a class-level default, the simplest way to do it is to wrap the default property instance with staticmethod, so that it's not treated as a property of the class/instance. (Property instances are of course not callable.) So that it is a 'static object' in some sense, but not a static *method*. Thanks for the clarification and example. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
