[Python-porting] future newdict kwargs result in bytes

Buck Golemon buck.2019 at gmail.com
Mon May 19 17:42:42 CEST 2014


Yes, I'd expect the keys to be newstr, since that would match python3
behavior.

Here's my udict:


def udict(*args, **kwargs):
    """Similar to dict(), but keyword-keys are text.
    TODO: refactor out udict in favor of future.newdict
    """
    kwargs = dict([
        (u(key), val)
        for key, val in kwargs.items()
    ])

    return dict(*args, **kwargs)



On Mon, May 19, 2014 at 4:30 AM, Ed Schofield <ed at pythoncharmers.com> wrote:

>
> On 14 May 2014, at 3:40 am, Buck Golemon <buck.2019 at gmail.com> wrote:
>
> As I understand it, the contract of future.builtins is to act like the
> python3 builtins, but this behavior is distinctly python2-ish (and
> necessitates me to write my own `udict`).
>
> >>> dict
> <class 'future.builtins.types.newdict.newdict'>
> >>> type(tuple(dict(a=1).keys())[0]).mro()
> [<type 'str'>, <type 'basestring'>, <type 'object’>]
>
>
> Hi Buck,
>
> Yes, the type of ‘a’ is a native string. This seems to be what Python does
> when passing a kwarg to a function. Can you think of a way around this?
>
> What would you prefer to happen instead? Would you prefer for
> ``dict(a=1)`` to give you a dict with a ``newstr`` as the key? What is the
> application you have in mind?
>
> I would be interested in seeing your ``udict`` class to consider whether
> ``future.types.newdict`` can be modified to meet this need.
>
> Best wishes,
>     Ed
>
>
>
>
> --
> Dr. Edward Schofield
> Python Charmers
> http://pythoncharmers.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-porting/attachments/20140519/7c732c91/attachment.html>


More information about the Python-porting mailing list