On 01Feb2022 09:13, Chris Angelico wrote:
>On Tue, 1 Feb 2022 at 09:02, Cameron Simpson wrote:
>> On 22Jan2022 01:41, Chris Angelico wrote:
>> >On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno
>> >wrote:
>> >> At that point, I argue that despite adding still more things to
>> >> the syntax, it
[... big snip...]
On 22Jan2022 01:41, Chris Angelico wrote:
>On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno wrote:
>> 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,
On Tue, 1 Feb 2022 at 09:02, Cameron Simpson wrote:
>
> [... big snip...]
>
> On 22Jan2022 01:41, Chris Angelico wrote:
> >On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno wrote:
> >> At that point, I argue that despite adding still more things to
> >> the syntax, it is one that will spare time
On Sat, Jan 29, 2022 at 3:16 AM Jure Šorn wrote:
> frozenset.from_args(1, 2, 3)
This wouldn’t solve the problem at hand, as ‘frozenset’ could be rebound.
And what advantage does this have over the existing constructors?
-CHB
> iter.from_args(1, 2, 3)
> array.array.from_args('i', 1, 2, 3)
>
Hello, I'm new here. Has anyone proposed the following solution yet?
list.from_args(1, 2, 3)
tuple.from_args(1, 2, 3)
set.from_args(1, 2, 3)
frozenset.from_args(1, 2, 3)
iter.from_args(1, 2, 3)
array.array.from_args('i', 1, 2, 3)
___
Python-ideas
+1 I would appreciate being able to create a frozenset using f{1, 2, 3}.
This will also make the `repr` of frozensets shorter.
On Sun, Jan 16, 2022 at 10:33 AM Steven D'Aprano
wrote:
> Inspired by this enhancement request:
>
> https://bugs.python.org/issue46393
>
> I thought it might be time to
Hi
Steve D'Aprano started this thread on 16 Jan, referencing
https://bugs.python.org/issue46393.
In the 95th message in this thread, on 27 Jan, Stephen J. Turnbull wrote:
I think for many of us (specifically me, but I don't think I'm alone) it's
> equally important that we aren't persuaded that
Matsuoka Takuo writes:
> I hope the following remarks are constructive to the subject.
They are constructive, but I disagree with the factual assessment:
> It seems what's not liked about f{*x} notation is mainly that it looks
> parallel to f(*x) or e.g., often possibly f[(*x, )] ,
I think
I hope the following remarks are constructive to the subject.
It seems what's not liked about f{*x} notation is mainly that it looks
parallel to f(*x) or e.g., often possibly f[(*x, )] , which seems to
be a problem mostly only because of the character "f". If the prefix
were "frozenset", then
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
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
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
>
> 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
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
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
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()
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
On 20/01/22 3:17 am, Joao S. O. Bueno wrote:
But upon seeing a method call, we can just think first of a runtime behavior
Correctly, btw. Any optimization there would be an exception, that
people would
have to know by heart.
Frozensets are immutable, so nobody should be making any
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
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
On Wed, Jan 19, 2022 at 6:21 AM Joao S. O. Bueno
wrote:
> Here is another hint that this usage would not resolve the problem of
>>
> having a literal frozenset. Even in the core of this discussion, with folks
> participating and knowing what they are talking about, the first thing that
> comes
>
> Also, it is standard in Python to avoid properties if the computation
> could be expensive. Copying a large set or millions of elements into a
> frozenset could be expensive, so we should keep it a method call.
Here is another hint that this usage would not resolve the problem of
having a
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
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,
On Wed, Jan 19, 2022 at 02:20:06PM +0100, Marco Sulla wrote:
> I can understand, but if you do it for set, why not for list,
> bytearray... And so it becomes a sort of protocol for freezing
> objects.
YAGNI.
If you want a frozen list, you can already write that as a tuple. There
is no need to
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
On Wed, Jan 19, 2022 at 07:12:04AM -0500, Ricky Teachey wrote:
> Why does it need to be called at all?
>
> {1, 2, 3}.frozen
For the same reason that most methods are methods, not properties.
The aim of a good API is not to minimize the amount of typing, it is to
communicate the *meaning* of
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
Why does it need to be called at all?
{1, 2, 3}.frozen
Or even:
{1, 2, 3}.f
On Wed, Jan 19, 2022, 6:28 AM Steven D'Aprano wrote:
> On Wed, Jan 19, 2022 at 07:20:12AM +, Ben Rudiak-Gould wrote:
> > My preferred syntax for a frozenset literal would be something like
> >
> > {1, 2,
On Wed, Jan 19, 2022 at 07:20:12AM +, Ben Rudiak-Gould wrote:
> My preferred syntax for a frozenset literal would be something like
>
> {1, 2, 3}.freeze()
>
> This requires no new syntax, and can be safely optimized at compile time
> (as far as I can tell).
I like that, it is similar to
On Wed, Jan 19, 2022 at 6:31 PM Ben Rudiak-Gould wrote:
>
> My preferred syntax for a frozenset literal would be something like
>
> {1, 2, 3}.freeze()
>
> This requires no new syntax, and can be safely optimized at compile time (as
> far as I can tell).
>
> set.freeze would be a new method
+1
On Wed, 2022-01-19 at 07:20 +, Ben Rudiak-Gould wrote:
> My preferred syntax for a frozenset literal would be something like
>
> {1, 2, 3}.freeze()
>
> This requires no new syntax, and can be safely optimized at compile
> time (as far as I can tell).
>
> set.freeze would be a new
My preferred syntax for a frozenset literal would be something like
{1, 2, 3}.freeze()
This requires no new syntax, and can be safely optimized at compile time
(as far as I can tell).
set.freeze would be a new method of sets which could also be used at run
time. It would return a new
On 2022-01-18 23:50, Steven D'Aprano wrote:
On Wed, Jan 19, 2022 at 11:30:36AM +1300, Greg Ewing wrote:
I'd also be happy with making frozenset a keyword.
- int, float, str, tuple, dict, set, exceptions, len, etc
are not keywords, so they can be shadowed (for good or bad);
- alone out of
On Wed, Jan 19, 2022 at 11:30:36AM +1300, Greg Ewing wrote:
> I'd also be happy with making frozenset a keyword.
- int, float, str, tuple, dict, set, exceptions, len, etc
are not keywords, so they can be shadowed (for good or bad);
- alone out of all the builtin types and functions, frozenset
On 19/01/22 6:41 am, Rob Cliffe via Python-ideas wrote:
I'm happy with the
f{ ... }
Fine with me too.
I'd also be happy with making frozenset a keyword. It's hard to
imagine it breaking any existing code, it avoids having to make any
syntax changes, and all current uses of frozenset() on
On 19/01/22 6:41 am, Rob Cliffe via Python-ideas wrote:
I'm happy with the
f{ ... }
Fine with me too.
I'd also be happy with making frozenset a keyword. It's hard to
imagine it breaking any existing code, it avoids having to make any
syntax changes, and all current uses of frozenset() on
Not a huge fan of an f-prefix for a frozen set (I prefer just recognizing
the case and optimizing the byte code, I don't think frozensets are used
often enough to justify its own syntax), but I love {,} for an empty set.
On Tue, Jan 18, 2022 at 4:13 PM Rob Cliffe via Python-ideas <
On 18/01/2022 19:42, MRAB wrote:
On 2022-01-18 18:54, Neil Girdhar wrote:
Even if f{1} creates a frozenset, I don't think f{} should create a
frozenset. I think it makes more sense to keep f{1: 2} open for
frozendict if it ever makes it in. Also, {} should be consisten with
f{} (both
On 2022-01-18 18:54, Neil Girdhar wrote:
Even if f{1} creates a frozenset, I don't think f{} should create a
frozenset. I think it makes more sense to keep f{1: 2} open for
frozendict if it ever makes it in. Also, {} should be consisten with
f{} (both should create dicts). If you want an
Even if f{1} creates a frozenset, I don't think f{} should create a
frozenset. I think it makes more sense to keep f{1: 2} open for frozendict
if it ever makes it in. Also, {} should be consisten with f{} (both should
create dicts). If you want an empty frozenset, you would have to do it the
One thing to consider is if we're going to have a syntax capable of
creating an empty frozenset, we need one that creates an empty set.
if f{...} exists, then s{...} should also exist?
Regards
João Bernardo
On Tue, Jan 18, 2022 at 2:59 PM Rob Cliffe via Python-ideas <
python-ideas@python.org>
I'm +1 on the idea.
I'm happy with the
f{ ... }
syntax (although I did suggest something else).
We already have letter-prefixes, let's stick to them rather than adding
something new (which conceivably might one day find another use).
Best wishes
Rob Cliffe
On 18/01/2022 15:53, Ricky
On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno
wrote:
> > but I don't think we should underestimate the cost of even this small
> complexity increase in the language.
>
> Actually, I think _maybe_ in this case the "complexity increase" cost is
> _negative_. People might waste
> more time
> but I don't think we should underestimate the cost of even this small
complexity increase in the language.
Actually, I think _maybe_ in this case the "complexity increase" cost is
_negative_. People might waste
more time looking for a way of spelling a frozenset literal than just
filling in
On Mon, Jan 17, 2022 at 07:19:17AM -0800, Jelle Zijlstra wrote:
> > That is in the global scope, which will be much slower than a local scope.
>
> Global builtins do a hash table lookup; local lookups just follow a
> pointer.
Yes, that is correct, frozenset is a builtin, not a local variable, so
On Mon, Jan 17, 2022 at 3:50 AM Steven D'Aprano wrote:
> If you saw this code in a review:
>
> t = tuple([1, 2, 3, 4, 5])
>
> would you say "that is okay, because the name lookup is smaller than the
> cost of building the list"?
>
> I wouldn't. I would change the code to `(1, 2, 3, 4, 5)`.
>
On Mon, Jan 17, 2022 at 9:07 AM Ronald Oussoren
wrote:
>
> For example:
>
> If flag in {‘the’, ‘allowable’, ‘flags’}:
> …
>
> If a frozen set was even a little bit faster or used less memory, it would
> be nice to be able to create one directly.
>
>
> Not really relevant for the discussion,
On 2022-01-17 06:07, Greg Ewing wrote:
U+2744 Snowflake, anyone?
my_frozenset = ❄{1, 2, 3}
That makes me think about using '@':
my_frozenset = @{1, 2, 3}
It's currently used as a prefix for decorators, but that's at the start
of a line.
It could be a problem for the REPL, though:
> On 16 Jan 2022, at 18:44, Christopher Barker wrote:
>
> Is there no way to optimize the byte code without adding to the language?
>
> Not that it’s a bad idea anyway, but I wonder if frozen sets are common
> enough to warrant a change.
>
> Are there any performance advantages to a frozen
Earlier today in https://bugs.python.org/issue46393, Serhiy Storchaka wrote:
As Steven have noted the compiler-time optimization is not applicable here
because name frozenset is resolved at run-time.
In these cases where a set of constants can be replaced with a frozenset of
constants (in "x in
El lun, 17 ene 2022 a las 7:11, Steven D'Aprano ()
escribió:
> On Mon, Jan 17, 2022 at 11:18:13PM +0900, Inada Naoki wrote:
> > On Mon, Jan 17, 2022 at 8:49 PM Steven D'Aprano
> wrote:
> > >
> > > On Mon, Jan 17, 2022 at 08:04:50PM +0900, Inada Naoki wrote:
> > >
> > > > Name lookup is faster
On Mon, Jan 17, 2022 at 11:18:13PM +0900, Inada Naoki wrote:
> On Mon, Jan 17, 2022 at 8:49 PM Steven D'Aprano wrote:
> >
> > On Mon, Jan 17, 2022 at 08:04:50PM +0900, Inada Naoki wrote:
> >
> > > Name lookup is faster than building set in most case.
> > > So I don't think cost to look name up is
On Mon, Jan 17, 2022 at 8:49 PM Steven D'Aprano wrote:
>
> On Mon, Jan 17, 2022 at 08:04:50PM +0900, Inada Naoki wrote:
>
> > Name lookup is faster than building set in most case.
> > So I don't think cost to look name up is important at all.
>
> But the cost to look up the name is *in addition*
The compiler can figure out that the value of
{1, 2, 3}
is a set containing the elements 1, 2 and 3.
The problem with the value of
frozenset({1, 2, 3})
is that the value of frozenset depends on the context. This is because
frozenset = print
is allowed.
According to help(repr):
On Mon, Jan 17, 2022 at 08:04:50PM +0900, Inada Naoki wrote:
> Name lookup is faster than building set in most case.
> So I don't think cost to look name up is important at all.
But the cost to look up the name is *in addition* to building the set.
If you saw this code in a review:
t =
On Sun, Jan 16, 2022 at 05:53:19PM -0800, Brendan Barnwell wrote:
> > f{1, 2, 3}
>
> I don't like that syntax. In the first place, as others have noted,
> it treads too close to existing function-call and indexing syntax. In
> those syntaxes, `f` is a name, whereas here it is
On Mon, Jan 17, 2022 at 7:10 PM Steven D'Aprano wrote:
>
> Out of those 29 calls, I think that probably 13 would be good candidates
> to use a frozenset display form (almost half). For example:
>
> ast.py:binop_rassoc = frozenset(("**",)) # f{("**",)}
> asyncore.py:
On Mon, Jan 17, 2022 at 7:44 PM Paul Moore wrote:
>
> On Mon, 17 Jan 2022 at 10:12, Steven D'Aprano wrote:
> > That would make the creation of frozensets more efficient, possibly
> > encourage people who currently are writing slow and inefficient code
> > like
> >
> > targets = (3, 5, 7, 11,
On Mon, Jan 17, 2022 at 07:07:51PM +1300, Greg Ewing wrote:
> U+2744 Snowflake, anyone?
>
> my_frozenset = ❄{1, 2, 3}
If I knew how to type that, I'd be more impressed :-)
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To
On Sun, Jan 16, 2022 at 06:10:58PM -0800, Christopher Barker wrote:
> In a way, what this might do is open the door to interning (some) frozen
> sets, like cPython does for some ints and strings.
I don't think that interning is relevant here. Interning is orthogonal
to the existence of a
On Mon, 17 Jan 2022 at 10:12, Steven D'Aprano wrote:
> That would make the creation of frozensets more efficient, possibly
> encourage people who currently are writing slow and inefficient code
> like
>
> targets = (3, 5, 7, 11, 12, 18, 27, 28, 30, 35, 57, 88)
> if n in targets:
>
On Mon, Jan 17, 2022 at 12:54:58AM +, Oscar Benjamin wrote:
> A more relevant question right now is if any other set syntax should apply
> to frozensets e.g. should this work:
>
> >>> squares = f{x**2 for x in range(10)}
If display syntax for frozensets were to be approved, then we
On Sun, Jan 16, 2022 at 10:33:41PM -0800, Christopher Barker wrote:
> On Sun, Jan 16, 2022 at 7:05 PM Steven D'Aprano wrote:
>
> >
> > I never suggested adding this "for consistency".
> >
>
> Then what ARE you suggesting it for?
Apologies if my initial post was not clear enough:
On Mon, Jan 17, 2022 at 7:12 PM Paul Moore wrote:
>
> On Mon, 17 Jan 2022 at 01:11, Chris Angelico wrote:
> >
> > On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
> > >
> > > On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > > > >>> def f():
> > > > ... return frozenset({1, 2, 3})
On Mon, Jan 17, 2022 at 03:05:36AM +, MRAB wrote:
> How about doubling-up the braces:
>
> {{1, 2, 3}}
I mentioned that earlier. Its not *awful*, but as you point out
yourself, it does run into the problem that nested sets suffer from
brace overflow.
# A set of sets.
}},
On Mon, 17 Jan 2022 at 01:11, Chris Angelico wrote:
>
> On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
> >
> > On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > > >>> def f():
> > > ... return frozenset({1, 2, 3})
> > > ...
> > > >>> a = f.__code__.co_consts[1]
> > > >>> a
> > >
On Mon, Jan 17, 2022 at 4:38 PM Christopher Barker wrote:
>
> On Sun, Jan 16, 2022 at 6:34 PM Chris Angelico wrote:
>>
>> > def fun():
>> > return "some string"
>> >
>> > doesn't return the same string, unless it's iterned, which is an
>> > implementation detail, yes?
>>
>> Not sure what
On Sun, Jan 16, 2022 at 7:05 PM Steven D'Aprano wrote:
>
> I never suggested adding this "for consistency".
>
Then what ARE you suggesting it for?
As far as I can tell, it would be a handy shorthand.
And you had suggested it could result in more efficient bytecode, but I
think someone else
On Mon, Jan 17, 2022 at 2:01 PM Steven D'Aprano wrote:
> > Yes. ONLY on strings. That's exactly what I said. Strings are
> > different. For starters, we already have multiple different data types
> > that can come from quoted literals, plus a non-literal form that
> > people treat like a literal
U+2744 Snowflake, anyone?
my_frozenset = ❄{1, 2, 3}
--
Greg
___
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
On Sun, Jan 16, 2022 at 6:34 PM Chris Angelico wrote:
> > def fun():
> > return "some string"
> >
> > doesn't return the same string, unless it's iterned, which is an
> implementation detail, yes?
>
> Not sure what you mean. That's a constant, so it'll always return the
> exact same object,
On 2022-01-17 01:36, Steven D'Aprano wrote:
On Sun, Jan 16, 2022 at 04:23:47PM -0800, Brendan Barnwell wrote:
On 2022-01-16 16:11, Steven D'Aprano wrote:
>Do they? How are they different? You have a start delimiter and an end
>delimiter.
>
[snip]
Hell, even if your argument is just "Nope, I
On Mon, Jan 17, 2022 at 10:15:50AM +0900, Inada Naoki wrote:
> Unless how the literal improve codes is demonstrated, I am -0.5 on new
> literal only for consistency.
I never suggested adding this "for consistency".
--
Steve
___
Python-ideas mailing
On Mon, Jan 17, 2022 at 12:16:07PM +1100, Chris Angelico wrote:
> > > Strings behave differently in many many ways. Are there any non-string
> > > types that differ?
> >
> > There are plenty of non-string types which differ :-)
>
> *sigh* I know you love to argue for the sake of arguing, but
>
On 2022-01-16 00:27, Steven D'Aprano wrote:
It seems to me that all of the machinery to make this work already
exists. The compiler already knows how to create frozensets at
compile-time, avoiding the need to lookup and call the frozenset()
builtin. All we need is syntax for a frozenset display.
On Mon, Jan 17, 2022 at 1:14 PM Christopher Barker wrote:
> why/how would it do that? It *could* do that -- as above, with interning. but:
>
> def fun():
> return "some string"
>
> doesn't return the same string, unless it's iterned, which is an
> implementation detail, yes?
Not sure what
On 17/01/2022 00:16, Steven D'Aprano wrote:
On Sun, Jan 16, 2022 at 01:11:13PM +, Rob Cliffe via Python-ideas wrote:
How about
fs{1, 2, 3}
What does the "s" add that the set {1, 2, 3} doesn't already tell us?
It helps to distinguish it from
f(1, 2, 3)
f[1, 2, 3]
f"1, 2,
On Sun, Jan 16, 2022 at 3:14 PM Paul Moore wrote:
> I may just be reiterating your point here (if I am, I'm sorry - I'm
> not completely sure), but isn't that required by the definition of the
> frozenset function. You're calling frozenset(), which is defined to
> "Return a new frozenset object,
On Sun, Jan 16, 2022 at 4:55 PM Oscar Benjamin
wrote:
> How often do folks need a frozen set literal? I don’t think I’ve ever used
>> one.
>>
>
> You won't have used one because they have not yet existed (hence this
> thread).
>
di you really notunderstand my point?
I have never used the
On Sun, Jan 16, 2022 at 04:43:36PM -0800, Christopher Barker wrote:
> I’m a bit confused — would adding a “literal” form for frozenset provide
> much, if any, of an optimization?
Yes. In at least some cases, it would avoid going through the song and
dance:
1. create a frozenset
2. convert the
On Sun, Jan 16, 2022 at 04:23:47PM -0800, Brendan Barnwell wrote:
> On 2022-01-16 16:11, Steven D'Aprano wrote:
> >Do they? How are they different? You have a start delimiter and an end
> >delimiter.
> >
> >The only difference I see is that with strings the delimiter is the
> >same, instead of a
On Mon, Jan 17, 2022 at 11:18 AM Steven D'Aprano wrote:
>
> On Sun, Jan 16, 2022 at 11:41:52PM +1100, Chris Angelico wrote:
> > On Sun, Jan 16, 2022 at 11:18 PM Steven D'Aprano
> > wrote:
>
> > > Not to mention:
> > >
> > > r(1, 2, 3) # look up r, call it with parameters
> > > r[1, 2,
On Mon, Jan 17, 2022 at 9:58 AM Oscar Benjamin
wrote:
>
> On Mon, 17 Jan 2022 at 00:46, Christopher Barker wrote:
>>
>> I’m a bit confused — would adding a “literal” form for frozenset provide
>> much, if any, of an optimization? If not,
>> that means it’s only worth doing for convenience.
>>
On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
>
> On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > >>> def f():
> > ... return frozenset({1, 2, 3})
> > ...
> > >>> a = f.__code__.co_consts[1]
> > >>> a
> > frozenset({1, 2, 3})
> > >>> b = f()
> > >>> assert a == b
> > >>> a is b
On Mon, 17 Jan 2022 at 00:46, Christopher Barker
wrote:
> I’m a bit confused — would adding a “literal” form for frozenset provide
> much, if any, of an optimization? If not,
> that means it’s only worth doing for convenience.
>
> How often do folks need a frozen set literal? I don’t think I’ve
I’m a bit confused — would adding a “literal” form for frozenset provide
much, if any, of an optimization? If not,
that means it’s only worth doing for convenience.
How often do folks need a frozen set literal? I don’t think I’ve ever used
one.
If we did, then f{‘this’: ‘that’} should make a
On 2022-01-16 16:11, Steven D'Aprano wrote:
Do they? How are they different? You have a start delimiter and an end
delimiter.
The only difference I see is that with strings the delimiter is the
same, instead of a distinct open and close delimiter. But that
difference is surely not a reason to
On Sun, Jan 16, 2022 at 01:11:13PM +, Rob Cliffe via Python-ideas wrote:
> How about
> fs{1, 2, 3}
What does the "s" add that the set {1, 2, 3} doesn't already tell us?
We don't say rs"\d+" for raw strings, or fs"{x =}" for f-strings.
--
Steve
On Sun, Jan 16, 2022 at 11:41:52PM +1100, Chris Angelico wrote:
> On Sun, Jan 16, 2022 at 11:18 PM Steven D'Aprano wrote:
> > Not to mention:
> >
> > r(1, 2, 3) # look up r, call it with parameters
> > r[1, 2, 3] # look up r, subscript it
> > r"1, 2, 3" # a string literal
>
>
On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> >>> def f():
> ... return frozenset({1, 2, 3})
> ...
> >>> a = f.__code__.co_consts[1]
> >>> a
> frozenset({1, 2, 3})
> >>> b = f()
> >>> assert a == b
> >>> a is b
> False
>
> Each time you call the function, you get a distinct frozenset
On Mon, Jan 17, 2022 at 9:55 AM Steven D'Aprano wrote:
>
> On Sun, Jan 16, 2022 at 04:50:40PM +, MRAB wrote:
>
> > Not quite as bad as that:
> >
> > >>> f = frozenset({1, 2, 3})
> > >>> f is frozenset(f)
> > True
>
> Mark suggested that on the bug tracker too, but that's not relevant. As
> I
On Sun, Jan 16, 2022 at 04:50:40PM +, MRAB wrote:
> Not quite as bad as that:
>
> >>> f = frozenset({1, 2, 3})
> >>> f is frozenset(f)
> True
Mark suggested that on the bug tracker too, but that's not relevant. As
I replied there:
>>> def f():
... return frozenset({1, 2, 3})
...
>>>
Summary: Further information is provided, which suggests that it may be
best to amend Python so that "frozenset({1, 2, 3})" is the literal for
eval("frozenset({1, 2, 3})").
Steve D'Aprano correctly notes that the bytecode generated by the expression
x in {1, 2 ,3}
is apparently not optimal.
Is there no way to optimize the byte code without adding to the language?
Not that it’s a bad idea anyway, but I wonder if frozen sets are common
enough to warrant a change.
Are there any performance advantages to a frozen set? I ask because I do
often use sets that could be frozen, but don’t
On 2022-01-16 08:27, Steven D'Aprano wrote:
[snip]
dis.dis("frozenset({1, 2, 3})")
1 0 LOAD_NAME0 (frozenset)
2 BUILD_SET0
4 LOAD_CONST 0 (frozenset({1, 2, 3}))
6 SET_UPDATE 1
On 16/01/2022 14:23, Marco Sulla wrote:
I think it could also be cool to create a literal frozenset this way:
a = fs{1, 2, 3}
or, why not, a frozenset comprehension:
a = fs{i+1 for i in range(3)}
Maybe too much?
+0.5
It would be nice for consistency (and perhaps performance). But you can
How about
fs{1, 2, 3}
?
Best wishes
Rob Cliffe
On 16/01/2022 12:41, Chris Angelico wrote:
On Sun, Jan 16, 2022 at 11:18 PM Steven D'Aprano wrote:
On Sun, Jan 16, 2022 at 09:18:40PM +1100, Chris Angelico wrote:
While it's tempting, it does create an awkward distinction.
f(1, 2, 3) #
On Sun, Jan 16, 2022 at 11:18 PM Steven D'Aprano wrote:
>
> On Sun, Jan 16, 2022 at 09:18:40PM +1100, Chris Angelico wrote:
>
> > While it's tempting, it does create an awkward distinction.
> >
> > f(1, 2, 3) # look up f, call it with parameters
> > f[1, 2, 3] # look up f, subscript it with
On Sun, Jan 16, 2022 at 09:18:40PM +1100, Chris Angelico wrote:
> While it's tempting, it does create an awkward distinction.
>
> f(1, 2, 3) # look up f, call it with parameters
> f[1, 2, 3] # look up f, subscript it with paramters
> f{1, 2, 3} # construct a frozenset
You forgot
f"1, 2,
1 - 100 of 101 matches
Mail list logo
