Fully agreed on the sentiment that we shouldn't treat compile-time literals differently from runtime operations. It has no precedent in Python and adds a significant mental burden to keep track of. I can only imagine the deluge StackOverflow threads from surprised users if this were to be done.
That said, I also really like the idea of better Python support for symbolic and decimal math. How about this as a compromise: `from __feature__ import decimal_math, fraction_math` With the 2 interpreter directives above (which must appear at the top of the module, either before or after __future__ imports, but before anything else), any float literals inside that module would be automatically coerced to `Decimal`, and any division operations would be coerced to `Fraction`. You could also specify just one of those directives if you wanted. Upsides - No change at all to existing code - By specifically opting into this behavior you would be accepting the reduced performance and memory-efficiency - Very simple to explain to people using Python for maths or science (not an insignificant userbase) who don't understand or care about the merits and downsides of various data-types and just want to do math that behaves the way they expect. Downsides: - the complexity of adding this new '__feature__' interpreter directive, although it *should* be possibly to reuse the existing __future__ machinery for it - having to maintain these new 'features' into the future - you can't choose to mark a single float literal as a decimal or a single division operation as a fraction, it's all-or-nothing within a given module I don't know. It was just an idea off the top of my head. On second thought, maybe it's needlessly contrived. Cheers everyone On Tue, May 18, 2021 at 4:05 PM Ricky Teachey <ri...@teachey.org> wrote: > On Tue, May 18, 2021 at 10:55 AM Paul Moore <p.f.mo...@gmail.com> wrote: > >> On Tue, 18 May 2021 at 15:16, Martin Teichmann >> <martin.teichm...@gmail.com> wrote: >> > >> > Because reality. People would like to write 1/2 * m * v**2 to mean the >> obvious thing, without having to think about the details. And there are >> many people like this, this is why it shows up on this mailing list >> regularly. I have never felt the urge to write two/three * m * v**two. >> >> I'd actually prefer to write (m*v**2)/2. Or (m/2)*v**2. But those >> wouldn't work, the way you describe your proposal. And I'd be very >> concerned if they behaved differently than 1/2 * m * v**2... >> >> Paul >> > > A much more concrete way of making the point I was trying to make! > > Different results from: > > >>> one = 1 > >>> three = 3 > >>> one/three > > ..and: > > >>> 1/3 > > ... has to be avoided. I don't see how it can be with the way the proposal > has been described. > > --- > Ricky. > > "I've never met a Kentucky man who wasn't either thinking about going home > or actually going home." - Happy Chandler > _______________________________________________ > 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/OKMGLONWE2MMV3S6EJF76QEAIHYHQHAZ/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/LTXILSTOOXRBOVERCLEJCHUCQM6T3VA5/ Code of Conduct: http://python.org/psf/codeofconduct/
