RetroSearch Browse

Thu Mar 8 04:15:33 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-March/117416.html

On Thu, Mar 08, 2012 at 12:20:21PM +1000, Nick Coghlan wrote:
> On Thu, Mar 8, 2012 at 11:42 AM, Benjamin Peterson <benjamin at python.org> wrote:
> > 2012/3/7 Victor Stinner <victor.stinner at gmail.com>:
> >> Can't we simply raise an error if the dict contains
> >> non-string keys?
> >
> > Sounds okay to me.
> 
> For 3.3, the most we can do is trigger a deprecation warning, since
> removing this feature *will* break currently running code. I don't
> have any objection to us starting down that path, though.

Could we make string-key-only dicts a public type instead of an 
implementation detail? I've used string-only keys in my code, 
and it seems silly to have to re-invent the wheel.

I don't care if it is a built-in. I don't even care if I have to do 
something gnarly like StringDict = type(type.__dict__), so long 
as doing so is officially supported.

(But "from collections import StringDict" would be better from the point 
of discoverability.)

-- 
Steven

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-March/117416.html below:

[Python-Dev] Non-string keys in type dict