subject:"\[Python\-ideas\] Re\: Revisiting a frozenset display literal"

On Wed, Jan 19, 2022 at 10:30:05AM -0300, Joao S. O. Bueno wrote:
> Maybe the "special optimizable method" will solve some of the problems, and
> appraise the "no new syntax" folks.
[...]

I pretty much agree with everything Joao says here. The hypothetical 
peephole optimization trick for {1, 2, 3}.frozen() is a nifty trick, but 
it is a poor second cousin to a real frozenset display syntax.

Still, it's an option that shouldn't be dismissed out of hand.

-- 
Steve
___
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/B4P3VCQFVUN4XXUCCUMW343E63JRE2Q6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 do:

[1, 2, 3].frozen()

when you can just write `(1, 2, 3)`. Same for bytearray and bytes.

We already have display or literal syntax for frozen lists and frozen 
bytearrays. It is only frozensets which don't, and since people cannot 
agree on syntax for a frozenset display, we're stuck with approaching it 
side-ways: a method call which, if applied to a set display of literals, 
could be safely optimized out by the compiler.

The rest of the time, someset.frozen() would just call frozenset.

-- 
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/WVMP4PW2K66I6KVYWQU3FSDMB7XB7TSB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-19 Thread Joao S. O. Bueno

Maybe the "special optimizable method" will solve some of the problems, and
appraise the "no new syntax" folks. But IMHO, it (1) it is more verbose
than the prefix/suffix new syntax alternatives, to the point of getting
in the way of reading

mysets = [{1 ,2 ,3 }.freeze(), {4,5,6}.freeze()]
X
mysets = [{f{1, 2, 3}, f{4, 5, 6}]

and (2), as stated, although introducing no new syntax, require
fiddling in a couple of places in order to actually work in an optimized
way,
and the optimization would end up as an "implementation detail".

(In order not to generate yet another message): I've seem no new arguments
by the opponents of "f{...}"at all - but re-stating that "strings are
different than sets".
Indeed: strings(bytestrings, raw, fstrings) have a lot of factors in common
that the
other built-in datatypes don't share. But the prefix thing is orthogonal to
that,
and the same motivations that led to the introduction of quote-prefixes for
strings
to start with apply here, with no drawbacks. As already stated
in other messages, calling it a "bug magnet" is a gross exaggeration. One
would
get a "NameError" on the first try and have it either fixed seconds later,
or revisiting the concept of functions and calling functions, which would
be needed anyway, in case the person in error is a begginner
to programming in general.

best regards,

   js
  -><-

On Wed, Jan 19, 2022 at 10:14 AM Steven D'Aprano 
wrote:

> On Wed, Jan 19, 2022 at 01:56:54PM +0100, Marco Sulla wrote:
>
> > PEP 351 for the frozen protocol was rejected. I didn't read why, but
> > it's probably hard to resurrect.
>
> This is not a proposal for a generic frozen protocol. It is a simple
> proposal for a set method that returns a frozenset, with the aim that
> the peephole optimiser will be able to optimise the call out for set
> displays consisting only of literals.
>
>
> --
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-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/BH2VZ3RSI3KRQ4F6P6HHZ23APR6CBQ3R/
> 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/PPON7EOH7ZFQDEQNACMLPR3RQS55ZUKQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 the code as best as possible.

`{1, 2, 3}.frozen` says that the result is an attribute (property, 
member) of the set. Like *name* to a person, or *tail* to a dog, the 
attribute API represents something which is part of, or a quality of, 
the object. The frozenset is not an attribute of the set, it is a 
transformation of the set into a different type.

A transformation should be written as an explicit function or method 
call, not as attribute access. Yes, we can hide that transformation 
behind a property just to save typing two characters, but that is an 
abuse of notation.

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.

-- 
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/WS5IXNJKETM5JICWCYJPDOF2HNK75DNK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

On Wed, Jan 19, 2022 at 01:56:54PM +0100, Marco Sulla wrote:

> PEP 351 for the frozen protocol was rejected. I didn't read why, but
> it's probably hard to resurrect.

This is not a proposal for a generic frozen protocol. It is a simple 
proposal for a set method that returns a frozenset, with the aim that 
the peephole optimiser will be able to optimise the call out for set 
displays consisting only of literals.

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-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/BH2VZ3RSI3KRQ4F6P6HHZ23APR6CBQ3R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-19 Thread Ricky Teachey

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, 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 a proposal for docstrings:
>
> https://bugs.python.org/issue36906
>
> This would be safe to optimize at compile time, so long as the contents
> of the set were all literals. And for implementations that didn't
> optimize at compile time, it would be no worse than the situation now.
>
> Perhaps a better name would be "frozen()` since that doesn't imply
> an in-place operation like "freeze" does.
>
>
>
> --
> 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/B3GTIXHL6QBJP5BIBAPP2TUQ2EO3GNPO/
> 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/TEBK2PJAKKWE52FE7XJVC4WEFZKWRUGD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 a proposal for docstrings:

https://bugs.python.org/issue36906

This would be safe to optimize at compile time, so long as the contents 
of the set were all literals. And for implementations that didn't 
optimize at compile time, it would be no worse than the situation now.

Perhaps a better name would be "frozen()` since that doesn't imply 
an in-place operation like "freeze" does.

-- 
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/B3GTIXHL6QBJP5BIBAPP2TUQ2EO3GNPO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Chris Angelico

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 of sets which could also be used at run 
> time. It would return a new frozenset object and wouldn't alter the set 
> object (so perhaps the name I suggested isn't ideal). Of course 
> frozenset.freeze would just return itself.
>

+0.5. I'm not sure if CPython is currently optimizing this (I tried
"spam".upper() and it didn't constant-fold), but it certainly could.
Making this work would depend on several optimizations:

1) Recognize literal.method() as being potentially constant-foldable
2) Marke some methods as pure and therefore optimizable
3) Recognize that the (mutable) set to the left of .freeze() can be
frozen just as "a in {1,2,3}" can

But yes, in theory, this could work. There's no way that it can be
semantically wrong, no way to shadow that method.

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/YDESIUXVULQMTYTRT65FT7SSWER3EELA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Paul Bryan

+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 method of sets which could also be used at
> run time. It would return a new frozenset object and wouldn't alter
> the set object (so perhaps the name I suggested isn't ideal). Of
> course frozenset.freeze would just return itself.
> 
> ___
> 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/LYGTXEHMUVVPC3DAHUDLMKLP2574GX5L/
> 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/TG7HGCXR3OVR25GPSWXVDRROSUALBES6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Ben Rudiak-Gould

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 frozenset object and wouldn't alter the set
object (so perhaps the name I suggested isn't ideal). Of course
frozenset.freeze would just return itself.
___
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/LYGTXEHMUVVPC3DAHUDLMKLP2574GX5L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread MRAB


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 all the builtin types and functions, frozenset is a
   keyword.

Shadowing of builtin functions is a double-edged feature. But I think
that, having made the decision to make them *not* keywords, they
should either *all* be keywords, or *none*. It is weird to have some of
them shadowable and some of them not.

None, True and False are special values, in a category of their own, so
I don't think the inconsistency there is important. But having frozenset
_alone_ out of the builtin functions and types a keyword would be a real
Wat? moment.

I know about "foolish consistency", but then there is also foolish
inconsistency. If we could just make one builtin function/type a
keyword, with all the optimization advantages that allows for, would we
*really* choose frozenset as the most important?

I don't know, the answer isn't clear to me. But it certainly wouldn't
be my first choice.

A suggestion (that you're probably not going to like!) would be to have 
a way of indicating explicitly that you're referring a builtin, e.g. 
`frozenset` (using backticks).


You could redefine "frozenset", but `frozenset` still refers to the 
builtin "frozenset".

___
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/2TEC75RRPQNK3RUPZGXDH56QHK565A62/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Steven D'Aprano

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 is a 
  keyword.

Shadowing of builtin functions is a double-edged feature. But I think 
that, having made the decision to make them *not* keywords, they 
should either *all* be keywords, or *none*. It is weird to have some of 
them shadowable and some of them not.

None, True and False are special values, in a category of their own, so 
I don't think the inconsistency there is important. But having frozenset 
_alone_ out of the builtin functions and types a keyword would be a real 
Wat? moment.

I know about "foolish consistency", but then there is also foolish 
inconsistency. If we could just make one builtin function/type a 
keyword, with all the optimization advantages that allows for, would we 
*really* choose frozenset as the most important?

I don't know, the answer isn't clear to me. But it certainly wouldn't 
be my first choice.


-- 
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/GCGTIGNJRFXFK66FRR57TEWATQPRLEQE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Greg Ewing


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 a constant
set would immediately benefit from it.

--
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 archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DWNELMJRPH5MJDKS2USTCS2FU5O4RY7H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Greg Ewing


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 a constant
set would immediately benefit from it.

--
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 archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X72PHEE2Y7IO5VI7XDGZM7MJTG3XSSID/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Jonathan Crall

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 <
python-ideas@python.org> wrote:

>
>
> 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 should create dicts).  If you want an empty frozenset, you
> >> would have to do it the same way you do it for sets: either
> >> frozenset() or f{*()}.
> >>
> > [snip]
> > An alternative might be to allow {,} for an empty set, which would
> > then let you have f{,} for an empty frozenset.
> I like it!
> Rob Cliffe
> ___
> 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/HXJXYO5A7CO6HZHBQEFYS5Q7IHKSY7Y3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
-Dr. Jon Crall (him)
___
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/JMTIQSP6IKXZWZSWWWJME2HLPASJVMXM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread 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 should create dicts).  If you want an empty frozenset, you 
would have to do it the same way you do it for sets: either 
frozenset() or f{*()}.



[snip]
An alternative might be to allow {,} for an empty set, which would 
then let you have f{,} for an empty frozenset.

I like it!
Rob Cliffe
___
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/HXJXYO5A7CO6HZHBQEFYS5Q7IHKSY7Y3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread MRAB

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 empty frozenset, you 
would have to do it the same way you do it for sets: either frozenset() 
or f{*()}.

[snip]
An alternative might be to allow {,} for an empty set, which would then 
let you have f{,} for an empty frozenset.

On Tuesday, January 18, 2022 at 1:19:30 PM UTC-5 João Bernardo wrote:

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
 wrote:

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 Teachey wrote:

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 looking for a way of spelling a frozenset
literal than just filling in "frozenset()".
I for one, even knowing that the cost of
writing "frozenset({1,2,3})" is negligible, would
"feel" better there was a way to spell that without the
needless conversions.

That said, an appropriate prefix for the {} just as we do
for strigns would be nice, and
I disagree that it would be a significant source for
"bugs". The "@{" is a nice
way out if people think "f{}" would be too close to "f()".
And "<1,2,3>" just for frozensets
are indeed overkill. We already do "literal prefixing"
with `"` after all. and formally extending this
prefix usage as needed for other literals seems like a
nice path.
But, as far as bikeshedding go, we also have "literal
sufixing" (2.0j anyone?)- maybe
"{1,2,3}f" ?

I have been following along with not much to comment but this
response sparked something in me.

After reading all the viewpoints I think I would be +1 on the
basic idea, and a +1 on the postfix/suffix syntax just
suggested... the other syntaxes I'm more of +0.5

I like the way the suffix FLOWS with the act of writing the
program. When I write a set, I am primarily focused on /what I
am going to put in it/, and whether or not it should be
mutable is kind of a later thought/debate in my head after I
have established what it contains.

As a dumb example, if my task at hand is "I need to create a
bag of sports balls", I am mostly thinking about what goes
into that bag at first, so I will write that first:

   >>> {Ball("basketball"), Ball("soccer"), Ball("football"),
Ball("golf")}

Now I get to the end of that line, and I then sort of
naturally think "ok does it make sense to freeze this" after i
know what is in it.  With the postfix syntax, I then either
type the f:

   >>> {Ball("basketball"), Ball("soccer"), Ball("football"),
Ball("golf")}f

...or not. With a prefix type syntax, or a smooth bracket
syntax, either:

A. it takes slightly more "work' at this point to "convert"
the set to a frozenset, OR
B. i have to think about ahead of time-- before i have
actually written what is in the set- whether it will be
frozen, or not.

In contrast, when you are deciding whether to write a list vs
a tuple, you are deciding between two things that are
fundamentally far more different IDEAS than a "bag of things,
frozen or unfrozen". A list is very often more of an open
ended stack than it is "an unfrozen tuple". A tuple is very
often much more of an object that can be used as a dictionary
key, or a member of a set, than it is a container of things
(of course, it is a container of things, too). These
differences make is a lot easier to choose, ahead of time,
which one makes sense before you have even written the line of
code.

Maybe I'm making too much of this, but I really like the idea

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Neil Girdhar

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 
same way you do it for sets: either frozenset() or f{*()}.

Best

Neil

On Tuesday, January 18, 2022 at 1:19:30 PM UTC-5 João Bernardo wrote:

>
> 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...@python.org> wrote:
>
>> 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 Teachey wrote:
>>
>> 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 looking for a way of spelling a frozenset literal than just 
>>> filling in "frozenset()". 
>>> I for one, even knowing that the cost of writing "frozenset({1,2,3})" is 
>>> negligible, would 
>>> "feel" better there was a way to spell that without the needless 
>>> conversions.
>>>
>>> That said, an appropriate prefix for the {} just as we do for strigns 
>>> would be nice, and
>>> I disagree that it would be a significant source for "bugs". The "@{" is 
>>> a nice
>>> way out if people think "f{}" would be too close to "f()". And "<1,2,3>" 
>>> just for frozensets
>>> are indeed overkill. We already do "literal prefixing" with `"` after 
>>> all. and formally extending this
>>> prefix usage as needed for other literals seems like a nice path. 
>>> But, as far as bikeshedding go, we also have "literal sufixing" (2.0j 
>>> anyone?)- maybe
>>> "{1,2,3}f" ? 
>>>
>>
>> I have been following along with not much to comment but this response 
>> sparked something in me.
>>
>> After reading all the viewpoints I think I would be +1 on the basic idea, 
>> and a +1 on the postfix/suffix syntax just suggested... the other syntaxes 
>> I'm more of +0.5
>>
>> I like the way the suffix FLOWS with the act of writing the program. When 
>> I write a set, I am primarily focused on *what I am going to put in it*, 
>> and whether or not it should be mutable is kind of a later thought/debate 
>> in my head after I have established what it contains.
>>
>> As a dumb example, if my task at hand is "I need to create a bag of 
>> sports balls", I am mostly thinking about what goes into that bag at first, 
>> so I will write that first:
>>
>>>>> {Ball("basketball"), Ball("soccer"), Ball("football"), 
>> Ball("golf")} 
>>
>> Now I get to the end of that line, and I then sort of naturally think "ok 
>> does it make sense to freeze this" after i know what is in it.  With the 
>> postfix syntax, I then either type the f:
>>
>>>>> {Ball("basketball"), Ball("soccer"), Ball("football"), 
>> Ball("golf")}f
>>
>> ...or not. With a prefix type syntax, or a smooth bracket syntax, either:
>>
>> A. it takes slightly more "work' at this point to "convert" the set to a 
>> frozenset, OR
>> B. i have to think about ahead of time-- before i have actually written 
>> what is in the set- whether it will be frozen, or not.
>>
>> In contrast, when you are deciding whether to write a list vs a tuple, 
>> you are deciding between two things that are fundamentally far more 
>> different IDEAS than a "bag of things, frozen or unfrozen". A list is very 
>> often more of an open ended stack than it is "an unfrozen tuple". A tuple 
>> is very often much more of an object that can be used as a dictionary key, 
>> or a member of a set, than it is a container of things (of course, it is a 
>> container of things, too). These differences make is a lot easier to 
>> choose, ahead of time, which one makes sense before you have even written 
>> the line of code.
>>
>> Maybe I'm making too much of this, but I really like the idea of deciding 
>> at the END of the set literal whether to tack on that "f".
>>
>> ---
>> 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...@python.org
>> To unsubscribe send an email to 
>> python-id...@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at 
>>

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread João Bernardo

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> wrote:

> 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 Teachey wrote:
>
> 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 looking for a way of spelling a frozenset literal than just
>> filling in "frozenset()".
>> I for one, even knowing that the cost of writing "frozenset({1,2,3})" is
>> negligible, would
>> "feel" better there was a way to spell that without the needless
>> conversions.
>>
>> That said, an appropriate prefix for the {} just as we do for strigns
>> would be nice, and
>> I disagree that it would be a significant source for "bugs". The "@{" is
>> a nice
>> way out if people think "f{}" would be too close to "f()". And "<1,2,3>"
>> just for frozensets
>> are indeed overkill. We already do "literal prefixing" with `"` after
>> all. and formally extending this
>> prefix usage as needed for other literals seems like a nice path.
>> But, as far as bikeshedding go, we also have "literal sufixing" (2.0j
>> anyone?)- maybe
>> "{1,2,3}f" ?
>>
>
> I have been following along with not much to comment but this response
> sparked something in me.
>
> After reading all the viewpoints I think I would be +1 on the basic idea,
> and a +1 on the postfix/suffix syntax just suggested... the other syntaxes
> I'm more of +0.5
>
> I like the way the suffix FLOWS with the act of writing the program. When
> I write a set, I am primarily focused on *what I am going to put in it*,
> and whether or not it should be mutable is kind of a later thought/debate
> in my head after I have established what it contains.
>
> As a dumb example, if my task at hand is "I need to create a bag of sports
> balls", I am mostly thinking about what goes into that bag at first, so I
> will write that first:
>
>>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
> Ball("golf")}
>
> Now I get to the end of that line, and I then sort of naturally think "ok
> does it make sense to freeze this" after i know what is in it.  With the
> postfix syntax, I then either type the f:
>
>>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
> Ball("golf")}f
>
> ...or not. With a prefix type syntax, or a smooth bracket syntax, either:
>
> A. it takes slightly more "work' at this point to "convert" the set to a
> frozenset, OR
> B. i have to think about ahead of time-- before i have actually written
> what is in the set- whether it will be frozen, or not.
>
> In contrast, when you are deciding whether to write a list vs a tuple, you
> are deciding between two things that are fundamentally far more different
> IDEAS than a "bag of things, frozen or unfrozen". A list is very often more
> of an open ended stack than it is "an unfrozen tuple". A tuple is very
> often much more of an object that can be used as a dictionary key, or a
> member of a set, than it is a container of things (of course, it is a
> container of things, too). These differences make is a lot easier to
> choose, ahead of time, which one makes sense before you have even written
> the line of code.
>
> Maybe I'm making too much of this, but I really like the idea of deciding
> at the END of the set literal whether to tack on that "f".
>
> ---
> 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-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/
> 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/VRGSQR7ISWFLKJTFDYWRNBGA47ECFDRU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Rob Cliffe via Python-ideas

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 Teachey wrote:
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 looking for a way of spelling a frozenset literal than
just filling in "frozenset()".
I for one, even knowing that the cost of
writing "frozenset({1,2,3})" is negligible, would
"feel" better there was a way to spell that without the needless
conversions.

That said, an appropriate prefix for the {} just as we do for
strigns would be nice, and
I disagree that it would be a significant source for "bugs". The
"@{" is a nice
way out if people think "f{}" would be too close to "f()". And
"<1,2,3>" just for frozensets
are indeed overkill. We already do "literal prefixing" with `"`
after all. and formally extending this
prefix usage as needed for other literals seems like a nice path.
But, as far as bikeshedding go, we also have "literal sufixing"
(2.0j anyone?)- maybe
"{1,2,3}f" ?

I have been following along with not much to comment but this response
sparked something in me.

After reading all the viewpoints I think I would be +1 on the basic
idea, and a +1 on the postfix/suffix syntax just suggested... the
other syntaxes I'm more of +0.5

I like the way the suffix FLOWS with the act of writing the program.
When I write a set, I am primarily focused on /what I am going to put
in it/, and whether or not it should be mutable is kind of a later
thought/debate in my head after I have established what it contains.

As a dumb example, if my task at hand is "I need to create a bag of
sports balls", I am mostly thinking about what goes into that bag at
first, so I will write that first:

>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
Ball("golf")}

Now I get to the end of that line, and I then sort of naturally think
"ok does it make sense to freeze this" after i know what is in it.
With the postfix syntax, I then either type the f:

>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
Ball("golf")}f

...or not. With a prefix type syntax, or a smooth bracket syntax, either:

A. it takes slightly more "work' at this point to "convert" the set to
a frozenset, OR
B. i have to think about ahead of time-- before i have actually
written what is in the set- whether it will be frozen, or not.

In contrast, when you are deciding whether to write a list vs a tuple,
you are deciding between two things that are fundamentally far more
different IDEAS than a "bag of things, frozen or unfrozen". A list is
very often more of an open ended stack than it is "an unfrozen tuple".
A tuple is very often much more of an object that can be used as a
dictionary key, or a member of a set, than it is a container of things
(of course, it is a container of things, too). These differences make
is a lot easier to choose, ahead of time, which one makes sense before
you have even written the line of code.

Maybe I'm making too much of this, but I really like the idea of
deciding at the END of the set literal whether to tack on that "f".

---
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 topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived
athttps://mail.python.org/archives/list/python-ideas@python.org/message/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/
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/VRGSQR7ISWFLKJTFDYWRNBGA47ECFDRU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Ricky Teachey

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 looking for a way of spelling a frozenset literal than just
> filling in "frozenset()".
> I for one, even knowing that the cost of writing "frozenset({1,2,3})" is
> negligible, would
> "feel" better there was a way to spell that without the needless
> conversions.
>
> That said, an appropriate prefix for the {} just as we do for strigns
> would be nice, and
> I disagree that it would be a significant source for "bugs". The "@{" is a
> nice
> way out if people think "f{}" would be too close to "f()". And "<1,2,3>"
> just for frozensets
> are indeed overkill. We already do "literal prefixing" with `"` after all.
> and formally extending this
> prefix usage as needed for other literals seems like a nice path.
> But, as far as bikeshedding go, we also have "literal sufixing" (2.0j
> anyone?)- maybe
> "{1,2,3}f" ?
>

I have been following along with not much to comment but this response
sparked something in me.

After reading all the viewpoints I think I would be +1 on the basic idea,
and a +1 on the postfix/suffix syntax just suggested... the other syntaxes
I'm more of +0.5

I like the way the suffix FLOWS with the act of writing the program. When I
write a set, I am primarily focused on *what I am going to put in it*, and
whether or not it should be mutable is kind of a later thought/debate in my
head after I have established what it contains.

As a dumb example, if my task at hand is "I need to create a bag of sports
balls", I am mostly thinking about what goes into that bag at first, so I
will write that first:

   >>> {Ball("basketball"), Ball("soccer"), Ball("football"), Ball("golf")}

Now I get to the end of that line, and I then sort of naturally think "ok
does it make sense to freeze this" after i know what is in it.  With the
postfix syntax, I then either type the f:

   >>> {Ball("basketball"), Ball("soccer"), Ball("football"), Ball("golf")}f

...or not. With a prefix type syntax, or a smooth bracket syntax, either:

A. it takes slightly more "work' at this point to "convert" the set to a
frozenset, OR
B. i have to think about ahead of time-- before i have actually written
what is in the set- whether it will be frozen, or not.

In contrast, when you are deciding whether to write a list vs a tuple, you
are deciding between two things that are fundamentally far more different
IDEAS than a "bag of things, frozen or unfrozen". A list is very often more
of an open ended stack than it is "an unfrozen tuple". A tuple is very
often much more of an object that can be used as a dictionary key, or a
member of a set, than it is a container of things (of course, it is a
container of things, too). These differences make is a lot easier to
choose, ahead of time, which one makes sense before you have even written
the line of code.

Maybe I'm making too much of this, but I really like the idea of deciding
at the END of the set literal whether to tack on that "f".

---
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/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-18 Thread Joao S. O. Bueno

>  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 "frozenset()".
I for one, even knowing that the cost of writing "frozenset({1,2,3})" is
negligible, would
"feel" better there was a way to spell that without the needless
conversions.

That said, an appropriate prefix for the {} just as we do for strigns would
be nice, and
I disagree that it would be a significant source for "bugs". The "@{" is a
nice
way out if people think "f{}" would be too close to "f()". And "<1,2,3>"
just for frozensets
are indeed overkill. We already do "literal prefixing" with `"` after all.
and formally extending this
prefix usage as needed for other literals seems like a nice path.
But, as far as bikeshedding go, we also have "literal sufixing" (2.0j
anyone?)- maybe
"{1,2,3}f" ?

On Mon, Jan 17, 2022 at 2:43 PM Christopher Barker 
wrote:

> 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, but CPython automaticly creates a
>> frozenset here (set display with immutable members) as an optimisation.
>>
>
> I think it's quite relevant to the discussion, because as far as I can
> tell, better performance in particular cases is the primary motivator.
>
> Funny that this has come up -- not too long ago, I did some
> experiments with code like the above: and to the surprise of myself and
> some other long-time Pythonistas I work with, using sets, rather tha tuples
> in those kinds of constructs, e.g.:
>
> if something in :
>
> was always as faster or faster with sets than tuples. That was surprising
> because we assumed that construction of a set would be slower than
> construction of a tuple. And that was probably the case ten years ago. The
> proof is in the pudding,so I never bothered to figure out why, but now I
> know :-)
>
> Back to the topic at hand -- IIUC, set constants are already optimized, so
> the only places having a frozenset display would be when it is a constant,
> and it has to be a frozenset, where a regular one won't do.
>
> And that would only be noticeable  if it was in a function that didn't do
> much else, and was called often. And in that case, it could be put in the
> global scope to ameliorate some of that cost.
>
> I believe Stephens' point is that the benefit may be fairly small, but so
> is the cost. I'm not so sure. I kind of like the idea myself, and the cost
> does seem small, but I don't think we should underestimate the cost of even
> this small complexity increase in the language. Sure, folks don't  have
> toeven  know it exists to write fine code, but it would be one more thing
> that newbies will need to figure out when they see it in others' code.
>
> In fact, there' a lot of what I might call "Python Scripters" that aren't
> even familiar with the set display at all.
>
> -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/Q2VUUY6I4JJHQOHMO2JMMRPZGVZU44N6/
> 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/VB4OI47LQ4PMNG6IQRFIQ2BR2LZII5L3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 
looking the name up does two hash table lookups: one in globals, and if 
the name hasn't been shadowed, a second in builtins.


-- 
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/EMSUSD73ALYS3CTOLMUSCMM7SQCJIN6D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Christopher Barker

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)`.
>

Of course, everyone would -- because tuple displays already exist. I'd
suggest refactoring that code even if the compiler could completely
optimize it away.

Would you let:

 l = list([1, 2, 3, 4, 5])

pass code review either? even if there were no performance penalty? I
wouldn't, because it's redundant, not because it's slower.

Also that pattern is actually very common for types that aren't built-in
(or even in the stdlib).

It's always kind of bugged me that I need to write:

arr = np.array([1, 2, 3, 4])

And I'm creating a list just so I can pass it to the array constructor. But
in practice, it's not a performance problem at all.

And in code in the wild, I'll bet numpy arrays are used orders of
magnitude more than frozen sets ;-)

Sometimes, now, the compiler *pessimizes* the construction of the frozen
> set. See b.p.o #46393.
>

yup. Using a 'constant' frozenset is slower than 'constant' set, when doing
not much else:

In [29]: def setfun():
...: s = {1, 3, 5, 2}
...: i = 3
...: if i in s:
...: return 'yes'
...:

In [30]: def fsetfun():
...: s = frozenset((1, 3, 5, 2))
...: i = 3
...: if i in s:
...: return 'yes'
...:

In [31]: %timeit setfun()
194 ns ± 10.6 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [32]: %timeit fsetfun()
286 ns ± 2.72 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)

But: would you notice if that function did any real work?

And I think we could call this one of the many micro-optimizations we have
in Python:

Don't use a frozenset as a constant when a regular set will do.

So it comes down to how often frozen sets as constants are required.

-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/DPNGLQ6BCLSZPV3LGXACPTDPWIIK66DD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Christopher Barker

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, but CPython automaticly creates a
> frozenset here (set display with immutable members) as an optimisation.
>

I think it's quite relevant to the discussion, because as far as I can
tell, better performance in particular cases is the primary motivator.

Funny that this has come up -- not too long ago, I did some
experiments with code like the above: and to the surprise of myself and
some other long-time Pythonistas I work with, using sets, rather tha tuples
in those kinds of constructs, e.g.:

if something in :

was always as faster or faster with sets than tuples. That was surprising
because we assumed that construction of a set would be slower than
construction of a tuple. And that was probably the case ten years ago. The
proof is in the pudding,so I never bothered to figure out why, but now I
know :-)

Back to the topic at hand -- IIUC, set constants are already optimized, so
the only places having a frozenset display would be when it is a constant,
and it has to be a frozenset, where a regular one won't do.

And that would only be noticeable  if it was in a function that didn't do
much else, and was called often. And in that case, it could be put in the
global scope to ameliorate some of that cost.

I believe Stephens' point is that the benefit may be fairly small, but so
is the cost. I'm not so sure. I kind of like the idea myself, and the cost
does seem small, but I don't think we should underestimate the cost of even
this small complexity increase in the language. Sure, folks don't  have
toeven  know it exists to write fine code, but it would be one more thing
that newbies will need to figure out when they see it in others' code.

In fact, there' a lot of what I might call "Python Scripters" that aren't
even familiar with the set display at all.

-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/Q2VUUY6I4JJHQOHMO2JMMRPZGVZU44N6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread MRAB

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:

>>> @{1, 2, 3}

Looks like a decorator there, but you could parenthesise it in that case:

>>> (@{1, 2, 3})
___
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/AVVD6YWOEKOOJWB53UAQJZCQSMXAM3AG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Ronald Oussoren via Python-ideas



> 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 set? I ask because I do 
> often use sets that could be frozen, but don’t need to be. E.g. they don’t 
> change, nor are they used as keys.
> 
> 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, but CPython automaticly creates a 
frozenset here (set display with immutable members) as an optimisation.

>>> dis.dis("x in {1,2,3}")
  1   0 LOAD_NAME0 (x)
  2 LOAD_CONST   0 (frozenset({1, 2, 3}))
  4 CONTAINS_OP  0
  6 RETURN_VALUE

AFAIK the primary advantage of doing this is that the frozenset gets created 
once instead of every time the expression is executed.  Frozenset itself is not 
faster than a regular set.

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
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/GPAWWSBPPUYXUPQGSIZMD2RO3UF3HWH6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Jonathan Fine

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 {1,2,3}" and in "for x in {1,2,3}") the compiler does
it.

And I don't think there is an issue which is worth changing the language.
Creating a frozenset of constants is pretty rare, and it is even more rare
in tight loops. The most common cases (which are pretty rare anyway) are
already covered.

-- 
Jonathan
___
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/7WVR2TY6PQQ6H4EG2JCAJGWPS42D57BF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Jelle Zijlstra

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 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.
> > >
> >
> > I meant it is negligible so we can just ignore it while this discussion.
>
> On my computer, the name lookup is almost a quarter of the time to build
> a set:
>
> [steve ~]$ python3.10 -m timeit "frozenset"
> 1000 loops, best of 5: 24.4 nsec per loop
> [steve ~]$ python3.10 -m timeit "{1, 2, 3, 4, 5}"
> 200 loops, best of 5: 110 nsec per loop
>
> and about 10% of the total time:
>
> [steve ~]$ python3.10 -m timeit "frozenset({1, 2, 3, 4, 5})"
> 100 loops, best of 5: 237 nsec per loop
>
> If I use a tuple instead of the set, it is about 12% of the total time:
>
> [steve ~]$ python3.10 -m timeit "frozenset((1, 2, 3, 4, 5))"
> 200 loops, best of 5: 193 nsec per loop
>
> So not negligible.
>
> 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.

>
>
>
> --
> 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/YL2DW3GDYQZS4HEOIUG6T25HAUL3DGAQ/
> 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/EOAX3UEMBOCNWULBV2K54TUNFMWTT2XM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 important at all.
> >
> > But the cost to look up the name is *in addition* to building the set.
> >
> 
> I meant it is negligible so we can just ignore it while this discussion.

On my computer, the name lookup is almost a quarter of the time to build 
a set:

[steve ~]$ python3.10 -m timeit "frozenset"
1000 loops, best of 5: 24.4 nsec per loop
[steve ~]$ python3.10 -m timeit "{1, 2, 3, 4, 5}"
200 loops, best of 5: 110 nsec per loop

and about 10% of the total time:

[steve ~]$ python3.10 -m timeit "frozenset({1, 2, 3, 4, 5})"
100 loops, best of 5: 237 nsec per loop

If I use a tuple instead of the set, it is about 12% of the total time:

[steve ~]$ python3.10 -m timeit "frozenset((1, 2, 3, 4, 5))"
200 loops, best of 5: 193 nsec per loop

So not negligible.




-- 
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/YL2DW3GDYQZS4HEOIUG6T25HAUL3DGAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Inada Naoki

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* to building the set.
>

I meant it is negligible so we can just ignore it while this discussion.

> 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)`.
>

* I never said it. I just said just lookup cost is not good reason
because you listed name lookup cost for rationale. Please stop
strawman.
* tuple construction is much faster than set construction. So name
lookup speed is more important for tuple.
* Constant tuple is much much frequently used than constant set.

>
> > Proposed literal might have significant efficiency benefit only when:
> >
> > * It is used in the function scope. and,
> > * It can not be optimized by the compiler now.
>
> Sometimes, now, the compiler *pessimizes* the construction of the frozen
> set. See b.p.o #46393.
>

I saw. And I know all the discussions in the b.p.o. already.
But how important it is for Python depends on how often it is used,
especially in hot code.

Regards,

-- 
Inada Naoki  
___
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/DSUYXZBLQ62MMRUYJ2ZNLDXYSEEOGDHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Jonathan Fine

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):
repr(obj, /)
Return the canonical string representation of the object.
For many object types, including most builtins, eval(repr(obj)) ==
obj.

Consistency suggests that if
x = f{1, 2, 3}
gives always gives frozenset as the value of x then
repr(x)
should be the string 'f{1, 2, 3}'. At present, I think, repr(x) always
returns a literal if it can.

However, changing the repr of frozenset introduces problems of backwards
compatibility, particularly in doctests and documentation.

Another way to achieve consistency is to make frozenset a keyword, in the
same way that None, True and False are identifiers that are also language
keywords.

Both proposals as stated have negative side-effects. I suggest we explore
ways of reducing the above and any other side effects.

-- 
Jonathan
___
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/L3TVX5Z52DGOPV4LUUB2GNIW7IVLK3IG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 = 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)`.


> Proposed literal might have significant efficiency benefit only when:
> 
> * It is used in the function scope. and,
> * It can not be optimized by the compiler now.

Sometimes, now, the compiler *pessimizes* the construction of the frozen 
set. See b.p.o #46393.


-- 
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/NJZJI5G5FNPSBH2WTJWGTCHHCFB4WEM3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 not a name but just a 
> syntactic marker (as in f-strings).

I think the horse has well and truly bolted on that. We've had syntactic 
markers that look like names forever: r"" goes back to Python 1.x days.

Given the proposed syntax `f{a, b, c}`, that would be a transformation 
of three arguments a, b and c to a frozenset. That makes it closer to a 
function call than r"abc", which is not a transformation at all.

So if this looks like a function call, good, that's because semantically 
it is kind of like a function call.

>   In the second place, I don't like the idea of using prefixes to 
>   change the types of objects like this.  As far as I know we only have 
> one 
> example of that, namely byte strings.

Okay, so we have a precedence where a prefix on the delimiter changes 
the type: b'' is a different type to ''. In Python 2, it was the other 
way around, it was u'' that returned a different type.

I think that the use of a prefix has been a moderately good design, good 
enough to cautiously extend it beyond raw strings to unicode strings, 
f-strings, and byte-strings, and beyond that to other delimiters.

But if you think that the difference between '' and b'' is a terrible 
design flaw that has caused all sorts of badness in Python 3, I'm all 
ears. Please explain, and persuade me.

>   I would prefer some sort of augmented bracket notation, like {:1, 2, 
> 3:} or something along those lines.

You don't think that people will associate {:1, 2:} with badly-written 
dicts rather than sets? If not, is there some sort of mental association 
between frozensets and those colons inside the set syntax?

-- 
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/RLIY4HZD2HVK42GLXFZGTG3UH6DVXZPQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Inada Naoki

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:   ignore_log_types = frozenset({'warning'})  # f{'warning'}
>

Both are in class scope so the overhead is very small.

> Not all of them are purely literals, e.g.
>
> asyncore.py:   _DISCONNECTED = frozenset({ECONNRESET, ENOTCONN, ...})
>
> would still have to generate the frozenset at runtime, but it wouldn't
> need to look up the frozenset name to do so so there would still be some
> benefit.

Name lookup is faster than building set in most case.
So I don't think cost to look name up is important at all.

Proposed literal might have significant efficiency benefit only when:

* It is used in the function scope. and,
* It can not be optimized by the compiler now.

I am not sure how many such usages in stdlib.

Regards,

-- 
Inada Naoki  
___
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/GL6KUTJZ67CQ37NK64LJF4XTPAS564OA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Inada Naoki

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, 12, 18, 27, 28, 30, 35, 57, 88)
> > if n in targets:
> > do_something()
> >
> > to use a frozenset, as they probably should already be doing.
>
> More realistically, would they not use a set already, as in
>
> targets = {3, 5, 7, 11, 12, 18, 27, 28, 30, 35, 57, 88}
> if n in targets:
> do_something()
>
> ?
>

This is very inefficient because building a set is much heavier in `n in tuple`.
We should write `if n in {3, 5, 7, 11, 12, 18, 27, 28, 30, 35, 57, 88}` for now.
Or we should write `_TARGETS = frozenset((3, 5, 7, 11, 12, 18, 27, 28,
30, 35, 57, 88))` in global scope and use it as `if n in _TARGETS`.

-- 
Inada Naoki  
___
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/RAW2KG77YI5GS4AXLLFKLBR3PTVE65OA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 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/M32OISXSYNR3LJQYCQPI3NJEMHQLDHQE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 frozenset display. You don't need to use a literal 
or display syntax to take advantage of interning:

# At least some versions of CPython
>>> m = int('78')
>>> n = int('78')
>>> m is n
True

And the existence of a literal or display syntax does not imply 
interning, e.g. floats, tuples.

If there was a use for interning frozensets, we could do so regardless 
of whether or not there is a display syntax.

> > (using f{...} as a frozenset literal) does something different - it
> > returns the *same* object, compiled once at function definition time,
> > every time it's called.
> >
> 
> why/how would it do that? It *could* do that -- as above, with interning.

Inside a function, CPython can cache literals and immutable displays 
made from purely literals, e.g. the tuple (1, 2, 3) but not the tuple 
(1, 2, x)) in co_consts.

But we can't do any of that if the only way to create a frozenset is to 
lookup the name "frozenset" and call that function. So while not all 
frozensets inside a function could be built at compile-time and 
retrieved from co_consts, some of them could -- if only we had a display 
syntax equivalent to tuple displays.

Ironically, if the compiler can prove that a regular mutable set display 
is only ever used once inside a function, CPython will make it a 
frozenset:

>>> def func(a):
... return a in {1, 2, 4}
... 
>>> func.__code__.co_consts
(None, frozenset({1, 2, 4}))

So ironically the only way to put a constant frozenset into co_consts is 
to write it as a mutable set and only use it once!

> We don't make changes to Python syntax unless there is a compelling reason.

"Compelling" depends on the cost of making the change. The bigger the 
cost, the more compelling the reason. The smaller the change, then the 
reason need not be as huge.

I think this is a small change with a moderate benefit, which puts the 
cost vs benefit ratio on the benefit side.

> There are any number of python types with no "literal" (well, not any
> number, it's quite defined. but still) heck, we don't even have literals
> for Decimal. Why this one?

Nearly all of those types are not builtins. As far as I can see, 
frozenset is the only commonly used, immutable, builtin type that 
doesn't have a literal display syntax, and the consequence of that is 
that code using frozensets does much more work than needed.

-- 
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/DLD52KXWR7HYLYTXOTIFCCJIULZJ2P7L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Paul Moore

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:
> do_something()
>
> to use a frozenset, as they probably should already be doing.

More realistically, would they not use a set already, as in

targets = {3, 5, 7, 11, 12, 18, 27, 28, 30, 35, 57, 88}
if n in targets:
do_something()

?

Is using a frozenset a significant improvement for that case? Because
I doubt that anyone currently using a tuple would suddenly switch to a
frozenset, if they haven't already switched to a set. Sure, there
might be the odd person who sees the release notes and is prompted by
the mention of frozenset literals to re-think their code, but that's
probably a vanishingly small proportion of the audience for this
change.

BTW, I should say that I'm actually +0.5 on the idea. It seems like a
reasonable thing to want, and if an acceptable syntax can be found,
then why not? But I doubt it's going to have a major impact either
way.

Paul
___
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/EYQC3PH3W24K7NTQ66KB3DL334LYDK5A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 should 
consider frozenset comprehensions as well. That would be an obvious 
extension of the syntax. But I don't know if there are technical 
difficulties with that proposal that might make it less attractive.

-- 
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/7IA5RXMH6A4NV6L3QRI46CQVBUSGPSSP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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:

https://mail.python.org/archives/list/python-ideas@python.org/message/GRMNMWUQXG67PXXNZ4W7W27AQTCB6UQQ/

CPython already has all the machinery needed to create constant 
frozensets of constants at compile time. It already implicitly optimizes 
some expressions involving tuples and sets into frozensets, but such 
optimizations are fragile and refactoring your code can remove them. 
Ironically, that same optimization makes the explicit creation of a 
frozenset needlessly inefficient. See also b.p.o. #46393.

The only thing we need in order to be able to explicitly create 
frozensets efficiently, without relying on fragile, implicit, 
implementation-dependent peephole optimizations which may or may not 
trigger, and without triggering the usual global+builtins name lookup, 
is (I think) syntax for a frozenset display.

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:
do_something()

to use a frozenset, as they probably should already be doing.

> As far as I can tell, it would be a handy shorthand.

If you consider tuple, list and dict displays to be a handy shortcut, 
then I guess this would be too :-)

> And you had suggested it could result in more efficient bytecode, but I
> think someone else thought that wasn't the case.

I see no reason why it wouldn't lead to more efficient bytecode, at 
least sometimes.

> But what does that matter? are they heavenly used in any common code?

Personally, I think my code using frozensets is extremely heavenly :-)

I doubt that frozensets are, or ever will be, as common as lists or 
dicts. In that sense, sets (frozen or otherwise) are, I guess, "Second 
Tier" data structures:

- first tier are lists, tuples, dicts;

- second tier are sets, deques etc.

Or possibly "tier and a half" in that unlike deques they are builtins, 
which suggest that they are somewhat more important.

In the top level of the stdlib (not dropping down into packages or 
subdirectories), I count 29 calls to frozenset.

(Compared to 14 calls to deque, so on mere call count, I would say 
frozenset is twice as important as deque :-)

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:   ignore_log_types = frozenset({'warning'})  # f{'warning'}

Not all of them are purely literals, e.g.

asyncore.py:   _DISCONNECTED = frozenset({ECONNRESET, ENOTCONN, ...})

would still have to generate the frozenset at runtime, but it wouldn't 
need to look up the frozenset name to do so so there would still be some 
benefit.

If we were particularly keen, that might go up to 19 out of the 29.

The benefit is not huge. This is not list comprehensions or decorator 
syntax, which revolutionized the way we write Python, it is an 
incremental improvement. If the compiler didn't already have the 
machinery in place for building compile-time constant frozensets, this 
might not be worth the effort.

But since we do, the cost of adding a frozenset display is relatively 
low (most of the work is already done, yes?) and so the benefit needs 
only to be small to justify the small(?) amount of work needed.

-- 
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/S7MR2EF2KPHMMT7O6E743FO34OZEZNUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Chris Angelico

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})
> > > > ...
> > > > >>> 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 object.
> > >
> > > 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, optionally with elements taken from
> > > iterable". The iterable is the (non-frozen) set {1, 2, 3}.
> >
> > Where is that definition?
>
> https://docs.python.org/3/library/functions.html#func-frozenset
>
> > According to help(frozenset), it will
> > "[b]uild an immutable unordered collection of unique elements", so it
> > doesn't necessarily have to be a brand new object.
>
> I'd read "build" as meaning it is a new object. But regardless, I view
> the language documentation as authoritative here.

That should probably be corrected, then.

> > With mutables, it
> > does have to return a new one every time (list(x) will give you a
> > shallow copy of x even if it's already a list), but with immutables,
> > it's okay to return the same one (str and tuple will return self).
>
> That's an optimisation, not a guarantee, so while it's relevant, it's
> not sufficient (IMO).
>

Hmm, not sure whether it's a guarantee or not. It's certainly a very
obvious optimization.

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/WIVALQFQRZUB67P6GY4BKTJ2USZD23SC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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.
}}, {{1, 2}}, {{'a', {{}}, None

> and for frozen dicts:

We don't even have a frozen dict in the stdlib, so I'm not going to 
discuss that here. If and when we get a frozen dict, if it is important 
enough to be a builtin, then we can debate syntax for it.

> but how often would you do that?

Often enough:

https://www.delftstack.com/howto/python/python-set-of-sets/

https://stackoverflow.com/questions/37105696/how-to-have-a-set-of-sets-in-python/37105728

https://stackoverflow.com/questions/5931291/how-can-i-create-a-set-of-sets-in-python

-- 
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/INLZ7BEWYIRGIM55EQ7D3UO3UWME3H2P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-17 Thread Paul Moore

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
> > > frozenset({1, 2, 3})
> > > >>> b = f()
> > > >>> assert a == b
> > > >>> a is b
> > > False
> > >
> > > Each time you call the function, you get a distinct frozenset object.
> >
> > 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, optionally with elements taken from
> > iterable". The iterable is the (non-frozen) set {1, 2, 3}.
>
> Where is that definition?

https://docs.python.org/3/library/functions.html#func-frozenset

> According to help(frozenset), it will
> "[b]uild an immutable unordered collection of unique elements", so it
> doesn't necessarily have to be a brand new object.

I'd read "build" as meaning it is a new object. But regardless, I view
the language documentation as authoritative here.

> With mutables, it
> does have to return a new one every time (list(x) will give you a
> shallow copy of x even if it's already a list), but with immutables,
> it's okay to return the same one (str and tuple will return self).

That's an optimisation, not a guarantee, so while it's relevant, it's
not sufficient (IMO).

However, it's not clear how relevant this is to the actual proposal,
so the precise details probably aren't that important.

Paul
___
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/7ISKPLVO3KFDGMQL5UKNBGO3QGVZWFNA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 you mean. That's a constant, so it'll always return the
>> exact same object, surely?
>
>
> I *think* that's only if it's interned -- and in any case, is a guarantee of 
> the language, or an optimization?
>
> I tried to test with a longer string, and it was the same one, but then I 
> found in this arbitrary post on the internet:
>
> ... in Python 3.7, this has been changed to 4096 characters
>
> ( I guess I haven't played with that since 3.7) -- I haven't actually tried 
> with a string literal linger than 4096 chars :-)

When you return a literal, like that, the literal becomes a function
constant. That's not necessarily a language guarantee, but I would be
hard-pressed to imagine a Python implementation that copied it for no
reason.

> But this certainly doesn't:
>
> In [1]: def fun():
>...: return [1,2,3]
>...:
>
> In [2]: l1 = fun()
>
> In [3]: l2 = fun()
>
> In [4]: l1 is l2
> Out[4]: False
>
> So the issue is immutability and interning, not "literal display".

The difference is that list display isn't a literal, but a simple
quoted string is. The square brackets are guaranteed to construct a
new list every time.

> My point is that a frozenset litteral could open the door to interning frozen 
> sets, but that could probably be done anyway. And why? Are they heavily used 
> in any code base?
>

A frozenset literal would allow the same frozenset to be reused, but
it's not about interning. You're right that interning would be
possible even without a literal, but in order to intern frozensets
without a literal, we'd still need to construct a brand new
(non-frozen) set to pass to the constructor, since there needs to be a
way to indicate which elements we want.

Technically, there are no "complex literals", but thanks to constant
folding, a value like 3+4j can become a function constant. In theory,
I could imagine a Python implementation that treats 3 and 4j as
constants, but adds them at runtime, producing a unique complex object
every time. But since there are no shadowable name lookups, it's easy
enough to take advantage and gain a nice optimization.

In theory, what could be done for frozensets would be to use a *tuple*
for the arguments, which can then be used for an intern-style lookup:

_frozenset = frozenset
_fscache = {}
def frozenset(t):
if type(t) is tuple: # strict check, don't allow subclasses
if t not in _fscache: _fscache[t] = _frozenset(t)
return _fscache[t]
return _frozenset(t)

This would remove some of the copying, but at the cost of retaining
all the tuples (in other words: now you have a classic caching
problem). Could be useful for situations where it really truly is
constant, but it's still a bit of a roundabout way to do things.

A true frozenset literal can't possibly be shadowed, so the compiler
would be free to do all the same optimizations that it does with
tuples.

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/7LRVPVKTQULH7QSF7GURV2W2MIVTWLKK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 thought that wasn't the case.

It could lead to some optimization -- literals being treated as contents,
yes?

But what does that matter? are they heavenly used in any common code?

-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/DYUT7BIWXOIEJCQSMS5XRAGGOLVZZ76A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 (f-strings). Is there any non-string type
> > that doesn't follow that pattern?
>
> So... not "ONLY" (your emphasis, not mine) strings. As you say, there
> are already two different data types, strings and bytes, plus a
> non-literal executable code (f-strings).
>
> Again, I don't understand your point. You have just told us that there
> are already non-string literals and types that use a prefix on the
> delimiter, and then you ask me if there are any non-string types that
> follows that pattern. Haven't you just answered your own question?

An f-string still yields a string. It's not a literal but it's still a
string. A bytestring is still a string. It's not a Unicode string but
it's still a string. These are not the same as lists, tuples, sets,
dicts, etc, which contain arbitrary objects.

ONLY strings. You just picked up on the part where I said "not only
literals" and got it completely backwards.

Strings are not the same as lists.

Strings are not the same as tuples.

Strings are the only data type in Python that has prefixes that
determine the data type you get.

Strings are TREATED DIFFERENTLY by programmers, which is why f-strings
get treated like string literals.

Strings. Are. Different.

I do not know how to make this any clearer. If you do not understand
my position, please stop misrepresenting me.

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/EL3EWL6OAZHVKSPVJJGOL253NBHLL2SO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Greg Ewing


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 archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M5KUU65YVZVY72VVSIW33ZANNMBAFJEH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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, surely?
>

I *think* that's only if it's interned -- and in any case, is a
guarantee of the language, or an optimization?

I tried to test with a longer string, and it was the same one, but then I
found in this arbitrary post on the internet:

... in Python 3.7, this has been changed to 4096 characters

( I guess I haven't played with that since 3.7) -- I haven't actually tried
with a string literal linger than 4096 chars :-)

But this certainly doesn't:

In [1]: def fun():
   ...: return [1,2,3]
   ...:

In [2]: l1 = fun()

In [3]: l2 = fun()

In [4]: l1 is l2
Out[4]: False

So the issue is immutability and interning, not "literal display".

My point is that a frozenset litteral could open the door to interning
frozen sets, but that could probably be done anyway. And why? Are they
heavily used in any code base?

-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/SM2SBPTFFEK7I6AHEEXYKZWRNLC4G3J7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread MRAB

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 just don't like the look of
it!", I would respect that even if I disagree. Aesthetics are important,
even when they are totally subjective.

If it helps, Julia supports this syntax for typed dicts:

 Dict{keytype, valuetype}(key => value)

where the braces {keytype, valuetype} are optional. That's not a display
syntax as such, or a prefix, but it is visually kinda similar.

Here are some similar syntax forms with prefixes:

* Dylan list displays: #(a, b, c)
* Smalltalk drops the comma separators: #(a b c)
* Scheme and Common Lisp: '(a b c)

and double delimiters:

* Pike: ({ a, b, c })
* Pike dicts: ([ a:b, c:d ])

Not that we could use any of those as-given.

How about doubling-up the braces:

{{1, 2, 3}}

and for frozen dicts:

{{1: 'one', 2: 'two', 3: 'three'}}

if needed?

Those currently raise exception because sets and dics are unhashable.

It might be confusing, though, if you try to nest them, putting a 
frozenset in a frozenset:

{{ {{1, 2, 3}} }}

or, without the extra spaces:

1, 2, 3

but how often would you do that?
___
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/JJICU47NVIU5MJYRASI6SM4J7UFWBGFQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 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/TXR242V4DHJE2MGPR7IQTSD6UYNWIMWJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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
> seriously, can't you read back to your own previous message and get
> your own context?

Speaking of context, it is not nice of you to strip the context of my 
very next sentence, in order to make me out to be the bad guy here.

"Differ in what way? I don't understand your question."

Let me repeat: I do not understand your question.

In what way do you think that non-string types differ, that is relevant 
to the discussion? There are plenty of ways that they differ. I don't 
see how those differences are meaningful. If you do, please explain.

(I see that further on, you made an attempt. Thank you, I will respond 
to that below.)

> With punctuation like parentheses, square brackets, angle brackets,
> etc, does not ever, to my knowledge, have prefixes.

In another post, I have pointed out a few languages which do something 
very close to this, e.g. Scheme.

A better example is Coconut.

Coconut allows an optional 's' prefix on sets, so as to allow `s{}` for 
an empty set. It also allows the 'f' prefix for frozensets:

https://coconut.readthedocs.io/en/v1.1.0/DOCS.html#set-literals

But even if it has never been done before, someone has to be the first. 
There was a time that no language ever used r"..." for raw strings, or 
f"..." for f-strings. There was a time where there was no language in 
the world that used slice notation, or {a, b} for sets. There was once a 
time that no language had list comprehension syntax.

And now Python has all those syntactic features.

"It has never been done before" is a weak argument, and it is especially 
weak when it *has* been done before. We have at least three syntactic 
forms that use an alphabetical prefix on a delimiter.

It seems rather dubious that you are happy to use the < and > operators 
as delimiters, just to avoid a prefix.

- There is no precedent in Python of a symbol being used as both an 
  operator and a delimiter: none of ( [ { } ] ) are ever used as 
  operators, and no operator + - etc are ever used as delimiters.
  But you are happy to make this radical change to the language,
  even though you agree that it looks pretty awful when used with
  the < and > operators.

- But there is precedent in Python of adding an alphabetic prefix to
  delimiters: we have b' r' f'. But you are unhappy with making a
  minor change to the language by putting the prefix on a symbol
  different from a quote mark, because the data type is not a string
  or bytes.

Your position seems to be:

We have used prefixes on delimiters before, therefore we cannot do it 
again; and we've never used operators as delimiters before, therefore we 
should do it now.

Is that accurate? If not, I apologise for misunderstanding you, but 
please explain what you mean.

These are not rhetorical questions:

(1) Why does it matter that string and bytes syntax are the only types 
that currently use a prefix on a delimiter? Surely delimiters are 
delimiters, whatever the type they represent.

(2) What is so special about the string and bytes types that tells you 
that it is okay to use a prefix on the delimiter, but other data 
structures must not do the same?

> ONLY strings behave differently. Are there any non-string types which 
> have special behaviour based on a prefix, like you're suggesting for 
> sets?

I am not proposing any special behaviour. This is *syntax*, not 
behaviour. Frozensets will continue to behave exactly the same as they 
behave now. If that was not clear, I apologise for giving you the wrong 
impression.

As mentioned above, Coconut already supports this, and some other 
languages support similar prefixes on delimiters for lists and dicts.

> > You were concerned that adding a prefix to a delimiter in the form of
> > f{...} would be a bug magnet, but we have had prefixes on delimiters for
> > 30 years in the form of r"..." etc, and it hasn't been a problem.
> 
> 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 (f-strings). Is there any non-string type
> that doesn't follow that pattern?

So... not "ONLY" (your emphasis, not mine) strings. As you say, there 
are already two different data types, strings and bytes, plus a 
non-literal executable code (f-strings).

Again, I don't understand your point. You have just told us that there 
are already non-string literals and types that use a prefix on the 
delimiter, and then you ask me if there are any non-string types that 
follows that pattern. Haven't you just answered your own question?

Sure, bytes and f-strings are quite closely related to

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Brendan Barnwell

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.

How does this work for you?

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 not a name but just a
syntactic marker (as in f-strings).

In the second place, I don't like the idea of using prefixes to change
the types of objects like this. As far as I know we only have one
example of that, namely byte strings. The other string prefixes do not
create different types, they just affect how the literal is eventually
parsed into a string.

I would prefer some sort of augmented bracket notation, like {:1, 2,
3:} or something along those lines.

I do think it would be nice to have a frozenset literal, because I'm a
purity-beats-practicality person and it bugs me that there isn't one.
However, from that perspective I'd much rather have a frozen-dict type
and then a syntax for it. :-)

--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."

--author unknown
___
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/YE4NC7YTZNIFSGUGMUMGVR2IBT2A7B5W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 you mean. That's a constant, so it'll always return the
exact same object, surely?

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/UBS2LTN4YD7IBQT52CXRKBB3YHJJTZY3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Rob Cliffe via Python-ideas




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, 3"
Yes, I know you can still have
    fs(1, 2, 3)
    fs[1, 2, 3]
but IMO those are less common.


We don't say rs"\d+" for raw strings, or fs"{x =}" for f-strings.





___
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/RSEE4H6NV3HGVTBCZGZN3LYA3C32SSAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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, optionally with elements taken from
> iterable". The iterable is the (non-frozen) set {1, 2, 3}.
>

Exactly.

In a way, what this might do is open the door to  interning (some) frozen
sets, like cPython does for some ints and strings.

But that's only helpful is they are very heavily used, which they are not.

And I'm sure a way to intern them could be done without a literal anyway.

(using f{...} as a frozenset literal) does something different - it
> returns the *same* object, compiled once at function definition time,
> every time it's called.
>

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?

Stephen -- I'm going to paraphrase you now:

We don't make changes to Python syntax unless there is a compelling reason.

I'm really lost on what the compelling reason is for this one?

There are any number of python types with no "literal" (well, not any
number, it's quite defined. but still) heck, we don't even have literals
for Decimal. Why this one?

-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/MO2YMAV254EAOSUFHIRETB3TSOJSJW3G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 frozenset() with a literal. i.e. never had a use case
for a frozenset literal.

As I mentioned in another note, I do use set displays where they *could* be
frozen sets, but I dont think they've ever needed to be. And if there isn't
a performance advantage, then I'm fine with that.

> A frozen dict would also be useful but the implementation doesn't exist.
If it did exist then in combination with this proposal that syntax for
frozen dicts would be an obvious extension.

Ah yes, I think my brain blipped because there have been multiple proposals
on this list for such a thing -- but they were never realized.

> >>> squares = f{x**2 for x in range(10)}
>

Interesting idea. It feels a bit like that's realyl opening a door to a lot
if proposals -- is that good or bad thing?

-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/LZC6ZP6T5IIWMEQV422L5QW7L7WMYPK2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 frozenset to a regular set
3. convert the regular set back to a frozenset
4. garbage collect the regular set

See the b.p.o. ticket referenced earlier, as well as the disassembled
code.

In other cases it would avoid:

1. create a set, tuple or list
2. create a frozenset
3. garbage collect the set, tuple or list

It would also avoid the name lookup of `frozenset`, and guarantee that
even if that name was shadowed or monkey-patched, you still get a
genuine frozenset.

(Just as [1, 2, 3] is guaranteed to return a genuine list, even if the
name "list" is deleted, shadowed or replaced.)

At the moment, sets and frozensets still share the same implementation,
but some years ago Serhiy suggested that he had some optimizations in
mind that would make frozensets smaller than regular sets.

> How often do folks need a frozen set literal? I don’t think I’ve ever used
> one.

If you are writing `if x in ("this", "that", "another", "more")` then
you probably should be using a frozenset literal, since membership
testing in sets is faster than linear search of a tuple.

I think that the CPython peephole optimizer actually replaces that
tuple with a frozenset, which is cool, but you can defeat that
optimization and go back to slow linear search by refactoring the code
and giving the targets a name:

targets = ("this", "that", "another", "more")
if x in targets: ...

> If we did, then f{‘this’: ‘that’} should make a frozen dict, yes?

We would have to get a frozen dict first, but if we did, that would be
an obvious syntax to use.

--
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/EEJQ5ZL76RZN2DONSELJQFKVV7MG4NEX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 distinct open and close delimiter. But that
> >difference is surely not a reason to reject the use of a prefix.
> 
>   Well, there is a big difference, which is that the stuff between 
>   other delimiters (parentheses, brackets, etc.) is wholly constrained by 
> Python syntax, whereas the stuff between string delimiters is free-form 
> text, with only a few restrictions (like not being able to use the 
> delimiter itself, or to include newlines in single-quoted strings).

Which is also wholly constrained by Python syntax, seeing as they are 
Python strings :-)

>   Whether that difference is important for your proposal I won't 
>   address right now.  But it is a big difference.  It also greatly 
> affects 
> how people view the code, since syntax highlighters will often color an 
> entire string literal with the same color, whereas they don't typically 
> do that for other kinds of delimited chunks, instead highlighting only 
> the delimiters themselves.

Are any of these differences relevant to putting a prefix on the opening 
delimiter? If they are not, why mention them?

We could also talk about the difference between the numeric value of the 
ASCII symbols, or the number of pixels in a " versus a { glyph, or the 
linguistic history of the words "quotation mark" versus "curly bracket" 
too, but none of these things seem to be any more relevant than whether 
IDEs and syntax colourizers colour "..." differently to {1, None, 4.5}.

Can we bypass what could end up being a long and painful discussion if I 
acknowledge that, yes, frozensets are different to strings, and so the 
syntax is different.

(Different things necessarily have different syntax. Otherwise they 
would be indistinguishable.)

- Sets (like lists, tuples and dicts) are compound objects that contain
  other objects, so their displays involve comma-separated items;

- string (and byte) literals are not, except in the sense that strings 
  can be considered to be an array of single-character substrings.

I thought that was so obvious and so obviously irrelevant that it didn't 
even need mentioning. Perhaps I am wrong. (It has to happen eventually 
*wink*) If somebody can explain *why* that matters, rather than just 
declare that it rules out using a prefix, I would appreciate the 
education.

Hell, even if your argument is just "Nope, I just don't like the look of 
it!", I would respect that even if I disagree. Aesthetics are important, 
even when they are totally subjective.

If it helps, Julia supports this syntax for typed dicts:

Dict{keytype, valuetype}(key => value)

where the braces {keytype, valuetype} are optional. That's not a display 
syntax as such, or a prefix, but it is visually kinda similar.

Here are some similar syntax forms with prefixes:

* Dylan list displays: #(a, b, c)
* Smalltalk drops the comma separators: #(a b c)
* Scheme and Common Lisp: '(a b c)

and double delimiters:

* Pike: ({ a, b, c })
* Pike dicts: ([ a:b, c:d ])

Not that we could use any of those as-given.

-- 
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/S6IGTIUXRPY23DW7CJPRMUZSR6EZJIZ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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, 3]  # look up r, subscript it
> > > r"1, 2, 3"  # a string literal
> >
> > 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
seriously, can't you read back to your own previous message and get
your own context?

With punctuation like parentheses, square brackets, angle brackets,
etc, does not ever, to my knowledge, have prefixes. ONLY strings
behave differently. Are there any non-string types which have special
behaviour based on a prefix, like you're suggesting for sets?

> You were concerned that adding a prefix to a delimiter in the form of
> f{...} would be a bug magnet, but we have had prefixes on delimiters for
> 30 years in the form of r"..." etc, and it hasn't been a problem.

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 (f-strings). Is there any non-string type
that doesn't follow that pattern?

> I mean, sure, the occasional beginner might get confused and write
>
> len{mystring}
>
> and if by some fluke they call f() rather than len() they will get a
> silent failure instead of a SyntaxError, but is this really a serious
> problem that is common enough to get labelled "a bug magnet"?

len{mystring} looks a lot like len(mystring), but len"mystring" looks
very very different. Or do you treat all punctuation exactly the same
way?

> I've been coding in Python for two decades and I still occassionally
> mess up round and square brackets, especially late at night, and I won't
> tell you how often I write my dict displays with equal signs
> {key=value}, or misspell str.center.
>
> And I still cringe about the time a few years back where my brain forgot
> that Python spells it "None" rather than "nil" like in Pascal, and I
> spent about an hour writing a ton of "if obj is nil"... tests.
>
> Typos and brain farts happen.

You mess up round and square brackets, yes. You might mess up double
and single quotes, too, in languages that care. But you aren't going
to mess up brackets and quotes.

> > > Triple quoted strings say hello :-)
> >
> > See above, strings are different, and people treat them differently.
>
> 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 reject the use of a prefix.
>
> "We can't use a prefix because the closing delimiter is different from
> the opening delimiter" does not follow.

People treat them differently. That's why f-strings are a thing: we
treat strings as strings even when they're expressions.

Strings ARE special. I asked you if there are any non-strings that are
similarly special. You have not found any examples.

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/L2QSK3SU3A2NQDSZ4R3VQNLVZDO2D44Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Inada Naoki

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.
>>
>> 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).
>

Although we don't have frozenset literal now, we have frozenset.
So we can estimate how frozenset literal is useful by seeing how
frozenset is used.

Unless how the literal improve codes is demonstrated, I am -0.5 on new
literal only for consistency.

Regards,
-- 
Inada Naoki  
___
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/AYO2GIDUZZ43KTBP7P2TRYGORSWVFYO5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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
> > False
> >
> > Each time you call the function, you get a distinct frozenset object.
>
> 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, optionally with elements taken from
> iterable". The iterable is the (non-frozen) set {1, 2, 3}.

Where is that definition? According to help(frozenset), it will
"[b]uild an immutable unordered collection of unique elements", so it
doesn't necessarily have to be a brand new object. With mutables, it
does have to return a new one every time (list(x) will give you a
shallow copy of x even if it's already a list), but with immutables,
it's okay to return the same one (str and tuple will return self).

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/G23OMELEM6KFNTB36ZIBA23K2XXUWJLU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Oscar Benjamin

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 ever used
> one.
>

You won't have used one because they have not yet existed (hence this
thread).

> If we did, then f{‘this’: ‘that’} should make a frozen dict, yes?
>

A frozen dict would also be useful but the implementation doesn't exist. If
it did exist then in combination with this proposal that syntax for frozen
dicts would be an obvious extension.

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)}

--
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/SCHOMJYEZYTAEZYYU2YV3J4VXUL36WNY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 frozen dict, yes?



On Sun, Jan 16,  I suggest his goal of a frozenset literal might be better
achieved by making 'frozenset' a keyword, much as None and True and False
are already keywords.

Adding a keyword is a very Big Deal.

I don’t think this rises to that level at all.

It was done for True and False because having them as non-redefineable
names referencing singletons is really helpful.

-CHB
___
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/452SRDHFTOWEX5M6ZUUSTINAQO6LXOCS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Brendan Barnwell

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 reject the use of a prefix.

Well, there is a big difference, which is that the stuff between other
delimiters (parentheses, brackets, etc.) is wholly constrained by Python
syntax, whereas the stuff between string delimiters is free-form text,
with only a few restrictions (like not being able to use the delimiter
itself, or to include newlines in single-quoted strings).

Whether that difference is important for your proposal I won't address
right now. But it is a big difference. It also greatly affects how
people view the code, since syntax highlighters will often color an
entire string literal with the same color, whereas they don't typically
do that for other kinds of delimited chunks, instead highlighting only
the delimiters themselves.

--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."

--author unknown
___
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/EJG2LDJTTZVHTN5CHN23PE33RZD35UAI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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
___
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/RYSN6ILR5DZNUJJC7ZICMHKQDPWHYCAM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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
> 
> Strings behave differently in many many ways. Are there any non-string
> types that differ?

There are plenty of non-string types which differ :-)

Differ in what way? I don't understand your question.

You were concerned that adding a prefix to a delimiter in the form of 
f{...} would be a bug magnet, but we have had prefixes on delimiters for 
30 years in the form of r"..." etc, and it hasn't been a problem.

I mean, sure, the occasional beginner might get confused and write

len{mystring}

and if by some fluke they call f() rather than len() they will get a 
silent failure instead of a SyntaxError, but is this really a serious 
problem that is common enough to get labelled "a bug magnet"?

I've been coding in Python for two decades and I still occassionally 
mess up round and square brackets, especially late at night, and I won't 
tell you how often I write my dict displays with equal signs 
{key=value}, or misspell str.center.

And I still cringe about the time a few years back where my brain forgot 
that Python spells it "None" rather than "nil" like in Pascal, and I 
spent about an hour writing a ton of "if obj is nil"... tests.

Typos and brain farts happen.

> > Reading this makes my eyes bleed:
> >
> > >>> <1, 2, 3> < <1, 2, 3, 4>
> > True
> 
> Fair point, but I can't imagine people comparing two literals like
> that.

They don't have to be literals inside the brackets. Especially in the 
REPL, `{*a} < {*b}` is a quick way of testing that every element of a is 
an element of b.

[...]
> > Triple quoted strings say hello :-)
> 
> See above, strings are different, and people treat them differently.

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 reject the use of a prefix.

"We can't use a prefix because the closing delimiter is different from 
the opening delimiter" does not follow.

-- 
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/MZZLCW6VOQI7GGBJJWWDIT6IKMBGOST4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Paul Moore

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 object.

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, optionally with elements taken from
iterable". The iterable is the (non-frozen) set {1, 2, 3}.

The function

def f1():
return f{1, 2, 3}

(using f{...} as a frozenset literal) does something different - it
returns the *same* object, compiled once at function definition time,
every time it's called.

So frozenset literals would allow us to express something that we
can't currently express (at least not without going through some
complicated contortions) in Python. I'm not sure it's a particularly
*important* thing to be able to do, but whatever ;-)

Paul
___
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/K5DDGSLSMVFA35HLWFJE43XYOKSPAWWL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 replied there:
>
>
> >>> 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 object.
>

And semantically, I believe that's correct. The set display MUST
create a new set every time, and since the compiler/optimizer can't
assume that the name 'frozenset' hasn't been rebound, it has to then
call the function to get its result. So it will, by language
definition, build a set from the given values, then build a frozenset
from that. It optimizes "add 1, add 2, add 3" down to "here's a
frozenset, add them", but it can't skip the whole job.

def frozenset(stuff):
print("You can't optimize me out")
stuff.remove(2)
return builtins.frozenset(stuff)

If the compiler did any of the optimizations it's currently not doing,
this code would break.

The only way to solve this is an actual frozenset literal, and I would
love to have one, but it stands or falls on the syntax.

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/7MQZUAGGDHMZTIC7OUSPVZGMDI2HL6EC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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})
...
>>> 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 object.



-- 
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/RMPLHFYH2SH6LCYCKGTY6V3ME4NCCAWO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Jonathan Fine

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. He then argues that introducing a frozenset
literal would allow
   x in f{1, 2, 3} # New syntax, giving a frozenset literal
would allow better bytecode to be generated.

However, the following has the same semantics as "x in {1, 2, 3}" and
perhaps gives optimal bytecode.
>>> import dis
>>> dis.dis("x in (1, 2, 3)")
  1   0 LOAD_NAME0 (x)
  2 LOAD_CONST   3 ((1, 2, 3))
  4 COMPARE_OP   6 (in)
  6 RETURN_VALUE

For comparison, here's the bytecode Steve correctly notes is apparently not
optimal.
>>> dis.dis("x in {1, 2, 3}")
  1   0 LOAD_NAME0 (x)
  2 LOAD_CONST   3 (frozenset({1, 2, 3}))
  4 COMPARE_OP   6 (in)
  6 RETURN_VALUE

Steve states that "x in {1, 2, 3}" when executed calls "frozenset({1, 2,
3})", and in particular looks up "frozenset" in builtins and literals.

I can see why he says that, but I've done an experiment that suggests
otherwise.
>>> bc = compile("x in {1, 2, 3}", "filename", "eval")
>>> eval(bc, dict(x=1))
True
>>> eval(bc, dict(x=1, frozenset="dne"))
True

I suspect that if you look up in the C-source for Python, you'll find that
dis.dis ends up using
frozenset({1, 2, 3})
as the literal for representing the result of evaluating frozenset({1, 2,
3}).

The following is evidence for this hypothesis:
>>> frozenset({1, 2, 3})
frozenset({1, 2, 3})
>>> set({1, 2, 3})
{1, 2, 3}
>>> set([1, 2, 3])
{1, 2, 3}
>>> set([])
set()

To conclude, I find it plausible that:

1. The bytecode generated by "x in {1, 2, 3}" is already optimal.
2. Python already uses "frozenset({1, 2, 3})" as the literal representation
of a frozenset.

Steve in his original post mentioned the issue
https://bugs.python.org/issue46393, authored by Terry Reedy. Steve rightly
comments on that issue that "may have been shadowed, or builtins
monkey-patched, so we cannot know what frozenset({1, 2, 3}) will return
until runtime."

Steve's quite right about this shadowing problem. In light of my plausible
conclusions I suggest his goal of a frozenset literal might be better
achieved by making 'frozenset' a keyword, much as None and True and False
are already keywords.

>>> True = False
  File "", line 1
SyntaxError: can't assign to keyword

Once this is done we can then use
   frozenset({1, 2, 3})
as the literal for a frozenset, not only in dis.dis and repr and elsewhere,
but also in source code.

As a rough suggestion, something like
from __future__ import literal_constructors_as_keywords
would prevent monkey-patching of set, frozenset, int and so forth (just as
True cannot be monkeypatched).

I thank Steve for bringing this interesting question to our attention, for
his earlier work on the issue, and for sharing his current thoughts on this
matter. It's also worth looking at the message for Gregory Smith that Steve
referenced in his original post.
https://mail.python.org/pipermail/python-ideas/2018-July/051902.html

Gregory wrote: frozenset is not the only base type that lacks a literals
leading to loading values into these types involving creation of an
intermediate throwaway object: bytearray.  bytearray(b'short lived bytes
object')

I hope this helps.
-- 
Jonathan
___
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/KKUZCKB4L5AZJWFLEYZ44IHBXQBRUHJC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 need to be. E.g. they don’t
change, nor are they used as keys.

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.

-CHB


On Sun, Jan 16, 2022 at 8:50 AM MRAB  wrote:

> 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
> >8 CALL_FUNCTION1
> >   10 RETURN_VALUE
> >
> > Got that? To create a frozenset of literals, first the compiler creates
> > a frozenset constant containing what you wanted. Then at runtime, it:
> >
> > - looks up frozenset in globals and builtins;
> > - loads the pre-prepared frozenset (which is exactly what we want);
> > - creates a new set from that frozenset;
> > - calls the frozenset() function on that set to create a new frozenset
> >that duplicates the pre-prepared one;
> > - and finally garbage-collects the temporary set.
> >
> [snip]
>
> Not quite as bad as that:
>
>  >>> f = frozenset({1, 2, 3})
>  >>> f is frozenset(f)
> True
> ___
> 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/M2N3GNQRCPDYUQK7KGS3T5RI5NE3BBYJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
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/DF44POLKWU3KUKXU2NR6NI4OYWMYG3NN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread MRAB


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
   8 CALL_FUNCTION1
  10 RETURN_VALUE

Got that? To create a frozenset of literals, first the compiler creates
a frozenset constant containing what you wanted. Then at runtime, it:

- looks up frozenset in globals and builtins;
- loads the pre-prepared frozenset (which is exactly what we want);
- creates a new set from that frozenset;
- calls the frozenset() function on that set to create a new frozenset
   that duplicates the pre-prepared one;
- and finally garbage-collects the temporary set.


[snip]

Not quite as bad as that:

>>> f = frozenset({1, 2, 3})
>>> f is frozenset(f)
True
___
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/M2N3GNQRCPDYUQK7KGS3T5RI5NE3BBYJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Rob Cliffe via Python-ideas


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 
already say

a = frozenset({i+1 for i in range(3)})
which is not too bad.


On Sun, 16 Jan 2022 at 14:14, Rob Cliffe via Python-ideas 
 wrote:


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) # 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, {x+1}"  # eval some code and construct a string
>>
>> 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
> Strings behave differently in many many ways. Are there any
non-string
> types that differ?
>
>> Reading this makes my eyes bleed:
>>
>>      >>> <1, 2, 3> < <1, 2, 3, 4>
>>      True
> Fair point, but I can't imagine people comparing two literals like
> that. It's not quite as bad if you replace the left side with a
> variable or calculation, though it's still kinda weird.
>
>>> Unfortunately there aren't many symbols available, and
Python's kinda
>>> locked into a habit of using just one at each end (rather
than, say,
>>> (<1, 2, 3>) or something), so choices are quite limited.
>> Triple quoted strings say hello :-)
> See above, strings are different, and people treat them differently.
>
>> {{1, 2, 3}} would work, since that's currently a runtime error.
But I
>> prefer the f{} syntax.
>>
> Yeah, I think that ship has sailed. Double punctuation just isn't
> Python's thing, so there aren't really any good ways to shoehorn
more
> data types into fewer symbols.
>
> 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/PMK36CYTHNNJEEDBPEO5T3RN6PCZZVZO/
> 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/SWDTEHB5PEHBR45UL6AHXY2DKYEBVJ26/
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/2ZBVGPQJBDWIOEUJO55BEZB25DQYWM3K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

2022-01-16 Thread Rob Cliffe via Python-ideas


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) # 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, {x+1}"  # eval some code and construct a string

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

Strings behave differently in many many ways. Are there any non-string
types that differ?


Reading this makes my eyes bleed:

 >>> <1, 2, 3> < <1, 2, 3, 4>
 True

Fair point, but I can't imagine people comparing two literals like
that. It's not quite as bad if you replace the left side with a
variable or calculation, though it's still kinda weird.


Unfortunately there aren't many symbols available, and Python's kinda
locked into a habit of using just one at each end (rather than, say,
(<1, 2, 3>) or something), so choices are quite limited.

Triple quoted strings say hello :-)

See above, strings are different, and people treat them differently.


{{1, 2, 3}} would work, since that's currently a runtime error. But I
prefer the f{} syntax.


Yeah, I think that ship has sailed. Double punctuation just isn't
Python's thing, so there aren't really any good ways to shoehorn more
data types into fewer symbols.

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/PMK36CYTHNNJEEDBPEO5T3RN6PCZZVZO/
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/SWDTEHB5PEHBR45UL6AHXY2DKYEBVJ26/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

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 paramters
> > f{1, 2, 3} # construct a frozenset
>
> You forgot
>
> f"1, 2, {x+1}"  # eval some code and construct a string
>
> 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

Strings behave differently in many many ways. Are there any non-string
types that differ?

> Reading this makes my eyes bleed:
>
> >>> <1, 2, 3> < <1, 2, 3, 4>
> True

Fair point, but I can't imagine people comparing two literals like
that. It's not quite as bad if you replace the left side with a
variable or calculation, though it's still kinda weird.

> > Unfortunately there aren't many symbols available, and Python's kinda
> > locked into a habit of using just one at each end (rather than, say,
> > (<1, 2, 3>) or something), so choices are quite limited.
>
> Triple quoted strings say hello :-)

See above, strings are different, and people treat them differently.

> {{1, 2, 3}} would work, since that's currently a runtime error. But I
> prefer the f{} syntax.
>

Yeah, I think that ship has sailed. Double punctuation just isn't
Python's thing, so there aren't really any good ways to shoehorn more
data types into fewer symbols.

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/PMK36CYTHNNJEEDBPEO5T3RN6PCZZVZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal