[Python-ideas] Literals call local constructors()?

[Franklin? Lee]

Nope, I retract what I said.


On Tue, Apr 15, 2014 at 3:02 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> On Apr 15, 2014, at 10:24, "Franklin? Lee" <leewangzhong+python at gmail.com>
> wrote:
>
> I think C Anthony is saying that he tried to make it happen, and it
> didn't, but he figured something else out, which is what is relevant to him
> here.
>
>
> What's the something else?
>
> It seems to me he was asking why hacking dict literals doesn't work
> (either from an implementation point of view or from a language design
> point of view) because he _hadn't_ figured it out. And that's what Chris
> Angelico answered (from both points of view).
>
> I am mostly sure he isn't arguing for the ability to hack dict literals
>
>
> On Tue, Apr 15, 2014 at 6:40 AM, Chris Angelico <rosuav at gmail.com> wrote:
>
>> On Tue, Apr 15, 2014 at 8:11 PM, C Anthony Risinger <anthony at xtfx.me>
>> wrote:
>> > This not working is unexpected, if considering the expectation literals:
>> >
>> > {..} and [...]
>> >
>> > ...translate to:
>> >
>> > dict(...) and list(...) [int(..) and str(..)]
>> >
>> > Why isn't/can't this be true?
>>
>> They don't. They translate into dict-creation bytecodes. In CPython:
>>
>> Python 3.5.0a0 (default:6a0def54c63d, Mar 26 2014, 01:11:09)
>> [GCC 4.7.2] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import dis
>> >>> def make_dict1():
>> ...     return {'hello':1, 'world':2}
>> ...
>> >>> def make_dict2():
>> ...     return dict(hello=1, world=2)
>> ...
>> >>> dis.dis(make_dict1)
>>   2           0 BUILD_MAP                2
>>               3 LOAD_CONST               1 (1)
>>               6 LOAD_CONST               2 ('hello')
>>               9 STORE_MAP
>>              10 LOAD_CONST               3 (2)
>>              13 LOAD_CONST               4 ('world')
>>              16 STORE_MAP
>>              17 RETURN_VALUE
>> >>> dis.dis(make_dict2)
>>   2           0 LOAD_GLOBAL              0 (dict)
>>               3 LOAD_CONST               1 ('hello')
>>               6 LOAD_CONST               2 (1)
>>               9 LOAD_CONST               3 ('world')
>>              12 LOAD_CONST               4 (2)
>>              15 CALL_FUNCTION          512 (0 positional, 2 keyword pair)
>>              18 RETURN_VALUE
>>
>> If you want the name dict to be looked up, look up the name dict.
>> Otherwise, code like this would be very VERY confusing:
>>
>> >>> def make_dict3():
>> ...     dict = {'hello':1, 'world':2}
>> ...     return dict
>> ...
>> >>> dis.dis(make_dict3)
>>   2           0 BUILD_MAP                2
>>               3 LOAD_CONST               1 (1)
>>               6 LOAD_CONST               2 ('hello')
>>               9 STORE_MAP
>>              10 LOAD_CONST               3 (2)
>>              13 LOAD_CONST               4 ('world')
>>              16 STORE_MAP
>>              17 STORE_FAST               0 (dict)
>>
>>   3          20 LOAD_FAST                0 (dict)
>>              23 RETURN_VALUE
>>
>> If that had to actually call dict(), it would raise UnboundLocalError
>> for something that doesn't seem to reference locals before assigning
>> to them. As it is, it's exactly the same as make_dict1 except that it
>> does a store/load unnecessarily.
>>
>> ChrisA
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140415/b675f758/attachment-0001.html>