This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Ben Burrill
Recipients Ben Burrill, mark.dickinson, rhettinger
Date 2017-10-06.02:46:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507258009.66.0.213398074469.issue31707@psf.upfronthosting.co.za>
In-reply-to
Content
The core operators, like multiplication and division, should work for any type that defines the right operators.  Hashing is tricky, and reducing the fraction is pretty much off the table.  This is why I suggested a superclass.  I'll try making a patch sometime soon.

I am aware of sympy and am not proposing that the standard library stray too far into symbolic mathematics.  Sympy's re-invention of the fraction makes sense given sympy's scope, but simpler libraries that offer other abstract math features (like one that just implemented a simple Polynomial type) would benefit from using fractions.Fraction.

This change would probably make it so that sympy symbols worked with fractions.Fraction, which although unnecessary, might be nice.
History
Date User Action Args
2017-10-06 02:46:49Ben Burrillsetrecipients: + Ben Burrill, rhettinger, mark.dickinson
2017-10-06 02:46:49Ben Burrillsetmessageid: <1507258009.66.0.213398074469.issue31707@psf.upfronthosting.co.za>
2017-10-06 02:46:49Ben Burrilllinkissue31707 messages
2017-10-06 02:46:48Ben Burrillcreate