[Python-3000] sets in P3K?

[Jim Jewett]

On 4/25/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> Greg Wilson <gvwilson at cs.utoronto.ca> wrote:
> > > On Tue, 25 Apr 2006, Raymond Hettinger wrote:

> > > 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.

> > Do you have any data to back up these assertions?  Something like
> > http://mail.python.org/pipermail/python-dev/2000-July/006427.html?

I think that actually provides some indirect evidence there.

In the abstract, there is nothing about "zip" to suggest a
crossproduct, but seeing it used with 3x2 somehow distracted people. 
It would probably have misdirected me, if the questions had been "What
does this mean?", rather than "What should this mean?", because I
would have been reluctant to say error.

The punctuation creates groups, but what to do with that group is just
like any other random association -- at best, it seems similar to
something you've seen before.

> Assuming programmer sanity, how can naming the data type in the
> construction of the data type be ambiguous?  Or really, how could
> learning a name be more difficult than learning a syntax?  It seems to
> be quite clear, if one bothers to read the name, precisely what is being
> constructed (assuming the reader understands what a 'set', 'frozenset',
> etc. is).

set, Set.
frozenset, frozen_set, FrozenSet, frozenSet, forzenset.

(I left in a typo, because I actually typed three of them while writing this.)

If you don't see frozenset (and I generally haven't, even with what it
effectively a literal constant), then you need to wonder whether or
not set is mutable.

And this all assumes that you know sets are collections (rather than
data binding functions) which can hold arbitrary objects.

{} seems less likely to hide something tricky, precisely because it is
anonymous.  Technically, this is a false confidence, but it can be
helpful anyhow.

> If list comprehensions didn't come first (and even though list
> comprehensions came first), I would argue that there should only be
> generator expressions.  If one wants a list comprehension, one should
> use list(genexp).

It isn't just about generators; it is also about literals.

"mixed feelings"

-jJ