On Sat, 18 Feb 2006 00:52:51 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Adam Olsen wrote:
>> Consider these two pieces of code:
>>
>> if key in d:
>> dosomething(d[key])
>> else:
>> dosomethingelse()
>>
>> try:
>> dosomething(d[key])
>> except KeyError:
>> dosomethingelse()
>>
>> Before they were the same (assuming dosomething() won't raise
>> KeyError). Now they would behave differently.
>
>I personally think they should continue to do the same thing,
>i.e. "in" should return True if there is a default; in the
>current proposal, it should invoke the default factory.
>
>But that's beside the point: Where is the real example
>where this difference would matter? (I'm not asking for
>a realistic example, I'm asking for a real one)
>
My guess is that realistically default_factory will be used
to make clean code for filling a dict, and then turning the factory
off if it's to be passed into unknown contexts. Those contexts
can then use old code to do as above, or if worth it can
temporarily set a factory to do some work. Tightly coupled
code I guess could pass factory-enabled dicts between each other.
IOW, no code should break unless you pass a factory-enabled dict
where you shouldn't ;-)
That said, maybe enabling/disabling could be separate from d.default_factory
(e.g., d.defaults_enabled) as that could allow e.g. foo(**kw) more options
in how to copy kw and what foo could do. Would total copy including defaulting
state
be best? What other copies must be sanitized? type('Foo',(), **{'this':'one?'})
It will be interesting to see what comes out of the woodwork ;-)
Regards,
Bengt Richter
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
