On Sat, May 15, 2021 at 1:39 AM Paul Moore <p.f.mo...@gmail.com> wrote:
>
> On Fri, 14 May 2021 at 16:29, David Mertz <me...@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
_______________________________________________
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/6FIY7BMCJ7TTVQCXOT47PMCL363PCYYC/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to