[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
Joao, apologies for replying late - I never got back to this message.
I wrote:
>> Yes, but have you _seen_ the bickering about the existing bracket
>> choices just for frozenset? Eww. Hence the going for a distinct
>> operator
>> altogether. Yes, I'd prefer brackets of some kind too, but they're
>> taken.
On 21Jan2022 10:29, Joao S. O. Bueno wrote:
>> If one uses prefixes, you start from 53 valid (all latin areas,
>> upper,
>lower and @)
>new brackets for {} .
>I can't see how they are "all taken" when the strongest argument against
>prefixing seems to be "but _only strings_ should have prefixes".
>(with the "typing f{} instead of f() is going to be a bug magnet"
>as a runner up). None of those stand up to any logical analysis
Agreed. I think I found a short prefix "f{" hard to see, but that is
just "practice". I'm not inherently in the "but _only strings_ should
have prefixes" camp.
My remark about the bickering was aimed at unadorned brackets eg the
"{{frozen literal set here }}" suggestion.
Anyway, this post is just for clarification, not arguing any particular
point.
Cheers,
Cameron Simpson
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/5JVZFRHZT3P5IHES5ISTQBUKQYTVZUUH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On Sat, Jan 22, 2022 at 09:57:44AM +1100, Chris Angelico wrote: > Okay, so what would freezing a function be useful for, then? Why are you asking me, I'm not proposing a generic "freeze" protocol. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/AGHWYDJDAKVJEU4JDM5QFPOTP3NUDP7V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On Sat, 22 Jan 2022 at 09:45, Steven D'Aprano wrote: > > On Fri, Jan 21, 2022 at 10:56:42PM +1100, Chris Angelico wrote: > > > Let's be fair here... The idea of freezing is to make it hashable, > > And immutable. > > > so there's no point talking about freezing a function, module, > > Neither of which are immutable. > Okay, so what would freezing a function be useful for, then? What is your use-case here? Mutable objects can't be used as dict keys, so there is a strong use-case for versions of them which can. But when arbitrary attributes don't contribute to equality, freezing becomes largely irrelevant. I can subclass frozenset and allow attributes. Do we then need a "really frozen set"? What is the point of such a protocol, given that my subclass is still hashable? Or are you just arguing for the sake of arguing? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/UTN7G5XQ5QTJKH4TFCM7WXIQE4JIIW3D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On Fri, Jan 21, 2022 at 10:56:42PM +1100, Chris Angelico wrote: > Let's be fair here... The idea of freezing is to make it hashable, And immutable. > so there's no point talking about freezing a function, module, Neither of which are immutable. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/2TCZND772OFXF3QNX5II7KQD55RZXLY2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On 21Jan2022 12:22, Ben Rudiak-Gould wrote:
>There seem to be two different reasons people want a generic freeze syntax:
>
>1. Making a hashable copy of an arbitrary object
>
>2. Avoiding O(n) rebuilding of literals on every use (a constant for
>bytecode, as you put it)
The purpose of the operator (aside from genericity) was to enable
expression inspection by the compiler so that it can do for "|{1,2,3}|"
what it already does for "x in {1,2,3}".
The "generic" side to the operator approach was to provide a "freeze"
protocol one could use for generic objects.
>In both 1 and 2, not only the object but all of its children need to be
>immutable.
This is not strictly true. My own notion was a "shallow" freeze, not a
recursive freeze. For hashability, provided the hash and equality tests
only consider the frozen components, there's no need for a deep freeze -
just a frezze of the relevant aspects.
Cheers,
Cameron Simpson
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/K4TFYDV47M73GSGFHOUTXHQ7MLJE727C/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
There seem to be two different reasons people want a generic freeze syntax: 1. Making a hashable copy of an arbitrary object 2. Avoiding O(n) rebuilding of literals on every use (a constant for bytecode, as you put it) In both 1 and 2, not only the object but all of its children need to be immutable. For 2, that's the status quo, but for 1 it seems like a bigger problem. There is already a solution of sorts for 1: pickle. It may even be more efficient than a subobject-by-subobject deep freeze since it stores the result contiguously in RAM. On the other hand it can't share storage with already-hashable objects. For the second one, I would rather have an "inline static" syntax (evaluates to the value of an anonymous global variable that is initialized on first use), since it would be more broadly useful, and the disadvantages seem minor. (The disadvantages I see are that it's built per run instead of per compile, it's theoretically mutable (but mutation would be evident at the sole use site), and it may use more heap space depending on how constants are implemented which I don't know.) As for the syntax... well, backticks, obviously... ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/YM3Z2NMM6AZNSZ67KET6QBIBEFRD3WYW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On 21Jan2022 20:57, Steven D'Aprano wrote:
>On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
>
>> Paired with a __freeze__ dunder method, this applies to any type, not
>> just sets. (Where appropriate of course.)
>>
>> So:
>>
>> |{1,2,3}| frozen set
>> |[1,2,3]| tuple!
>> |any-iterable| tuple!
>> |{1:2, 3:4}|frozen dict
>
>A frozen "any iterable" is not necessarily a tuple.
Yeah, I had misgivings myself. I can imagine the freeze operator falling
back to iteration if there's no __freeze__dunder (like bool falls back
to length). I can equally imagine just raising a TypeError for no
__freeze__. More inclined to the latter on reflection - iterators get
consumed.
>For example, a frozen binary tree should probably keep the tree
>structure and methods; a frozen dict.keys() should be a frozen set;
Sure. According to their __freeze__.
>and
>its not clear what a frozen iterator should do. Should it run the
>iterator to exhaustion? Seems odd.
Hence thinking freezing an iterator might just make a tuple.
>What about non-collections? What's a frozen re.MatchObject?
A type error.
Let's not get insane. The idea is a generic operator, but not everything
can be used with such an operator.
Cheers,
Cameron Simpson
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/HVSE7HGGBCUAUEAZLOQX243R7ZBGXCSI/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On Sat, 22 Jan 2022 at 00:30, Joao S. O. Bueno wrote:
>>
>> Yes, but have you _seen_ the bickering about the existing bracket
>>
>> choices just for frozenset? Eww. Hence the going for a distinct operator
>> altogether. Yes, I'd prefer brackets of some kind too, but they're
>> taken.
>
> If one uses prefixes, you start from 53 valid (all latin areas, upper, lower
> and @)
> new brackets for {} .
Distinguishing upper and lower would be even more inconsistent, since
strings don't. Or rather, they sorta-kinda do, but always define that
x and X mean the same thing.
The at sign is an operator, and cannot be used as a prefix.
So you have 26, which is approximately 25 more than you will actually
want, or maybe 23 if there's an explicit prefix for "set" and "dict"
in there somewhere.
> I can't see how they are "all taken" when the strongest argument against
> prefixing seems to be "but _only strings_ should have prefixes".
> (with the "typing f{} instead of f() is going to be a bug magnet"
> as a runner up). None of those stand up to any logical analysis
Nice how you are the judge of whether it stands up to logical
analysis. Nice way to pooh-pooh an argument without any actual
reasoning. Oh wait, that's exactly what logical analysis would be...
So actually it's your rebuttal that doesn't stand logical analysis :)
> It is ok voting that "the language should not be made more complex
> at this point, and we won't add any new syntax for a frozenset", but
> I think that if it is agreed that frozensets are ok, a prefix
> is just straightforward.
>
> And then, adopting prefixes for curly braces, you have 52 other
> bracket types to try and sell this "generic freezer operator"
> you are presenting here. :-).
>
Prefixes on braces are not a generic freezer operator. An operator has
to be able to act on any object, not a specific syntactic construct.
Unless you're suggesting that q{obj} would mean "obj, but frozen",
which would be a quite inconsistent protocol, given that it's doing
the same job as a function call, looks disturbingly similar to a
function call, but is actually an operator. I don't know of anything
else in Python that behaves that way, except *maybe* the way a comma
can create a tuple, or can be used as part of a series of things. (And
that's a pretty weak line of argument, except in specific cases where
it's actually ambiguous - see assert (x,y) for instance.)
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/X3KPFUAWSTO7QKROWW465P2CFX27NDUP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
>
> Yes, but have you _seen_ the bickering about the existing bracket
>
> choices just for frozenset? Eww. Hence the going for a distinct operator
> altogether. Yes, I'd prefer brackets of some kind too, but they're
> taken.
>
> If one uses prefixes, you start from 53 valid (all latin areas, upper,
lower and @)
new brackets for {} .
I can't see how they are "all taken" when the strongest argument against
prefixing seems to be "but _only strings_ should have prefixes".
(with the "typing f{} instead of f() is going to be a bug magnet"
as a runner up). None of those stand up to any logical analysis
It is ok voting that "the language should not be made more complex
at this point, and we won't add any new syntax for a frozenset", but
I think that if it is agreed that frozensets are ok, a prefix
is just straightforward.
And then, adopting prefixes for curly braces, you have 52 other
bracket types to try and sell this "generic freezer operator"
you are presenting here. :-).
On Fri, Jan 21, 2022 at 5:52 AM Cameron Simpson wrote:
> On 21Jan2022 01:16, MRAB wrote:
> >On 2022-01-21 00:18, Cameron Simpson wrote:
> >>This all feels to me like a special case of "wanting a constant for
> >>bytecode". What is we had a "freeze" operator, eg:
> >> |foo|
> [...]
> >>Paired with a __freeze__ dunder method, this applies to any type, not
> >>just sets. (Where appropriate of course.)
> >> |{1,2,3}| frozen set
> >> |[1,2,3]| tuple!
> >> |any-iterable| tuple!
> >> |{1:2, 3:4}|frozen dict
> [...]
> >>My main question is: is the syntax unambiguous?
> >>
> >I don't know whether it's unambiguous, but it could be confusing.
> >
> >For example, what does this mean:
> >| a | b |
> >?
>
> Yeah.
>
> >It's:
> >| (a | b) |
> >I think.
>
> Probably. Running precedence the other way (or even worse, letting the
> valid combinations just shake out) would be confusing.
>
> >The problem is that '|' could be an opening '|', a closing '|', or an
> >infix '|'.
> >
> >You don't get this problem with differing open and closing pairs such
> >as '(' and ')'.
>
> Yes, but have you _seen_ the bickering about the existing bracket
> choices just for frozenset? Eww. Hence the going for a distinct operator
> altogether. Yes, I'd prefer brackets of some kind too, but they're
> taken.
>
> Cheers,
> Cameron Simpson
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@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/FZN74PZJBZCLULMT5AMTT6MP2L6RCENP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/RW6AHZAHRNGWV2HPULVC7J45GO7NEGOP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On Fri, Jan 21, 2022 at 6:57 AM Chris Angelico wrote:
> On Fri, 21 Jan 2022 at 22:52, Ricky Teachey wrote:
> >
> > On Fri, Jan 21, 2022 at 5:04 AM Steven D'Aprano
> wrote:
> >>
> >> On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
> >>
> >> > Paired with a __freeze__ dunder method, this applies to any type, not
> >> > just sets. (Where appropriate of course.)
> >> >
> >> > So:
> >> >
> >> > |{1,2,3}| frozen set
> >> > |[1,2,3]| tuple!
> >> > |any-iterable| tuple!
> >> > |{1:2, 3:4}|frozen dict
> >>
> >> A frozen "any iterable" is not necessarily a tuple.
> >>
> >> For example, a frozen binary tree should probably keep the tree
> >> structure and methods; a frozen dict.keys() should be a frozen set; and
> >> its not clear what a frozen iterator should do. Should it run the
> >> iterator to exhaustion? Seems odd.
> >>
> >> What about non-collections? What's a frozen re.MatchObject?
> >>
> >>
> >> --
> >> Steve
> >
> >
> > lord have mercy, what a can of worms this could end up being!:
> >
> > frozen iostream
> > frozen property
> > frozen function object
> > frozen module object
> > frozen iterator
> > frozen datetime
> >
>
> Let's be fair here... The idea of freezing is to make it hashable, so
> there's no point talking about freezing a function, module, or
> datetime, since they are already hashable. Don't saddle the proposal
> with issues it doesn't have :)
>
> (Technically this applies to an re.Match object too, actually,
> although I had to check to be sure. I've never once wanted to use one
> as a dict key. In contrast, I most certainly *have* used functions as
> dict keys, and it's safe and dependable.)
>
> ChrisA
>
Great point! I learned something.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/NY55JUHLGVNA43FS4UBGJMBULCKVG4TM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On Fri, 21 Jan 2022 at 22:52, Ricky Teachey wrote:
>
> On Fri, Jan 21, 2022 at 5:04 AM Steven D'Aprano wrote:
>>
>> On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
>>
>> > Paired with a __freeze__ dunder method, this applies to any type, not
>> > just sets. (Where appropriate of course.)
>> >
>> > So:
>> >
>> > |{1,2,3}| frozen set
>> > |[1,2,3]| tuple!
>> > |any-iterable| tuple!
>> > |{1:2, 3:4}|frozen dict
>>
>> A frozen "any iterable" is not necessarily a tuple.
>>
>> For example, a frozen binary tree should probably keep the tree
>> structure and methods; a frozen dict.keys() should be a frozen set; and
>> its not clear what a frozen iterator should do. Should it run the
>> iterator to exhaustion? Seems odd.
>>
>> What about non-collections? What's a frozen re.MatchObject?
>>
>>
>> --
>> Steve
>
>
> lord have mercy, what a can of worms this could end up being!:
>
> frozen iostream
> frozen property
> frozen function object
> frozen module object
> frozen iterator
> frozen datetime
>
Let's be fair here... The idea of freezing is to make it hashable, so
there's no point talking about freezing a function, module, or
datetime, since they are already hashable. Don't saddle the proposal
with issues it doesn't have :)
(Technically this applies to an re.Match object too, actually,
although I had to check to be sure. I've never once wanted to use one
as a dict key. In contrast, I most certainly *have* used functions as
dict keys, and it's safe and dependable.)
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/DZGRBDWNRG2B5GH6XDIRZB5GA6OGUKY3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On Fri, Jan 21, 2022 at 5:04 AM Steven D'Aprano wrote:
> On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
>
> > Paired with a __freeze__ dunder method, this applies to any type, not
> > just sets. (Where appropriate of course.)
> >
> > So:
> >
> > |{1,2,3}| frozen set
> > |[1,2,3]| tuple!
> > |any-iterable| tuple!
> > |{1:2, 3:4}|frozen dict
>
> A frozen "any iterable" is not necessarily a tuple.
>
> For example, a frozen binary tree should probably keep the tree
> structure and methods; a frozen dict.keys() should be a frozen set; and
> its not clear what a frozen iterator should do. Should it run the
> iterator to exhaustion? Seems odd.
>
> What about non-collections? What's a frozen re.MatchObject?
>
>
> --
> Steve
>
lord have mercy, what a can of worms this could end up being!:
frozen iostream
frozen property
frozen function object
frozen module object
frozen iterator
frozen datetime
i mean, i could certainly imagine rational (maybe even useful...?) ideas
for ALL of these. can you imagine the endless discussion about what to do
with the shiny new frozen operator, for every object under the sun?
obviously it would to nothing by raise an error by default. but people
would be asking to freeze everything and there would be mountains of ideas
threads and it would never end.
i'm not saying that reason means we don't have such an operator, but it
seems to me this just shows the decision on PEP 315 was the right one. why
have such a general operator, that could conceivably- and will be endlessly
requested and argued- be expanded to apply MANY things that even though
YAGNI for nearly all of them, when the only REAL need is only for a
frozenset?
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/K5KAKGI5T6XTKPYC5IXA4LXJGDWDTHL6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
> Paired with a __freeze__ dunder method, this applies to any type, not
> just sets. (Where appropriate of course.)
>
> So:
>
> |{1,2,3}| frozen set
> |[1,2,3]| tuple!
> |any-iterable| tuple!
> |{1:2, 3:4}|frozen dict
A frozen "any iterable" is not necessarily a tuple.
For example, a frozen binary tree should probably keep the tree
structure and methods; a frozen dict.keys() should be a frozen set; and
its not clear what a frozen iterator should do. Should it run the
iterator to exhaustion? Seems odd.
What about non-collections? What's a frozen re.MatchObject?
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/IRISCFVAO3LNT56H7I25NGVS47DCD525/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On Fri, 21 Jan 2022 at 19:53, Cameron Simpson wrote: > > On 20Jan2022 19:31, Eric V. Smith wrote: > >See also the rejected PEP 351. > > Ah. So close to my idea as to be indistinguishable. That's a shame. > Thanks, Cameron Simpson It's worth noting that a rejected PEP isn't the final and uneditable conclusion of a proposal. If you can show that something in the past seventeen years means this should be revisited, then by all means, revive the idea. (I suspect that, in this case, the rejection still applies - sets are still the only thing you'd viably want to freeze - but the option is there if you feel you can answer the original objections. Seventeen years is a long time.) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/WRQFIXXYBWDSW5BZWK77D5EP5F7AJT5J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On 21Jan2022 01:16, MRAB wrote:
>On 2022-01-21 00:18, Cameron Simpson wrote:
>>This all feels to me like a special case of "wanting a constant for
>>bytecode". What is we had a "freeze" operator, eg:
>> |foo|
[...]
>>Paired with a __freeze__ dunder method, this applies to any type, not
>>just sets. (Where appropriate of course.)
>> |{1,2,3}| frozen set
>> |[1,2,3]| tuple!
>> |any-iterable| tuple!
>> |{1:2, 3:4}|frozen dict
[...]
>>My main question is: is the syntax unambiguous?
>>
>I don't know whether it's unambiguous, but it could be confusing.
>
>For example, what does this mean:
>| a | b |
>?
Yeah.
>It's:
>| (a | b) |
>I think.
Probably. Running precedence the other way (or even worse, letting the
valid combinations just shake out) would be confusing.
>The problem is that '|' could be an opening '|', a closing '|', or an
>infix '|'.
>
>You don't get this problem with differing open and closing pairs such
>as '(' and ')'.
Yes, but have you _seen_ the bickering about the existing bracket
choices just for frozenset? Eww. Hence the going for a distinct operator
altogether. Yes, I'd prefer brackets of some kind too, but they're
taken.
Cheers,
Cameron Simpson
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/FZN74PZJBZCLULMT5AMTT6MP2L6RCENP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On 20Jan2022 19:31, Eric V. Smith wrote: >See also the rejected PEP 351. Ah. So close to my idea as to be indistinguishable. That's a shame. Thanks, Cameron Simpson ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/6LG7PSFM4HOEG3UUJOA7FMVZUDI4RBVS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
See also the rejected PEP 351.
--
Eric
> On Jan 20, 2022, at 7:21 PM, Cameron Simpson wrote:
>
> Well, I've just waded through this discussion.
>
> This all feels to me like a special case of "wanting a constant for
> bytecode". What is we had a "freeze" operator, eg:
>
>|foo|
>
> which would produce a frozen version of foo. I'm liking the vertical
> bars myself, I think because it feels vaguely slightly analogous to
> "absolute value". So (assuming we can squeeze it into the expression
> syntax):
>
>|{1,2,3}|
>
> always makes a direct frozen set on the same basis that:
>
>x in {1,2,3}
>
> directly makes a frozenset by expression inspection. Then
>
> Paired with a __freeze__ dunder method, this applies to any type, not
> just sets. (Where appropriate of course.)
>
> So:
>
>|{1,2,3}| frozen set
>|[1,2,3]| tuple!
>|any-iterable| tuple!
>|{1:2, 3:4}|frozen dict
>
> Ths saves us (a) inventing a special syntax for frozen sets and (b)
> gateways to freezing many things, starting with the obvious above, via
> the __freeze__ dunder method.
>
> This feels more general and less bikeshedable.
>
> My main question is: is the syntax unambiguous?
>
> Cheers,
> Cameron Simpson
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@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/2RW36I5XBTODSS4L3EHQ5ZXOWUVHDGWH/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/KJMHLLX2WLTAGDGYE4E4PMA4BR5QHVHY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
On 2022-01-21 00:18, Cameron Simpson wrote:
Well, I've just waded through this discussion.
This all feels to me like a special case of "wanting a constant for
bytecode". What is we had a "freeze" operator, eg:
|foo|
which would produce a frozen version of foo. I'm liking the vertical
bars myself, I think because it feels vaguely slightly analogous to
"absolute value". So (assuming we can squeeze it into the expression
syntax):
|{1,2,3}|
always makes a direct frozen set on the same basis that:
x in {1,2,3}
directly makes a frozenset by expression inspection. Then
Paired with a __freeze__ dunder method, this applies to any type, not
just sets. (Where appropriate of course.)
So:
|{1,2,3}| frozen set
|[1,2,3]| tuple!
|any-iterable| tuple!
|{1:2, 3:4}|frozen dict
Ths saves us (a) inventing a special syntax for frozen sets and (b)
gateways to freezing many things, starting with the obvious above, via
the __freeze__ dunder method.
This feels more general and less bikeshedable.
My main question is: is the syntax unambiguous?
I don't know whether it's unambiguous, but it could be confusing.
For example, what does this mean:
| a | b |
?
It's:
| (a | b) |
I think.
The problem is that '|' could be an opening '|', a closing '|', or an
infix '|'.
You don't get this problem with differing open and closing pairs such as
'(' and ')'.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/ZU24ILSJLN4U6XGYAOP6RVGDQ7XOAWAO/
Code of Conduct: http://python.org/psf/codeofconduct/
