Hacker News Reader

Comment by charlieyu1 | Hacker News Reader

More and more dubious things were designed in Python these days. A recent PEP purposes to use {/} as the empty set

Problem is, we already have a syntax for empty lists [], empty tuples (), and {} is taken for an empty dict. So having a syntax for an empty set actually makes sense to me

{:} should have been the empty dict, now there's no good solution

I agree that {:} would be a better empty expression for dicts, but that ship has already sailed. {/} looks like a good enough alternative

There is a way to make it work. Python has no problem breaking things across major versions.

Python needed a breaking change for Unicode and a breaking change for exceptions and took it ages ago for a better future today - and it's still remembered as a huge PITA by everyone. I think you'll find everyone in the Python community disagreeing with you about a not-backwards-compatible Python 4.

Every minor release of Python is a breaking change. They deprecate stuff all the time, and remember the stdlib and the wider ecosystem has to also move in concert so the breaking changes cascade.

By major version I meant minor version, 3.13 -> 3.14 is a minor version in Python, but a major source of breaking changes, that is what I meant. There will be no Python 4

If Python actually incremented the major version every time they broke backwards compatibility, we'd be on something like Python 36 by now.

Almost every version they break existing code. This is why it's common for apps written in Python to depend on specific Python versions instead of just "anything above 3.x".

Are you suggesting to bump to Python 4 in order to be able to write `{}` instead of `set()` (or `{/}`) and simultaneously break all existing code using `{}` for dicts?

Jesus can you imagine if they announced Python 4? :-D

Breaking {} to be an empty set would be a HUGE breaking change, a _lot_ of code is already written where it is expected to be an empty dict. I don't think anyone in the Python committee would agree with breaking that

You can use “set()”. Introducing more weird special cases into the language is a bad direction for Python.

And you can use dict() for an empty dictionary, and list() for an empty list.

Yes but they are not equivalent. dict and list are factories; {} and [] are reified when the code is touched and then never reinitialised again. This catches out beginners and LLMs alike:

https://www.inspiredpython.com/article/watch-out-for-mutable...

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.

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.

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.

For reasons I don't think I understand, using the functions is "discouraged" because "someone might muck with how those functions work" and the python world, in it's perfect wisdom responded "Oh of course" instead of "That's so damn stupid, don't do that because it would be surprising to people who expect built in functions to do built in logic"

No no no, it's a great direction towards becoming the new Perl.

Making sense, and being good, is not necessary the same.

Yes, having a solution for this makes sense, but the proposed solutions are just not good. Sometimes one has to admit that not everything can be solved gracefully and just stop, hunting the whale.

Idk that doesn’t sound so dubious to me. ∅ might be more approachable for the PHDs then set() ;)

we all love non ascii code (cough emoji variable names)

Reply on news.ycombinator.com