On Wed, 5 Jan 2022 at 23:02, Chris Angelico <ros...@gmail.com> wrote: > > On Thu, Jan 6, 2022 at 8:01 AM Marco Sulla <marco.sulla.pyt...@gmail.com> > wrote: > > > > On Wed, 5 Jan 2022 at 14:16, Chris Angelico <ros...@gmail.com> wrote: > > > That's an entirely invisible optimization, but it's more than just > > > "frozenset is faster than set". It's that a frozenset or tuple can be > > > stored as a function's constants, which is a massive difference. > > > > Can you explain this? > > Play around with dis.dis and timeit.
? I don't understand. You're talking about function constants. What are they? I can't dig deep into something if I can't know what it is. Maybe are you talking about function default values for parameters? > > > Function positional arguments aren't interchangeable, so it makes > > > sense to have them as a tuple. > > > > You are wrong, since kwarg is a dict. Indeed I proposed to use > > frozendict for kwargs, and Guido said that it's a pity that this will > > break a lot of existing Python code :D, since the fact that args is > > _immutable_ and kwargs not always bothered him. > > Excuse me? I mentioned kwargs in the part that you removed from the > quote, and the part you're quoting explicitly says "positional > arguments". Ok, I quote also the other part: > (Function *keyword* arguments, on the other hand, are different; as > long as the mapping from keys to values is maintained, you can remove > some of them and pass the rest on, without fundamentally changing > their meaning.) First of all, I repeat, Guido said (more or less) that in a perfect world, kwargs are immutable. Or maybe I did not understand what he said, maybe he said that in a perfect world also args are mutable. But I suppose it's more probable the first hypothesis :D Secondly, you can also get the args from a function, transform it in a list, change something and pass it unpacked to another function. You will not change the meaning of the tuple, since, well, you copied it in another mutable object. The original object is untouched. I perfectly agree that, in the majority of cases, returning an immutable vs a mutable are a matter of... sense? Meaning? Ok, I perfectly agree. But IMHO there are many cases in which immutable objects are used for a matter of speed, and I bet that args is one of them. > > Anyway, I'm starting to think that neither set nor frozenset are good > > for dict items: > > > > (venv_3_10) marco@buzz:~$ python > > Python 3.10.0 (heads/3.10-dirty:f6e8b80d20, Nov 18 2021, 19:16:18) > > [GCC 10.1.1 20200718] on linux > > Type "help", "copyright", "credits" or "license" for more information. > > >>> a = {1: 2} > > >>> b = {3: []} > > >>> a | b > > {1: 2, 3: []} > > >>> a.items() | b.items() > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > TypeError: unhashable type: 'list' > > >>> > > Well yes. Only dict keys can be considered to be set-like. This is not true. It's at least from Python 3.6, and I think also before, that almost the full Set API was added to both keys and items view. Items indeed are a sort of set, in a mathematical sense, since any pair (key, value) is unique, even if value is mutable. > I don't > know WHAT you think you're trying to do here, but if you ever thought > of set operations on dict values, you may want to completely rethink > what you're doing. set ops on values? Never said that :) I said that currently you can operate on item views with set operators. This is a fact. I also said that, since py sets accept only hashable objects, maybe another ad-hoc object should be used for the result of the items operations. But maybe the change isn't worth the additional trouble. Indeed I didn't know about the new set methods and operations on dict views until I explored dictobject.c > Performance is not an automatic result of immutability. That simply > isn't how it works. Of course. You can use a proxy and slow down almost everything much more. Or you can simply create a version of the mutable object with fewer methods, as more or less frozenset is. I checked the implementation, no fast iteration is implemented. I do not understand why in `for x in {1, 2, 3}` the set is substituted by a frozenset. -- https://mail.python.org/mailman/listinfo/python-list