A Revised Rational Proposal

[Steve Holden]

Re: A Revised Rational Proposal

Dan Bishop wrote:
[color=blue]
> Steven Bethard wrote:
>[color=green]
>>Dan Bishop wrote:
>>[color=darkred]
>>>Mike Meyer wrote:
>>>
>>>>PEP: XXX
>>>
>>>I'll be the first to volunteer an implementation.[/color]
>>
>>Very cool. Thanks for the quick work!
>>
>>For stdlib acceptance, I'd suggest a few cosmetic changes:[/color]
>
>
> No problem.
>
> """Implementati on of rational arithmetic."""
>[/color]
[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]

Re: A Revised Rational Proposal

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

Since when is use of old-style classes discouraged?

Skip

[Steve Holden]

Re: A Revised Rational Proposal

Skip Montanaro wrote:
[color=blue]
> Mike> ... or making them old-style classes, which is discouraged.
>
> Since when is use of old-style classes discouraged?
>[/color]

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]

Re: A Revised Rational Proposal

Nick Coghlan <ncoghlan@iinet .net.au> writes:
[color=blue]
> Mike Meyer wrote:[color=green]
>> 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?[/color]
>
> Sounds fine to me.
>
> On the str() front, I was wondering if Rational("x / y") should be an
> acceptable string input format.[/color]

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 <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Re: A Revised Rational Proposal

Skip Montanaro <skip@pobox.com > writes:
[color=blue]
> Mike> ... or making them old-style classes, which is discouraged.
>
> Since when is use of old-style classes discouraged?[/color]

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 <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[John Roth]

Re: A Revised Rational Proposal


"Mike Meyer" <mwm@mired.or g> wrote in message
news:86r7lbviye .fsf@guru.mired .org...[color=blue]
> Nick Coghlan <ncoghlan@iinet .net.au> writes:
>[color=green]
>> Mike Meyer wrote:[color=darkred]
>>> 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?[/color]
>>
>> Sounds fine to me.
>>
>> On the str() front, I was wondering if Rational("x / y") should be an
>> acceptable string input format.[/color]
>
> 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 .[/color]

How would that work? I though the divide would be
evaluated before the function call, resulting in an exception
(strings don't implement the / operator).

John Roth[color=blue]
>
> <mike
> --
> Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
> Independent WWW/Perforce/FreeBSD/Unix consultant, email for more
> information.[/color]