[Python-3000] sets in P3K?

[Ron Adam]

Raymond Hettinger wrote:
> Greg Wilson wrote:
> 
>> One of the reasons I'd like native syntax for sets is that I'd like set
>> comprehensions:
>>
>>    a = {b for b in c where b > 0}
>>
>>
>>  
>>
> 
> This is no good.  That form could as easily represent a frozenset 
> comprehension or dict comprehension. It buys us nothing over the clear 
> and unambiguous form we have now:
> 
>    set(b for b in collection if b > 0)
> 
> Distinguishing between sets, frozensets, and dicts is an insurmountable 
> hurdle for punctuation based proposals (because you can't make the 
> distinctions without introducing complexity).  Besides, there are no 
> real gains to be had -- adding punctuation seems to have become a quest 
> unto itself.
> 
> Embrace genexps -- they are a path to uniform and clear expression 
> across a wide range of datatypes.
> 
> Avoid punctuation and funky syntax -- they burden the learning curve, 
> they do not generalize well, they challenge parsers (both human and 
> electronic), and they throw-away the clarity affored by spelled-out 
> datatype names.

I agree with Raymond on these points, but maybe not for the same 
reasons.  Punctuation can be clear *if* it has a strong underlying 
consistency.  This just isn't possible with the current data types 
without making quite a few changes that probably wouldn't be liked.

For example.  (not a suggestion)

     set   {}
     dict  {:}
     list  []
     ordered multi dict  [:]    ; *A

*A - Yes, this is ambiguous with slicing and the ordered multi-dict 
isn't a part of the language.

Then some way to indicate each of these is immutable or frozen would be 
needed, where a frozen list is equivalent to a tuple, but it then gets 
messy and looses the nice symmetry.  There just isn't enough symbols. 
And if there were, you wouldn't want to do more than a handful of types 
with shorthand syntax anyway.

I like being able to create data structures by explicitly typing them 
out. I also like being able to convert a repr() of a data structure back 
to it's original for simple data types.  But these are not big things I 
can live without. (and aren't the best way to do it in most cases)

The obvious (to me) kiss compromise would be to continue to let (), and 
[] be used as they are and have all other data types explicitly spelled out.

Since dict has a convenient creation syntax dict(a=val, b=val), I am ok 
with spelling it out.

It may also be possible to optimize named data types that have are all 
literals as components at compile time...  set(1,2,3), 
list('a','b','c'), etc...  Then it would be equivalent to using the 
shorthand forms in these cases.

Yes, these cause errors presently, but maybe they shouldn't.

Cheers,
    Ron