date:20220116

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: Shouldn't 'input' prompt be going to stderr?

On 2022-01-17 03:11, Cameron Simpson wrote:

On 16Jan2022 20:57, MRAB wrote:
There was a discussion on another forum that mentioned the 'input'
function, and it made me wonder whether 'input' should be printing the
prompt to stderr instead of stdout.

The convention is for normal output to go to stdout and error messages
to go to stderr, so if a program needs to ask the user, shouldn't it be
using stderr for prompts in order not to mess up the normal output?

This is a good reason to avoid sending prompts to stdout. But stderr
isn't necessarily right either. If stderr's attached to a tty (UNIX,
different techiness for Windows) you could reasonably send to stderr,
otherwise you might be better opening /dev/tty (if you're allowed to,
and if you have one). Etc etc.

There was a long thread in the "Core Development" forum just the other
day about this, here:
https://discuss.python.org/t/builtin-function-input-writes-its-prompt-to-sys-stderr-and-not-to-sys-stdout/12955

Have a read.

Thanks for that.

I did think that it's way too late to change it now, but perhaps an
argument to redirect the prompt is a possibility.

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

[Python-ideas] Re: Shouldn't 'input' prompt be going to stderr?

2022-01-16 Thread Cameron Simpson

On 16Jan2022 20:57, MRAB  wrote:
>There was a discussion on another forum that mentioned the 'input' 
>function, and it made me wonder whether 'input' should be printing the 
>prompt to stderr instead of stdout.
>
>The convention is for normal output to go to stdout and error messages 
>to go to stderr, so if a program needs to ask the user, shouldn't it be 
>using stderr for prompts in order not to mess up the normal output?

This is a good reason to avoid sending prompts to stdout. But stderr 
isn't necessarily right either. If stderr's attached to a tty (UNIX, 
different techiness for Windows) you could reasonably send to stderr, 
otherwise you might be better opening /dev/tty (if you're allowed to, 
and if you have one). Etc etc.

There was a long thread in the "Core Development" forum just the other 
day about this, here: 
https://discuss.python.org/t/builtin-function-input-writes-its-prompt-to-sys-stderr-and-not-to-sys-stdout/12955

Have a read.

Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NNK7KBEAOIHKHZVXLMDRAHQOIYYP6FSC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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] Shouldn't 'input' prompt be going to stderr?

There was a discussion on another forum that mentioned the 'input' 
function, and it made me wonder whether 'input' should be printing the 
prompt to stderr instead of stdout.


The convention is for normal output to go to stdout and error messages 
to go to stderr, so if a program needs to ask the user, shouldn't it be 
using stderr for prompts in order not to mess up the normal output?

___
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/DPWGFP2E77QSNRXQGSULIVIXA5QC7NFL/
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


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] Limit scope of variables using round brackets

2022-01-16 Thread Iyad Ahmed

Example use cases:

   - Loop variables and similar, it is sometimes more comfortable to scope
   it to the loop body only
   - Not having to name variables var1, var2, var3, or makeup unnecessarily
   unique variable names, in some situations



In other languages the curly bracket is used, in Python round brackets
might fit more in the syntax.

I don’t have much experience with the implementation of Python, so not sure
if there’s a technical reason against such idea,

feedback is very appreciated



Best regards,

Iyad Ahmed



Email: iyadah...@cgonfire.com

Socials: Twitter 

GitHub: https://github.com/iyadahmed
___
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/HH3XMQCGVWVHLOR3GV5A2EYTLWYASS72/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP Idea: Better return type annotation syntax

2022-01-16 Thread Tushar Sadhwani

Jelle Zijlstra wrote:
> > I like this too. A practical issue is that list[(a, b)] and list[a, b] look
> the same to the compiler, but they would mean very different things. It's
> not obvious how to fix this in a backward-compatible way.
> > I think it looks much cleaner, and if there isn't any drawbacks to adding
> > this syntax, I'd love to work on bringing this to life.

Restricting it to only the top level of a return type annotation should do the 
trick!

Such that:

def f() -> (X, Y, Z): ...

is interpreted as tuple[X, Y, Z], but:

def f(x: (X, Y, Z)) -> None: ...
def f() -> Union[int, (X, Y, Z)]: ...
def f() -> list[(X, Y, Z)]: ...

Are not considered as tuple[...]
___
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/GDTLCSBIGY7W6GNWHUMRGY7KKFDKT3LU/
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

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


> And that means it's going to be a bug magnet.

I don't think that f{} will be any more of a bug magnet than f"" and r"" 
already are.



> Are we able to instead make a sort of vector literal?
> 
> <1, 2, 3>

Back in the days when Python's parser was LL(1), that wasn't possible. 
Now that it uses a PEG parser, maybe it is, but is it desirable?

Reading this makes my eyes bleed:

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


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

{{1, 2, 3}} would work, since that's currently a runtime error. But I 
prefer the f{} 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/7RNS6HALAPTTFAOFCTTUNUNFRYU6EYV3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

On Sun, Jan 16, 2022 at 7:35 PM Steven D'Aprano  wrote:
> How does this work for you?
>
> f{1, 2, 3}
>

While it's tempting, it does create an awkward distinction.

f(1, 2, 3) # look up f, call it with parameters
f[1, 2, 3] # look up f, subscript it with paramters
f{1, 2, 3} # construct a frozenset

And that means it's going to be a bug magnet.

Are we able to instead make a sort of vector literal?

<1, 2, 3>

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.

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

[Python-ideas] Revisiting a frozenset display literal