[Python-ideas] syntax for set

average dreamingforward at gmail.com
Wed Nov 24 05:15:25 CET 2010

On Mon, Nov 22, 2010 at 11:40 AM, Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:

> > I'd be happy with:
> >
> > * {:} for empty dict() (as a collection of key-value *pairs*)
> > * {.} for empty set() (as a similar collection of *single* elements)
> >
> > And {} for empty dict() as well -- to keep compatibility (maybe to be
> > deprecated later).
> I'm curious why you guys think you *need* an empty set literal.
> The current spelling using set() and frozenset() is unambiguous.
> So what's the point of trying to shoehorn-in a new literal?
> AFAICT, this discussion has been solely motivated by
> a shallow itch, "dicts have one, so sets have to have one too".

Because those forms (to the starting programmer especially) make it seem
like a second-class citizen.  That may seem a trivial objection, but those
"sensitive initial conditions" set up trajectories which have (eventually)
far-reaching consequences.  Separately, but along those lines,  if
mutability and immutability are frequent enough concerns, then perhaps some
thought should be given to how one might address that with a simple
syntactical or general, object-wise methodology.  Perhaps this thread is not
appropriate to pose the question, but should there be a general mutable bit
attached to any given object?

If there were a clean, beautiful, obvious correct answer,
> it would have already been done.   Since there isn't,
> we have to ask, who cares?
> No! there is a clean, beautiful, obvious correct answer!  The problem is
*only* backwards-compatibility.  That is why we care.

Cordially, in any case... :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20101123/01d9d306/attachment.html>

More information about the Python-ideas mailing list