[Python-3000] Dict literal bytecode

[Adam Olsen]

On Wed, Mar 26, 2008 at 9:18 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>
> On Tue, Mar 25, 2008 at 5:06 PM, Adam Olsen <rhamph at gmail.com> wrote:
>  > On Tue, Mar 25, 2008 at 2:43 PM, Alexander Belopolsky
>  >
>  > <alexander.belopolsky at gmail.com> wrote:
>  >
>  > > On Tue, Mar 25, 2008 at 4:26 PM, Adam Olsen <rhamph at gmail.com> wrote:
>  >
>  > >  >  It does not even have to be a frozenset.  A set works just as well,
>  >  >  >  never modified by the produced bytecode.
>  >  >
>  >  >  With the current implementation, precomputed constants must be
>  >  >  hashable because the compiler uses a dictionary lookup in order to
>  >  >  eliminate duplicates.  This is of course just an implementation
>  >  >  detail, but it would actually be hard to work around it.
>  >
>  >  Only builtin types with literal syntax may be deemed "constant"
>  >  anyway.  I fail to see how that's relevant to my frozenset vs set
>  >  comment.
>
>  I realized that right after I hit the "send" button, so my comment
>  about optimizing
>  frozenset({...}) was wrong.  With respect to frozenset vs set comment,
>  I understand
>  your proposal as transforming current
>
>  >>> dis(lambda: i in {1,2,3})
>   1           0 LOAD_GLOBAL              0 (i)
>
>               3 LOAD_CONST               0 (1)
>               6 LOAD_CONST               1 (2)
>               9 LOAD_CONST               2 (3)
>              12 BUILD_SET                3
>              15 COMPARE_OP               6 (in)
>              18 RETURN_VALUE
>
>
>  to
>
>   1           0 LOAD_GLOBAL              0 (i)
>               3 LOAD_CONST               3 ({1, 2, 3})
>               6 COMPARE_OP               6 (in)
>               9 RETURN_VALUE
>
>  This will not work because {1, 2, 3} is not hashable, but it should be
>  possible to do
>
>   1           0 LOAD_GLOBAL              0 (i)
>               3 LOAD_CONST               3 (frozenset({1, 2, 3}))
>               6 COMPARE_OP               6 (in)
>               9 RETURN_VALUE

Ahh, I see!  It's "safe" to use a set, but it internally gets stuck in
a dict to intern it, which a set doesn't allow.  Fixable, but
annoying.


>  On the other hand, our dialog is increasingly off-topic.  My original
>  question was whether or not it will be a good idea to unify how set
>  and dict literals are processed.  Please comment on the following
>  options:
>
>  1. Do nothing: dicts are built incrementally, and sets in batch.
>  2. Implement batch processing for dict literals.
>  3. Implement incremental processing for sets.
>
>  My order of preference is 2, 1, 3.

IMHO, just go ahead with 2.

-- 
Adam Olsen, aka Rhamphoryncus