Re: Revisiting a frozenset display literal
![](https://secure.gravatar.com/avatar/5615a372d9866f203a22b2c437527bbb.jpg?s=120&d=mm&r=g)
On Wed, Jan 19, 2022 at 01:56:54PM +0100, Marco Sulla wrote:
PEP 351 for the frozen protocol was rejected. I didn't read why, but it's probably hard to resurrect.
This is not a proposal for a generic frozen protocol. It is a simple proposal for a set method that returns a frozenset, with the aim that the peephole optimiser will be able to optimise the call out for set displays consisting only of literals. -- Steve
![](https://secure.gravatar.com/avatar/2240a37aad5f5834a92809a5e5f01fe1.jpg?s=120&d=mm&r=g)
Maybe the "special optimizable method" will solve some of the problems, and appraise the "no new syntax" folks. But IMHO, it (1) it is more verbose than the prefix/suffix new syntax alternatives, to the point of getting in the way of reading mysets = [{1 ,2 ,3 }.freeze(), {4,5,6}.freeze()] X mysets = [{f{1, 2, 3}, f{4, 5, 6}] and (2), as stated, although introducing no new syntax, require fiddling in a couple of places in order to actually work in an optimized way, and the optimization would end up as an "implementation detail". (In order not to generate yet another message): I've seem no new arguments by the opponents of "f{...}"at all - but re-stating that "strings are different than sets". Indeed: strings(bytestrings, raw, fstrings) have a lot of factors in common that the other built-in datatypes don't share. But the prefix thing is orthogonal to that, and the same motivations that led to the introduction of quote-prefixes for strings to start with apply here, with no drawbacks. As already stated in other messages, calling it a "bug magnet" is a gross exaggeration. One would get a "NameError" on the first try and have it either fixed seconds later, or revisiting the concept of functions and calling functions, which would be needed anyway, in case the person in error is a begginner to programming in general. best regards, js -><- On Wed, Jan 19, 2022 at 10:14 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Wed, Jan 19, 2022 at 01:56:54PM +0100, Marco Sulla wrote:
PEP 351 for the frozen protocol was rejected. I didn't read why, but it's probably hard to resurrect.
This is not a proposal for a generic frozen protocol. It is a simple proposal for a set method that returns a frozenset, with the aim that the peephole optimiser will be able to optimise the call out for set displays consisting only of literals.
-- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BH2VZ3... Code of Conduct: http://python.org/psf/codeofconduct/
![](https://secure.gravatar.com/avatar/5615a372d9866f203a22b2c437527bbb.jpg?s=120&d=mm&r=g)
On Wed, Jan 19, 2022 at 10:30:05AM -0300, Joao S. O. Bueno wrote:
Maybe the "special optimizable method" will solve some of the problems, and appraise the "no new syntax" folks. [...]
I pretty much agree with everything Joao says here. The hypothetical peephole optimization trick for {1, 2, 3}.frozen() is a nifty trick, but it is a poor second cousin to a real frozenset display syntax. Still, it's an option that shouldn't be dismissed out of hand. -- Steve
![](https://secure.gravatar.com/avatar/6dcbad6503875324049cdad1f2426e3a.jpg?s=120&d=mm&r=g)
Joao's {1, 2, 3}.frozen() shows real originality, arising from deep creative thought about the roots of the problem. I was both surprised and delighted when I saw it, and I think some others were too. (I agree with others that here 'freeze' is better than 'frozen'.) Obviously, each of the two proposals f{1, 2, 3} {1, 2, 3}.freeze() has advantages and disadvantages when compared to the other. Both deserve full and fair consideration. -- Jonathan
participants (3)
-
Joao S. O. Bueno
-
Jonathan Fine
-
Steven D'Aprano