Mailman 3 Bad programming style in decorators? - Python-ideas

newer
How exactly does from ... import...

Bad programming style in decorators?

older
Re: [Python-ideas] Bad programming...

u8y7541 The Awesome Person

2 Jan 2016 2 Jan '16

6:14 p.m.

In most decorator tutorials, it's taught using functions inside functions. Isn't this inefficient because every time the decorator is called, you're redefining the function, which takes up much more memory? I prefer defining decorators as classes with __call__ overridden. Is there a reason why decorators are taught with functions inside functions? -- -Surya Subbarao

Attachments:

attachment.htm (text/html — 538 bytes)

Show replies by thread

Andrew Barnert

2 Jan 2 Jan

6:56 p.m.

On Jan 2, 2016, at 10:14, u8y7541 The Awesome Person wrote:

...

In most decorator tutorials, it's taught using functions inside functions. Isn't this inefficient because every time the decorator is called, you're redefining the function, which takes up much more memory?

No. First, most decorators are only called once. For example: @lru_cache(maxsize=None) def fib(n) if n < 2: return n return fib(n-1) + fib(n-2) The lru_cache function gets called once, and creates and returns a decorator function. That decorator function is passed fib, and creates and returns a wrapper function. That wrapper function is what gets stored in the globals as fib. It may then get called a zillion times, but it doesn't create or call any new function. So, why should you care whether lru_cache is implemented with a function or a class? You're talking about a difference of a few dozen bytes, once in the entire lifetime of your program. Plus, where do you get the idea that a function object is "much larger"? Each new function that gets built used the same code object, globals dict, etc., so you're only paying for the cost of a function object header, plus a tuple of cell objects (pointers) for any state variables. Your alternative is to create a class instance header (maybe a little smaller than a function object header), and store all those state variables in a dict (33-50% bigger even with the new split-instance-dict optimizations). Anyway, I'm willing to bet that in this case, the function is ~256 bytes while the class is ~1024, so you're actually wasting rather than saving memory. But either way, it's far too little memory to care.

...

I prefer defining decorators as classes with __call__ overridden. Is there a reason why decorators are taught with functions inside functions?

Because most decorators are more concise, more readable, and easier to understand that way. And that's far more important than a micro-optimization which may actually be a pessimization but which even more likely isn't going to matter at all.

Nick Coghlan

3 Jan 3 Jan

2:42 a.m.

On 3 January 2016 at 04:56, Andrew Barnert via Python-ideas wrote:

...

On Jan 2, 2016, at 10:14, u8y7541 The Awesome Person wrote:

...
In most decorator tutorials, it's taught using functions inside functions. Isn't this inefficient because every time the decorator is called, you're redefining the function, which takes up much more memory?

No.

First, most decorators are only called once. For example:

@lru_cache(maxsize=None) def fib(n) if n < 2: return n return fib(n-1) + fib(n-2)

The lru_cache function gets called once, and creates and returns a decorator function. That decorator function is passed fib, and creates and returns a wrapper function. That wrapper function is what gets stored in the globals as fib. It may then get called a zillion times, but it doesn't create or call any new function.

So, why should you care whether lru_cache is implemented with a function or a class? You're talking about a difference of a few dozen bytes, once in the entire lifetime of your program.

We need to make a slight terminology clarification here, as the answer to Surya's question changes depend on whether we're talking about implementing wrapper functions inside decorators (like the "_lru_cache_wrapper" that lru_cache wraps around the passed in callable), or about implementing decorators inside decorator factories (like the transient "decorating_function" that lru_cache uses to apply the wrapper to the function being defined). Most of the time that distinction isn't important, so folks use the more informal approach of using "decorator" to refer to both decorators and decorator factories, but this is a situation where the difference matters. Every decorator factor does roughly the same thing: when called, it produces a new instance of a callable type which accepts a single function as its sole argument. From the perspective of the *user* of the decorator factory, it doesn't matter whether internally that's handled using a def statement, a lambda expression, functools.partial, instantiating a class that defines a custom __call__ method, or some other technique. It's also rare for decorator factories to be invoked in code that's a performance bottleneck, so it's generally more important to optimise for readability and maintainability when writing them than it is to optimise for speed. The wrapper functions themselves, though, exist in a one:one correspondence with the functions they're applied to - when you apply functools.lru_cache to a function, the transient decorator produced by the decorator factory only lasts as long as the execution of the function definition, but the wrapper function lasts for as long as the wrapped function does, and gets invoked every time that function is called (and if a function is performance critical enough for the results to be worth caching, then it's likely performance critical enough to be thinking about micro-optimisations). As such, from a micro-optimisation perspective, it's reasonable to want to know the answers to: * Which is faster, defining a new function object, or instantiating an existing class? * Which is faster, calling a function object that accepts a single parameter, or calling a class with a custom __call__ method? * Which uses more memory, defining a new function object, or instantiating an existing class? The answers to these questions can technically vary by implementation, but in practice, CPython's likely to be representative of their *relative* performance for any given implementation, so we can use it to check whether or not our intuitions about relative speed and memory consumption are correct. For the first question then, here are the numbers I get locally for CPython 3.4: $ python3 -m timeit "def f(): pass" 10000000 loops, best of 3: 0.0744 usec per loop $ python3 -m timeit -s "class C: pass" "c = C()" 10000000 loops, best of 3: 0.113 usec per loop The trick here is to realise that *at runtime*, a def statement is really just instantiating a new instance of types.FunctionType - most of the heavy lifting has already been done at compile time. The reason it manages to be faster than typical class instantiation is because we get to use customised bytecode operating on constant values rather than having to look the class up by name and making a standard function call:

...

...
...
dis.dis("def f(): pass") 1 0 LOAD_CONST 0 () 3 LOAD_CONST 1 ('f') 6 MAKE_FUNCTION 0 9 STORE_NAME 0 (f) 12 LOAD_CONST 2 (None) 15 RETURN_VALUE dis.dis("c = C()") 1 0 LOAD_NAME 0 (C) 3 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 6 STORE_NAME 1 (c) 9 LOAD_CONST 0 (None) 12 RETURN_VALUE

For the second question: $ python3 -m timeit -s "def f(arg): pass" "f(None)" 10000000 loops, best of 3: 0.111 usec per loop [ncoghlan@thechalk ~]$ python3 -m timeit -s "class C:" -s " def __call__(self, arg): pass" -s "c = C()" "c(None)" 1000000 loops, best of 3: 0.232 usec per loop Again, we see that the native function outperforms the class with a custom __call__ method. There's no difference in the bytecode this time, but rather a difference in what happens inside the CALL_FUNCTION opcode: for the second case, we first have to retrieve the bound c.__call__() method, and then call *that* as c.__call__(None), which in turn internally calls C.__call__(c, None), while for the native function case we get to skip straight to running the called function. The speed difference can be significantly reduced (but not entirely eliminated), by caching the bound method during setup: $ python3 -m timeit -s "class C:" -s " def __call__(self, arg): pass" -s "c_call = C().__call__" "c_call(None)" 10000000 loops, best of 3: 0.115 usec per loop Finally, we get to the question of relative size: are function instances larger or smaller than your typical class instance? Again, we don't have to guess, we can use the interpreter to experiment and check our assumptions: >>> import sys >>> def f(): pass ... >>> sys.getsizeof(f) 136 >>> class C(): pass ... >>> sys.getsizeof(C()) 56 That's a potentially noticeable difference if we're applying the wrapper often enough - the native function is 80 bytes larger than an empty standard class instance. Looking at the available data attributes on f, we can see the likely causes of the difference: >>> set(dir(f)) - set(dir(C())) {'__code__', '__defaults__', '__name__', '__closure__', '__get__', '__kwdefaults__', '__qualname__', '__annotations__', '__globals__', '__call__'} There are 10 additional attributes there, although 2 of them (__get__ and __call__) relate to methods our native function has defined, but the empty class doesn't. The other 8 represent additional pieces of data stored (or potentially stored) per function, that we don't store for a typical class instance. However, we also need to account for the overhead of defining a new class object, and that's a non-trivial amount of memory when we're talking about a size difference of only 80 bytes per wrapped function: >>> sys.getsizeof(C) 976 That means if a wrapper function is only used a few times in any given run of the program, then native functions will be faster *and* use less memory (at least on CPython). If the wrapper is used more often than that, then native functions will still be the fastest option, but not the lowest memory option. Furthermore, if we decide to cache the bound __call__ method to reduce the speed impact of using a custom __call__ method, we give up most of the memory gains: >>> sys.getsizeof(C().__call__) 64 This all suggests that if your application is severely memory constrained (e.g. it's running on an embedded interpreter like MicroPython), then it *might* make sense to incur the extra complexity of using classes with a custom __call__ method to define wrapper functions, over just using a nested function. For more typical cases though, the difference is going to disappear into the noise, so you're likely to be better off defaulting to using nested function definitions, and only switching to the class based version in cases where it's more readable and maintainable (and in those cases considering whether or not it might make sense to return the bound __call__ method from the decorator, rather than the callable itself). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia



    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
        
        
            
                Sign in to reply online
            
            Use email software


    
    
      
      







    
        
            
                
            
            
                
                    
                       u8y7541 The Awesome Person
                    
                
            
        
        
            
            
            
                3 a.m.
            

        
        
    
 
    
      The wrapper functions themselves, though, exist in a one:one
...
correspondence with the functions they're applied to - when you apply
functools.lru_cache to a function, the transient decorator produced by
the decorator factory only lasts as long as the execution of the
function definition, but the wrapper function lasts for as long as the
wrapped function does, and gets invoked every time that function is
called (and if a function is performance critical enough for the
results to be worth caching, then it's likely performance critical
enough to be thinking about micro-optimisations). (Nick Coghlan)
Yes, that is what I was thinking of. Just like Quake's fast inverse square
root. Even though it is a micro-optimization, it greatly affects how fast
the game runs.

But, as I explained, the function will _not_ be redefined and trashed every
...
frame; it will be created one time. (Andrew Barnert)
Hmm... Nick says different...

This all suggests that if your application is severely memory
...
constrained (e.g. it's running on an embedded interpreter like
MicroPython), then it *might* make sense to incur the extra complexity
of using classes with a custom __call__ method to define wrapper
functions, over just using a nested function. (Nick Coghlan)
Yes, I was thinking of that when I started this thread, but this thread is
just from my speculation.


-- 
-Surya Subbarao

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
            
                
                 attachment
                
                
                
            
            
            
                attachment.htm
                    
                
            
            
        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Guido van Rossum
                    
                
            
        
        
            
            
            
                3:34 a.m.
            

        
        
    
 
    
      If you want more discussion please discuss a specific example, showing the
decorator code itself (not just the decorator call).

The upshot is that creating a function object is pretty efficient and
probably more efficient than instantiating a class -- if you don't believe
that write a micro-benchmark.

On Sat, Jan 2, 2016 at 8:00 PM, u8y7541 The Awesome Person <
surya.subbarao1@gmail.com> wrote:
...
The wrapper functions themselves, though, exist in a one:one
...
correspondence with the functions they're applied to - when you apply
functools.lru_cache to a function, the transient decorator produced by
the decorator factory only lasts as long as the execution of the
function definition, but the wrapper function lasts for as long as the
wrapped function does, and gets invoked every time that function is
called (and if a function is performance critical enough for the
results to be worth caching, then it's likely performance critical
enough to be thinking about micro-optimisations). (Nick Coghlan)
Yes, that is what I was thinking of. Just like Quake's fast inverse square
root. Even though it is a micro-optimization, it greatly affects how fast
the game runs.
But, as I explained, the function will _not_ be redefined and trashed
...
every frame; it will be created one time. (Andrew Barnert)
Hmm... Nick says different...
This all suggests that if your application is severely memory
...
constrained (e.g. it's running on an embedded interpreter like
MicroPython), then it *might* make sense to incur the extra complexity
of using classes with a custom __call__ method to define wrapper
functions, over just using a nested function. (Nick Coghlan)
Yes, I was thinking of that when I started this thread, but this thread is
just from my speculation.
--
-Surya Subbarao
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
-- 
--Guido van Rossum (python.org/~guido)

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
            
                
                 attachment
                
                
                
            
            
            
                attachment.htm
                    
                
            
            
        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Nick Coghlan
                    
                
            
        
        
            
            
            
                3:39 a.m.
            

        
        
    
 
    
      On 3 January 2016 at 13:00, u8y7541 The Awesome Person
 wrote:
...
...
The wrapper functions themselves, though, exist in a one:one
correspondence with the functions they're applied to - when you apply
functools.lru_cache to a function, the transient decorator produced by
the decorator factory only lasts as long as the execution of the
function definition, but the wrapper function lasts for as long as the
wrapped function does, and gets invoked every time that function is
called (and if a function is performance critical enough for the
results to be worth caching, then it's likely performance critical
enough to be thinking about micro-optimisations). (Nick Coghlan)
Yes, that is what I was thinking of. Just like Quake's fast inverse square
root. Even though it is a micro-optimization, it greatly affects how fast
the game runs.
For Python, much bigger performance pay-offs are available without
changing the code by adopting tools like PyPy, Cython and Numba.
Worrying about micro-optimisations like this usually only makes sense
if a profiler has identified the code as a hotspot for your particular
workload (and sometimes not even then).
...
...
But, as I explained, the function will _not_ be redefined and trashed
every frame; it will be created one time. (Andrew Barnert)
Hmm... Nick says different...
...
This all suggests that if your application is severely memory
constrained (e.g. it's running on an embedded interpreter like
MicroPython), then it *might* make sense to incur the extra complexity
of using classes with a custom __call__ method to define wrapper
functions, over just using a nested function. (Nick Coghlan)
The memory difference is only per function defined using the wrapper,
not per call. The second speed difference I described (how long the
CALL_FUNCTION opcode takes) is per call, and there native functions
are the clear winner (followed by bound methods, and custom callable
objects a relatively distant third).

The other thing to keep in mind is that the examples I showed were
focused specifically on measuring the differences in overhead, so the
function bodies don't actually do anything, and the class instances
didn't contain any state of their own. Adding even a single
instance/closure variable is likely to swamp the differences in memory
consumption between a native function and a class instance.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Guido van Rossum
                    
                
            
        
        
            
            
            
                3:48 a.m.
            

        
        
    
 
    
      Whoops, Nick already did the micro-benchmarks, and showed that creating a
function object is faster than instantiating a class. He also measured the
size, but I think he forgot that sys.getsizeof() doesn't report the size
(recursively) of contained objects -- a class instance references a dict
which is another 288 bytes (though if you care you can get rid of this by
using __slots__). I expect that calling an instance using __call__ is also
slower than calling a function (but you can do your own benchmarks :-).

On Sat, Jan 2, 2016 at 8:39 PM, Nick Coghlan  wrote:
...
On 3 January 2016 at 13:00, u8y7541 The Awesome Person
 wrote:
...
...
The wrapper functions themselves, though, exist in a one:one
correspondence with the functions they're applied to - when you apply
functools.lru_cache to a function, the transient decorator produced by
the decorator factory only lasts as long as the execution of the
function definition, but the wrapper function lasts for as long as the
wrapped function does, and gets invoked every time that function is
called (and if a function is performance critical enough for the
results to be worth caching, then it's likely performance critical
enough to be thinking about micro-optimisations). (Nick Coghlan)
Yes, that is what I was thinking of. Just like Quake's fast inverse
square
...
root. Even though it is a micro-optimization, it greatly affects how fast
the game runs.
For Python, much bigger performance pay-offs are available without
changing the code by adopting tools like PyPy, Cython and Numba.
Worrying about micro-optimisations like this usually only makes sense
if a profiler has identified the code as a hotspot for your particular
workload (and sometimes not even then).
...
...
But, as I explained, the function will _not_ be redefined and trashed
every frame; it will be created one time. (Andrew Barnert)
Hmm... Nick says different...
...
This all suggests that if your application is severely memory
constrained (e.g. it's running on an embedded interpreter like
MicroPython), then it *might* make sense to incur the extra complexity
of using classes with a custom __call__ method to define wrapper
functions, over just using a nested function. (Nick Coghlan)
The memory difference is only per function defined using the wrapper,
not per call. The second speed difference I described (how long the
CALL_FUNCTION opcode takes) is per call, and there native functions
are the clear winner (followed by bound methods, and custom callable
objects a relatively distant third).
The other thing to keep in mind is that the examples I showed were
focused specifically on measuring the differences in overhead, so the
function bodies don't actually do anything, and the class instances
didn't contain any state of their own. Adding even a single
instance/closure variable is likely to swamp the differences in memory
consumption between a native function and a class instance.
Cheers,
Nick.
--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
-- 
--Guido van Rossum (python.org/~guido)

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
            
                
                 attachment
                
                
                
            
            
            
                attachment.htm
                    
                
            
            
        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Andrew Barnert
                    
                
            
        
        
            
            
            
                3:50 a.m.
            

        
        
    
 
    
      On Jan 2, 2016, at 19:00, u8y7541 The Awesome Person  wrote:
...
...
The wrapper functions themselves, though, exist in a one:one
correspondence with the functions they're applied to - when you apply
functools.lru_cache to a function, the transient decorator produced by
the decorator factory only lasts as long as the execution of the
function definition, but the wrapper function lasts for as long as the
wrapped function does, and gets invoked every time that function is
called (and if a function is performance critical enough for the
results to be worth caching, then it's likely performance critical
enough to be thinking about micro-optimisations). (Nick Coghlan)
Yes, that is what I was thinking of. Just like Quake's fast inverse square root. Even though it is a micro-optimization, it greatly affects how fast the game runs.
Of course micro-optimizations _can_ matter--when you're optimizing the work done in the inner loop of a program that's CPU-bound, even a few percent can make a difference.

But that doesn't mean they _always_ matter. Saving 50ns in some code that runs thousands of times per frames makes a difference; saving 50ns in some code that happens once at startup does not. That's why we have profiling tools: so you can find the bit of your program where you're spending 99% of your time doing something a billion times, and optimize that part.

And it also doesn't mean that everything that sounds like it should be lighter is worth doing. You have to actually test it and see. In the typical case where you're replacing one function object with one class object and one instance object, that's actually taking more space, not less.
...
...
But, as I explained, the function will _not_ be redefined and trashed every frame; it will be created one time. (Andrew Barnert)
Hmm... Nick says different...
No, Nick doesn't say different. Read it again. The wrapper function lives as long as the wrapped function lives. It doesn't get created anew each time you call it.

If you don't understand this, it may help to profile [fib(i) for i in range(10000)]. You'll see that the wrapper function gets called a ton of times, the wrapper function gets called 10000 times, and the factory function (which created wrapper functions) gets called 0 times.
...
...
This all suggests that if your application is severely memory
constrained (e.g. it's running on an embedded interpreter like
MicroPython), then it *might* make sense to incur the extra complexity
of using classes with a custom __call__ method to define wrapper
functions, over just using a nested function. (Nick Coghlan)
Yes, I was thinking of that when I started this thread, but this thread is just from my speculation.
Nick is saying that there may be some cases where it might make sense to use a class. That doesn't at all support your idea that tutorials should teach using classes instead of functions. In general, using functions will be faster; in the most common case, using functions will use less memory; most importantly, in the vast majority of cases, it won't matter anyway.  Maybe a MicroPython tutorial should have a section on how running on a machine with only 4KB changes a lot of the usual tradeoffs, using a decorator as an example. But a tutorial on decorators should show using a function, because it's the simplest, most readable way to do it.

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
            
                
                 attachment
                
                
                
            
            
            
                attachment.htm
                    
                
            
            
        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                       u8y7541 The Awesome Person
                    
                
            
        
        
            
            
            
                3:56 a.m.
            

        
        
    
 
    
      ...
If you don't understand this, it may help to profile [fib(i) for i in
range(10000)]. You'll see that the wrapper function gets called a ton of
times, the wrapper function gets called 10000 times, and the factory
function (which created wrapper functions) gets called 0 times.
Ah, I see now. Thank you.

On Sat, Jan 2, 2016 at 7:50 PM, Andrew Barnert  wrote:
...
On Jan 2, 2016, at 19:00, u8y7541 The Awesome Person <
surya.subbarao1@gmail.com> wrote:
The wrapper functions themselves, though, exist in a one:one
...
correspondence with the functions they're applied to - when you apply
functools.lru_cache to a function, the transient decorator produced by
the decorator factory only lasts as long as the execution of the
function definition, but the wrapper function lasts for as long as the
wrapped function does, and gets invoked every time that function is
called (and if a function is performance critical enough for the
results to be worth caching, then it's likely performance critical
enough to be thinking about micro-optimisations). (Nick Coghlan)
Yes, that is what I was thinking of. Just like Quake's fast inverse square
root. Even though it is a micro-optimization, it greatly affects how fast
the game runs.
Of course micro-optimizations _can_ matter--when you're optimizing the
work done in the inner loop of a program that's CPU-bound, even a few
percent can make a difference.
But that doesn't mean they _always_ matter. Saving 50ns in some code that
runs thousands of times per frames makes a difference; saving 50ns in some
code that happens once at startup does not. That's why we have profiling
tools: so you can find the bit of your program where you're spending 99% of
your time doing something a billion times, and optimize that part.
And it also doesn't mean that everything that sounds like it should be
lighter is worth doing. You have to actually test it and see. In the
typical case where you're replacing one function object with one class
object and one instance object, that's actually taking more space, not less.
But, as I explained, the function will _not_ be redefined and trashed
...
every frame; it will be created one time. (Andrew Barnert)
Hmm... Nick says different...
No, Nick doesn't say different. Read it again. The wrapper function lives
as long as the wrapped function lives. It doesn't get created anew each
time you call it.
If you don't understand this, it may help to profile [fib(i) for i in
range(10000)]. You'll see that the wrapper function gets called a ton of
times, the wrapper function gets called 10000 times, and the factory
function (which created wrapper functions) gets called 0 times.
This all suggests that if your application is severely memory
...
constrained (e.g. it's running on an embedded interpreter like
MicroPython), then it *might* make sense to incur the extra complexity
of using classes with a custom __call__ method to define wrapper
functions, over just using a nested function. (Nick Coghlan)
Yes, I was thinking of that when I started this thread, but this thread is
just from my speculation.
Nick is saying that there may be some cases where it might make sense to
use a class. That doesn't at all support your idea that tutorials should
teach using classes instead of functions. In general, using functions will
be faster; in the most common case, using functions will use less memory;
most importantly, in the vast majority of cases, it won't matter anyway.
Maybe a MicroPython tutorial should have a section on how running on a
machine with only 4KB changes a lot of the usual tradeoffs, using a
decorator as an example. But a tutorial on decorators should show using a
function, because it's the simplest, most readable way to do it.
-- 
-Surya Subbarao

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
            
                
                 attachment
                
                
                
            
            
            
                attachment.htm
                    
                
            
            
        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Random832
                    
                
            
        
        
            
            
            
                4:01 a.m.
            

        
        
    
 
    
      Nick Coghlan  writes:
...
(and if a function is performance critical enough for the
results to be worth caching, then it's likely performance critical
enough to be thinking about micro-optimisations).
Maybe. It could be that the "real" implementation is Very Expensive to
invoke, and/or that the characteristics of how the function is called
change the complexity class of an algorithm that calls it for a cached
vs non-cached version.

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Nick Coghlan
                    
                
            
        
        
            
            
            
                6:42 a.m.
            

        
        
    
 
    
      On 3 January 2016 at 13:48, Guido van Rossum  wrote:
...
Whoops, Nick already did the micro-benchmarks, and showed that creating a
function object is faster than instantiating a class. He also measured the
size, but I think he forgot that sys.getsizeof() doesn't report the size
(recursively) of contained objects -- a class instance references a dict
which is another 288 bytes (though if you care you can get rid of this by
using __slots__).
You're right I forgot to account for that (54 bytes without __slots__
did seem surprisingly small!), but functions also always allocate
f.__annotations__ at the moment.

Always allocating f.__annotations__ actually puzzled me a bit - did we
do that for a specific reason, or did we just not think of setting it
to None when it's unused to save space the way we do for other
function attributes? (__closure__, __defaults__, etc)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Serhiy Storchaka
                    
                
            
        
        
            
            
            
                11:55 a.m.
            

        
        
    
 
    
      On 03.01.16 04:42, Nick Coghlan wrote:
...
Finally, we get to the question of relative size: are function
instances larger or smaller than your typical class instance? Again,
we don't have to guess, we can use the interpreter to experiment and
check our assumptions:
>>> import sys
     >>> def f(): pass
     ...
     >>> sys.getsizeof(f)
     136
     >>> class C(): pass
     ...
     >>> sys.getsizeof(C())
     56
sys.getsizeof() returns only the bare size of the object, not including 
the size of subobjects. To calculate total size you have to sum sizes of 
all subobjects recursively. [1]

[1] http://bugs.python.org/file31822/gettotalsizeof.py

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                       u8y7541 The Awesome Person
                    
                
            
        
        
            
            
            
                6:57 p.m.
            

        
        
    
 
    
      Thanks for explaining the differences tho. I got confused between the
decorator and the decorator factory, thinking the decorator had a function
inside it. Sorry :)

On Sat, Jan 2, 2016 at 10:42 PM, Nick Coghlan  wrote:
...
...
Whoops, Nick already did the micro-benchmarks, and showed that creating a
function object is faster than instantiating a class. He also measured
On 3 January 2016 at 13:48, Guido van Rossum  wrote:
the
...
size, but I think he forgot that sys.getsizeof() doesn't report the size
(recursively) of contained objects -- a class instance references a dict
which is another 288 bytes (though if you care you can get rid of this by
using __slots__).
You're right I forgot to account for that (54 bytes without __slots__
did seem surprisingly small!), but functions also always allocate
f.__annotations__ at the moment.
Always allocating f.__annotations__ actually puzzled me a bit - did we
do that for a specific reason, or did we just not think of setting it
to None when it's unused to save space the way we do for other
function attributes? (__closure__, __defaults__, etc)
Cheers,
Nick.
--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
-- 
-Surya Subbarao

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
            
                
                 attachment
                
                
                
            
            
            
                attachment.htm
                    
                
            
            
        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Guido van Rossum
                    
                
            
        
        
            
            
            
                5 Jan
                
            
            
                5 Jan
                
            
            
            
                12:26 a.m.
            

        
        
    
 
    
      On Sat, Jan 2, 2016 at 10:42 PM, Nick Coghlan  wrote:
...
...
Whoops, Nick already did the micro-benchmarks, and showed that creating a
function object is faster than instantiating a class. He also measured
On 3 January 2016 at 13:48, Guido van Rossum  wrote:
the
...
size, but I think he forgot that sys.getsizeof() doesn't report the size
(recursively) of contained objects -- a class instance references a dict
which is another 288 bytes (though if you care you can get rid of this by
using __slots__).
You're right I forgot to account for that (54 bytes without __slots__
did seem surprisingly small!), but functions also always allocate
f.__annotations__ at the moment.
Always allocating f.__annotations__ actually puzzled me a bit - did we
do that for a specific reason, or did we just not think of setting it
to None when it's unused to save space the way we do for other
function attributes? (__closure__, __defaults__, etc)
Where do you see that happening? The code in funcobject.c seems to indicate
that it's created on demand. (And that's how I remember it always being.)

-- 
--Guido van Rossum (python.org/~guido)

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
            
                
                 attachment
                
                
                
            
            
            
                attachment.htm
                    
                
            
            
        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Emanuel Barry
                    
                
            
        
        
            
            
            
                3:08 a.m.
            

        
        
    
 
    
      Output from both 3.4.1 and 3.5.0:
...
...
...
def foo(): pass>>> foo.__annotations__{}
Probably an oversight. I'm also not a C expert, but func_get_annotations (line 396 and onwards in funcobject.c) explicitely returns a new, empty dict if the function doesn't have any annotations (unlike all the other slots, like __defaults__ or __kwdefaults__, which merely return None if they're not present).
From: guido@python.org
Date: Mon, 4 Jan 2016 16:26:53 -0800
To: ncoghlan@gmail.com
Subject: Re: [Python-ideas] Bad programming style in decorators?
CC: python-ideas@python.org; surya.subbarao1@gmail.com
On Sat, Jan 2, 2016 at 10:42 PM, Nick Coghlan  wrote:
On 3 January 2016 at 13:48, Guido van Rossum  wrote:
...
Whoops, Nick already did the micro-benchmarks, and showed that creating a
...
function object is faster than instantiating a class. He also measured the
...
size, but I think he forgot that sys.getsizeof() doesn't report the size
...
(recursively) of contained objects -- a class instance references a dict
...
which is another 288 bytes (though if you care you can get rid of this by
...
using __slots__).
You're right I forgot to account for that (54 bytes without __slots__

did seem surprisingly small!), but functions also always allocate

f.__annotations__ at the moment.



Always allocating f.__annotations__ actually puzzled me a bit - did we

do that for a specific reason, or did we just not think of setting it

to None when it's unused to save space the way we do for other

function attributes? (__closure__, __defaults__, etc)

Where do you see that happening? The code in funcobject.c seems to indicate that it's created on demand. (And that's how I remember it always being.)
-- 
--Guido van Rossum (python.org/~guido)


_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
            
                
                 attachment
                
                
                
            
            
            
                attachment.htm
                    
                
            
            
        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Andrew Barnert
                    
                
            
        
        
            
            
            
                3:33 a.m.
            

        
        
    
 
    
      On Jan 4, 2016, at 19:08, Emanuel Barry  wrote:
...
Output from both 3.4.1 and 3.5.0:
...
...
...
def foo(): pass
foo.__annotations__
{}
Probably an oversight. I'm also not a C expert, but func_get_annotations (line 396 and onwards in funcobject.c) explicitely returns a new, empty dict if the function doesn't have any annotations (unlike all the other slots, like __defaults__ or __kwdefaults__, which merely return None if they're not present).
But that code implies if you just create a new function object and never check its __annotations__, it's not wasting any space for them. Otherwise, it wouldn't have to check for NULL there.

We can't test this _directly_ from Python, but with a bit of ctypes hackery and funcobject.h, we can define a PyFunctionObject(Structure)... or, keeping things a bit more concise but a lot more hacky for the purposes of email:

    def func(): pass
    pf = cast(id(func), POINTER(c_voidp))
    assert pf[2] == id(func.__code__)
    assert not pf[12]
    f.__annotations__
    assert pf[12]

So it is indeed NULL until you check it, and then it becomes something (an empty dict).

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
            
                
                 attachment
                
                
                
            
            
            
                attachment.htm
                    
                
            
            
        
        
        
        
        
            
                Sign in to reply online
            
            Use email software
        
        

        

    



      
    
    
    
      
      







    
        
            
                
            
            
                
                    
                    Nick Coghlan
                    
                
            
        
        
            
            
            
                5:55 a.m.
            

        
        
    
 
    
      On 5 January 2016 at 10:26, Guido van Rossum  wrote:
...
On Sat, Jan 2, 2016 at 10:42 PM, Nick Coghlan  wrote:
...
Always allocating f.__annotations__ actually puzzled me a bit - did we
do that for a specific reason, or did we just not think of setting it
to None when it's unused to save space the way we do for other
function attributes? (__closure__, __defaults__, etc)
Where do you see that happening? The code in funcobject.c seems to indicate
that it's created on demand. (And that's how I remember it always being.)
I didn't check the code, only the behaviour, so I missed that querying
f.__annotations__ was implicitly creating the dictionary.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

    

    

    
      
        
          
          
        
        

    
    
    
		
			
					 0
			
			
				 0
			
		
    

    

        

        
        
        
        
            
            Reply
        
        
        

        
        
        
        
        
            
                Sign in to reply online
            
            Use email software



            
                
                    
                
                






    
    
      
        3033
        
          Age (days ago)
        
      
      
        3036
        
          Last active (days ago)
        
        
    
 

    
        
            List overview
        
    

    

    
    
         Download
    

    
    

        
        16 comments
    
    
        
        7 participants
    
    
    

    
        
        
        
            
                Add to favorites
            
                Remove from favorites
        
    

    

    
        

        tags 
        

    
    
    
    
        participants (7)
        
            
            
                
                
                    Andrew Barnert
                
            
            
            
                
                
                    Emanuel Barry
                
            
            
            
                
                
                    Guido van Rossum
                
            
            
            
                
                
                    Nick Coghlan
                
            
            
            
                
                
                    Random832
                
            
            
            
                
                
                    Serhiy Storchaka
                
            
            
            
                
                
                    u8y7541 The Awesome Person