[Python-3000] sets in P3K?

[Raymond Hettinger]

Greg Wilson wrote:

>I'm sure we can work something out --- I agree, {} for empty set and {:}
>for empty dict would be ideal, were it not for backward compatibility. 
>

For the record, I am strong -1 on adding a custom syntax for sets.

IMO, most of the interesting uses of sets start with some external data 
source or some function which builds-up a dataset.  Accordingly, the 
notation should be biased toward construction from iterables rather than 
for writing hard-coded literals.  IOW, it is more important to be able 
to write set(data) than set(0,1,2).

Proposals for set syntax all have some problems.  It is a wart to invent 
a kludge to distinguish between an empty set and an empty dict with {} 
and {:}.  Also, it is not obvious whether {0,1,2} would construct a set 
or a frozenset.  In contrast, the current approach is unambiguous and 
completely clear even if you've been away from the language for a long 
time:   frozenset(range(3)). 

Further, punctuation approaches face uncomfortable choices with respect 
to iterables.  Would {range(3)} be allowed?  If not, then you've lost a 
key bit of functionality and imposed an arbitrary restriction.  If so, 
then do you allow something similar for dicts?  If not, then you've 
introduced another arbitrary inconsistency.  If so, then you face more 
challenges distinguishing between sets and dicts -- is {somegen()} a set 
or dict -- there are valid interpretations either way if somegen() 
returns tuples.

With the collections module, we can expect a few more datatypes to be 
added over time (with ordered dicts being the next most likely 
addition).  IMO, we gain greater consistency, learnability, and 
substitutability by sticking with uniform constructors not based on 
punctuation:   datatype(iterable). 

I understand the temptation to save five characters but think that would 
be a foolish savings, trading readability and clarity for brevity.  
Also, I concur with Alex's thought that it is a lost cause to twist 
ourselves into knots trying to emulate the high-school-whiteboard.

Likewise, I understand being bugged by bracketed set representation; 
however, it is unambiguous and not without precedent:  array('i', [0, 1, 
2, 3, 4, 5, 6, 7, 8, 9]).  IMO, adding punctuation will unnecessarily 
burden the learning curve.

IIRC, this was previously discussed and settled on python-dev.  Also, I 
believe similar thoughts were behind the effort to remove backticks as 
syntactic sugar for repr().

gratuitous-punctuation-is-the-road-to-hell-ly yours,


Raymond