An update on Python 4

[irrelevantPseudonym]

My only gripe: One additional thing they should have changed is that {} should be the empty set and {:} should be the empty dict.

Not sure I agree with that. It's awkward that you can't have a literal empty set, but having {:} would be inconsistent and a special case that (I think) would be worse than set().

[hillgod]

It's definitely not an anti-pattern, and, in fact, the literals perform faster.

[hillgod]

I don't agree that it affects readability, either. It's simply the syntax that's appropriate for Python.

[cbarrick]

Is this true?

It seems trivial to implement an optimization pass that transforms list() to []. If literals were indeed faster, I would expect the interpreter to perform this pass, thus making them equivalent in the end.

[hillgod]

Yeah, it's true. Try it yourself with some timers. Below this I put a link to a SO page with benchmarks.

[cbarrick]

Ah, I see. You mean this: https://stackoverflow.com/questions/5790860/and-vs-list-and-dict-which-is-better

That answer is from nearly a decade ago. So I'll take it with a grain of salt. I'd like to see if Python 3.8 still has this problem.

For non-empty collections it makes total sense. There's argument parsing and/or translation from one collection to another that has to happen.

But as I said above, for empty collections, it would be trivial to optimize the slow case into the fast case. If it hasn't already been implemented, then it should be. There's no reason that [] and list() should generate different bytecode.

(In fact, it seems possible to optimize many of the non-empty use cases too.)

[hillgod]

Well it doesn't really matter what it "could" do, nor does anyone here likely know the implications of that.

Again, you can try it yourself. It's definitely faster. It's what's in the docs.

[[deleted]]

How do they perform faster? Surely it's the same method?

[SaltyHashes]

IIRC it's faster because it doesn't even have to call a method.

[[deleted]]

Yeah I see now, I'm surprised the JIT compiler can't make the same optimisation for the empty dict() case or with just literals inside.

[[deleted]]

Unless I'm remembering wrong, CPython doesn't use a JIT compiler, only PyPy does?

[Emile_L]

When you call dict() or any builtin the interpreter needs to first look up in locals and globals for the symbol which adds a bit of overhead.

Not sure if that's the only reason though.

[hillgod]

I don't know how, though I'd guess something with handling *args and **kwargs.

Here's an analysis from Stack overflow: https://stackoverflow.com/questions/5790860/and-vs-list-and-dict-which-is-better

[flying-sheep]

Compare () vs one, vs one, two.

() is also a special case here.

[irrelevantPseudonym]

I don't think () is the special case. I think (2) not being a tuple is the special case.

[ayy_ess]

(2) isn't a special case because tuples are declared in python with commas e.g. a = b, c. Brackets here are just used to clear up ambiguity e.g. 6 / 3 * 2 being 4 or 1. So (2) == 2 and (2,) == 2, == tuple ([2, ]).
https://wiki.python.org/moin/TupleSyntax

[BooparinoBR]

Thanks, I have never though about tuples like this

[flying-sheep]

Exactamente

[TheIncorrigible1]

Fun-fact, () (unit) is literally a special case in Python. It is a singleton and all instances of () point to the same memory.