That article is about how defaults for arguments are evaluated eagerly. It doesn't real have to do with dict vs {}.

However, using the literal syntax does seem to be more efficient. So that is an argument for having dedicated syntax for an empty set.

I am not replying to the article but to the poster.

I am talking about the article you linked to in your comment.

They are equivalent. In function signatures (what your article is talking about), using dict() instead of {} will have the same effect. The only difference is that {} is a literal of an empty dict, and dict is a name bound to the builtin dict class. So you can reassign dict, but not {}, and if you use dict() instead of {}, then you have a name lookup before a call, so {} is a little more efficient.

Right, but it instantiates it _once_ on module load! That is the point I am making; nothing else.

Your link doesn't support your argument.

I wrote the link and yes it does. Module evaluations reify {}, [], etc. once. That is why people keep making subtle bugs when they do `def foo(a=[]):` unaware that this will in fact not give you a brand new list on every function call.

Factory functions like list/tuple/set are function calls and are executed and avoid this problem. Hence why professional python devs default to `None` and check for that and _then_ initialise the list internally in the function body.

Adding {/} as empty set is great, sure; but that again is just another reified instance and the opposite of set() the function.

There is no difference between “def f(x={})” and “def f(x=dict())”, unless you have shadowed the dict builtin. They both have exactly the same subtle bug if you are mutating or return x later.