On 01Feb2022 09:13, Chris Angelico <[email protected]> wrote:
>On Tue, 1 Feb 2022 at 09:02, Cameron Simpson <[email protected]> wrote:
>> On 22Jan2022 01:41, Chris Angelico <[email protected]> wrote:
>> >On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno <[email protected]>
>> >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". <snark/>
Cheers,
Cameron Simpson <[email protected]>
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/VKWTMLVOLZQ45CRPPTU65FJTD6MJU6D5/
Code of Conduct: http://python.org/psf/codeofconduct/
