__iadd__ and fellows missing (Python 2.2)

[Mike C. Fletcher]

Rather than confuse Tim further with abstract samples of where I want to 
define a "NULL" default argument, here's a particular example of where 
the "NULL pattern" I've described is used:

NULL = []

class BasicProperty (property):
...
	def __init__( self, name, documentation = "", bounds = (), 
defaultValue=NULL, defaultFunction=NULL ):
...
		if defaultValue is not NULL:
			self.defaultValue = defaultValue
		elif defaultFunction is not NULL:
			self.defaultFunction = defaultFunction

Now, I want to store/define defaultValue only if defaultValue is 
explicitly specified (same for defaultFunction).

I _could_ (as you suggest) use namedarguments and require that the user 
name the arguments explicitly.  However, when I do that, the 
defaultValue and defaultFunction arguments don't show up in the user's 
call-tip window using Python IDEs.  (And I dislike the aesthetics of 
using **namedarguments when all acceptable names are known anyway :) ).

As for the "designed purpose of default arguments" :) .  I see the value 
"no value/not specified" as a perfectly suitable default value.  Sure, 
it may offend your sensibilities, but when has that stopped me in the 
past ;) .

As for the brittle-ness.  Yes, it's a problem, especially if someone 
decides to implement copy-on-write semantics for lists some day (so that 
different lists could have the same id).  Of course, when you do that, 
all hell will break loose with code everywhere crashing and burning, we 
all know how much you like to party ;) :) .  For now, I'll switch the 
pattern over to using Singleton objects I suppose.  I don't think even 
you're planning to optimise away instance identity any time soon.

Okay, enough, I'm getting back to work :) .  Enjoy,
Mike



Tim Peters wrote:
> [Mike C. Fletcher]
> 
>>I was unaware that there was no guarantee for 0-length tuples always
>>being unique objects.  There are lots of places in my code where I use
>>0-length tuples in this pattern:
>>
>>NULL = ()
>>
>>class A:
>>	def b( self, object=NULL ):
>>		if object is NULL:
>>			#was not specified
>>		elif object is None:
>>			#specified to be object None
> 
> 
> Mike, I'm pretty lost.  Are you saying that if a user explicitly calls
> 
>     A().b(())
> 
> or
> 
>     A().b((1, 2, 3)[2:2])
> 
> you *want* to hit the "was not specified" block?  That's all a guarantee
> about 0-length tuples would buy you.  But if it's not what you want, such a
> guarantee is irrelevant:  the method is full of holes regardless of whether
> the empty tuple is unique.
> 
> Note that default arguments aren't designed to tell you whether a specific
> argument was explicitly passed.  They're designed to supply reasonable
> defaults that a user could just as well pass explicitly if they feel like
> it.  Rather than invent more brittle tricks, I suggest pondering whether the
> intended use of this gimmick isn't good enough for your purposes (and noting
> that it's always been good enough for mine).
> 
> If you really need to know whether a thing was passed explicitly, it makes
> more sense to insist that specifying it be done via keyword, and write the
> function to examine the keys in the keyword dict passed to it.  It's all
> obvious then.
> 
>     def f(required, **kw):
>         if 'abc' in kw:
>             print "'abc' was explicitly passed"
>             abc = kw['abc']
>         else:
>             print "'abc' was not specified"
>             abc = 42
>         print "'abc' is", abc
> 
>     f(3)
>     f(3, abc=666)
> 
> 
> 


-- 
_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/