Christian Heimes wrote:
... The performance penalty is slime to nothing for the common case
Sorry, I love this typo.
-Scott
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
Terry Reedy schrieb:
>> The first time a non str object is inserted or looked up, the dict
>> swiches to a more general lookup methods.
>
> This makes adding a string-only dict pretty trivial, if desired.
It's not as trivial as it seems. The switch over to the general lookup
method happens when a
Christian Heimes wrote:
Nick Coghlan wrote:
Generally speaking, Python namespace dictionaries (be it globals(),
locals(), the __dict__ attribute of an instance or a set of keyword
arguments) aren't required to enforce the use of legal identifiers (in
many cases, the CPython variants don't even e
> How are we going to handle str subclasses and unicode?
"Are we going to"? You mean, the current code is not good enough? Why not?
> Should we allow
> all subclasses of basestring? Or just str and unicode? Or str only?
In 2.x, str only, in 3.x, unicode only.
Regards,
Martin
___
Guido van Rossum schrieb:
> I'd prefer a compromise -- the keys should be strings, but should not
> be required to be valid identifiers. All Python implementations should
> support this. Rationale: a type check is cheap, and using strings
> exclusively makes the use of a faster dict implementation
Nick Coghlan wrote:
> Generally speaking, Python namespace dictionaries (be it globals(),
> locals(), the __dict__ attribute of an instance or a set of keyword
> arguments) aren't required to enforce the use of legal identifiers (in
> many cases, the CPython variants don't even enforce the use of s
I'd prefer a compromise -- the keys should be strings, but should not
be required to be valid identifiers. All Python implementations should
support this. Rationale: a type check is cheap, and using strings
exclusively makes the use of a faster dict implementation possible. A
check for a conforming
Michael Haggerty wrote:
> 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?
Generally speaking, Python namespace dictionaries (be it globals(),
locals(), the __dic
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
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 i
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 string
11 matches
Mail list logo
