Thanks. In case anyone else is looking, the recipe is at:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303440
(which also shows how to make it work with python2.3 and below since
they don't support decorators)
Brian
--
http://mail.python.org/mailman/listinfo/python-list
Fuzzyman wrote:
I see. I may be wrong on this... *but* I thought the only time when a
variable defined in the same scope as a function wouldn't be available
in the same namespace is when the function is a global but the variable
isn't ?
Sorta depends on what you mean by "available in the same names
Steven Bethard wrote:
> Fuzzyman wrote:
> > It wasn't that part of the example that I thought was over complex.
> > (although it's not a 'pattern' I use often). You suggested that if
we
> > had dynamic evaluation of default values, you would have to replace
it
> > with :
> >
> >class foo(objec
Fuzzyman wrote:
It wasn't that part of the example that I thought was over complex.
(although it's not a 'pattern' I use often). You suggested that if we
had dynamic evaluation of default values, you would have to replace it
with :
class foo(object):
matcher=re.compile(r'...')
def __new__(sel
<[EMAIL PROTECTED]> wrote:
...
> the default params are evaluated at the definition. However, I still
> can't give a nice looking solution on how to re-write a function to
> have empty mutable values as default arguments: eg.
>
> def method(a,b,opt1=[],opt2=None,opt3="",opt4={})
>
> How could
<[EMAIL PROTECTED]> wrote:
...
> I'm really looking for a neat way to do the following:
>
> def method(a,b,opt1=None,opt2=None,opt3="",opt4=None):
> if opt1 is None: opt1=[]
> if opt2 is None: opt2={}
> if opt4 is None: opt4=[]
>
> Python syntax is normally so neat but this just looks a mess i
Steven Bethard wrote:
> Fuzzyman wrote:
> >>>Steven Bethard wrote:
>
> So, one of my really common use cases that takes advantage of the
> fact that default parameters are evaluated at function definition
> time:
>
> def foo(bar, baz, matcher=re.compile(r'...')):
>
Fuzzyman wrote:
Steven Bethard wrote:
So, one of my really common use cases that takes advantage of the
fact that default parameters are evaluated at function definition
time:
def foo(bar, baz, matcher=re.compile(r'...')):
...
text = matcher.sub(r'...', text)
...
Sure.. but you also gave a
Steven Bethard wrote:
> Fuzzyman wrote:
> > Steven Bethard wrote:
> >
> >>[EMAIL PROTECTED] wrote:
> >>
> >>>However, is there a good reason why default parameters aren't
> >>>evaluated as the function is called? (apart from efficiency
> >>>and backwards compatibility)?
> >>
> >>So, one of my real
Fuzzyman wrote:
Steven Bethard wrote:
[EMAIL PROTECTED] wrote:
However, is there a good reason why default parameters aren't
evaluated as the function is called? (apart from efficiency
and backwards compatibility)?
So, one of my really common use cases that takes advantage of the
fact that default
Steven Bethard wrote:
> [EMAIL PROTECTED] wrote:
> > However, is there a good reason why default parameters aren't
evaluated
> > as the function is called? (apart from efficiency and backwards
> > compatibility)?
>
> So, one of my really common use cases that takes advantage of the
fact
> that def
[EMAIL PROTECTED] wrote:
> > Channelling the effbot, I think he was asking what namespace
context
> you
> > expected the expression "arg=otherfunction(x)" to be evaluated in
> when
> > it's used at the time of a function call to dynamically create a
new
> > default value for arg.
>
> Thanks, I rea
[EMAIL PROTECTED] wrote:
> > Channelling the effbot, I think he was asking what namespace
context
> you
> > expected the expression "arg=otherfunction(x)" to be evaluated in
> when
> > it's used at the time of a function call to dynamically create a
new
> > default value for arg.
>
> Thanks, I rea
> Channelling the effbot, I think he was asking what namespace context
you
> expected the expression "arg=otherfunction(x)" to be evaluated in
when
> it's used at the time of a function call to dynamically create a new
> default value for arg.
Thanks, I realise now that's what was meant. I think I
[EMAIL PROTECTED] wrote:
However, is there a good reason why default parameters aren't evaluated
as the function is called? (apart from efficiency and backwards
compatibility)?
So, one of my really common use cases that takes advantage of the fact
that default parameters are evaluated at function
harold fellermann wrote:
Hi,
I cannot see any strange behavior. this code works exacly as you and I
suspect:
>>> def otherfunction(x) :
return x
>>> def function(arg=otherfunction(5)) :
return arg
>>> function(3)
3
>>> function()
5
Or is this not what you excepted?
"harold fellermann" wrote:
> I cannot see any strange behavior. this code works exacly as you and I
> suspect:
you seem to have missed some of the posts that led up to the one you
replied to. (most importantly, the first one).
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
I cannot see any strange behavior. this code works exacly as you and I
suspect:
>>> def otherfunction(x) :
... return x
...
>>> def function(arg=otherfunction(5)) :
... return arg
...
>>> function(3)
3
>>> function()
5
Or is this not what you excepted?
- harold -
On 21.12.2004, at 15:
<[EMAIL PROTECTED]> wrote:
> def function(arg=otherfunction(value)):
> return arg
>
> My expectation would have been that otherfunction(value) would be
> called if (and only if) the arg keyword parameter was missing from the
> function() call (ie. the optional value is evaluated the lazy way).
def function(arg=otherfunction(value)):
return arg
My expectation would have been that otherfunction(value) would be
called if (and only if) the arg keyword parameter was missing from the
function() call (ie. the optional value is evaluated the lazy way).
Also, otherfunction would be called each a
<[EMAIL PROTECTED]> wrote:
> However, is there a good reason why default parameters aren't evaluated
> as the function is called? (apart from efficiency and backwards
> compatibility)?
how would you handle this case:
def function(arg=otherfunction(value)):
return arg
--
http:
Thanks, this makes perfect sense. The phrase which sums it up neatly is
"Default parameter values are evaluated when the function definition is
executed"
However, is there a good reason why default parameters aren't evaluated
as the function is called? (apart from efficiency and backwards
compatib
wrote:
> Can anyone explain the behaviour of python when running this script?
>
def method(n, bits=[]):
> ... bits.append(n)
> ... print bits
> ...
method(1)
> [1]
method(2)
> [1, 2]
>
> It's the same in python 1.5, 2.3 and 2.4 so it's not a bug. But I
> expected the vari
[EMAIL PROTECTED] wrote:
> Can anyone explain the behaviour of python when running this script?
the language reference has the full story:
http://www.python.org/doc/2.4/ref/function.html
"Default parameter values are evaluated when the function
definition is executed"
--
http
[EMAIL PROTECTED] wrote:
Can anyone explain the behaviour of python when running this script?
(...)
Is there a good reason why these scripts are not the same? I can
understand how/why they are different, it's just not what I expected.
(It seems strange to me that the result of the first method can
Can anyone explain the behaviour of python when running this script?
>>> def method(n, bits=[]):
... bits.append(n)
... print bits
...
>>> method(1)
[1]
>>> method(2)
[1, 2]
It's the same in python 1.5, 2.3 and 2.4 so it's not a bug. But I
expected the variable "bits" to be re-initialised
26 matches
Mail list logo
