[Python-ideas] Re: Revisiting a frozenset display literal
On 01Feb2022 09:13, Chris Angelico wrote:
>On Tue, 1 Feb 2022 at 09:02, Cameron Simpson wrote:
>> On 22Jan2022 01:41, Chris Angelico wrote:
>> >On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno
>> >wrote:
>> >> At that point, I argue that despite adding still more things to
>> >> the syntax, it is one that will spare time in average than the other
>> >> way around, due to the time people, needing frozensets for
>> >> the first time in any project, waste looking for a literal syntax for them
>> >> only to find out there is not any.
>> >
>> >Have you any stats on this? There is no literal/display syntax for
>> >datetimes, regular expressions, ranges, bytearrays, or a host of other
>> >common types. How often do people reach for a literal syntax for
>> >those? (I say "literal/display" since, technically, dicts have a
>> >display syntax, not a literal, and complex numbers are written as a
>> >constant-folded sum, but in practical terms, those count. The other
>> >types don't even get that.) If frozensets are so special that they
>> >need syntax, why not ranges, which are used far more frequently?
>>
>> Well, some data.
>>
>> a) if the, for example, f{constant-set-display} syntax is generalisable
>> (notionally, where we generalise it or not), it offers a path to frozen
>> literals for other things via a prefix notation, should be become
>> desirable.
>>
>> b) literal regexps: people use these _all the time_, conceptually.
>>
>
>In other words: If we create literals for a bunch of different things,
>then frozensets would be neat, but if we don't, then other types
>should have priority. Is that correct?
I don't have a priority really. I was trying to address your "There is
no literal/display syntax for datetimes, regular expressions, ranges,
bytearrays, or a host of other common types. How often do people reach
for a literal syntax for those?" question with a concrete commonplace
example.
I expect that people often want a literal (or at least convenient) way
to express whatever they're working with. "Make a class" only goes so
far, though it is pretty far.
>I'm of the opinion that range objects should get literal syntax before
>frozensets do.
Maybe; I'm of the opinion that maybe they should use a similar syntactic
approach to avoid bloating the syntaxes one must deal with. Isn't a
slice close to a literal range?
>You're of the opinion that regexps should get literal
>syntax before frozensets do.
Very much NOT. I explicitly said I wasn't arguing for that, just arguing
that many people write code which would be using literal regexps if they
were there.
Personally, literal regexps are NOT ahead of frozensets in my mind. To
quote the last piece of my post:
I'm _not_ arguing for regexp literals in Python - IMO they're
undesirable, a separate argument. (Note: not "undesired", just
undesirable: to be avoided except when they're the right solution.)
I'm kind of -0.1 on literal regexps - it makes them _too_ convenient.
>I would *much* rather see {1,2,3}.frozen() be constant-foldable than
>f{1,2,3} as a literal.
I'm ambivalent myself. The general "prefix" approach is slowly growing
on me. However, "{1,2,3}.frozen() be constant-foldable" is indeed
implementable without inventing new syntax.
>(That said: I'm actually not convinced that regexps need literal
>syntax, because it wouldn't benefit alternate regexp engines on PyPI.)
That too. Unless there was a suffix syntax to attach a literal regexp to
a specific implementation "/regexp-here/foo_class".
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/VKWTMLVOLZQ45CRPPTU65FJTD6MJU6D5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
[... big snip...]
On 22Jan2022 01:41, Chris Angelico wrote:
>On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno wrote:
>> At that point, I argue that despite adding still more things to
>> the syntax, it is one that will spare time in average than the other
>> way around, due to the time people, needing frozensets for
>> the first time in any project, waste looking for a literal syntax for them
>> only to find out there is not any.
>
>Have you any stats on this? There is no literal/display syntax for
>datetimes, regular expressions, ranges, bytearrays, or a host of other
>common types. How often do people reach for a literal syntax for
>those? (I say "literal/display" since, technically, dicts have a
>display syntax, not a literal, and complex numbers are written as a
>constant-folded sum, but in practical terms, those count. The other
>types don't even get that.) If frozensets are so special that they
>need syntax, why not ranges, which are used far more frequently?
Well, some data.
a) if the, for example, f{constant-set-display} syntax is generalisable
(notionally, where we generalise it or not), it offers a path to frozen
literals for other things via a prefix notation, should be become
desirable.
b) literal regexps: people use these _all the time_, conceptually.
To the latter: Perl has literal regexps, you just write:
/regexp-goes-here/
It even has a verbose commentable form of that to aid writing
understandable regexps (hahaha!).
What, we're not Perl? True, but you see _lots_ of code like this:
# apologies if I have the argument order wrong here
if re.match('regexp-string', 'target-string'):
which effectively relies on the re module's autocaching of regexps to be
efficient while skipping the more overt:
# top of module
foo_re = re.compile('regexp-string'[,options])
# in the main code
if m := foo_re.match('target-string'):
The former is nothing else but a metaphor for a literal regexp.
I'm _not_ arguing for regexp literals in Python - IMO they're
undesirable, a separate argument. (Note: not "undesired", just
undesirable: to be avoided except when they're the right solution.)
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/DCOH4HQ26AU2DJBEBSFUPQSIECLOOSR4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
Joao, apologies for replying late - I never got back to this message.
I wrote:
>> Yes, but have you _seen_ the bickering about the existing bracket
>> choices just for frozenset? Eww. Hence the going for a distinct
>> operator
>> altogether. Yes, I'd prefer brackets of some kind too, but they're
>> taken.
On 21Jan2022 10:29, Joao S. O. Bueno wrote:
>> If one uses prefixes, you start from 53 valid (all latin areas,
>> upper,
>lower and @)
>new brackets for {} .
>I can't see how they are "all taken" when the strongest argument against
>prefixing seems to be "but _only strings_ should have prefixes".
>(with the "typing f{} instead of f() is going to be a bug magnet"
>as a runner up). None of those stand up to any logical analysis
Agreed. I think I found a short prefix "f{" hard to see, but that is
just "practice". I'm not inherently in the "but _only strings_ should
have prefixes" camp.
My remark about the bickering was aimed at unadorned brackets eg the
"{{frozen literal set here }}" suggestion.
Anyway, this post is just for clarification, not arguing any particular
point.
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/5JVZFRHZT3P5IHES5ISTQBUKQYTVZUUH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On Tue, 1 Feb 2022 at 09:02, Cameron Simpson wrote:
>
> [... big snip...]
>
> On 22Jan2022 01:41, Chris Angelico wrote:
> >On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno wrote:
> >> At that point, I argue that despite adding still more things to
> >> the syntax, it is one that will spare time in average than the other
> >> way around, due to the time people, needing frozensets for
> >> the first time in any project, waste looking for a literal syntax for them
> >> only to find out there is not any.
> >
> >Have you any stats on this? There is no literal/display syntax for
> >datetimes, regular expressions, ranges, bytearrays, or a host of other
> >common types. How often do people reach for a literal syntax for
> >those? (I say "literal/display" since, technically, dicts have a
> >display syntax, not a literal, and complex numbers are written as a
> >constant-folded sum, but in practical terms, those count. The other
> >types don't even get that.) If frozensets are so special that they
> >need syntax, why not ranges, which are used far more frequently?
>
> Well, some data.
>
> a) if the, for example, f{constant-set-display} syntax is generalisable
> (notionally, where we generalise it or not), it offers a path to frozen
> literals for other things via a prefix notation, should be become
> desirable.
>
> b) literal regexps: people use these _all the time_, conceptually.
>
In other words: If we create literals for a bunch of different things,
then frozensets would be neat, but if we don't, then other types
should have priority. Is that correct?
I'm of the opinion that range objects should get literal syntax before
frozensets do. You're of the opinion that regexps should get literal
syntax before frozensets do. We're broadly in agreement here.
I would *much* rather see {1,2,3}.frozen() be constant-foldable than
f{1,2,3} as a literal.
(That said: I'm actually not convinced that regexps need literal
syntax, because it wouldn't benefit alternate regexp engines on PyPI.)
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/NUU3TDWKRF4OMH6UFPEJCYG2BY6OSO52/
Code of Conduct: http://python.org/psf/codeofconduct/
