Calvin Spealman wrote:
> I would favor this not being constrained. I don't want every use of **
> to cause a pattern match to verify each key. I would even be fine
> without the check for being strings. Define what it should be, but let
> the implementation be lax. It is no different from any other place
> where you need to know its not a promise, just an artifact, and
> shouldn't rely on what the implementation currently does or does not
> force.
I agree. There was a similar issue in http://bugs.python.org/issue2598,
and we decided not to do anything about it.
Eric.
>
> On Thu, Feb 5, 2009 at 3:03 AM, Michael Haggerty <mhagger at alum.mit.edu> wrote:
>> I can't find documentation about whether there are constraints imposed
>> on the keys in the map passed to a function via **, as in f(**d).
>>
>> According to
>>
>> http://docs.python.org/reference/expressions.html#id9
>>
>> , d must be a mapping.
>>
>> test_extcall.py implies that the keys of this map must be strings in the
>> following test:
>>
>> >>> f(**{1:2})
>> Traceback (most recent call last):
>> ...
>> TypeError: f() keywords must be strings
>>
>> But must the keys be valid python identifiers?
>>
>> In particular, the following is allows by the Python 2.5.2 and the
>> Jython 2.2.1 interpreters:
>>
>> >>> f(**{'1':2})
>> {'1': 2}
>>
>> Is this behavior required somewhere by the Python language spec, or is
>> it an error that just doesn't happen to be checked, or is it
>> intentionally undefined whether this is allowed?
>>
>> Michael
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com
>>
>
>
>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4