PEP 802 – Display Syntax for the Empty Set
Posted by kirara0048@reddit | Python | View on Reddit | 262 comments
PEP 802 – Display Syntax for the Empty Set
https://peps.python.org/pep-0802/
Abstract
We propose a new notation, {/}
, to construct and represent the empty set. This is modelled after the corresponding mathematical symbol ‘∅’.
This complements the existing notation for empty tuples, lists, and dictionaries, which use ()
, []
, and {}
respectively.
>>> type({/})
<class 'set'>
>>> {/} == set()
True
Motivation
Sets are currently the only built-in collection type that have a display syntax, but no notation to express an empty collection. The Python Language Reference notes this, stating:
An empty set cannot be constructed with
{}
; this literal constructs an empty dictionary.
This can be confusing for beginners, especially those coming to the language from a scientific or mathematical background, where sets may be in more common use than dictionaries or maps.
A syntax notation for the empty set has the important benefit of not requiring a name lookup (unlike set()
). {/}
will always have a consistent meaning, improving teachability of core concepts to beginners. For example, users must be careful not to use set
as a local variable name, as doing so prevents constructing new sets. This can be frustrating as beginners may not know how to recover the set
type if they have overriden the name. Techniques to do so (e.g. type({1})
) are not immediately obvious, especially to those learning the language, who may not yet be familiar with the type
function.
Finally, this may be helpful for users who do not speak English, as it provides a culture-free notation for a common data structure that is built into the language.
riffito@reddit
That can't be a serious argument. The whole language keywords and all of the standard library API are in English, do we get localized or language neutral version of those next?
Just in case: I say this as a non-native speaker of English (heck, I'm even a non-speaker, I can only brokenly read/write it :-D).
Liledroit@reddit
Idk man, your written English doesn’t seem broken to me. You probably speak better than you think.
zaboron@reddit
Maybe he's German:
It's okay, friend. Learning a second language is difficult, but with enough practice and time you'll acquire the vernacular and colloquialisms to communicate in a concordant matter vis-à-vis other Germans. I myself still struggle with the endeavor of mastering the English language, ergo, I hope I have articulated myself in a proper manner.
https://linguisticsyall.tumblr.com/post/112360066764/me-speaking-german-to-a-german
WhiteHeadbanger@reddit
Most Germans I've met speak indistinguishable from native USA people. But, of course, I'm not native, so I may not collect the nuances of the language at a granular level.
met0xff@reddit
Even for me as a non-native speaker, German-accented English is usually very obvious (just like my Austrian English is obvious, no matter how hard I try ;)). I have an awesome colleague at my US company whose family moved from Germany to the US when he was a kid, I'd guess 30-40 years ago, and I'm regularly astonished how German his English still sounds.
Actually the accents are even different by region within Austria - compare the Styrian Arnold Schwarzenegger with Vienna-born Christoph Waltz. Depending on the region, the L might be a dead giveaway. Some regions in Austria have 3 different ways of pronouncing an L and some regions are quite famous for their Ls ;). In English we sometimes use them incorrectly or at least different :). I just recently realized that in English the Ls in"Holly" are not pronounced as in "wall" as we would at first assume. I recently saw an interesting discussion Reddit about the difference between v and w that I had a really hard time to discern acoustically. And a person there taught me that it's called hypercorrection what's often happening here. Our v is typically pronounced like the English f, our w usually like English v and we don't really have a w as in "water". So people start to learn the "English water w" and assume we also have to use it in "very". And yeah, after listening to a dozen YouTube vids I understood the difference, at least when I produce very vs water myself I can still hardly hear the difference just from hearing. But it seems for many English speakers this is very :) noticeable and confusing.
Back to the Germans... What is for example common in many regions in Germany is that the s is often used as a voiced fricative (use the vocal cords while pronouncing the s in for example "summer/Sommer"), which is typically one big identifying factor for Germans in Austria besides different vocabulary. And they usually bring their voiced /s/ into English as well.
Idk... I still remember my master's thesis advisor advised me to write the thesis in German because my English writing is "good but noticeable that it's not written by an English native". Luckily I ignored his advice lol. I mean, probably 80% (warning, random number) of English scientific publications out there are non-native English. It's absurd to not participate because of being non-native.
WhiteHeadbanger@reddit
I can't pick up those nuances. My mother language is Spanish, and I live in Argentina.
However I can pick up different English accents. Most notably, the Australian and UK accents are so different than US. But aside from those, the rest of them I may pick up but I don't know where they come from.
GrumpyPenguin@reddit
The thicker the Aussie accent, the less separation between words or strong inflections. “How is it going, love?” becomes “‘ow’zitgahnluv?!”. Heck, we infamously don’t even bother with half the vowels in “good day”. It makes it hard for non-native speakers to identify individual words in a sentence.
And that’s before you get into the weird contextual nuances of vague expressions like “mate!” or “yeah, nah” / “nah, yeah”.
WhiteHeadbanger@reddit
Do you say "gd dy" instead of "good day"?
Also, we have the "yeah, nah" or "nah, yeah" in spanish, and also the verb "to be" is a lot more broad and extensive.
Drevicar@reddit
This is not true. Most Germans speak way better English than most Americans.
Schmittfried@reddit
At least in terms of grammar. Their accent usually sucks.
WhiteHeadbanger@reddit
Lol, I can't say one way or the other.
zaboron@reddit
Yes that's exactly what the quote is trying to illustrate: Germans tend to apologize for poor English skills despite speaking nearly flawless English.
WhiteHeadbanger@reddit
Well I see that as being humble :)
drunkondata@reddit
Are you translating all the dunder methods?
All the built-in functions?
All the built-in modules?
Or are we just trying to prevent interacting with one three-letter English word? Still got to interact with the rest of the English words and the programming language, but at least now you don't need to type set.
riffito@reddit
I appreciate your kind words, fellow redditor. May your day end well!
CSI_Tech_Dept@reddit
Also an argument against it, is: try searching for
{/}
on google.PresidentOfSwag@reddit
git0ffmylawnm8@reddit
Frython?
tilalis@reddit
Le Puauxiton
DogsAreAnimals@reddit
I can think of at least 1.000 reasons why this argument could get complicated.
Remarkable_Kiwi_9161@reddit
Only 1 reason?
larsga@reddit
Depends on locale. That's 1,000 reasons in Norway.
DogsAreAnimals@reddit
very relevant user name
Remarkable_Kiwi_9161@reddit
What does it have to do with dogs being animals?
DogsAreAnimals@reddit
I'm referring to your username...
Remarkable_Kiwi_9161@reddit
What's the connection with kiwis?
WhiteHeadbanger@reddit
Well that depends on which kiwi
So, you tell me
twenty-fourth-time-b@reddit
As a member of marginalized communities, I must say I welcome this change. It will definitely lower the entry barrier for people like me.
Git renaming the m-word branch to “main” was widely celebrated and appreciated. That showed to the world that people whom it concerns the most actually do care.
We should have more diversity/inclusion-oriented features in programming languages.
DailyScrollinnn@reddit
Thats actually a solid point I never considered
tartare4562@reddit
As someone from a non-engish speaking country who has to deal with excel every day: please don't.
eXtc_be@reddit
as someone from a non-English speaking country who has to support Windows, Office and a bunch of other software packages in three languages: please bring back the days when all software was written in English. come to think of it, I wish the world would decide on a standard keyboard layout and stick with it.
AiutoIlLupo@reddit
They are not ok if they can't put some DEI garbage in it.
giyokun@reddit
I know it is easy for people to repudiate this argument with an off-hand comment, but I can tell you that people in countries where the alphabet is not the main writing system appreciate every bit of non-roman language they can avoid. Yes, the majority of the standard library is in English but sets being first-class objects would benefit from an empty set litteral just like [] and {}, "" etc. do for the other important structures out there. I know some programming schools in Japan have "japanized" libraries so that kids can reason and code in Japanese....
judasthetoxic@reddit
Dude what’s the problem? Like, if there is a way to use culture-free notation why not? I don’t get your point
KronenR@reddit
His point is obvious, since the rest of the code uses culture-dependent notation, adding one culture-free notation is irrelevant.
kleinpengin@reddit
"Why take a shower if you get dirty everyday?"
muntoo@reddit
"Why not needlessly increase the syntactic complexity of the language under the claim that we now only need 9999 words instead of 10000 words, unless a user uses the type hint
Set
, or looks at 'legacy' code, or wants to create afrozenset
err I meanfrozen{/}
, in which case we both increase the syntactic complexity of the language and continue to require the usage of 10000 different words?"aa-b@reddit
That's a good point, nice one. I would almost argue
{/}
should be frozen, sinceset()
is already quite short and it would be useful to have a shorthand to use as a default in a function signature. For when you want to distinguish null from a default value for a set-typed parameter.But that is obviously a bad idea (IMO, too confusing for non-experts), and I think it goes to show that you have to draw the line on language syntax somewhere. I mean I like C#, but that language's syntax has gotten way too noisy for the feature set it provides. Less of an issue now, but trying to google weird punctuation-based tokens was always a hassle.
KronenR@reddit
Because staying clean, even for a little while, still makes a difference. Changing one lightbulb in a dark room full of broken lamps does not.
Select-Breadfruit95@reddit
Ok, do you know what Go is? It's a language that removes any logical ambiguity from programming. Do you know what python is? It's s language that has 5+ ways to construct a list, we don't need one more!!!
riffito@reddit
I wasn't attacking the need or usefulness of an empty set literal (that's a whole different discussion).
I was just complain about using "this will help non-English speakers" as an argument in favor for this inclusion. Is just lazy and silly padding.
Let's just add some odd ("but culturally free!") notation! Now both native and non-native speakers alike have to deal with even more odd symbols.
KronenR@reddit
any symbol is culture free notation
DoubleAway6573@reddit
> : I say this as a non-native speaker of English (heck, I'm even a non-speaker, I can only brokenly read/write it :-D).
Are you me?
ship0f@reddit
and I thought this other one couldn't be a serious argument... (i doubt anyone is fine using list as a variable name just because they can use [])
anyway, now that i think about it, none of this seems of much importance (to me at least). i guess they have to keep improving the language, just like with the walrus operator...
have at it
thearctican@reddit
It’s less broken than anything on twitter or threads.
pip_install_account@reddit
Please don't, this is horrible. even a=§ would be less confusing. Also, shouldn't there be only one way to do something?
_Answer_42@reddit
{,}
seems betteromg_drd4_bbq@reddit
that looks like it could be a set of a tuple of something
KronenR@reddit
how can you define a tuple with a single comma?
_Denizen_@reddit
def f(): return 1, 2
A = f()
A == (1, 2)
KronenR@reddit
No, you can’t confuse
{,}
with a tuple. Your example is a function returning two values — it’s not “a single comma magically becoming a tuple,” and you can’t confuse{,}
withf()
._Denizen_@reddit
It's a function which returns a tuple of values...
The variable "A" is literally a tuple, and this outcome was technically achieved by a singla comma.
Furthermore, (1,) creates a tuple but (1) creates an int. Note that the comma is the difference here - it's an issue commonly encountered by new python users.
KronenR@reddit
Yeah, because
{,}
and (1, 2) are totally the same thing, and we can confuse them with sets lolcommy2@reddit
KronenR@reddit
Not sure how you could confuse
{,}
with(),
but… ok.commy2@reddit
I'm not arguing for any side here, I'm just showing off, because
(),
creating an empty tuple is not immediately obvious.HommeMusical@reddit
You are a fount of entertainment this morning.
TheWorstePirate@reddit
Python
KronenR@reddit
Nope
TheWorstePirate@reddit
Yeah, that was dumb on my part. You cannot.
BrisklyBrusque@reddit
dictionary with two null keys
Gugalcrom123@reddit
It's actually an empty dictionary
Deto@reddit
If that's an empty tuple does this syntax work already?
fiddle_n@reddit
Python 4 should have empty set as {} and empty dict as {:} . Don’t @ me.
Ikinoki@reddit
no, empty set should follow tuple notation {,}
Ihaveamodel3@reddit
How do we know that isn’t a set with an empty tuple in it?
Ikinoki@reddit
How do you know you are not a newt?
You can't define tuple with just , it throws syntax error
pmormr@reddit
That isn't really "tuple" notation though because the comma creates the tuple, not the parents. eg
test_tuple = ,
CanineLiquid@reddit
People who denote empty tuples with
test_tuple = ,
scare me.Ikinoki@reddit
Yeah this throws for me, just as (,)
shawnz@reddit
This makes way more sense to me
Sneyek@reddit
I’d actually like that. But we would definitely need a new major and quite some time to refactor. I’m not sure I’m ready yet for a new py2 to py3…
Toby_Wan@reddit
How would that require major refactoring? Wouldn't it just be a simple search and replace?
fiddle_n@reddit
You have to avoid things like {} in f strings or JSON string literals as part of your find and replace. You also can’t write code that is Python 3/4 compatible without, rather ironically, ditching the literals and using set() and dict().
Wonderful-Habit-139@reddit
What are you talking about? An empty {} is not valid in an fstring and you’d replace {}, not anything that starts with { and ends with } (for the json string literals part).
There’s code that would break for sure but the examples you gave could be better.
fiddle_n@reddit
Rather than f sting, I meant to say str.format string literal. {} is absolutely valid in those.
As for JSON strings, {} on its own is absolutely valid to denote an empty object.
Jubijub@reddit
I quite like it, although it would break A LOT of code
revonrat@reddit
Why? I would expect set() to still work. I hope the {/} syntax is optional.
alcalde@reddit
We're Python; we like doing that. Also, never forget that just as support for Python 2 ended, a plague swept the planet.
case_O_The_Mondays@reddit
The Python team has said multiple times that they won’t break things again, like 3 did. Pretty sure that’s why changing a new empty dictionary to
{:}
hasn’t been done, even though it makes the most sense, imo.alcalde@reddit
They can be replaced.
8day@reddit
I'll be damned, that actually makes sense.
rasm866i@reddit
I like it. looks kinda like ∅.
ziggomatic_17@reddit
That just tells me brain "diameter" lol
Drevicar@reddit
Or just don’t overload the squiggly brackets. Make the dictionary with <> or something.
CanineLiquid@reddit
Honestly, I feel like
<>
should have been used for typing Generics. Liketest: list<int> = [1, 2, 3]
Square brackets are already doing so many things, and I think it makes sense to use a set of characters for typing that otherwise have very little syntactic use in the language.
commy2@reddit
Could've easily used [key: value] for mappings, but I guess current Python matches JSON syntax which some people care about. Drop the set literals entirely too and now you have an entire type of brackets free for an entirely different purpose.
georgehank2nd@reddit
JSON didn't exist when Python got the duct literally syntax.
case_O_The_Mondays@reddit
That’s a cool bit of trivia.
tavianator@reddit
Python 4 should make dict equivalent to a set of
(k, v)
tuples so that{}
can be both an empty set and empty dictofficerthegeek@reddit
sure, I guess we don't need dicts anymore
case_O_The_Mondays@reddit
That’s just a doctrines view, no?
Gugalcrom123@reddit
There will be no more Python 4.
commy2@reddit
Windows 10 will be the last Windows
Gugalcrom123@reddit
Then what about
{*}
and{**}
?commy2@reddit
The first one looks like he spreading his cheeks to show me his anus.
case_O_The_Mondays@reddit
Yes, but each person’s anus is unique, so it makes perfect sense for declaring a new set!
aa-b@reddit
I'd guess they'll end up doing exactly what Firefox did: stuck on 3.x for so many years that they eventually just dropped the 3 and carried on like nothing happened
Gugalcrom123@reddit
Python minor versions aren't always fully backwards-compatible, but a redesign of the language isn't going to happen, probably.
mr_claw@reddit
thisismyfavoritename@reddit
whats the big deal with typing
set()
ordict()
for that matter_Denizen_@reddit
(), [], {} all make empty objects, and there was no equivalent for set. Seems to me to be an attempt at internal consistency.
Phi, ∅ is an empty set in maths. {/} is reminiscent of ∅. It makes logical sense.
I'm not sure why everyone is so opposed to this.
HommeMusical@reddit
When I write a sentence like that, I generally stop and think. "Perhaps everyone is right, and I'm not the lone voice of reason!"
/
.worthwhilewrongdoing@reddit
Oh god.
Go. Leave this thread immediately.
HommeMusical@reddit
Haha, thanks!
I didn't invent that, actually, it was someone else on this thread.
CanineLiquid@reddit
Oh no.
twigboy@reddit
Sir, this is Python.
Not all of us are mathematicians
_Denizen_@reddit
Same difference, in my experience
alcalde@reddit
They knew there wasn't internal consistency when they created the set type. They went and made it this way anyway.
_Denizen_@reddit
Revisiting past decisions is an indicator of a healthy development environment.
larsga@reddit
Yes and no. Any language change is a cost, and any addition to the language is also a cost.
It wouldn't really be a problem if the rate of change of the language (not the implementation) slowed to 10% of what it is now.
jaerie@reddit
{} is also an empty set in maths. (/) is reminiscent of ∅. There is no good argument for {/}. It does not look like ∅ when seen in python code, it looks like an empty dict with a slash in it, which is nonsensical.
_Denizen_@reddit
{} is an empty dict - redefining that would be hugely unpopular due to the headaches it would create.
{/} is clearly using standard set syntax with an operator. If you mistake it for a dict, that's user error.
larsga@reddit
In Python, but not in maths.
In maths, {1, 2, 3} is the set of ... you know. You can also write something like {x | x = 2i, where i ∈ {\displaystyle \mathbb {Z} }}.
So {} sort of is the empty set, although I've never seen it written that way.
jaerie@reddit
You're not reading my comment correctly if you feel the need to explain that {} is an empty dict. Read it more thoroughly please or ask what you don't understand about it.
larsga@reddit
∅ is not Phi. This is Phi: Φ
thisismyfavoritename@reddit
i understand the point of the PIP, i'm saying not having a shorthand with symbols isn't a big deal
jaerie@reddit
PEP*
We don't improve python, we only enhance it.
thisismyfavoritename@reddit
never too late
IllogicalLunarBear@reddit
why? what problem does this solve. do not do this
nekokattt@reddit
frozenset syntax when
erez27@reddit
{//}
muntoo@reddit
frozenfrozenset syntax when
commy2@reddit
Fun fact, the literal syntax associated with sets actually creates frozensets in case they are not returned or assigned a variable.
larsga@reddit
Whoa!
Well, that kind of changes things. That's definitely inconsistent.
Of course, changing the language so that:
doesn't help at all.
ZYy9oQ@reddit
That's gotta be cpython specific (but where it's impossible to tell at runtime, so the good version of this)
HommeMusical@reddit
TIL! Quite a surprise.
jaerie@reddit
{*}, because the * looks like a snowflake, which is frozen.
sunyata98@reddit
If you're a beginner and you see
x=set()
in a codebase, you probably will be less confused than if you were to seex={/}
PersonalityIll9476@reddit
Correct me if I'm wrong, but Python sets don't have a unique notation to begin with. If I write `test = set([1,2])` then the result of `__repr__` is the string `{1,2}`. So already we've overloaded dictionary notation on behalf of sets.
It almost seems like the real proposal should be to overhaul set notation writ-large. At any rate, I find `x = set()` to be very clear, much moreso than `x={/}` which could, at first glance, be some kind of weird dict.
muntoo@reddit
Improving notational consistency of
...is possibly the only actual positive benefit of
{/}
.njharman@reddit
Ok. Set's unique notation is (taken from Set documentation;
This is the set literal syntax grammer:
The only thing missing is, exactly what this pep means to address, the "empty set" literal syntax.
CanineLiquid@reddit
Not really? A non-empty dictionary has colons, sets do not. So I wouldn't call the notation overloaded, really.
If you do
test = dict()
the result of__repr__
is{}
. But if you dotest = set()
, then the result of__repr__
isset()
.gonna-see-riverman@reddit
I'm advanced and if i saw {/} i'd be super confused.
Maybe { , } would be more intuitive? kinda like the awkward comma in tuples of one (1, ).
But it's not much neater than just writing set().
Wonderful-Habit-139@reddit
Yeah this one is a bit better, and also easier to write.
newontheblock99@reddit
As a non-expert, I feel like this would be interpreted as some sort of dictionary than a set.
njharman@reddit
How about!
You had a good run, "There should be one way to do it." But they just couldn't stop themselves; and now you are gone.
AMartin223@reddit
The only option at this point other than do nothing is rust/python string style and prepend a letter. So d{} for dict, s{} for set, f{} for frozenset etc. Anything else just moves the confusion around
YtterbiJum@reddit
(6 keystrokes, all pinkies) shift-[-unshift-/-shift-]
{/}
🤮
(6 keystrokes, all different fingers) s-e-t-shift-9-0
set()
😁
Wonderful-Habit-139@reddit
When you type the opening brace, your ide should write the closing brace.
syklemil@reddit
I'm not certain I'd count releasing a key as a keystroke, but how come you don't use your thumb?
{
/
}
(some of us have som slight preference for Python because that saves us on the AltGr use. I've rebound some keys so I can do AltGr-æø instead to get {} because AltGr-numbers really is a reach, even for someone with big hands)
CanineLiquid@reddit
That's only for QWERTZ keyboard layouts, isn't it?
syklemil@reddit
Nope, this is QWERTY.
DogsAreAnimals@reddit
Hot take: if typing speed/efficiency is your bottleneck, you're doing something wrong.
I_Punch_My_Mom@reddit
I believe this is a critique focusing on UX, and not a complaint about how it affects his productivity, bud
DogsAreAnimals@reddit
How about: "If you're concerned about the number of unique fingers needed to input 6 keystrokes, you're doing something wrong"?
HommeMusical@reddit
I'm sitting here with a brace on my left hand, waving it at you to show why shift keys are hard on your hands.
I optimized my workflow so much that I almost never use the mouse, and my right hand is fine - but I use too many modifiers, at least partly due to emacs. Now I have a foot pedal for the modifiers, and I'm fine... until I drift back into bad habits...
floydmaseda@reddit
I can do it in 5 like a REAL coder:
shift-[-unshift-pause to wait for copilot to fill in the rest of the line... no I don't want a dict I want an empty set-/-pause again for copilot... ok yes now that's more like it-tab
revonrat@reddit
The comments on this post are doing a wonderful job of demonstrating why all the previous attempt to gain consensus failed. The pep has some history in the Rationale section:
Rationale
Sets were introduced to Python 2.2 via PEP 218, which did not include set notation, but discussed the idea of {-} for the empty set:
The PEP originally proposed {1,2,3} as the set notation and {-} for the empty set. Experience with Python 2.3’s sets.py showed that the notation was not necessary. Also, there was some risk of making dictionaries less instantly recognizable.
Python 3.0 introduced set literals (PEP 3100), but again chose not to introduce notation for the empty set, which was omitted out of pragmatism (python-3000, April 2006, python-3000, May 2006).
Since then, the topic has been discussed several times, with various proposals, including:
Changing {} to mean an empty set and using {:} for an empty dictionary (python-ideas, January 2008, Discourse, March 2023)
njharman@reddit
FWIW, I'm against PEP. I'm against all the empty literals [], (), {}. Always use list(), tuple(), dict(). These should be the pep8/ruff enforced default.
Consistent across all constructors. No confusion, as to what {} is; how to write empty set literal; why "()" is a tuple, but "(x)" is not, unless x happens to already be a tuple, but "x," with no parens is a tuple! [parens are do nothing, expression evaluation order groupers. The comma, ",", is the tuple literal syntax and is what creates a tuple. Unless of course the empty tuple which doesn't require a comma and is syntax error if you try].
"One way to do it" is wisdom beyond our comprehension. Its positive follow on effects are legion.
N3RO-@reddit
This is dumb, just dumb. There is nothing wrong with set() and your syntax proposal is terrible. Go use your time improving things that actually needs improvement.
MinuteMeringue6305@reddit
I am not native speaker, and please no
Ill-Look9810@reddit
I don’t mind to get syntax for empty set, I once when I am beginner confused between empty dictionary syntax ;) But I think {/} is very strange and awful, if I want to create empty dictionary I just type {}, empty list [] and empty string “”, but the provided syntax is not intuitive
ACont95@reddit
I’d almost prefer {…}
tehsilentwarrior@reddit
That’s horrible… why?!
And even if there’s a true need for it, why not something like “{..}”?
I am never going to use “{/}”.
syklemil@reddit
Can't we just use
Ø
as a keyword?Med vennlig hilsen,
Norge
kingminyas@reddit
I don't know how to type that
syklemil@reddit
It's easy, you just hit the
Ø
key. It's the key to the right of theL
key!kingminyas@reddit
How very unnecessary
TheStonningMan@reddit
IDK, there is already a very simple notation that exists :
empty_set = {i for i in ()}
(please don't ever use this)
kingminyas@reddit
{*()}
sluuuurp@reddit
What’s wrong with set()? If you don’t know and can’t learn the word “set” in English I think you’re going to have a hard time using python.
Jhuyt@reddit
set()
does a lot more work under the hood at runtime compared to using literals, which will compile to more efficient bytecode.kingminyas@reddit
If name lookup is your bottleneck you're using the wrong language
sluuuurp@reddit
What? Why? Can’t the interpreter easily see that the two methods are identical and use whichever one is faster?
jaerie@reddit
It has to do a name lookup for set() because it might have been dynamically overwritten. The literal token can't be overwritten and is directly compiled.
Does it matter in a practical (performance) context? Probably not, accidentally overwriting built ins is just something you have to deal with in python, and I doubt there is a real place where creating a set is a significant part of a hot path.
Do I think sets should have had better notation from the beginning to have parity with the other collections? Absolutely, but none of the proposed options achieve that parity outside of <>, but that's not remotely worth implementing imo.
Jhuyt@reddit
The performance difference before the specializing adaptive interpreter would have been quite large on a small hot loop if you compared
[]
andlist()
I reckon (depending on the size of the loop), but since the specializing interpreter and with the coming JIT the difference would likely be insignificant, unless maybe if you do something silly likevBut I haven't played much with the newer interpreter to know exactly how it'd do
jaerie@reddit
Yes but in any real code the loop would contain more than just the instantiation of an empty said. Like I said, "real place"
JJJSchmidt_etAl@reddit
Maybe but that's also true of
tuple()
ordict()
or evenlist()
for that mattersluuuurp@reddit
But those all live in symbols in a pair so it makes sense.
s-to-the-am@reddit
This seems like a bad option, I don’t know if there is a good one, but this is definitely a bad one.
bbolli@reddit
Yeah. Why not just use
∅
?qubidt@reddit
ansi keyboard doesn't have have a key for ∅
Deto@reddit
Maybe I'm just a cranky old man but I feel like the current way is fine
Temporary_Pie2733@reddit
I’m happy to wait until Unicode is less stigmatized and ∅ can be used for an empty set. It would be nice to have an empty set display but there’s no need to settle for an ASCII lookalike.
Qudit314159@reddit
The trouble is it's still PITA to type.
Temporary_Pie2733@reddit
In vim, you can type ctrl-k 0 /. Other decent editors could provide something similar. For something you wouldn’t need to type very often, that’s not very onerous.
Qudit314159@reddit
I'm aware but plain ASCII is still easier.
JJJSchmidt_etAl@reddit
Allowing unicode at all would be a huge leap, almost a new language. Everything so far is ascii.
danted002@reddit
The reason why everything is ASCII is because every char maps to a keystroke. Having unicode chars as language syntax seems like s nightmare, because now I’m required to create a special file with all the “fancy” tokens from which I need to copy paste.
georgehank2nd@reddit
Compose key to the rescue.
danted002@reddit
… no
Temporary_Pie2733@reddit
You have a keyboard with separate lower and uppercase keys? Part of the stigma I mentioned is the belief that your keyboard layout is the only one that matters. We accept that capital letters require the shift key to type without even thinking about it. Compose keys have existed on some keyboards since the seventies; macOS has supported the Option key for typing non-standard characters from its inception. Switching entire keyboard layouts on the fly isn’t that hard. I just don’t believe that typing non-ASCII characters is some insurmountable obstacle.
georgehank2nd@reddit
Identifiers in Python can use the full Unicode "alphanumeric" class (I don't recall the exact definition). Not limited to ASCII.
s-to-the-am@reddit
I was thinking a bit more about this last night and maybe doing s{} would be better almost like f string, but i don’t know
8day@reddit
Someone with a more upvoted reply said that in Python 4 it should be
{}
, whereas empty dict should be{:}
, which is likely derived from{k: v for k, v in dict.items()}
, and IMO that makes a lot of sense.BatterCake74@reddit
What if the empty set literal was just ∅? Hard to type, but more readable. It's the responsibility of our text editors to make it easier to type characters not found on a keyboard, like converting -> to →, typing math formulas and entering Greek characters as variable names.
Sneyek@reddit
Why not
<>’ ? Where we could also define
<‘a’, ‘b’, ‘c’>`.gmes78@reddit
That would make the syntax ambiguous.
Sneyek@reddit
Well, you’re right, it’s a bad idea but it would’ve been unique for the set.
nicholashairs@reddit
Except for the part where this would be a significant breaking change, this doesn't actually feel like that an insane of a proposal
Electronic-Duck8738@reddit
Any way we could also use the empty set symbol? This is the age of UTF-8 and it seems a shame not to use it.
MarsupialMole@reddit
I would prefer all these as valid empty collections:
{...:...}
is not ok tho.jwink3101@reddit
This all makes sense but also feels overblown in importance. The concept is fine but the arguments are weak.
tsqd@reddit
I think there should be a higher bar when introducing syntax that doesn’t read like natural language, for lack of a better term.
Each non-natural language syntax introduces cognitive load that, in my experience, is a worse outcome for the majority of users. It feels like we have decades of examples of this in other languages; one of the things that makes Python beautiful is its natural language readability.
I’m skeptical this meets the even the regular bar for warranting inclusion.
_Denizen_@reddit
In my experience, people don't like change and will keep doing things because that's what they know, and oppose change if it means they need to learn new things. My role at work has literally been to drag a business with 500 employees into the 21st century by updating 20-year old software development and data quality management processes that are no longer fit for purpose.
I've often been the lone voice of reason, and saved my employer a lot of money by challenging resistance to change.
If I can't understand why people oppose a change, then it's impossible to implement a change. So in this case saying "I can't understand why people are so opposed to X" is me requesting information so that I can challenge my own understanding.
Note that I did not say "my understanding is the correct one" or "everyone is dumb hurr hurr".
My self-critique is that I could have worded it differently.
Regarding your points:
The PEP has identified a use case where the syntax change benefits end users, and some here have shown that they are those end users. This suggests that research was done to assess the value of the change. Feature enhancements are a thing, not everything is a bug fix.
Valid, however do you accept the goal was to look similar to phi? Additional, is that critique enough to reject the entire PEP, and would a small change here be preferable to scrapping to entire change?
This is why you pin your range of supported python versions in each application. You can choose to update to this python version, at which point you choose to do the migration work. Similarly, you can choose not to upgrade. Nothing is forced on you.
I've been using python for over 10 years and never seen that specific snippet, and it's way more complex than the proposal. It requires a deeper understanding set definition, tuples, and the * operator to be able to understand - which is in direct opposition to the stated goal of making empty sets more accessible to new users.
Inbetweene@reddit
Anyone thought of using <>? It’s not like html has a patent on tags.
tav_stuff@reddit
I would prefer consistency with tuples:
(,)
and{,}
QuirkyImage@reddit
So do you also suggest { /, 1, 2, 3 }
aqjo@reddit
As I said in r/programming
Simple and intuitive.
onicx4@reddit
I was against this PEP until I saw the recommendation to include `{:}` as a paired alternate syntax for the empty dict. That kind of sold it for me, tbh.
KingHavana@reddit
We could still include {:} for a third empty dictionary without introducing this.
DorianTurba@reddit
Reading this, the pep and comments, I don't dislike it, it is an addiction that feels less difficult to teach then the walrus operator (
:=
), make sense, and yes we are used to useset()
but it is not like we won't be able to do so in the future. not having syntactic sugar to create a set feels wierd compared to all other common datastructs (do bytesarrays that common? IMHO no).I wouldn't mind is this was added, and I would definitely use it.
jjrreett@reddit
why do sets even get to use curly braces. imo that should just be dicts, don’t over load it. set() is fine. it is very clear. i do wish the constructor could take *args tho
nekokattt@reddit
dicts are technically sets of keys that then map to values
jjrreett@reddit
yes they are both hashing containers, but they are fundamentally different. therefore I believe they deserve different syntax. Reasonable minds may disagree.
HommeMusical@reddit
That ship sailed over 30 years ago.
double_en10dre@reddit
Idk, I think it makes sense. They are both collections of unique items
The only difference is that one associates a value with each key. A set is basically a
dict[KeyType, null]
If I see {}, I know the keys are unique. And if I see :, I know they map to something
nekokattt@reddit
I prefer the ruby route.
xxx.freeze!
georgehank2nd@reddit
If Guido had put sets into the first Python, in pretty sure they would have gotten the curlies, and ducts would have a different symbol.
ship0f@reddit
a mathematician would say that the dict is the one using the wrong sintax. the curly braces were always the mathematical symbol for sets. before python existed...
Gugalcrom123@reddit
Because math
HommeMusical@reddit
It's generally a bad idea to shadow built-ins with local variables anyway. Beginners should just not do that in the first place, and that's what we should be teaching them (and our linters should be helping them).
mjmikulski@reddit
That is a linux version, for windows we absolutely need
{\}
james_pic@reddit
The zen of Python sayeth:
If this were maybe part of some more general new syntax that solved some other problems, maybe (my first thought on skim reading it was that it looked like the "positional arguments separator", and maybe this was part of a wider proposal to do something positional-argument-y, but no, it isn't), but it seems like a slash inside a curly-bracketed collection literal is only intended to have semantics in this one specific construction.
Hard nope.
Qudit314159@reddit
A literal syntax for the empty set isn't a bad idea but
{/}
is a pretty strange notation for it.RestauradorDeLeyes@reddit
If you don't come from a math background, maybe. I think it's good.
HommeMusical@reddit
I come from a math background, but I didn't see
{/}
as looking like ∅ until someone told me about it, and it still doesn't help.dev_vvvvv@reddit
I come from a math background and {/} makes me think of a set containing the string "/".
Qudit314159@reddit
It makes me wonder how legion is supposed to divide { by } 😆
Charlie_Yu@reddit
It’s bad because it assigned a new meaning to / in an arbitrary way.
Qudit314159@reddit
Exactly. That's why it looks bizarre to me.
Qudit314159@reddit
I do.
vloris@reddit
There are plenty of reserved words in all kinds of programming languages which give you trouble if you (try to) use them as variable names.
I think it’s a valuable lesson to be confronted with early on in your career to realise that you should be careful with some words in your own code. So therefore I don’t think this is a very good argument here.
nicholashairs@reddit
As I said on the r/programming version of this post:
They are really scraping the bottom of the barrel with their justifications with this particular one.
Even if this were a good idea, the fact that they are using such weak justifications causes me to want to reject the proposal as it stands because it's clearly not that well thought through.
commy2@reddit
Should there even be set literals in the first place?
nicholashairs@reddit
Yes, regularly use them and set comprehensions
Grouchy-Friend4235@reddit
Not needed.
logophage@reddit
What about making
set() == {}
evaluate as true? How bad would that break things?qckpckt@reddit
That would be an absolute nightmare, probably.
logophage@reddit
Can you think of an example? Right now, I'm not thinking of one.
qckpckt@reddit
Any time that set() == {} should evaluate to false like it currently does?
You simply don’t change fundamental characteristics such as this of any programming language. It’s totally absurd.
JJJSchmidt_etAl@reddit
It's an empty dict. Equality is not generally ever true for different collection types.
ship0f@reddit
how does this have an upvote?
it's ludicrous.
you'd have to change the meaning of the literal (this is worse than the pep) or the meaning of the comparison (which i imagine is what you mean) in both ways.
either way, what does this solve?
it doesn't solve the set creation nor other comparisons between already created sets with the literal, which are the main objectives of the pep.
Trick_Brain7050@reddit
I wish i could downvote a PEP oof
prophile@reddit
Why?
double_en10dre@reddit
It distracts from other (infinitely better) proposals and it wastes a lot of time and energy
“{}” is not going to be more intuitive to a beginner than “set()”. It’s just not. It looks like some bizarre form of slice notation
So this entire charade is based on a change that at best adds minimal value, and in all likelihood actually makes things worse
commy2@reddit
I don't like the proposal either, but counterpoint: It is a common proposal, so even if it will be rejected, what's the harm in collecting the best arguments (such as they are...) for it in one place and then give it an official rejection? Assuming rejection, I think of it as a more official form of typing: why can't we.
The pep process has indeed become wasteful in the last few years with ever longer and longer essays. The worst one is probably the pattern matching tutorial. That's not even an "enhancement proposal"; if more thought went into pattern matching instead, we'd perhaps have something less half-baked and without introducing an entire mini language. At least the pep in question is concise.
Temporary_Pie2733@reddit
https://discuss.python.org/t/pep-802-display-syntax-for-the-empty-set/101676
david-vujic@reddit
Adding the possibility to create sets without calling a constructor function is a nice addition, and fits well in how we can do the same with dicts, lists and tuples. The notation looks a bit awkward at first, but new syntax usually do!
From a non-math perspective, I think {,} would make more sense (but also awkward).
lolcrunchy@reddit
It should be {+}. Go ahead, type it yourself and see why.
thrag_of_thragomiser@reddit
A plus should not be representing empty things
lolcrunchy@reddit
But it's so easy to type!
del1ro@reddit
Today is not April 1st
Select-Breadfruit95@reddit
Ok, do you know what Go is? It's a language that removes any logical ambiguity from programming. Do you know what python is? It's s language that has 5+ ways to construct a list, we don't need one more!!!
Go community: asking advice/making projects
Python community: what new feature should we add?
Gugalcrom123@reddit
I like it simply because literals are not like constructors and it is weird to have to use a constructor just for the empty case
divad1196@reddit
Been teaching for long, never was I issue. Most languages have explicit name. Usually, they prefer to write
dict()
instead of{}
and do loop afterward to fill the dict than using comprehension. Same forlist()
I believe thatset()
is therefore also fine for beginners.Zerocchi@reddit
Adding a syntax for the sake of adding lmao
imagineepix@reddit
As a math nerd I really like this lol
New-Watercress1717@reddit
nah, we don't need this, = set() is enough. There is no reason to make this language any more complex.
Wh00ster@reddit
Lol.
rghthndsd@reddit
Glad Python has solved all the serious problems and now this is what's left. /s
denehoffman@reddit
You can create an empty set with
set()
though, no? I get that you want some shorthand syntax for this, but it’s super niche. I don’t think many beginners are noticing this, since they are told that{}
is an empty dict and they typically don’t even use sets that often early on, I don’t think most people are that confused by it. And if they desperately need an empty set, they just reach forset()
. Introducing new syntax is tricky, but/
kinda feels too close the syntax we use for https://peps.python.org/pep-0570/ .On the other hand, I do agree it looks neat, though I don’t think I’d ever use it. But I don’t think beginners should be the motivation for this PEP.
griffin_quill06@reddit
While I do agree with the motivation behind this, the syntax is... odd to put it simply. Yes, it is weird, confusing, and a bit frustrating that there's notation for tuples, lists, and dicts but not for sets. I get what this is going for (I can even appreciate it coming from a math background) but the syntax is not particularly ergonomic. I wonder if there are other alternatives to this?
No_Flounder_1155@reddit
not a big fan of notation and breaks existing conventions. Maybe a rethink on what an dict should look like. an empty set makes more sense to be {}.
WildCard65@reddit
You can't just suddenly change the meaning of {} without breaking existing code, would require a major version change.
No_Flounder_1155@reddit
I get that. {/} is a horrid patch to address it.
Deto@reddit
Yeah I feel the same. Empty dict already makes the whole thing non-ideal and this doesn't fix that. So feels like it's not worth it to introduce new syntax
Beatlepoint@reddit
What could be better for confused beginners than an idiosyncratic literal.
thearctican@reddit
That was my thought. Why introduce a thing that does nothing except represent nothing? That’s what nothing is for.
omg_drd4_bbq@reddit
I actually think this is pretty elegant.
KronenR@reddit
I’d call it anything but elegant.