What could 'f(this:that=other):' mean?

[Jonathan Fine]

Jeff Shannon wrote:
> Jonathan Fine wrote:
> 
>> Giudo has suggested adding optional static typing to Python.
>> (I hope suggested is the correct word.)
>>   http://www.artima.com/weblogs/viewpost.jsp?thread=85551
>>
>> An example of the syntax he proposes is:
>>  > def f(this:that=other):
>>  >     print this

<snip>

>> I'm going to suggest a different use for a similar syntax.
>>
>> In XML the syntax
>>  >  <element this:that='other'>
>> is used for name spaces.
>>
>> Name spaces allow independent attributes to be applied to an
>> element.  For example, 'fo' attributes for fonts and layout.
>> XSLT is of course a big user of namespaces in XML.
>>
>> Namespaces seems to be a key idea in allow independent
>> applications to apply attributes to the same element.
>> [...]
>> Here's an example of how it might work.  With f as above:
>>  > f(this:that='value')
>> {'that': 'value'}
> 
> 
> I fail to see how this is a significant advantage over simply using 
> **kwargs.  It allows you to have multiple dictionaries instead of just 
> one, that's all.  And as you point out, it's trivial to construct your 
> own nested dicts.

This argument could be applied to **kwargs (and to *args).  In other
words, **kwargs can be avoided using a trivial construction.

 >>> def f_1(**kwargs): print kwargs
...
 >>> f_1(a=3, b=4)
{'a': 3, 'b': 4}
 >>>
 >>> def f_2(kwargs): print kwargs
...
 >>> f_2({'a':3, 'b':4})
{'a': 3, 'b': 4}

(and in Python 2.3)
 >>> f_2(dict(a=3, b=4))
{'a': 3, 'b': 4}

f_1() is internally the same as f_2(), but the argument passing is
different.

Jeff, are you in favour of kwargs as a language feature?  If so, you
may wish to refine your argument.

(One can be in favour of kwargs and against my proposal.  That kwargs
is widely used, and my proposal would not be, is a good argument, IMO.)

I'll post some usage examples later today, I hope.


> Besides, Python already uses the concept of namespaces by mapping them 
> to object attributes.  Module references are a namespace, exposed via 
> the attribute-lookup mechanism.  This (IMO) fails the "there should be 
> one (and preferably only one) obvious way to do things" test.  The 
> functionality already exists, so having yet-another way to spell it will 
> only result in more confusion.  (The fact that we're borrowing the 
> spelling from XML does little to mollify that confusion.)


Here, I don't understand.  Could you give an example of two obvious ways
of doing the same thing, should my suggestion be adopted?

-- 
Jonathan
http://www.pytex.org