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 03:11, Cameron Simpson wrote:
On 16Jan2022 20:57, MRAB wrote:
There was a discussion on another forum that mentioned the 'input'
function, and it made me wonder whether 'input' should be printing the
prompt to stderr instead of stdout.
The convention is for normal output to go
On 16Jan2022 20:57, MRAB wrote:
>There was a discussion on another forum that mentioned the 'input'
>function, and it made me wonder whether 'input' should be printing the
>prompt to stderr instead of stdout.
>
>The convention is for normal output to go to stdout and error messages
>to go to
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})
...
>>>
There was a discussion on another forum that mentioned the 'input'
function, and it made me wonder whether 'input' should be printing the
prompt to stderr instead of stdout.
The convention is for normal output to go to stdout and error messages
to go to stderr, so if a program needs to ask
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
Example use cases:
- Loop variables and similar, it is sometimes more comfortable to scope
it to the loop body only
- Not having to name variables var1, var2, var3, or makeup unnecessarily
unique variable names, in some situations
In other languages the curly bracket is used, in
Jelle Zijlstra wrote:
> > I like this too. A practical issue is that list[(a, b)] and list[a, b] look
> the same to the compiler, but they would mean very different things. It's
> not obvious how to fix this in a backward-compatible way.
> > I think it looks much cleaner, and if there isn't any
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,
On Sun, Jan 16, 2022 at 7:35 PM Steven D'Aprano wrote:
> How does this work for you?
>
> f{1, 2, 3}
>
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
Inspired by this enhancement request:
https://bugs.python.org/issue46393
I thought it might be time to revist the idea of a frozenset display.
This has been discussed a few times before, such as here:
https://mail.python.org/pipermail/python-ideas/2018-July/051902.html
We have displays for
40 matches
Mail list logo
