Does anybody else find {:} and {} be a more natural way to construct empty dictionary and empty set as compared to {} and set()? Thanks.
views:
158answers:
4
+1
A:
It's not really backward-compatible - {} is already used everywhere. As everybody is used to the existing syntax, I wouldn't say {:} is a more natural way of constructing a dictionary (having a short form for empty sets would be nice, but set() isn't too verbose, either).
Alexander Gessler
2010-02-17 22:48:33
{} => {:} is the type of thing that 2to3 already does, so it would be possible to do it in 3to4 if the syntax change was going to happen
gnibbler
2010-02-18 01:35:41
Agreed, but it will just add another source of confusion. Thinking of thousands of python tutorials, book, samples, ...
Alexander Gessler
2010-02-18 01:40:23
Perhaps once more platforms support Unicode, `∅` could be an alternative notation for `set()`.
dan04
2010-08-15 04:24:25
dan04: I prefer to code in a language that only uses characters that are on my keyboard. Since it's unlikely that the empty-set character will ever become popular on keyboards, I think it's better to use the ASCII way of writing it (`set()` or `(/)`).
Gabe
2010-08-15 04:31:47
@dan, that symbol, even if to be used, only makes sense for an empty set, but not for a set.
Hamish Grubijan
2010-08-15 13:54:34
+2
A:
- Not really, personally.
{}has too long a history as an empty dict literal and while I see where you are coming from,{:}shouldn't really mean empty dict. - 3.3 would not be the right target version for this change. This would break backwards compatibility in a nontrivial way, which is not supposed to happen. (If it ever does, that should be Python 4.0.) This is especially not the proper target version since Python is currently under a syntax-change moratorium.
Mike Graham
2010-02-17 22:50:57
I shall hope that Python will stop breaking core backwards-compatibility for good now that they've seen what a horrible mess they created with Python 3.
Glenn Maynard
2010-02-18 02:40:11
+3
A:
It seems sensible enough, but that probably isn't enough to justify breaking backward compatiblity.
Perhaps if it was accepted for Python4 there could be a from __future__ to change the behaviour of {} in Python3 at a per module level.
Having {:} create empty dicts in the meantime would probably not be too harmful
gnibbler
2010-02-17 22:51:08
I doubt you'd get away with it, since it'd never actually get added to a future version. `__future__` is not the place for enabling more than one way to do the same thing, it's for allowing you to write forward-thinking code etc. and take advantage of new/upcoming features, without forcing everyone's code to break due to changed syntax/semantics.
Devin Jeanpierre
2010-02-17 23:22:15
@Devin Jeanpierre, Yes I agree, it is unlikely to ever change even in 4 so it shoudn't go into `__future__`. I reworded my answer.
gnibbler
2010-02-17 23:26:31
A:
Not really. You'd still have an ugly special case in the syntax, just move the specialness from the empty set to the empty dict.
The logical solution would be to change either set or dict to use different brackets. But to what? ( ) and [ ] are already taken.
And such a backwards-incompatible change wouldn't be approved for 3.3. You'd have to wait for 4.0.
dan04
2010-08-15 04:25:26
`<>` wouldn't introduce backwards compatibility if it was used for sets.
aaronasterling
2010-08-15 05:25:20
In fact, `<>` would collide with the still valid in Python 2.X alternative syntax for `!=`.
Muhammad Alkarouri
2010-08-15 12:52:10
Why do you think that `{:}` is an ugly special case? It is not a valid syntax for a set. Also, math notation for an empty set is `{}`, but dictionaries are only part of CompSci. Now, `<>` looks too much like a template/generic in other languages. Of course, one can get used to anything. All my opinions.
Hamish Grubijan
2010-08-15 13:42:02
A special case because a `dict` literal would no longer be `'{%s}' % ', '.join('%r: %r' % kv for kv in D.items())`.
dan04
2010-08-15 17:29:12
@dan04, I am not sure where that expression is used; please elaborate. Is it limited to certain version(s) of Python only?
Hamish Grubijan
2010-08-16 16:55:29