On May 4, 7:54 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> Michael <[EMAIL PROTECTED]> wrote:
> > Thus, whenever I need to pass information to a function, I use default
> > arguments now. Is there any reason not to do this other than the fact
> > that it is a bit more typing?
>
> You're giving
Michael <[EMAIL PROTECTED]> wrote:
> Thus, whenever I need to pass information to a function, I use default
> arguments now. Is there any reason not to do this other than the fact
> that it is a bit more typing?
You're giving your functions a signature that's different from the one
you expect it
On May 4, 4:13 am, Dustan <[EMAIL PROTECTED]> wrote:
> On May 4, 1:36 am, Michael <[EMAIL PROTECTED]> wrote:
> > ... def g(x=x):
> > ... x = x + 1
> > ... return x
> > ... return g
> > >>> g = f(3)
> > >>> g()>
> > 4
> >>> g()
> 4
> >>> g()
> 4
> >>> g() # what is going on h
On 4 May 2007 12:59:39 -0700, Michael <[EMAIL PROTECTED]> wrote:
> On May 4, 9:19 am, John Nagle <[EMAIL PROTECTED]> wrote:
> > > ... def g():
> > > ... x = x + 1
> >
> > Too cute. Don't nest functions in Python; the scoping model
> > isn't really designed for it.
>
> How can you
On 4 May 2007 12:55:03 -0700, Michael <[EMAIL PROTECTED]> wrote:
> On May 4, 5:49 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> > You aren't getting "bit" by any problem with closures - this is a
> > syntax problem.
>
> I understand that it is not closures that are specifically biting me.
> Howev
On May 4, 9:19 am, John Nagle <[EMAIL PROTECTED]> wrote:
> > ... def g():
> > ... x = x + 1
>
> Too cute. Don't nest functions in Python; the scoping model
> isn't really designed for it.
How can you make generators then if you don't nest?
> Python probably isn't the right l
On May 4, 5:49 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> You aren't getting "bit" by any problem with closures - this is a
> syntax problem.
I understand that it is not closures that are specifically biting me.
However, I got bit, it was unplesant and I don't want to be bit
again;-)
Thus, w
Michael wrote:
> On May 2, 6:08 am, Carsten Haese <[EMAIL PROTECTED]> wrote:
>
>>On Tue, 2007-05-01 at 22:21 -0700, Michael wrote:
> I agree the performance gains are minimal. Using function defaults
> rather than closures, however, seemed much cleaner an more explicit to
> me. For example, I h
On 3 May 2007 23:36:11 -0700, Michael <[EMAIL PROTECTED]> wrote:
> On May 2, 6:08 am, Carsten Haese <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-05-01 at 22:21 -0700, Michael wrote:
> > > Is there a reason for using the closure here? Using function defaults
> > > seems to give better performance:[.
On May 4, 1:36 am, Michael <[EMAIL PROTECTED]> wrote:
> On May 2, 6:08 am, Carsten Haese <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-05-01 at 22:21 -0700, Michael wrote:
> > > Is there a reason for using the closure here? Using function defaults
> > > seems to give better performance:[...]
>
> >
On May 2, 6:08 am, Carsten Haese <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-05-01 at 22:21 -0700, Michael wrote:
> > Is there a reason for using the closure here? Using function defaults
> > seems to give better performance:[...]
>
> It does? Not as far as I can measure it to any significant degree
[EMAIL PROTECTED] (Alex Martelli) wrote:
>> Is there a reason for using the closure here? Using function
>> defaults seems to give better performance:
>
> What measurements show you that...?
>
...
>
> brain:~ alex$ python -mtimeit -s'import powi; p=powi.powerfactory1(3)'
> 'p(27)'
> 100 lo
>> The answer is really really simple. The implementation of copy predates
>> mutability. When the copy code was written, functions *were* immutable.
>> When functions became mutable, the copy code was not changed, and
>> nobody noticed or complained.
>
> Likely scenario, but not true.
Interestin
>> The answer is really really simple. The implementation of copy predates
>> mutability. When the copy code was written, functions *were* immutable.
>> When functions became mutable, the copy code was not changed, and
>> nobody noticed or complained.
>
> That's probably an indication that mut
Michael <[EMAIL PROTECTED]> wrote:
> Is there a reason for using the closure here? Using function defaults
> seems to give better performance:
What measurements show you that...?
brain:~ alex$ cat powi.py
def powerfactory1(exponent):
def inner(x):
return x**exponent
return inner
de
On Tue, 2007-05-01 at 22:21 -0700, Michael wrote:
> Is there a reason for using the closure here? Using function defaults
> seems to give better performance:[...]
It does? Not as far as I can measure it to any significant degree on my
computer.
> This is definitely one viable solution and is ess
En Wed, 02 May 2007 01:42:17 -0300, Martin v. Löwis <[EMAIL PROTECTED]>
escribió:
> Michael schrieb:
>> A bit more info, but still no clear picture about why functions are
>> mutable but have immutable copy symantics. There are arguments why
>> functions should be immutable, but the decision wa
Martin v. Löwis wrote:
> Michael schrieb:
>
>>A bit more info, but still no clear picture about why functions are
>>mutable but have immutable copy symantics. There are arguments why
>>functions should be immutable, but the decision was to make user-
>>defined functions mutable. My question is s
> Your use case appears to be that you
> want to make multiple copies of the same function, and those copies
> should be almost, but not quite, the same.
>
> The Pythonic solution is to produce the copies by a factory function...
>
> >>> def powerfactory(exponent):
> ...def inner(x):
> ...
Michael schrieb:
> A bit more info, but still no clear picture about why functions are
> mutable but have immutable copy symantics. There are arguments why
> functions should be immutable, but the decision was to make user-
> defined functions mutable. My question is still: why the present
> ummu
On Tue, 2007-05-01 at 17:28 -0700, Michael wrote:
> A bit more info, but still no clear picture about why functions are
> mutable but have immutable copy symantics. There are arguments why
> functions should be immutable, but the decision was to make user-
> defined functions mutable. My question
A bit more info, but still no clear picture about why functions are
mutable but have immutable copy symantics. There are arguments why
functions should be immutable, but the decision was to make user-
defined functions mutable. My question is still: why the present
ummutable copy symantics?
http
>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-
On May 1, 9:34 am, John Nagle <[EMAIL PROTECTED]> wrote:
> 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
> 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 sho
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
--
http://mail.python.org/mailman/listinfo/python-list
On 1 May 2007 15:17:48 GMT, Duncan Booth <[EMAIL PROTECTED]> wrote:
> 7stud <[EMAIL PROTECTED]> wrote:
>
> > 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.
7stud <[EMAIL PROTECTED]> wrote:
> 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()
On May 1, 5:06 am, Michael <[EMAIL PROTECTED]> 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 = lam
Laurent Pointal wrote:
> http://docs.python.org/lib/partial-objects.html
OOps http://docs.python.org/lib/module-functools.html
--
http://mail.python.org/mailman/listinfo/python-list
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_default
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_defaults = (1,)
>>> g = copy(f)
>>> g.func_def
32 matches
Mail list logo
