[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/
[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
[... 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: 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/