Re: Default method arguments

2005-11-18 Thread Peter Otten
Martin Miller wrote:

> Well, perhaps the same in the sense of name binding, but there's a
> subtle difference in replacing the 's = [n]'  with 'foo.s = n'.  Namely
> that in the former case (with the essay's original code) a separate
> container is created when foo() is first called and is what is used in
> subsequent calls to the function returned.  Whereas in the latter case
> where the foo object itself is used as the container, there's only a
> single container used by all returned objects -- which would cause
> problems if you try accumulating two or more different totals
> simultaneously.

[snip example using the outer foo() as a container]

You can easily get a unique container using the function attribute style, to
-- just use the inner function bar():

>>> def foo(n):
... def bar(i):
... bar.i += 1
... re
...
>>>
>>> def foo(n):
... def bar(i):
... bar.s += i
... return bar.s
... bar.s = n
... return bar
...
>>> a1 = foo(0)
>>> a2 = foo(0)
>>> a1(0), a2(0)
(0, 0)
>>> a1(1), a2(1)
(1, 1)

Peter

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-18 Thread Gregory Petrosyan
Thanks Martin, you are right.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-17 Thread Martin Miller
Mike Meyer wrote, in part::
> "Gregory Petrosyan" <[EMAIL PROTECTED]> writes:
> ...
> > 2) Is 'foo.s = n' a correct solution? It seems to be a little more
> > elegant.  (I tested it, and it worked well)
>
> It's basically the same solution. You're replacing binding a variable
> with mutating an object bound to a name in an outer scope. In one case
> the container is named s and is a list that you're setting an element
> of. In the other case, the container is named foo and is an object
> that you're setting an attribute on.

Well, perhaps the same in the sense of name binding, but there's a
subtle difference in replacing the 's = [n]'  with 'foo.s = n'.  Namely
that in the former case (with the essay's original code) a separate
container is created when foo() is first called and is what is used in
subsequent calls to the function returned.  Whereas in the latter case
where the foo object itself is used as the container, there's only a
single container used by all returned objects -- which would cause
problems if you try accumulating two or more different totals
simultaneously.

Here's a very contrived test case which illustrates the point I'm
trying to make:

def foo(n):
foo.s = n
def bar(i):
 foo.s += i
 return foo.s
return bar

a1 = foo(0)
a2 = foo(0)
print "before a1(0):", a1(0)
print "before a2(0):", a2(0)
a1(1)
a2(1)
print "after a1(0):", a1(0)
print "after a2(0):", a2(0)

 outputs
before a1(0): 0
before a2(0): 0
after a1(0): 2
after a2(0): 2

Notice that it even though each was only incremented by 1 once, they
interacted, and show the effects of two calls.  This doesn't happen in
in Paul Graham's version, where the two 'after' calls would correctly
retrun a value of 1.

-Martin

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-16 Thread Duncan Booth
Steven D'Aprano wrote:

> My philosophy is, any time you have an object that has a magic meaning
> (e.g. as a sentinel), don't tempt your users to try to use it as if it
> were an ordinary object.

In that case the simplest thing is to give _marker a more appropriate name 
such as '_use_late_bound_default_for_argument' or '_foot_gun_aim_fire'.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-16 Thread Fredrik Lundh
Duncan Booth wrote:

> What you really want is for the marker to exist only in its own little
> universe, but the code for that is even messier:
>
> class A(object):
>def __init__(self, n):
>self.data =n
>def make_f():
>marker = object()
>def f(self, x = _marker):

NameError: global name '_marker' is not defined

>if x is _marker:
>x = self.data
>print x
>return f
>f = make_f()
>
 instance = A(6)
 instance.f()
> 6

in another universe, perhaps, but not very far away:

>>> instance.f.im_func.func_defaults[0]


>>> inspect.getargspec(A.f)
(['self', 'x'], None, None, (,))

 



-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-16 Thread Steven D'Aprano
On Wed, 16 Nov 2005 09:48:47 +, Duncan Booth wrote:

> Steven D'Aprano wrote:
>> I would like to see _marker put inside the class' scope. That prevents
>> somebody from the outside scope easily passing _marker as an argument
>> to instance.f. It also neatly encapsulates everything A needs within
>> A. 
> 
> Surely that makes it easier for someone outside the scope to pass in 
> marker:

>  >>> instance = A(5)
>  >>> instance.f(instance._marker)
>  5

Sure, but they have to explicitly qualify marker with the instance. If
they want to do that, I'm not going to stop them. But I'm trying to avoid
tempting them from doing this:

instance.f(_marker) 

and then complain that it doesn't print _marker.

In other words, I don't want to take away their ability to shoot
themselves in the foot, but I want them to have to *think about it* before
doing so.

 
-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-16 Thread Steven D'Aprano
On Wed, 16 Nov 2005 02:59:15 +, Bengt Richter wrote:

> On Tue, 15 Nov 2005 23:51:18 +0100, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:

>>> I would like to see _marker put inside the class' scope. That prevents
>>> somebody from the outside scope easily passing _marker as an argument
>>> to instance.f.
>>
>>if you don't want people to be able to easily pass _marker as an
>>argument to the f method, you probably shouldn't use it as the default
>>value.
>>
> LOL ;-)

Ha ha *wink*

What I meant was to discourage people from treating _marker as just
another ordinary sort of object, then making pointless bugs
reports "when you pass _marker as the argument to the f method, it doesn't
print _marker but instead prints something else."

My philosophy is, any time you have an object that has a magic meaning
(e.g. as a sentinel), don't tempt your users to try to use it as if it
were an ordinary object.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-16 Thread Duncan Booth
Steven D'Aprano wrote:
> I would like to see _marker put inside the class' scope. That prevents
> somebody from the outside scope easily passing _marker as an argument
> to instance.f. It also neatly encapsulates everything A needs within
> A. 

Surely that makes it easier for someone outside the scope to pass in 
marker:
 
 class A(object):
 _marker = []
 def __init__(self, n):
 self.data =n
 def f(self, x = _marker):
 if x is self.__class__._marker:
 # must use "is" and not "=="
 x = self.data
 print x
 
 >>> instance = A(5)
 >>> instance.f(instance._marker)
 5

What you really want is for the marker to exist only in its own little 
universe, but the code for that is even messier:

class A(object):
def __init__(self, n):
self.data =n
def make_f():
marker = object()
def f(self, x = _marker):
if x is _marker:
x = self.data
print x
return f
f = make_f()


>>> instance = A(6)
>>> instance.f()
6

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-16 Thread [EMAIL PROTECTED]
What you want is essentially :

if parm_x is not supplied, use self.val_x

So why not just express it clearly at the very beginning of the
function :

def f(self, parm_x=NotSupplied, parm_y=NotSupplied ,,,)
  if parm_x is NotSupplied: parm_x = self.val_x
  if parm_y is NotSupplied: parm_y = self.val_y

Much easier to understand than the "twisting your arm 720 degree in the
back" factory method, IMO.

Gregory Petrosyan wrote:
> Thanks a lot, but that's not what I do really want.
> 1) f() may have many arguments, not one
> 2) I don't whant only to _print_ x. I want to do many work with it, so
> if I could simply write
>
> def f(self, x = self.data)   (*)
>
> it would be much better.
>
> By the way, using
>
> class A(object):
> data = 0
> 
> def f(self, x = data)
>
> solves this problem, but not nice at all
> 
> So I think (*) is the best variant, but it doesn't work :(

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Bengt Richter
On 15 Nov 2005 11:02:38 -0800, "Martin Miller" <[EMAIL PROTECTED]> wrote:

>Alex Martelli wrote, in part:
>> If it's crucial to you to have some default argument value evaluated at
>> time X, then, by Python's simple rules, you know that you must arrange
>> for the 'def' statement itself to execute at time X.  In this case, for
>> example, if being able to have self.data as the default argument value
>> is the crucial aspect of the program, you must ensure that the 'def'
>> runs AFTER self.data has the value you desire.
>>
>> For example:
>>
>> class A(object):
>> def __init__(self, n):
>> self.data = n
>> def f(self, x = self.data)
>>  print x
>> self.f = f
>>
>> This way, of course, each instance a of class A will have a SEPARATE
>> callable attribute a.f which is the function you desire; this is
>> inevitable, since functions store their default argument values as part
>> of their per-function data.  Since you want a.f and b.f to have
>> different default values for the argument (respectively a.data and
>> b.data), therefore a.f and b.f just cannot be the SAME function object
>> -- this is another way to look at your issue, in terms of what's stored
>> where rather than of what evaluates when, but of course it leads to
>> exactly the same conclusion.
>
>FWIT and ignoring the small typo on the inner def statement (the
>missing ':'), the example didn't work as I (and possibily others) might
>expect.  Namely it doesn't make function f() a bound method of
>instances of class A, so calls to it don't receive an automatic 'self''
>argument when called on instances of class A.
>
>This is fairly easy to remedy use the standard new module thusly:
>
>import new
>class A(object):
>def __init__(self, n):
>self.data = n
>def f(self, x = self.data):
>print x
>self.f = new.instancemethod(f, self, A)
>
>This change underscores the fact that each instance of class A gets a
>different independent f() method.  Despite this nit, I believe I
>understand the points Alex makes about the subject (and would agree).
>
Or as Alex mentioned, a custom descriptor etc is possible, and can also
protect against replacing f by simple instance attribute assignment
like inst.f = something, or do some filtering to exclude non-function
assignments etc., e.g., (not sure what self.data is really
needed for, but we'll keep it):

BTW, note that self.data initially duplicates the default value,
but self.data per se is not used by the function (until the instance
method is replace by one that does, see further on)

 >>> class BindInstMethod(object):
 ... def __init__(self, inst_fname):
 ... self.inst_fname= inst_fname
 ... def __get__(self, inst, cls=None):
 ... if inst is None: return self
 ... return inst.__dict__[self.inst_fname].__get__(inst, cls) # return 
bound instance method
 ... def __set__(self, inst, val):
 ... if not callable(val) or not hasattr(val, '__get__'): # screen out 
some impossible methods
 ... raise AttributeError, '%s may not be replaced by  %r' % 
(self.inst_fname, val)
 ... inst.__dict__[self.inst_fname] = val
 ...

The above class defines a custom descriptor that can be instatiated as a class
variable of a given name. When that name is thereafter accessed as an attribute
of an instance of the latter class (e.g. A below), the decriptor __get__ or 
__set__
methods will be called (the __set__ makes it a "data" descriptor, which 
intercepts
instance attribute assignment.

 >>> class A(object):
 ... def __init__(self, n):
 ... self.data = n
 ... def f(self, x = self.data):
 ...  print x
 ... self.__dict__['f'] = f  # set instance attr w/o triggering 
descriptor
 ... f = BindInstMethod('f')
 ...

 >>> a = A(5)
 >>> a.f
 >

Note that a.f is dynamically bound at the time of a.f access, not
retrieved as a prebound instance method.

 >>> a.f()
 5
 >>> a.f('not default 5')
 not default 5
 >>> a.data
 5
 >>> a.data = 'not original data 5'

Since the default is an independent duplicate of a.data
a call with no arg produces the original default:
 >>> a.f()
 5
 >>> a.data
 'not original data 5'
 >>> a.f('this arg overrides the default')
 this arg overrides the default

Try to change a.f
 >>> a.f = 'sabotage f'
 Traceback (most recent call last):
   File "", line 1, in ?
   File "", line 10, in __set__
 AttributeError: f may not be replaced by  'sabotage f'

Now use a function, which should be accepted (note: a function, not an instance 
method)
 >>> a.f = lambda self: self.data*2
 >>> a.f
  of <__main__.A object at 0x02EF3B0C>>
Plainly the method was dynamically bound

 >>> a.f()
 'not original data 5not original data 5'
That was self.data*2 per the lambda we just assigned to a.f
BTW, the assignment is not directly to the instance attribute.
It goes via the descriptor __set__ method.

 >>> a.data = 12
 >>> a.f()
 24
 >>> b = A('bee')
 >>> b.f
 >
 >>> 

Re: Default method arguments

2005-11-15 Thread Bengt Richter
On Tue, 15 Nov 2005 23:51:18 +0100, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:

>Steven D'Aprano wrote:
>
>>> Another solution to this is the use of a 'marker' object and identity test:
>>>
>>> _marker = []
>>> class A(object):
>>> def __init__(self, n):
>>> self.data =n
>>> def f(self, x = _marker):
>>> if x is _marker:
>>> x = self.data
>>> print x
>>
>> I would like to see _marker put inside the class' scope. That prevents
>> somebody from the outside scope easily passing _marker as an argument to
>> instance.f.
>
>if you don't want people to be able to easily pass _marker as an argument
>to the f method, you probably shouldn't use it as the default value.
>
LOL ;-)

Regards,
Bengt Richter
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Fredrik Lundh
Steven D'Aprano wrote:

>> Another solution to this is the use of a 'marker' object and identity test:
>>
>> _marker = []
>> class A(object):
>> def __init__(self, n):
>> self.data =n
>> def f(self, x = _marker):
>> if x is _marker:
>> x = self.data
>> print x
>
> I would like to see _marker put inside the class' scope. That prevents
> somebody from the outside scope easily passing _marker as an argument to
> instance.f.

if you don't want people to be able to easily pass _marker as an argument
to the f method, you probably shouldn't use it as the default value.

 



-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Steven D'Aprano
On Tue, 15 Nov 2005 18:44:23 +0100, bruno at modulix wrote:

> Another solution to this is the use of a 'marker' object and identity test:
> 
> _marker = []
> class A(object):
> def __init__(self, n):
> self.data =n
> def f(self, x = _marker):
> if x is _marker:
> x = self.data
> print x

I would like to see _marker put inside the class' scope. That prevents
somebody from the outside scope easily passing _marker as an argument to
instance.f. It also neatly encapsulates everything A needs within A.

class A(object):
_marker = []
def __init__(self, n):
self.data =n
def f(self, x = _marker):
if x is self.__class__._marker:
# must use "is" and not "=="
x = self.data
print x

Note the gotcha though: in the method definition, you refer to a plain
_marker, but in the method code block, you need to qualify it.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Gregory Petrosyan
Thanks a lot, I understood the rule. Let's don't discuss this
(containers etc.) anymore, or it'll be offtopic.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Mike Meyer
"Gregory Petrosyan" <[EMAIL PROTECTED]> writes:

> I'm not very familiar with Python, so please explain me why should
> containers be used?
> For example in one of Paul Graham's essays there's an example of
> 'generator of accumulators' in Python:
>
> def foo(n):
> s = [n]
> def bar(i):
>  s[0] += i
>  return s[0]
> return bar
>
> 1) So, why just using 's = n' is not suitable? (It doesn't work, Python
> 'doesn't see' s, but why?)

The Python assignment statements bind a name to a value. By default,
they bind it in the current namespace. Doing "s = n" (or s = n) in
the function bar binds the name s in the function bar, and leaves the
value in foo as it was. "s[0] = i" (or s[0 += i) binds the name s[0],
not the name s, and hence mutates the object bound to s instead of
binding s in the function bar's namespace. In reality, this is
implemented by a mutator method of s, but it *looks* like you're
binding s[0].

> 2) Is 'foo.s = n' a correct solution? It seems to be a little more
> elegant.  (I tested it, and it worked well)

It's basically the same solution. You're replacing binding a variable
with mutating an object bound to a name in an outer scope. In one case
the container is named s and is a list that you're setting an element
of. In the other case, the container is named foo and is an object
that you're setting an attribute on.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Gregory Petrosyan
I'm not very familiar with Python, so please explain me why should
containers be used?
For example in one of Paul Graham's essays there's an example of
'generator of accumulators' in Python:

def foo(n):
s = [n]
def bar(i):
 s[0] += i
 return s[0]
return bar

1) So, why just using 's = n' is not suitable? (It doesn't work, Python
'doesn't see' s, but why?)
2) Is 'foo.s = n' a correct solution? It seems to be a little more
elegant.  (I tested it, and it worked well)

Sorry for possibly stupid questions.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Mike Meyer
Benji York <[EMAIL PROTECTED]> writes:
> I'll add my 2 cents to the mix:
>
> default = object()
>
> class A(object):
>  def __init__(self, n):
>  self.data = n
>
>  def f(self, x=default):
>  if x is default:
>  x = self.data
>  print x

There were a lot of solutions like this. I'd like to point out that
you can put the "marker" in the class:

class A(object):
   default = object()
   def __init__(self, n):
   self.data = n

   def f(self, x = default):
   if x is self.default:
  x = self.data
   print x

This way you don't pollute the module namespace with class-specific
names. You pollute the class namespace instead - which seems like an
improvement.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Mike Meyer
[EMAIL PROTECTED] writes:

> Hello everybody!
> I have little problem:
>
> class A:
> def __init__(self, n):
> self.data = n
> def f(self, x = )
> print x
>
> All I want is to make self.data the default argument for self.f(). (I
> want to use 'A' class as following :

Store your default value in a container, and test for it:

class A:
_data = [None]
def __init__(self, n):
self._data = [n]
def f(self, x = _data):
if x is self._data:
   x = x[0]
print x
  
There are lots of variations on this theme.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Benji York
bruno at modulix wrote:
 > Another solution to this is the use of a 'marker' object and identity 
test:
 >
 > _marker = []
 > class A(object):
 > def __init__(self, n):
 > self.data =n
 > def f(self, x = _marker):
 > if x is _marker:
 > x = self.data
 > print x

I'll add my 2 cents to the mix:

default = object()

class A(object):
 def __init__(self, n):
 self.data = n

 def f(self, x=default):
 if x is default:
 x = self.data
 print x
--
Benji York
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Gregory Petrosyan
Great thanks, Alex!

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Martin Miller
Alex Martelli wrote, in part:
> If it's crucial to you to have some default argument value evaluated at
> time X, then, by Python's simple rules, you know that you must arrange
> for the 'def' statement itself to execute at time X.  In this case, for
> example, if being able to have self.data as the default argument value
> is the crucial aspect of the program, you must ensure that the 'def'
> runs AFTER self.data has the value you desire.
>
> For example:
>
> class A(object):
> def __init__(self, n):
> self.data = n
> def f(self, x = self.data)
>  print x
> self.f = f
>
> This way, of course, each instance a of class A will have a SEPARATE
> callable attribute a.f which is the function you desire; this is
> inevitable, since functions store their default argument values as part
> of their per-function data.  Since you want a.f and b.f to have
> different default values for the argument (respectively a.data and
> b.data), therefore a.f and b.f just cannot be the SAME function object
> -- this is another way to look at your issue, in terms of what's stored
> where rather than of what evaluates when, but of course it leads to
> exactly the same conclusion.

FWIT and ignoring the small typo on the inner def statement (the
missing ':'), the example didn't work as I (and possibily others) might
expect.  Namely it doesn't make function f() a bound method of
instances of class A, so calls to it don't receive an automatic 'self''
argument when called on instances of class A.

This is fairly easy to remedy use the standard new module thusly:

import new
class A(object):
def __init__(self, n):
self.data = n
def f(self, x = self.data):
print x
self.f = new.instancemethod(f, self, A)

This change underscores the fact that each instance of class A gets a
different independent f() method.  Despite this nit, I believe I
understand the points Alex makes about the subject (and would agree).

-Martin

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Duncan Booth
Nicola Larosa wrote:

>> Using None might be problematic if None could be a valid argument.
> 
> That's like saying that NULL could be a significant value in SQL. In
> Python, "None" *is* the empty, not significant value, and should
> always be used as such. Specifically, never exchange "None" for
> "False". 
> 
You don't think there is a difference in SQL between a field explicitly set 
to NULL or a field initialised with a default value?

What you should be saying here is never use "None" when you actually mean 
"use the default non-None value for this parameter".
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread bruno at modulix
Dennis Lee Bieber wrote:
> 
> 
(snip)
> but that may not be desirable if None is a valid value => myA.f(None),
> so...
> 
> class A(object):
> def __init__(self, n):
> self.data =n
> def f(self, *arg):
> if len(arg) == 0:
> x = self.data
> else:
> x = arg[0]
> print x

Another solution to this is the use of a 'marker' object and identity test:

_marker = []
class A(object):
def __init__(self, n):
self.data =n
def f(self, x = _marker):
if x is _marker:
x = self.data
print x


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Alex Martelli
Gregory Petrosyan <[EMAIL PROTECTED]> wrote:
   ...
> def f(self, x = self.data)   (*)
   ...
> So I think (*) is the best variant, but it doesn't work :(

It DOES work -- it just does not work the way you _expect_ it to work,
but rather, it works the way it's _defined_ to work.

Specifically: all the evaluation of default arguments' values happens as
a part of the execution of the 'def' statement, and so, in particular,
happens at the TIME 'def' is executing.

A 'def' statement which is at the top level in a 'class' statement
evaluates as part of the evaluation of 'class'.

So, if, *while the 'class' statement is evaluating*, something known as
'self' exists, and has a 'data' attribute, this will give you the
default value for argument 'x'.  If the name 'self' is unknown, or
refers to an object which has no 'data' attribute, then of course
appropriate exceptions get raised (NameError or AttributeError) when
Python is TRYING to execute that 'def' statement.

Here's an example in which this works without exceptions:

class outer(object):
def __init__(self, data): self.data = data
def make_inner(self):
class inner(object):
def f(self, x=self.data):
print x
return inner()

Now, y = outer(23).make_inner() gives you an instance of an inner class,
such that y.f() is the same thing as y.f(23).  The 'self.data' in the
'def f', since it's the evaluation of a default value for an argument,
evaluates at the time 'def' evaluates -- and, at that time, 'self'
refers to the instance of class outer that's the only argument to method
make_inner of class outer.

While such "factories" (classes and functions making and returning other
classes and functions) are rarely used by beginners, they are an
extremely important idiom for advanced users of Python.  But the point
is that, by having extremely simple and universal rules, it takes no
exoteric knowledge to understand what the above Python code will do --
default argument values evaluate as 'def' executes, therefore there is
absolutely no ambiguity or difficulty to understand when this
'self.data' in particular evaluates.

If Python tried to guess at when to evaluate default argument values,
sometimes during the 'def', sometimes abstrusely storing "something"
(technically a 'thunk') for potential future evaluation, understanding
what's going on in any given situation would become extremely
complicated.  There are many languages which attempt to ``helpfully''
"do what the programmer meant in each single case" rather than follow
simple, clear and universal rules about what happens when; as a
consequence, programmers in such "helpful" languages spend substantial
energy fighting their compilers to try and work around the compilers'
attempted "helpfulness".

Which is why I use Python instead.  Simplicity is a GREAT virtue!


If it's crucial to you to have some default argument value evaluated at
time X, then, by Python's simple rules, you know that you must arrange
for the 'def' statement itself to execute at time X.  In this case, for
example, if being able to have self.data as the default argument value
is the crucial aspect of the program, you must ensure that the 'def'
runs AFTER self.data has the value you desire.

For example:

class A(object):
def __init__(self, n):
self.data = n
def f(self, x = self.data)
 print x
self.f = f

This way, of course, each instance a of class A will have a SEPARATE
callable attribute a.f which is the function you desire; this is
inevitable, since functions store their default argument values as part
of their per-function data.  Since you want a.f and b.f to have
different default values for the argument (respectively a.data and
b.data), therefore a.f and b.f just cannot be the SAME function object
-- this is another way to look at your issue, in terms of what's stored
where rather than of what evaluates when, but of course it leads to
exactly the same conclusion.

In practice, the solutions based on None or sentinels that everybody has
been suggesting to you are undoubtedly preferable.  However, you can, if
you wish, get as fancy as you desire -- the next level of complication
beyond the simple factory above is to turn f into a custom descriptor
and play similar tricks in the __get__ method of f (after which, one can
start considering custom metaclasses).  Exactly because Python's rules
and building blocks are simple, clean, and sharp, you're empowered to
construct as much complication as you like on top of them.

That doesn't mean you SHOULD prefer complication to simplicity, but it
does mean that the decision is up to you.


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Gregory Petrosyan
Thanks a lot, but that's not what I do really want.
1) f() may have many arguments, not one
2) I don't whant only to _print_ x. I want to do many work with it, so
if I could simply write

def f(self, x = self.data)   (*)

it would be much better.

By the way, using

class A(object):
data = 0

def f(self, x = data)

solves this problem, but not nice at all

So I think (*) is the best variant, but it doesn't work :(

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread bruno at modulix
[EMAIL PROTECTED] wrote:
> Hello everybody!
> I have little problem:
> 
> class A:
> def __init__(self, n):
> self.data = n
> def f(self, x = )
> print x
> 
> All I want is to make self.data the default argument for self.f(). (I
> want to use 'A' class as following :
> 
> myA = A(5)
> myA.f()
> 
> and get printed '5' as a result.)
> 

class A(object): # Stop using old-style classes, please
  def __init__(self, n):
self.data = n
  def f(self, x = None):
if x is None:
  x = self.data
print x



-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Nicola Larosa
> Using None might be problematic if None could be a valid argument.

That's like saying that NULL could be a significant value in SQL. In
Python, "None" *is* the empty, not significant value, and should always be
used as such. Specifically, never exchange "None" for "False".

-- 
Nicola Larosa - [EMAIL PROTECTED]

...Linux security has been better than many rivals. However, even
the best systems today are totally inadequate. Saying Linux is
more secure than Windows isn't really addressing the bigger issue
 - neither is good enough. -- Alan Cox, September 2005
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Gregory Petrosyan
I want to find REALLY NICE AND PYTHONIC solution (if any)

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Bill Mill
On 11/15/05, Nicola Larosa <[EMAIL PROTECTED]> wrote:
> > def f(self, x=None):
> > if not x:
>
> Ha! You fell for it! ;-D
> (Hint: what about x being passed with a value of zero? :-) )

I wasn't sure if you saw my post before you posted - good call. I just
tossed off an answer without thinking much, and we see the result. It
could have been a good debugging lesson for him if he'd tried to pass
0; I think I'll use that as my excuse.

Peace
Bill Mill
bill.mill at gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list


Default method arguments

2005-11-15 Thread gregory . petrosyan
Hello everybody!
I have little problem:

class A:
def __init__(self, n):
self.data = n
def f(self, x = )
print x

All I want is to make self.data the default argument for self.f(). (I
want to use 'A' class as following :

myA = A(5)
myA.f()

and get printed '5' as a result.)

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Duncan Booth
Nicola Larosa wrote:
> # use new-style classes, if there's no cogent reason to do otherwise
> class A(object):
> def __init__(self, n):
> self.data = n
> def f(self, x = None)
> # do NOT use "if not x" !
> if x is None:
> print self.data
> else:
> print x
> 

Using None might be problematic if None could be a valid argument. The 
safest way all round is to use a unique object created just for this 
purpose:

_marker = object()

class A(object):

def __init__(self, n):
self.data = n

def f(self, x=_marker)
if x is _marker:
x = self.data
print x
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Nicola Larosa
> def f(self, x=None):
> if not x:

Ha! You fell for it! ;-D
(Hint: what about x being passed with a value of zero? :-) )

> x = self.data
> print x

-- 
Nicola Larosa - [EMAIL PROTECTED]

...Linux security has been better than many rivals. However, even
the best systems today are totally inadequate. Saying Linux is
more secure than Windows isn't really addressing the bigger issue
 - neither is good enough. -- Alan Cox, September 2005
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Nicola Larosa
> I have little problem:
> 
> class A:
> def __init__(self, n):
> self.data = n
> def f(self, x = )
> print x
> 
> All I want is to make self.data the default argument for self.f(). (I
> want to use 'A' class as following :
> 
> myA = A(5)
> myA.f()
> 
> and get printed '5' as a result.)

# use new-style classes, if there's no cogent reason to do otherwise
class A(object):
def __init__(self, n):
self.data = n
def f(self, x = None)
# do NOT use "if not x" !
if x is None:
print self.data
else:
print x

-- 
Nicola Larosa - [EMAIL PROTECTED]

...Linux security has been better than many rivals. However, even
the best systems today are totally inadequate. Saying Linux is
more secure than Windows isn't really addressing the bigger issue
 - neither is good enough. -- Alan Cox, September 2005
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Default method arguments

2005-11-15 Thread Bill Mill
On 15 Nov 2005 08:03:26 -0800, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hello everybody!
> I have little problem:
>
> class A:
> def __init__(self, n):
> self.data = n
> def f(self, x = )
> print x
>
> All I want is to make self.data the default argument for self.f(). (I
> want to use 'A' class as following :
>
> myA = A(5)
> myA.f()
>
> and get printed '5' as a result.)
>

class A:
def __init__(self, n):
self.data = n

def f(self, x=None):
if not x:
x = self.data
print x

>>> myA = A(5)
>>> myA.f()
5

Peace
Bill Mill
bill.mill at gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list