[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: Revisiting a frozenset display literal
On Fri, Jan 21, 2022 at 08:36:37AM -0800, Christopher Barker wrote:
> On Fri, Jan 21, 2022 at 3:52 AM Oscar Benjamin
> wrote:
> > I really don't understand (having read everything above) why anyone
> > prefers {1,2,3}.frozen() over f{1,2,3}.
> >
>
> Because it doesn't require any change to the language -- it's a feature,
> not a language change. Every change to the language is s substantial burden
> to the whole community. Even a "small" one like this.
The change from "" ASCII byte strings to Unicode was a substaintial
change that lead to a substantial burden on library developers, at least
in the short-term. Adding a new operator like `@` has been barely
noticed. Out of the two extremes, I don't think that adding f{} displays
would be closer to changing the meaning of strings than to adding the
matmul operator.
I do acknowledge that f{} would be perplexing to beginners who just saw
it written down with no explanation or context, but then the same
applies to slicing and list comprehensions.
> Python is not a high-performance language -- has it ever had a feature
> added primirly so it could be optimized? (that is a serious question).
Maybe we should stop dismissing performance as unimportant. Nobody has
ever said that Python is too fast.
I was going to joke that nobody has ever asked "How do I make Python
slower?", but sure enough somebody has:
https://stackoverflow.com/questions/16555120/how-can-i-slow-down-a-loop-in-python
*wink*
I acknowledge that this specific change would likely be a micro-
optimization, but looking beyond this proposal, perhaps we should start
considering adding features specifically for performance?
People are developing entire new Python interpreters and variants to
improve performance, and have done so for many years. There is an
impressive list of past and present such projects:
- Cython
- Nuitka
- Pyston
- Cinder
- wpython
- Hotpy
- Unladen Swallow
- Numba
- Pythran
among others. So maybe we should consider *not* saying "Python is fast
enough", or "Just re-write it in C", and consider language features that
are aimed specifically or mainly at performance.
Just a thought to mull over.
--
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/CILW3LIGCPSHAPTDT2HWWV6CR236ZNSA/
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: Revisiting a frozenset display literal
On Fri, Jan 21, 2022 at 3:52 AM Oscar Benjamin
wrote:
> > If this does all come to pass, then:
>>> >
>>> > s = {3,8,2}.frozen()
>>> > will be slightly faster, in some case, than
>>> > s = frozenset({3,8,2}
>>> >
>>> > but the result would be the same.
>>>
>>> I really don't understand (having read everything above) why anyone
> prefers {1,2,3}.frozen() over f{1,2,3}.
>
Because it doesn't require any change to the language -- it's a feature,
not a language change. Every change to the language is s substantial burden
to the whole community. Even a "small" one like this.
It was absolutely worth for, e.g. f-strings, because they are a
feature that has very broad use. This would have narrow use, and, I think
even the OP said is more about potential optimization than a nicer syntax.
If others think this syntax is substantially nicer, sure -- but then I'd
argue that frozensets are simply not that commonly used -- you yourself
realized that while you have an important use case, you aren't using
literals that often anyway (at all?).
Python is not a high-performance language -- has it ever had a feature
added primirly so it could be optimized? (that is a serious question).
And this does seem like a very small change, but is it?
1) folks, a couple years from now, reading new code might have never heard
of a frozenset, and see:
frozenset(something)
or
{1,5,2}.frozen()
will probably have a pretty good idea what those mean, and if they have no
clue, then it's easy to look up.
f{3,1,6}
not so much.
And once we have ONE prefix on a bracket, I"ll bet you folks will suggest
more ...
small change
medium churn
tiny benefit
(frankly, it's confusing enough that {a,b,c} makes a set and {} makes a
dict, but what can we do? there's only so many brackets :-(
-CHB
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
___
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/K2ZD7DV3YKQ4YURQXHM3PBJDORWQIGZ6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] 'frozen set' discussion - please consider taking some time off.
Hi all, python-ideas moderator here. It’d be great if y’all could take a few days to cool off the frozen set discussion, which is veering off the rails a little bit into emotional language. I’ll keep an eye on it and put emergency moderation into effect if I must, but it’d be nicer if I didn’t feel the need to do that. thanks, —titus ___ 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/W5MS2FTUMSKYIFXDPPYJPIS3CFW43JYP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno wrote:
>>
>> I don't understand polynomials as frozensets. What's the point of
>> representing them that way? Particularly if you're converting to and
>> from dicts all the time, why not represent them as dicts? Or as some
>> custom mapping type, if you need it to be hashable?
>
>
> Sorry for deviating here, but this kind of argumentation is one
> that is sensitive for me - but here it is:
> I personally do not think the comment above adds anything to the discussion
> at hand.
> We've been presented to a real-world use case of frozensets that would
> benefit in readability from having a dedicated literal. How good it is to
> question the way it is coded without even checking the project out?
> (and even so, do that publicly in a non related discussion?)
>
> I had this happen to me in an email here, when I tried an early
> version of match/case in a code in a project of mine. Despite
> being a more or less internal API, the code was bashed in
> a way, in an unasked for code review,
> it took out the fun I had in coding the project for months.
>
> So, please, take care when deviating from the discussion at hand.
My comment was part of a lengthy response to a post which itself added
little, because it *would not benefit from literals*. My post was
arguing that this was the case. It was, in fact, entirely part of this
discussion. I did take care, and I was making points that are fully
relevant to whether a literal syntax would be beneficial or not.
> Back on topic:
> It looks like this thing of "prefixes are valid for strigns and no good
> for anything else" is, as yoiu put it, Chris, a personal thing.
Every opinion expressed in this thread is a personal one. You can't
dismiss one of them that way without dismissing them all. Does the
viewpoint have merit? It either does, or does not, regardless of who
came up with it. Please take care when deviating from discussion of
actual arguments to discussion of people.
> Do we have anyone else in this thread commenting (or even
> "+1ing") on that side? As I've mentioned a couple
> of times before: is there any other arguments against
> "f{}" other than "prefixes should be for strings only"
> (and the"bug magnet" perceived by many as a plain
> incorrect statement )?
We don't have anyone justifying it or disproving it. Only people
saying whether they like it or not. Ultimately, it is a matter of
aesthetics - whether the syntax is ugly or elegant. My opinion is that
it is ugly. Your opinion, it seems, is that it is elegant. These are
two equally valid opinions.
> If there is not, then we are not at "there is no viable syntax",
> as prefixable braces are perfectly viable. It is whether it should be
> done or not, despite some people finding it ugly, which is subjective.
On the contrary; if it is ugly, it probably shouldn't be done, so the
two questions are actually the same question.
Unless by "viable syntax" you are distinguishing from syntaxes which
can be rejected swiftly as being ambiguous or already legal with other
semantics (for instance, ({1,2,3}) should be rejected as unviable),
but few of the proposed syntaxes fall foul of that.
> At that point, I argue that despite adding still more things to
> the syntax, it is one that will spare time in average than the other
> way around, due to the time people, needing frozensets for
> the first time in any project, waste looking for a literal syntax for them
> only to find out there is not any.
>
Have you any stats on this? There is no literal/display syntax for
datetimes, regular expressions, ranges, bytearrays, or a host of other
common types. How often do people reach for a literal syntax for
those? (I say "literal/display" since, technically, dicts have a
display syntax, not a literal, and complex numbers are written as a
constant-folded sum, but in practical terms, those count. The other
types don't even get that.) If frozensets are so special that they
need syntax, why not ranges, which are used far more frequently?
With the method idea, there's a fully backward compatible way to add
it to the language, and an optimization that can be applied to many
types.
So I'm -1 on dedicated syntax for frozensets, -1 on prefixes on
braces, and +0.5 on set.frozen() and the ability to constant-fold
that.
But that's just personal opinion. Like everything else in this thread.
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/IE2KJ2UU64SKJPQBETEKOJ2V2TBNTNMU/
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: Revisiting a frozenset display literal
>
> I don't understand polynomials as frozensets. What's the point of
> representing them that way? Particularly if you're converting to and
> from dicts all the time, why not represent them as dicts? Or as some
> custom mapping type, if you need it to be hashable?
Sorry for deviating here, but this kind of argumentation is one
that is sensitive for me - but here it is:
I personally do not think the comment above adds anything to the
discussion at hand.
We've been presented to a real-world use case of frozensets that would
benefit in readability from having a dedicated literal. How good it is to
question the way it is coded without even checking the project out?
(and even so, do that publicly in a non related discussion?)
I had this happen to me in an email here, when I tried an early
version of match/case in a code in a project of mine. Despite
being a more or less internal API, the code was bashed in
a way, in an unasked for code review,
it took out the fun I had in coding the project for months.
So, please, take care when deviating from the discussion at hand.
Back on topic:
It looks like this thing of "prefixes are valid for strigns and no good
for anything else" is, as yoiu put it, Chris, a personal thing.
Do we have anyone else in this thread commenting (or even
"+1ing") on that side? As I've mentioned a couple
of times before: is there any other arguments against
"f{}" other than "prefixes should be for strings only"
(and the"bug magnet" perceived by many as a plain
incorrect statement )?
If there is not, then we are not at "there is no viable syntax",
as prefixable braces are perfectly viable. It is whether it should be
done or not, despite some people finding it ugly, which is subjective.
At that point, I argue that despite adding still more things to
the syntax, it is one that will spare time in average than the other
way around, due to the time people, needing frozensets for
the first time in any project, waste looking for a literal syntax for them
only to find out there is not any.
On Fri, Jan 21, 2022 at 9:16 AM Chris Angelico wrote:
> On Fri, 21 Jan 2022 at 22:52, Oscar Benjamin
> wrote:
> >
> > On Thu, 20 Jan 2022 at 10:19, Ricky Teachey wrote:
> >>
> >> On Thu, Jan 20, 2022 at 3:35 AM Stephen J. Turnbull <
> stephenjturnb...@gmail.com> wrote:
> >>>
> >>> Christopher Barker writes:
> >>>
> >>> > If this does all come to pass, then:
> >>> >
> >>> > s = {3,8,2}.frozen()
> >>> > will be slightly faster, in some case, than
> >>> > s = frozenset({3,8,2}
> >>> >
> >>> > but the result would be the same.
> >>> >
> >>> > There are plenty of tricks to in python to get a touch more
> performance,
> >>> > this would just be one more
> >>> > and frankly pretty rare that it would make an noticable difference
> at all.
> >>> >
> >>> > +1 on this
> >>> > +0 on f{}
> >>> > -1 on making frozenset a keyword
> >>>
> >>> Stated better than I could, expresses my feelings exactly. Sticking
> >>> to integers (in floats I'd be less than -0 on f{}), I'll go with
> >>> Chris's ratings, too.
> >>>
> >>> Steve
> >>
> >>
> >> Another agreement with Chris' ratings:
> >>
> >> +1 for .frozen()
> >> +0 on f{}
> >> -1 on keyword for frozenset
> >
> >
> > I really don't understand (having read everything above) why anyone
> prefers {1,2,3}.frozen() over f{1,2,3}. Yes, some people coming from some
> other languages might get confused (e.g. in Mathematica this is function
> call syntax) but that's true of anything: you have to learn Python syntax
> to use Python. The fact that {1,2,3} is a set and f{1,2,3} is a frozenset
> is not difficult to explain or to understand, especially in a language that
> already uses single letter prefixes for other things.
> >
> > The .frozen() method is a strangely indirect way to achieve a minor
> optimisation. Outside of attempting to achieve that optimisation it's
> basically useless because any time you would have written obj.frozen() you
> could have simply written frozenset(obj) so it does nothing to improve code
> that uses frozensets.
> >
>
> If set.frozen() is optimized, then str.upper() can be optimized the
> same way, which means there's a lot of places where constant folding
> can be used. We commonly write code like "7*24*60*60" to mean the
> number of seconds in a week, confident that it'll be exactly as fast
> as writing "604800", and there's no particular reason that method
> calls can't get the same optimization, other than that it hasn't been
> done yet.
>
> While dedicated syntax might be as good, it also wouldn't help with
> string methods (or int methods - I don't see it a lot currently, but
> maybe (1234).to_bytes() could become more popular), and it would also
> be completely backward incompatible - you can't feature-test for
> syntax without a lot of hassle with imports and alternates. In
> contrast, code that wants to use set.frozen() can at least test for
> that with a simple try/except in the same module.
>
> Not one of the proposed
[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: Revisiting a frozenset display literal
On 21/01/2022 11:51, Oscar Benjamin wrote:
I really don't understand (having read everything above) why anyone
prefers {1,2,3}.frozen() over f{1,2,3}. Yes, some people coming from
some other languages might get confused (e.g. in Mathematica this is
function call syntax) but that's true of anything: you have to learn
Python syntax to use Python. The fact that {1,2,3} is a set and
f{1,2,3} is a frozenset is not difficult to explain or to understand,
especially in a language that already uses single letter prefixes for
other things.
The .frozen() method is a strangely indirect way to achieve a minor
optimisation. Outside of attempting to achieve that optimisation it's
basically useless because any time you would have written obj.frozen()
you could have simply written frozenset(obj) so it does nothing to
improve code that uses frozensets.
With f{...} you have a nice syntax that clearly creates a frozenset
directly and that can be used for repr.
+1___
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/TJMIXB4V2WYYTI5IJ2LAL3N5XTTN4R57/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On Fri, 21 Jan 2022 at 12:15, Chris Angelico wrote:
>
> On Fri, 21 Jan 2022 at 22:52, Oscar Benjamin
> wrote:
> >
> > I really don't understand (having read everything above) why anyone prefers
> > {1,2,3}.frozen() over f{1,2,3}. Yes, some people coming from some other
> > languages might get confused (e.g. in Mathematica this is function call
> > syntax) but that's true of anything: you have to learn Python syntax to use
> > Python. The fact that {1,2,3} is a set and f{1,2,3} is a frozenset is not
> > difficult to explain or to understand, especially in a language that
> > already uses single letter prefixes for other things.
> >
> > The .frozen() method is a strangely indirect way to achieve a minor
> > optimisation. Outside of attempting to achieve that optimisation it's
> > basically useless because any time you would have written obj.frozen() you
> > could have simply written frozenset(obj) so it does nothing to improve code
> > that uses frozensets.
> >
>
> If set.frozen() is optimized, then str.upper() can be optimized the
> same way, which means there's a lot of places where constant folding
> can be used. We commonly write code like "7*24*60*60" to mean the
> number of seconds in a week, confident that it'll be exactly as fast
> as writing "604800", and there's no particular reason that method
> calls can't get the same optimization, other than that it hasn't been
> done yet.
>
> While dedicated syntax might be as good, it also wouldn't help with
> string methods (or int methods - I don't see it a lot currently, but
> maybe (1234).to_bytes() could become more popular), and it would also
> be completely backward incompatible - you can't feature-test for
> syntax without a lot of hassle with imports and alternates. In
> contrast, code that wants to use set.frozen() can at least test for
> that with a simple try/except in the same module.
The proposal for .frozen() is not about optimising method calls on
literals in general: the proposal is to add a method that is basically
redundant but purely so that calls to the method can be optimised
away.
> Not one of the proposed syntaxes has seen any sort of strong support.
> This isn't the first time people have proposed a syntactic form for
> frozensets, and it never achieves sufficient consensus to move
> forward.
>
> > With f{...} you have a nice syntax that clearly creates a frozenset
> > directly and that can be used for repr. This is some actual code that I
> > recently wrote using frozensets to represent monomials in a sparse
> > representation of a multivariate polynomial:
>
> "Clearly" is subjective. Any syntax could be used for repr, including
> {1,2,3}.frozen(), so f{1,2,3} doesn't have any particular edge there.
> Personally, I think that string literals are not the same thing as
> tuple/list/dict/set displays, and letter prefixes are not as useful on
> the latter.
>
> > >>> poly = {frozenset([(1,2), (3,4)]): 2, frozenset([(0,1)]): 3}
> > >>> poly
> > {frozenset({(1, 2), (3, 4)}): 2, frozenset({(0, 1)}): 3}
> >
> > With the f{...} proposal you have actual syntax for this:
> >
> > >>> poly = {f{(1,2), (3,4)}: 2, f{(0,1)}): 3}
> > >>> poly
> > {f{(1, 2), (3, 4)}: 2, f{(0, 1)}): 3}
> >
> > With .frozen() it's
> >
> > >>> poly = {{(1,2), (3,4)}.frozen(): 2, f{(0,1)}.frozen()): 3}
> > >>> poly
> > ??? does the repr change?
>
> Yes, it most certainly would change the repr. I don't see why that's an issue.
I'm not saying it's an issue. That was a genuine question. So I guess
you'd expect this:
>>> poly = {{(1,2), (3,4)}.frozen(): 2, f{(0,1)}.frozen()): 3}
>>> poly
{{(1, 2), (3, 4)}.frozen(): 2, f{(0, 1)}.frozen()): 3}
This btw is my real point of my post which you seem to have missed (I
probably should have kept it more direct):
> > That difference in code/repr may or may not seem like an improvement to
> > different people but that should be the real point of discussion if talking
> > about a frozenset literal. The performance impact of frozenset literals is
> > not going to be noticeable in any real application.
If we take performance out of the equation would anyone actually
propose to add a .frozen() method so that obj.frozen() could be used
instead of frozenset(obj)?
If so then what is the argument for having a redundant way of doing this?
> I don't understand polynomials as frozensets. What's the point of
> representing them that way? Particularly if you're converting to and
> from dicts all the time, why not represent them as dicts? Or as some
> custom mapping type, if you need it to be hashable?
Hashability is the point. The polynomial is a dict mapping monomials
to coefficients and the monomials are frozensets of factors so that
they are hashable with unordered equality. Another option would just
be a sorted tuple of tuples and then instead of frozenset(d.items())
you'd have tuple(sorted(d.items())) but that's slower in my timings
(for all input sizes). Any custom type with pure Python
[Python-ideas] Re: Revisiting a frozenset display literal
On Fri, 21 Jan 2022 at 22:52, Oscar Benjamin wrote:
>
> On Thu, 20 Jan 2022 at 10:19, Ricky Teachey wrote:
>>
>> On Thu, Jan 20, 2022 at 3:35 AM Stephen J. Turnbull
>> wrote:
>>>
>>> Christopher Barker writes:
>>>
>>> > If this does all come to pass, then:
>>> >
>>> > s = {3,8,2}.frozen()
>>> > will be slightly faster, in some case, than
>>> > s = frozenset({3,8,2}
>>> >
>>> > but the result would be the same.
>>> >
>>> > There are plenty of tricks to in python to get a touch more performance,
>>> > this would just be one more
>>> > and frankly pretty rare that it would make an noticable difference at
>>> all.
>>> >
>>> > +1 on this
>>> > +0 on f{}
>>> > -1 on making frozenset a keyword
>>>
>>> Stated better than I could, expresses my feelings exactly. Sticking
>>> to integers (in floats I'd be less than -0 on f{}), I'll go with
>>> Chris's ratings, too.
>>>
>>> Steve
>>
>>
>> Another agreement with Chris' ratings:
>>
>> +1 for .frozen()
>> +0 on f{}
>> -1 on keyword for frozenset
>
>
> I really don't understand (having read everything above) why anyone prefers
> {1,2,3}.frozen() over f{1,2,3}. Yes, some people coming from some other
> languages might get confused (e.g. in Mathematica this is function call
> syntax) but that's true of anything: you have to learn Python syntax to use
> Python. The fact that {1,2,3} is a set and f{1,2,3} is a frozenset is not
> difficult to explain or to understand, especially in a language that already
> uses single letter prefixes for other things.
>
> The .frozen() method is a strangely indirect way to achieve a minor
> optimisation. Outside of attempting to achieve that optimisation it's
> basically useless because any time you would have written obj.frozen() you
> could have simply written frozenset(obj) so it does nothing to improve code
> that uses frozensets.
>
If set.frozen() is optimized, then str.upper() can be optimized the
same way, which means there's a lot of places where constant folding
can be used. We commonly write code like "7*24*60*60" to mean the
number of seconds in a week, confident that it'll be exactly as fast
as writing "604800", and there's no particular reason that method
calls can't get the same optimization, other than that it hasn't been
done yet.
While dedicated syntax might be as good, it also wouldn't help with
string methods (or int methods - I don't see it a lot currently, but
maybe (1234).to_bytes() could become more popular), and it would also
be completely backward incompatible - you can't feature-test for
syntax without a lot of hassle with imports and alternates. In
contrast, code that wants to use set.frozen() can at least test for
that with a simple try/except in the same module.
Not one of the proposed syntaxes has seen any sort of strong support.
This isn't the first time people have proposed a syntactic form for
frozensets, and it never achieves sufficient consensus to move
forward.
> With f{...} you have a nice syntax that clearly creates a frozenset directly
> and that can be used for repr. This is some actual code that I recently wrote
> using frozensets to represent monomials in a sparse representation of a
> multivariate polynomial:
>
"Clearly" is subjective. Any syntax could be used for repr, including
{1,2,3}.frozen(), so f{1,2,3} doesn't have any particular edge there.
Personally, I think that string literals are not the same thing as
tuple/list/dict/set displays, and letter prefixes are not as useful on
the latter.
> >>> poly = {frozenset([(1,2), (3,4)]): 2, frozenset([(0,1)]): 3}
> >>> poly
> {frozenset({(1, 2), (3, 4)}): 2, frozenset({(0, 1)}): 3}
>
> With the f{...} proposal you have actual syntax for this:
>
> >>> poly = {f{(1,2), (3,4)}: 2, f{(0,1)}): 3}
> >>> poly
> {f{(1, 2), (3, 4)}: 2, f{(0, 1)}): 3}
>
> With .frozen() it's
>
> >>> poly = {{(1,2), (3,4)}.frozen(): 2, f{(0,1)}.frozen()): 3}
> >>> poly
> ??? does the repr change?
Yes, it most certainly would change the repr. I don't see why that's an issue.
> That difference in code/repr may or may not seem like an improvement to
> different people but that should be the real point of discussion if talking
> about a frozenset literal. The performance impact of frozenset literals is
> not going to be noticeable in any real application.
>
> My polynomial class makes extensive use of frozensets and is something that I
> do need to be as fast as possible. I just looked through the code I have for
> that class and none of the performance sensitive routines could benefit from
> this because they all actually need to build their elements in a dict before
> converting to a frozenset anyway e.g.:
>
I don't understand polynomials as frozensets. What's the point of
representing them that way? Particularly if you're converting to and
from dicts all the time, why not represent them as dicts? Or as some
custom mapping type, if you need it to be hashable?
> def mul(self, other):
> """multiply two
[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: Revisiting a frozenset display literal
On Thu, 20 Jan 2022 at 10:19, Ricky Teachey wrote:
> On Thu, Jan 20, 2022 at 3:35 AM Stephen J. Turnbull <
> stephenjturnb...@gmail.com> wrote:
>
>> Christopher Barker writes:
>>
>> > If this does all come to pass, then:
>> >
>> > s = {3,8,2}.frozen()
>> > will be slightly faster, in some case, than
>> > s = frozenset({3,8,2}
>> >
>> > but the result would be the same.
>> >
>> > There are plenty of tricks to in python to get a touch more
>> performance,
>> > this would just be one more
>> > and frankly pretty rare that it would make an noticable difference at
>> all.
>> >
>> > +1 on this
>> > +0 on f{}
>> > -1 on making frozenset a keyword
>>
>> Stated better than I could, expresses my feelings exactly. Sticking
>> to integers (in floats I'd be less than -0 on f{}), I'll go with
>> Chris's ratings, too.
>>
>> Steve
>>
>
> Another agreement with Chris' ratings:
>
> +1 for .frozen()
> +0 on f{}
> -1 on keyword for frozenset
>
I really don't understand (having read everything above) why anyone prefers
{1,2,3}.frozen() over f{1,2,3}. Yes, some people coming from some other
languages might get confused (e.g. in Mathematica this is function call
syntax) but that's true of anything: you have to learn Python syntax to use
Python. The fact that {1,2,3} is a set and f{1,2,3} is a frozenset is not
difficult to explain or to understand, especially in a language that
already uses single letter prefixes for other things.
The .frozen() method is a strangely indirect way to achieve a minor
optimisation. Outside of attempting to achieve that optimisation it's
basically useless because any time you would have written obj.frozen() you
could have simply written frozenset(obj) so it does nothing to improve code
that uses frozensets.
With f{...} you have a nice syntax that clearly creates a frozenset
directly and that can be used for repr. This is some actual code that I
recently wrote using frozensets to represent monomials in a sparse
representation of a multivariate polynomial:
>>> poly = {frozenset([(1,2), (3,4)]): 2, frozenset([(0,1)]): 3}
>>> poly
{frozenset({(1, 2), (3, 4)}): 2, frozenset({(0, 1)}): 3}
With the f{...} proposal you have actual syntax for this:
>>> poly = {f{(1,2), (3,4)}: 2, f{(0,1)}): 3}
>>> poly
{f{(1, 2), (3, 4)}: 2, f{(0, 1)}): 3}
With .frozen() it's
>>> poly = {{(1,2), (3,4)}.frozen(): 2, f{(0,1)}.frozen()): 3}
>>> poly
??? does the repr change?
That difference in code/repr may or may not seem like an improvement to
different people but that should be the real point of discussion if talking
about a frozenset literal. The performance impact of frozenset literals is
not going to be noticeable in any real application.
My polynomial class makes extensive use of frozensets and is something that
I do need to be as fast as possible. I just looked through the code I have
for that class and none of the performance sensitive routines could benefit
from this because they all actually need to build their elements in a dict
before converting to a frozenset anyway e.g.:
def mul(self, other):
"""multiply two (frozenset) monomials"""
powermap = dict(self)
for g, n in other:
other_n = powermap.get(g)
if other_n is None:
powermap[g] = n
else:
powermap_n = other_n + n
if powermap_n:
powermap[g] = powermap_n
else:
powermap.pop(g)
return frozenset(powermap.items())
I've just profiled this and the call to frozenset is always dwarfed by the
time taken in the preceding loop which shows how cheap converting between
builtins is compared to pretty much any other code.
If you're using literals then of necessity you are talking about small
sets. Even just using a small set over a small tuple is a hardly noticeable
difference in speed in most situations:
In [12]: s = {1,2,3}
In [13]: t = (1,2,3)
In [14]: timeit 2 in s
44.9 ns ± 0.17 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)
In [15]: timeit 2 in t
59.9 ns ± 5.67 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)
--
Oscar
___
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/5YECLMZ7ACSYOYPVK6U3NYDG5VJRLTUG/
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/
