On Wed, Feb 3, 2010 at 12:00 PM, "Martin v. Löwis" <mar...@v.loewis.de> wrote:
>>> That will raise a TypeError in 2.6 but works in 2.7.  Is it appropriate and
>>> feasible to back port that to Python 2.6?  I remember talking about this a
>>> while back but I don't remember what we decided and I can't find a bug on 
>>> the
>>> issue.
>> I don't know about feasible but I think it's (borderline) appropriate.
> I fail to see the point there as well. There will be about two more 2.6
> releases until we stop fixing bugs in it, and start recommending 2.7.
> So who would be helped if such a feature would be added to 2.6?

Presumably the people who asked for it want it. Regardless of what you
(or I) recommend, 2.6 will be in use for a long time.

>> There are various other paths that lead to this error and it feels to
>> me it's just a long-standing bug that we never took care of until 2.7.
>> However, I don't think it needs to support non-ASCII characters in the
>> keywords (even though 2.7 does seem to support those).
> Is it really necessary to ban them?

No, that's not what I meant -- I just meant that it wasn't necessary
to support non-ASCII if it would in any way complicate the patch.

> In the regular keyword argument
> syntax (arg=value), the lexer will reject them. If you pass them through
> a dictionary, why go through the dictionary and ban those that you don't
> like? If the callee also uses the **kw syntax, they may actually be able
> to receive them.
> Notice that this works also in 2.5:
> py> def foo(**kw):pass
> ...
> py> foo(**{'':None})
> py> foo(**{'\0':None})

OTOH a more conservative solution would convert the keywords to str
instances so that the receiving end (the body of foo) would never see
Unicode objects even while allowing (some) Unicode objects on the
sending end (foo's caller).

--Guido van Rossum (python.org/~guido)
Python-Dev mailing list

Reply via email to