On Sat, May 15, 2021 at 1:39 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, 14 May 2021 at 16:29, David Mertz <mertz@gnosis.cx> wrote:
That said, Chris's idea for a literal spelling of "Fraction" is very appealing. One extra letter or symbol could indicate that you want to work in the Fraction domain rather than floating point. That's a perfectly reasonable decision for a user to make.
Agreed, it is appealing. The problem (and this is not a new suggestion, it's come up a number of times)
Interestingly, even though it's definitely been proposed periodically, it actually hasn't been codified into a PEP except for PEP 240, which was associated with PEP 239, which was rejected: https://www.python.org/dev/peps/pep-0239/ https://www.python.org/dev/peps/pep-0240/ So we actually haven't had a proper PEP about adding a Fraction literal since the Fraction type itself was added. Whether it gets accepted or not, I think having a PEP would be a good thing here.
is that of having language syntax depend on non-builtin classes. So either you have to *also* propose making the fractions module a builtin, or you very quickly get sucked into "why not make this mechanism more general, so that libraries can define their own literals?"
Yes, fractions would have to become built-in. The consequences of doing so would have to be explored; I'd start by looking at: * Interpreter startup time * Memory usage * Subprocess creation time (only significant on Windows, I think - every other platform forks) * Possible interactions with decimal.Decimal (see below) * Whether Fraction would need to become a builtin name Currently, fractions.py imports decimal.py, mainly (purely?) for the sake of being able to construct a Fraction from a Decimal. The decimal module is *large* and has other reasons for not becoming builtin too, so ideally, the two should be decoupled. A solid proposal would need to explore decoupling the modules, figure out whether it's feasible, or if not, why not, and figure out how these constructors should be implemented. (For instance, should Fraction.from_decimal(123) cause the decimal module to be imported?)
Scope creep is nearly always what kills these proposals. Or the base proposal is too specialised to gain enough support.
Personally, I can see value in fraction, decimal and regex literals. But I can live without them.
Decimal literals have a number of awkward wrinkles, so I'd leave them aside for now; but if Fraction literals gain traction, it may be possible to figure out a similar proposal. But the two would be independent. IMO regex literals are less valuable in Python than in some other languages due to Python's rich set of string manipulation features, but if they existed, I'd probably use them. Anyone want to run with this? I'd be happy to help out with any PEP questions. ChrisA