Velocity Reviews > A Revised Rational Proposal

# A Revised Rational Proposal

Mike Meyer
Guest
Posts: n/a

 12-27-2004
"Dan Bishop" <(E-Mail Removed)> writes:

> Mike Meyer wrote:
>> This version includes the input from various and sundry people.

> Thanks
>> to everyone who contributed.
>>
>> <mike
>>
>> PEP: XXX
>> Title: A rational number module for Python

> ...
>> Implementation
>> ==============
>>
>> There is currently a rational module distributed with Python, and a
>> second rational module in the Python cvs source tree that is not
>> distributed. While one of these could be chosen and made to conform
>> to the specification, I am hoping that several people will volunteer
>> implementatins so that a ''best of breed'' implementation may be
>> chosen.

>
> I'll be the first to volunteer an implementation.

I've already got two implementations. Both vary from the PEP.

> I've made the following deviations from your PEP:
>
> * Binary operators with one Rational operand and one float or Decimal
> operand will not raise a TypeError, but return a float or Decimal.
> * Expressions of the form Decimal op Rational do not work. This is a
> bug in the decimal module.
> * The constructor only accepts ints and longs. Conversions from float
> or Decimal to Rational can be made with the static methods:
> - fromExactFloat: exact conversion from float to Rational
> - fromExactDecimal: exact conversion from Decimal to Rational
> - approxSmallestDenominator: Minimizes the result's denominator,
> given a maximum allowed error.
> - approxSmallestError: Minimizes the result's error, given a
> maximum allowed denominator.
> For example,

Part of finishing the PEP will be modifying the chosen contribution so
that it matches the PEP. As the PEP champion, I'll take that one (and
also write a test module) before submitting the PEP to the pep list
for inclusion and possible finalization.

If you still wish to contribute your code, please mail it to me as an
attachment.

Thanks,
<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Mike Meyer
Guest
Posts: n/a

 12-27-2004
"John Roth" <(E-Mail Removed)> writes:

> I'd suggest making them public rather than either protected or
> private. There's a precident with the complex module, where
> the real and imaginary parts are exposed as .real and .imag.

This isn't addressed in the PEP, and is an oversight on my part. I'm
against making them public, as Rational's should be immutable. Making
the two features public invites people to change them, meaning that
machinery has to be put in place to prevent that. That means either
making all attribute access go through __getattribute__ for new-style
classes, or making them old-style classes, which is discouraged.

If the class is reimplented in C, making them read-only attributes as
they are in complex makes sense, and should be considered at that
time.

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Mike Meyer
Guest
Posts: n/a

 12-27-2004
Nick Coghlan <(E-Mail Removed)> writes:

> Mike Meyer wrote:
>> Regarding str() and repr() behaviour, Ka-Ping Yee proposes that repr() have
>> the same behaviour as str() and Tim Peters proposes that str() behave like the
>> to-scientific-string operation from the Spec.

>
> This looks like a C & P leftover from the Decimal PEP

Yup. Thank you. This now reads:

Regarding str() and repr() behaviour, repr() will be either
''rational(num)'' if the denominator is one, or ''rational(num,
denom)'' if the denominator is not one. str() will be either ''num''
if the denominator is one, or ''(num / denom)'' if the denominator is
not one.

Is that acceptable?

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Steven Bethard
Guest
Posts: n/a

 12-27-2004
Mike Meyer wrote:
> "John Roth" <(E-Mail Removed)> writes:
>
>
>>I'd suggest making them public rather than either protected or
>>private. There's a precident with the complex module, where
>>the real and imaginary parts are exposed as .real and .imag.

>
>
> This isn't addressed in the PEP, and is an oversight on my part. I'm
> against making them public, as Rational's should be immutable. Making
> the two features public invites people to change them, meaning that
> machinery has to be put in place to prevent that. That means either
> making all attribute access go through __getattribute__ for new-style
> classes, or making them old-style classes, which is discouraged.

Can't you just use properties?

>>> class Rational(object):

.... def num():
.... def get(self):
.... return self._num
.... return dict(fget=get)
.... num = property(**num())
.... def denom():
.... def get(self):
.... return self._denom
.... return dict(fget=get)
.... denom = property(**denom())
.... def __init__(self, num, denom):
.... self._num = num
.... self._denom = denom
....
>>> r = Rational(1, 2)
>>> r.denom

2
>>> r.num

1
>>> r.denom = 2

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
AttributeError: can't set attribute

Steve

Nick Coghlan
Guest
Posts: n/a

 12-27-2004
Mike Meyer wrote:
> Yup. Thank you. This now reads:
>
> Regarding str() and repr() behaviour, repr() will be either
> ''rational(num)'' if the denominator is one, or ''rational(num,
> denom)'' if the denominator is not one. str() will be either ''num''
> if the denominator is one, or ''(num / denom)'' if the denominator is
> not one.
>
> Is that acceptable?

Sounds fine to me.

On the str() front, I was wondering if Rational("x / y") should be an acceptable
string input format.

Cheers,
Nick.

--
Nick Coghlan | http://www.velocityreviews.com/forums/(E-Mail Removed) | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

Steve Holden
Guest
Posts: n/a

 12-27-2004
Dan Bishop wrote:

> Steven Bethard wrote:
>
>>Dan Bishop wrote:
>>
>>>Mike Meyer wrote:
>>>
>>>>PEP: XXX
>>>
>>>I'll be the first to volunteer an implementation.

>>
>>Very cool. Thanks for the quick work!
>>
>>For stdlib acceptance, I'd suggest a few cosmetic changes:

>
>
> No problem.
>
> """Implementation of rational arithmetic."""
>

[Yards of unusable code]

I'd also request that you change all leading tabs to four spaces!

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119

Skip Montanaro
Guest
Posts: n/a

 12-27-2004
Mike> ... or making them old-style classes, which is discouraged.

Since when is use of old-style classes discouraged?

Skip

Steve Holden
Guest
Posts: n/a

 12-27-2004
Skip Montanaro wrote:

> Mike> ... or making them old-style classes, which is discouraged.
>
> Since when is use of old-style classes discouraged?
>

Well, since new-style classes came along, surely? I should have thought
the obvious way to move forward was to only use old-style classes when
their incompatible-with-type-based-classes behavior is absolutely required.

Though personally I should have said "use of new-style classes is
encouraged". I agree that there's no real need to change existing code
just for the sake of it, but it would be interesting to see just how
much existing code fails when preceded by the 1.5.2--to-2.4-compatible (?)

__metaclass__ = type

guessing-not-that-much-ly y'rs - steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119

Mike Meyer
Guest
Posts: n/a

 12-27-2004
Nick Coghlan <(E-Mail Removed)> writes:

> Mike Meyer wrote:
>> Yup. Thank you. This now reads:
>> Regarding str() and repr() behaviour, repr() will be either
>> ''rational(num)'' if the denominator is one, or ''rational(num,
>> denom)'' if the denominator is not one. str() will be either ''num''
>> if the denominator is one, or ''(num / denom)'' if the denominator is
>> not one.
>> Is that acceptable?

>
> Sounds fine to me.
>
> On the str() front, I was wondering if Rational("x / y") should be an
> acceptable string input format.

I don't think so, as I don't see it coming up often enough to warrant
implementing. However, Rational("x" / "y") will be an acceptable
string format as fallout from accepting floating point string
representations.

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Mike Meyer
Guest
Posts: n/a

 12-27-2004
Skip Montanaro <(E-Mail Removed)> writes:

> Mike> ... or making them old-style classes, which is discouraged.
>
> Since when is use of old-style classes discouraged?

I was under the imperssion that old-style classes were going away, and
hence discouraged for new library modules.

However, a way to deal with this cleanly has been suggested by Steven
Bethard, so the point is moot for this discussion.

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

 Thread Tools

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post opalpa@gmail.com opalinski from opalpaweb Java 2 03-16-2006 07:12 PM Mike Meyer Python 21 12-23-2004 07:17 AM Jp Calderone Python 1 12-18-2004 07:19 PM newtohtml@att.net HTML 1 07-19-2004 01:36 PM TechGeekPro MCSE 26 06-29-2004 06:01 AM

Advertisments