Why are functions atomic?

[Michael]

Why are functions atomic? (I.e. they are not copied.)

For example, I would like to make a copy of a function so I can change
the default values:

>>from copy import copy
f = lambda x: x
f.func_defaul ts = (1,)
g = copy(f)
g.func_defaul ts = (2,)
f(),g()

(2, 2)

I would like the following behaviour:

>>f(),g()

(1,2)

I know I could use a 'functor' defining __call__ and using member
variables, but this is more complicated and quite a bit slower. (I
also know that I can use new.function to create a new copy, but I
would like to know the rational behind the decision to make functions
atomic before I shoot myself in the foot;-)

Thanks,
Michael.

[Laurent Pointal]

Michael wrote:

Why are functions atomic? (I.e. they are not copied.)

For example, I would like to make a copy of a function so I can change
the default values:

>>>from copy import copy
f = lambda x: x
f.func_defau lts = (1,)
g = copy(f)
g.func_defau lts = (2,)
f(),g()

(2, 2)

I would like the following behaviour:

>>>f(),g()

(1,2)

I know I could use a 'functor' defining __call__ and using member
variables, but this is more complicated and quite a bit slower. (I
also know that I can use new.function to create a new copy, but I
would like to know the rational behind the decision to make functions
atomic before I shoot myself in the foot;-)

Thanks,
Michael.

This dont make functions copiable but may resolve your default arguments
problem. Under Python 2.5, see functools.parti al().

http://docs.python.org/lib/partial-objects.html

[Laurent Pointal]

Laurent Pointal wrote:

http://docs.python.org/lib/partial-objects.html

OOps http://docs.python.org/lib/module-functools.html

[7stud]

On May 1, 5:06 am, Michael <michael.for... @gmail.comwrote :

Why are functions atomic? (I.e. they are not copied.)

For example, I would like to make a copy of a function so I can change
the default values:

>from copy import copy
f = lambda x: x
f.func_default s = (1,)
g = copy(f)
g.func_default s = (2,)
f(),g()

(2, 2)

I would like the following behaviour:

>f(),g()

(1,2)

I know I could use a 'functor' defining __call__ and using member
variables, but this is more complicated and quite a bit slower. (I
also know that I can use new.function to create a new copy, but I
would like to know the rational behind the decision to make functions
atomic before I shoot myself in the foot;-)

Thanks,
Michael.

Does deepcopy work?

[Duncan Booth]

7stud <bb**********@y ahoo.comwrote:

Does deepcopy work?

It doesn't copy a function.

The easiest way to make a modified copy of a function is to use the 'new'
module.

>>def f(x=2): print "x=", x

>>g = new.function(f. func_code, f.func_globals, 'g', (3,),

f.func_closure)

>>g()

x= 3

>>f()

x= 2

[Chris Mellon]

On 1 May 2007 15:17:48 GMT, Duncan Booth <du**********@i nvalid.invalidw rote:

7stud <bb**********@y ahoo.comwrote:

Does deepcopy work?

It doesn't copy a function.

The easiest way to make a modified copy of a function is to use the 'new'
module.

>def f(x=2): print "x=", x

>g = new.function(f. func_code, f.func_globals, 'g', (3,),

f.func_closure)

>g()

x= 3

>f()

x= 2
--
http://mail.python.org/mailman/listinfo/python-list

The copy module considers functions to be immutable and just returns
the object. This seems pretty clearly wrong to me - functions are
clearly not immutable and it's easy to copy a function using new, as
shown above.

>From copy.py:

def _copy_immutable (x):
return x
for t in (type(None), int, long, float, bool, str, tuple,
frozenset, type, xrange, types.ClassType ,
types.BuiltinFu nctionType,
types.FunctionT ype):
d[t] = _copy_immutable

[John Nagle]

Michael wrote:

Why are functions atomic? (I.e. they are not copied.)

Because Python has objects for when you need to associate
state with a function.

John Nagle

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

I know I could use a 'functor' defining __call__ and using member

variables, but this is more complicated and quite a bit slower. (I
also know that I can use new.function to create a new copy, but I
would like to know the rational behind the decision to make functions
atomic before I shoot myself in the foot;-)

Function objects were not copyable because they were immutable. For
an immutable object, a copy cannot reasonably be distinguished from
the original object. See copy.py, around line 105.

Regards,
Martin

[Michael]

On May 1, 9:34 am, John Nagle <n...@animats.c omwrote:

Michael wrote:

Why are functions atomic? (I.e. they are not copied.)

Because Python has objects for when you need to associate
state with a function.

John Nagle

Then why are functions mutable?

I can understand to some extent why functions are not picklable,
because the bytecode may not be the same across python implementations
(is that true?), but I do not understand why copying functions is a
problem. The patch that allows copy to pass-through functions just
emulates pickle, but I can find no discussion or justification for not
allowing functions to be copied:

http://thread.gmane.org/gmane.comp.python.devel/76636

Michael.

[Michael]

>From TFM

"Function objects also support getting and setting arbitrary
attributes, which can be used, for example, to attach metadata to
functions. Regular attribute dot-notation is used to get and set such
attributes. Note that the current implementation only supports
function attributes on user-defined functions. Function attributes on
built-in functions may be supported in the future."

http://docs.python.org/ref/types.html

Again, rather inconsitent with the copy sematics.

On May 1, 9:34 am, John Nagle <n...@animats.c omwrote:

Because Python has objects for when you need to associate
state with a function.

John Nagle