i honestly don’t see the problem here.
if people are too lazy to find a input method that works for them (Alt Gr, compose key, copy&paste), they should just continue to type ASCII, and leave the more elegant unicode variants for others.
this violates TSBOOWTDI, but as there’s also dict()
next to {}
, this should neither be a problem.
i like scala’s way to allow both <-
and ←
, as well as =>
and ⇒
, and so on. ∅ and λ seem like good ideas to me as un-redefinable empty set literal and shorter/more elegant lambda. And “…” for “Ellipsis”.
there’s also ∀, ¬, ×, ∧,∨, ∩, ∪, ∈, ∉, ≠, ≡, ≤, and ≥, but i think those are a bit much:
my_set = ∅
my_set ∪= other_set
my_set = map(λ e: e × 5, my_set ∩ third_set)
∀ spam ∈ my_set:
if spam ≡ None ∨ spam ≤ 8:
print(spam ∉ allowed_values, ¬ spam)
vs.
my_set = ∅
my_set &= other_set
my_set = map(λ e: e * 5, my_set | third_set)
for spam in my_set:
if spam is None or spam <= 8:
print(spam not in allowed_values, not spam)
There's one more, even more obvious (IMO) option for an empty set literal: U+2205, EMPTY SET. But that opens a whole other can of worms, namely expanding the grammar to allow Unicode characters outside of identifiers.but that ship has sailed.[:] = ordered dict, (:) = named tuple, {:} = dict[] = list; () = tuple, {} = setif i’d develop a language from scratch, i’d possibly use the following empty literals:of course it’s ugly, but it’s also obvious that it had to be suggested, because it’s the only obvious idea.which leaves us with either a non-obvious idea or no empty set literal, which is a bit sad and inconsistent.
2014-06-10 18:39 GMT+02:00 Guido van Rossum <guido@python.org>:No. Jeez. :-(--Guido van Rossum (python.org/~guido)On Tue, Jun 10, 2014 at 9:25 AM, Ryan Gonzalez <rymg19@gmail.com> wrote:
+1 for using {,}.On Tue, Jun 10, 2014 at 4:07 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
Victor Stinner wrote:2014-06-10 8:15 GMT+02:00 Neil Girdhar <mistersheik at gmail.com>:Perhaps {,} would be a possible spelling. For consistency you might want to allow (,) to create an empty tuple as well; personally I would find that more intuitive that (()).> I've seen this proposed before, and I personally would love this, but my > guess is that it breaks too much code for too little gain. > > On Wednesday, May 21, 2014 12:33:30 PM UTC-4, Frédéric Legembre wrote: >> >> >> Now | Future | >> ---------------------------------------------------- >> () | () | empty tuple ( 1, 2, 3 ) >> [] | [] | empty list [ 1, 2, 3 ] >> set() | {} | empty set { 1, 2, 3 } >> {} | {:} | empty dict { 1:a, 2:b, 3:c } Your guess is right. It will break all Python 2 and Python 3 in the world. Technically, set((1, 2)) is different than {1, 2}: the first creates a tuple and loads the global name "set" (which can be replaced at runtime!), whereas the later uses bytecode and only store values (numbers 1 and 2). It would be nice to have a syntax for empty set, but {} is a no-no.Wichert._______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/--
RyanIf anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
--
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/