A rational proposal

[Mike Meyer]

PEP: XXX
Title: A rational number module for Python
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/09/22 04:51:50 $
Author: Mike Meyer <mwm@mired.or g>
Status: Draft
Type: Staqndards
Content-Type: text/x-rst
Created: 16-Dec-2004
Python-Version: 2.5
Post-History: 30-Aug-2002


Abstract
========

This PEP proposes a rational number module to add to the Python
standard library.


Rationale
=========

Rationals are a standard mathematical concept, included in a variety
of programming languages already. Python, which comes with 'batteries
included' should not be deficient in this area. When the subject was
brought up on comp.lang.pytho n several people mentioned having
implemented a rational number module, one person more than once. In
fact, there is a rational number module distributed with Python as an
example module. Such repetition shows the need for such a class in the
standard library.

There are currently two PEPs dealing with rational numbers - 'Adding a
Rational Type to Python' [#PEP-239] and 'Adding a Rational Literal to
Python' [#PEP-240], both by Craig and Zadka. This PEP competes with
those PEPs, but does not change the Python language as those two PEPs
do [#PEP-239-implicit]. As such, it should be easier for it to gain
acceptance. At some future time, PEP's 239 and 240 may replace the
``rational`` module.


Specification
=============

The module shall be ``rational``, and the class ``Rational``, to
follow the example of the decimal [#PEP-327] module. The class
creation method shall accept as arguments a numerator, and an optional
denominator, which defaults to one. Both the numerator and
denominator - if present - must be of integer type. Since all other
numeric types in Python are immutable, Rational objects will be
immutable. Internally, the representation will insure that the
numerator and denominator have a greatest common divisor of 1, and
that the sign of the denominator is positive.

The ``Rational`` class shall define all the standard mathematical
operations: addition, subtraction, multiplication, division, modulo
and power. It will also provide the methods:

- max(*args): return the largest of a list of numbers and self.
- min(*args): return the smallest of a list of numbers and self.
- decimal(): return the decimal approximation to the rational in the
current context.
- inv(): Return the inverse of self.

Rationals will mix with all other numeric types. When combined with an
integer type, that integer will be converted to a rational before the
operation. When combined with a floating type - either complex or
float - the rational will be converted to a floating approximation
before the operation, and a float or complex will be returned. The
reason for this is that floating point numbers - including complex -
are already imprecise. To convert them to rational would give an
incorrect impression that the results of the operation are
precise. Decimals will be converted to rationals before the
operation. [Open question: is this the right thing to do?]

Rationals can be converted to floats by float(rational) , and to
integers by int(rational).

The module will define and at times raise the following exceptions:

- DivisionByZero: divide by zero
- OverflowError: overflow attempting to convert to a float.

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.


References
==========

... [#PEP-239] Adding a Rational Type to Python, Craig, Zadka
(http://www.python.org/peps/pep-0239.html)
... [#PEP-240] Adding a Rational Literal to Python, Craig, Zadka
(http://www.python.org/peps/pep-0240.html)
... [#PEP-327] Decimal Data Type, Batista
(http://www.python.org/peps/pep-0327.html)
... [#PEP-239-implicit] PEP 240 adds a new literal type to Pytbon,
PEP 239 implies that division of integers would
change to return rationals.


Copyright
=========

This document has been placed in the public domain.



...
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:

[Raymond L. Buvel]

Re: A rational proposal

Mike Meyer wrote:[color=blue]
> PEP: XXX
> Title: A rational number module for Python[/color]
<snip>

I think it is a good idea to have rationals as part of the standard
distribution but why not base this on the gmpy module
(https://sourceforge.net/projects/gmpy)? That module already provides
good performance. However, it does a few things that may not be good ideas.

1. Floats are converted to rationals. I think your proposal of rational
to float is better.

2. Fails with a TypeError when used with a complex. Again Your proposal
provides a better solution.

3. Fractional powers fail with a ValueError if the root is not exact.
You do not address this in your proposal. Could silently convert to
float in this case but is it better to force the user to be explicit and
use the float() operation?

Ray Buvel

[John Roth]

Re: A rational proposal


"Mike Meyer" <mwm@mired.or g> wrote in message
news:864qik472n .fsf@guru.mired .org...[color=blue]
> PEP: XXX
> Title: A rational number module for Python
> Version: $Revision: 1.4 $
> Last-Modified: $Date: 2003/09/22 04:51:50 $
> Author: Mike Meyer <mwm@mired.or g>
> Status: Draft
> Type: Staqndards
> Content-Type: text/x-rst
> Created: 16-Dec-2004
> Python-Version: 2.5
> Post-History: 30-Aug-2002
>
>
> Abstract
> ========
>
> This PEP proposes a rational number module to add to the Python
> standard library.[/color]

[snip]
[color=blue]
> The ``Rational`` class shall define all the standard mathematical
> operations: addition, subtraction, multiplication, division, modulo
> and power. It will also provide the methods:
>
> - max(*args): return the largest of a list of numbers and self.
> - min(*args): return the smallest of a list of numbers and self.[/color]

max() and min() are already part of the standard library.
Providing them as instance methods is quite irregular.
[color=blue]
> - decimal(): return the decimal approximation to the rational in the
> current context.[/color]

This ought to be the responsibility of the decimal() constructor.
I can see including it here to avoid adding it to the decimal()
constructor, but IMO it's bad design.
[color=blue]
> - inv(): Return the inverse of self.[/color]

I presume this means that if the rational is x/y, then it
returns y/x?
[color=blue]
> Rationals will mix with all other numeric types. When combined with an
> integer type, that integer will be converted to a rational before the
> operation. When combined with a floating type - either complex or
> float - the rational will be converted to a floating approximation
> before the operation, and a float or complex will be returned. The
> reason for this is that floating point numbers - including complex -
> are already imprecise. To convert them to rational would give an
> incorrect impression that the results of the operation are
> precise. Decimals will be converted to rationals before the
> operation. [Open question: is this the right thing to do?][/color]

I'd prefer to have rationals converted to decimals before
the operation, for the same reason that they're converted
to floats. Decimals also have limited precision.
[color=blue]
> Rationals can be converted to floats by float(rational) , and to
> integers by int(rational).[/color]

If this is the case, then there is no reason to have a separate
member operation to convert rationals to decimal. Consistency
says to do it the same way for all similar operations.

....

John Roth

[Mike Meyer]

Re: A rational proposal

"Raymond L. Buvel" <levub137@wi.rr .com> writes:
[color=blue]
> Mike Meyer wrote:[color=green]
>> PEP: XXX
>> Title: A rational number module for Python[/color]
> <snip>
>
> I think it is a good idea to have rationals as part of the standard
> distribution but why not base this on the gmpy module
> (https://sourceforge.net/projects/gmpy)? That module already provides
> good performance. However, it does a few things that may not be good
> ideas.[/color]

It wraps a third party package, which can't really be added to the
standard libraray. The documentation for a rationa number package in
Python should include a pointer to gmpy with a note about performance.
[color=blue]
> 3. Fractional powers fail with a ValueError if the root is not
> exact. You do not address this in your proposal. Could silently
> convert to float in this case but is it better to force the user to be
> explicit and use the float() operation?[/color]

You're right. Raising a rational to a rational power isn't covered,
and may produce an irrational answer. Raising a rational to a floating
point power will cause the rational to be converted to a float, as is
specified.

I think forcing the use of float is wrong, as the rational may be an
integer. I'm not sure what should be done, so this is being added as
an open issue.

Thanks,
<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 rational proposal

"John Roth" <newsgroups@jhr othjr.com> writes:
[color=blue]
> "Mike Meyer" <mwm@mired.or g> wrote in message
> news:864qik472n .fsf@guru.mired .org...[color=green]
>> PEP: XXX
>> Title: A rational number module for Python
>> The ``Rational`` class shall define all the standard mathematical
>> operations: addition, subtraction, multiplication, division, modulo
>> and power. It will also provide the methods:
>>
>> - max(*args): return the largest of a list of numbers and self.
>> - min(*args): return the smallest of a list of numbers and self.[/color]
>
> max() and min() are already part of the standard library.
> Providing them as instance methods is quite irregular.[/color]

They don't handle decimals or rationals. This is following the lead of
the decimal package.
[color=blue][color=green]
>> - decimal(): return the decimal approximation to the rational in the
>> current context.[/color]
>
> This ought to be the responsibility of the decimal() constructor.
> I can see including it here to avoid adding it to the decimal()
> constructor, but IMO it's bad design.[/color]

Good point. Currently, objects now how to convert themselves to int,
float and complex. Should Rational now how to convert itself to
Decimal (and conversely, decimal now how to convert itself to
Rational)?
[color=blue][color=green]
>> - inv(): Return the inverse of self.[/color]
> I presume this means that if the rational is x/y, then it
> returns y/x?[/color]

Is this better wording:
- inv(): Return self to the power -1.

[color=blue][color=green]
>> Rationals will mix with all other numeric types. When combined with an
>> integer type, that integer will be converted to a rational before the
>> operation. When combined with a floating type - either complex or
>> float - the rational will be converted to a floating approximation
>> before the operation, and a float or complex will be returned. The
>> reason for this is that floating point numbers - including complex -
>> are already imprecise. To convert them to rational would give an
>> incorrect impression that the results of the operation are
>> precise. Decimals will be converted to rationals before the
>> operation. [Open question: is this the right thing to do?][/color]
>
> I'd prefer to have rationals converted to decimals before
> the operation, for the same reason that they're converted
> to floats. Decimals also have limited precision.[/color]

I'm of two minds about this one. One is that decimals have limited
precision. But they represent their values exactly, whereas 1E73 isn't
a 1 followed by 73 zeros when converted to an int. On the other hand,
every decimal has a rational equivalent, but not vice versa.

Thanks,
<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Tim Peters]

Re: A rational proposal

[Jp Calderone]
....[color=blue]
> The Decimal type seems to define min and max so that NaNs
> can be treated specially, but I glean this understanding from only
> a moment of reading decimal.py. Perhaps someone more well
> informed can declare definitively the purpose of these methods.[/color]

To conform to the semantics of the min and max operations defined in
IBM's proposed standard for decimal arithmetic:

http://www2.hursley.ibm.com/decimal/

and in particular:

http://www2.hursley.ibm.com/decimal/daops.html#refmax

and

http://www2.hursley.ibm.com/decimal/daops.html#refmin

Note that this is a moving target.

[Terry Reedy]

Re: A rational proposal


"Mike Meyer" <mwm@mired.or g> wrote in message
news:863by3sbnt .fsf@guru.mired .org...[color=blue][color=green][color=darkred]
>>> Title: A rational number module for Python[/color]
>> <snip>[/color][/color]

1. I would call this Not Necessary but Nice. Perhaps the time has come to
include rationals in the Standard Library, given that its expansion will be
a focus of the 2.5 cycle. It certainly seems time to have such a PEP
pushed to a formal decision.

To increase the chance of getting BDFL approval, you might search clp and
especially pydev archives for Guido's (and maybe other developers') past
objections and prepare to meet them. I vaguely remember things like too
specialized and not needed enough, need already met by third party modules,
and the inherent clumbsiness of exact rational calculations (due to length
growth of 'ators and the time needed to remove common factors, if one
does).

2. The initial and debugged implementation should be in Python at least
until the interface and behavioral specs are finalized. Beside the obvious
reasons, this will help the PyPy project which is currently being slowed a
bit by the needed to rewrite C-coded modules in Python.

Terry J. Reedy

[Nick Coghlan]

Re: A rational proposal

Mike Meyer wrote:[color=blue][color=green]
>>max() and min() are already part of the standard library.
>>Providing them as instance methods is quite irregular.[/color]
>
> They don't handle decimals or rationals. This is following the lead of
> the decimal package.[/color]

As Tim pointed out - decimal has its own versions of max & min which conform to
the decimal specification.

For the builtin in max and min, decimal's behave like any other number.
[color=blue][color=green][color=darkred]
>>>- decimal(): return the decimal approximation to the rational in the
>>> current context.[/color]
>>
>>This ought to be the responsibility of the decimal() constructor.
>>I can see including it here to avoid adding it to the decimal()
>>constructor , but IMO it's bad design.[/color][/color]

Actually, what's missing at the moment is the decimal equivalent of __int__,
__float__, etc.

Generally, for new types, it is the new type's responsibility to play well with
pre-existing types, not the other way round (think about what the __str__ method
actually does - it's the type conversion method for turning your object into a
string object)
[color=blue]
> Good point. Currently, objects now how to convert themselves to int,
> float and complex. Should Rational now how to convert itself to
> Decimal (and conversely, decimal now how to convert itself to
> Rational)?[/color]

Doing either of those properly requires adding slots to the type structure
(since you need new magic methods - __decimal__ and __rational__).

I believe the goal is to have Decimal.decimal become a builtin for Py 2.5, in
which case, I would also hope to see a __decimal__ special method.

The correct answer would then be for Rational.ration al to handle decimals in its
constructor, and provide an implementation of __decimal__ (similar to the way
Decimal.decimal interacts with the other builtin types).

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@email. com | Brisbane, Australia
---------------------------------------------------------------

http://boredomandlaziness.skystorm.net

[Alex Martelli]

Re: A rational proposal

Raymond L. Buvel <levub137@wi.rr .com> wrote:
[color=blue]
> Mike Meyer wrote:[color=green]
> > PEP: XXX
> > Title: A rational number module for Python[/color]
> <snip>
>
> I think it is a good idea to have rationals as part of the standard
> distribution but why not base this on the gmpy module
> (https://sourceforge.net/projects/gmpy)? That module already provides[/color]

gmpy wraps GMP, which is covered by LGPL; therefore, gmpy itself is
LGPL, and thus, sadly, cannot be included with python (otherwise,
speaking as gmpy's author, I'd be glad to fix its design to meet your
objections).


Alex

[Paul Rubin]

Re: A rational proposal

aleaxit@yahoo.c om (Alex Martelli) writes:[color=blue]
> gmpy wraps GMP, which is covered by LGPL; therefore, gmpy itself is
> LGPL, and thus, sadly, cannot be included with python (otherwise,
> speaking as gmpy's author, I'd be glad to fix its design to meet your
> objections).[/color]

There's no obstacle to including LGPL'd modules as part of the Python
distribution as long as those modules are also offered as source code.
The LGPL does place some conditions on how LGPL'd modules can be
further redistributed, which users would have to abide by; that might
or might not be considered undesirable for Python distro purposes.
There's certainly no reason the Python docs can't point to modules
like gmpy. They already point to code and documentation that's
flat-out proprietary.

[Raymond L. Buvel]

Re: A rational proposal

Alex Martelli wrote:[color=blue]
> Raymond L. Buvel <levub137@wi.rr .com> wrote:
>
>[color=green]
>>Mike Meyer wrote:
>>[color=darkred]
>>>PEP: XXX
>>>Title: A rational number module for Python[/color]
>>
>><snip>
>>
>>I think it is a good idea to have rationals as part of the standard
>>distributio n but why not base this on the gmpy module
>>(https://sourceforge.net/projects/gmpy)? That module already provides[/color]
>
>
> gmpy wraps GMP, which is covered by LGPL; therefore, gmpy itself is
> LGPL, and thus, sadly, cannot be included with python (otherwise,
> speaking as gmpy's author, I'd be glad to fix its design to meet your
> objections).
>
>
> Alex[/color]

Since the LGPL was designed to allow propritary software to link to a
LGPL module, I don't see why any software under a free license like
Python cannot link to the GMP library. The PSF may want you to release
gmpy under a dual license if it is incorporated into the Python standard
library but I don't see why that cannot be done.

Ray

[Fredrik Lundh]

Re: A rational proposal

Raymond L. Buvel wrote:
[color=blue][color=green]
>> gmpy wraps GMP, which is covered by LGPL; therefore, gmpy itself is
>> LGPL, and thus, sadly, cannot be included with python (otherwise,
>> speaking as gmpy's author, I'd be glad to fix its design to meet your
>> objections).[/color][/color]
[color=blue]
> Since the LGPL was designed to allow propritary software to link to a LGPL module, I don't see why
> any software under a free license like Python cannot link to the GMP library. The PSF may want
> you to release gmpy under a dual license if it is incorporated into the Python standard library
> but I don't see why that cannot be done.[/color]

core features cannot rely on software components with restrictive licenses.

nothing stops a Python distributor from shipping Python builds with LGPL'ed
(or GPL'ed) components today; Alex was talking about the core distribution.

</F>

[Dave Benjamin]

Re: A rational proposal

Hi Mike - Thanks for taking the time to put this together.

In article <864qik472n.fsf @guru.mired.org >, Mike Meyer wrote:[color=blue]
> - max(*args): return the largest of a list of numbers and self.
> - min(*args): return the smallest of a list of numbers and self.[/color]

I would strongly prefer either adapting the already built-in min/max
functions to support this type or creating functions in a module rather than
using the method approach. My reason is the assymetry; I would much prefer:

rational.max(ra t1, rat2, rat3)

over:

rat1.max(rat2, rat3)

for the simple reason that the latter looks unbalanced and empbasizes "rat1"
when there is really no reason to do so.
[color=blue]
> Rationals will mix with all other numeric types. When combined with an
> integer type, that integer will be converted to a rational before the
> operation. When combined with a floating type - either complex or
> float - the rational will be converted to a floating approximation
> before the operation, and a float or complex will be returned. The
> reason for this is that floating point numbers - including complex -
> are already imprecise. To convert them to rational would give an
> incorrect impression that the results of the operation are
> precise. Decimals will be converted to rationals before the
> operation. [Open question: is this the right thing to do?][/color]

Sounds right to me.

Cheers,
Dave

--
.:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
"talking about music is like dancing about architecture."

[Christopher A. Craig]

Re: A rational proposal

I've been thinking about doing this for a while. cRat
(http://sf.net/projects/pythonic) already meets these qualifications
except that I need to add decimal support to it now that decimals are
in the language. I could rewrite the existing code in Python (it's
currently in C), but there are some very real performance reasons to
do it in C rather than Python (i.e. I'm manipulating the internals of
the numerator and denominator by hand for performance in the GCD
function)

--
Christopher A. Craig <com-nospam@ccraig.o rg>
"I affirm brethren by the boasting in you which I have in Christ Jesus
our Lord, I die daily" I Cor 15:31 (NASB)

[Bengt Richter]

Re: A rational proposal

On Fri, 17 Dec 2004 21:29:52 -0600, Mike Meyer <mwm@mired.or g> wrote:
[color=blue]
>PEP: XXX
>Title: A rational number module for Python
>Version: $Revision: 1.4 $
>Last-Modified: $Date: 2003/09/22 04:51:50 $
>Author: Mike Meyer <mwm@mired.or g>
>Status: Draft
>Type: Staqndards
>Content-Type: text/x-rst
>Created: 16-Dec-2004
>Python-Version: 2.5
>Post-History: 30-Aug-2002
>
>
>Abstract
>========
>
>This PEP proposes a rational number module to add to the Python
>standard library.
>
>
>Rationale
>=========
>
>Rationals are a standard mathematical concept, included in a variety
>of programming languages already. Python, which comes with 'batteries
>included' should not be deficient in this area. When the subject was
>brought up on comp.lang.pytho n several people mentioned having
>implemented a rational number module, one person more than once. In
>fact, there is a rational number module distributed with Python as an
>example module. Such repetition shows the need for such a class in the
>standard library.
>
>There are currently two PEPs dealing with rational numbers - 'Adding a
>Rational Type to Python' [#PEP-239] and 'Adding a Rational Literal to
>Python' [#PEP-240], both by Craig and Zadka. This PEP competes with
>those PEPs, but does not change the Python language as those two PEPs
>do [#PEP-239-implicit]. As such, it should be easier for it to gain
>acceptance. At some future time, PEP's 239 and 240 may replace the
>``rational`` module.
>
>
>Specificatio n
>============ =
>
>The module shall be ``rational``, and the class ``Rational``, to
>follow the example of the decimal [#PEP-327] module. The class
>creation method shall accept as arguments a numerator, and an optional
>denominator, which defaults to one. Both the numerator and
>denominator - if present - must be of integer type. Since all other
>numeric types in Python are immutable, Rational objects will be
>immutable. Internally, the representation will insure that the
>numerator and denominator have a greatest common divisor of 1, and
>that the sign of the denominator is positive.[/color]
IMO a string should also be a legitimate constructor argument,
as e.g. it is for int. This also provides the opportunity to accept
strings ordinarily representing floating point values and convert them
to exact rationals. E.g., '1.23' is exactly 123/100 so IWT it convenient
if rational.rat('1 .23') == rational.rat(12 3, 100).

This principle is easily extended to '1.23e-45' etc., since any similar
otherwise-floating-point literal string can be represented exactly as
a rational if integer values of numerator and denominator are not limited
-- which they aren't in Python. Decimal floating point literal notation is
quite handy, and it is easy and exact to convert to rational, though
the reverse in not possible in general. A small further extension to literal
representation is to allow two of the aforementioned style of literals
to be joined with a '/' so that rat('x/y') == rat('x')/rat('y')
-- i.e., you could implement this extension of literal format by just trying
a literal_string. split('/') and doing the obvious. This also creates
a possible general repr format that can represent any rational accurately,
and the possibility if desired of a "friendly" __str__ format where a denominator
can be made a power of 10, e.g. '0.6' where __repr__ would be '3/5'.
[color=blue]
>
>The ``Rational`` class shall define all the standard mathematical
>operations: addition, subtraction, multiplication, division, modulo
>and power. It will also provide the methods:
>
>- max(*args): return the largest of a list of numbers and self.
>- min(*args): return the smallest of a list of numbers and self.
>- decimal(): return the decimal approximation to the rational in the
> current context.
>- inv(): Return the inverse of self.
>
>Rationals will mix with all other numeric types. When combined with an
>integer type, that integer will be converted to a rational before the
>operation. When combined with a floating type - either complex or
>float - the rational will be converted to a floating approximation
>before the operation, and a float or complex will be returned. The
>reason for this is that floating point numbers - including complex -
>are already imprecise. To convert them to rational would give an
>incorrect impression that the results of the operation are
>precise. Decimals will be converted to rationals before the
>operation. [Open question: is this the right thing to do?][/color]
Sounds right, iff the decimal really does represent an exact value.
But after a division or multiplication of decimals, I'm not sure I'm
comfortable with calling those results exact in the same sense as
if the operations had been with rationals.

IMO the issue of exactness deserves particular emphasis. Otherwise
why even bother with a rational type? If a decimal represents an exact
value, then it should become an exact rational in operations with rationals.

If you define the result of some rounding operations as exact, then
you could make exact rationals from the results. E.g., the string literal
argument would let you take an inexact float
f = 0.1
and round int with string formatting and convert thus
r = rat('%.2f'%f) # could also pass a rounding spec to rat, like rat(f, 2)

and similarly with a decimal type. So that's one mechanism to do capture
of exact values from values known to represent a set of exact values using a set
of approximations that cluster around the exact values in way that makes
unambiguous determination of the represented values possible. (I'm trying to
state it like a patent lawyer grabbing for unanticipated general coverage ;-)[color=blue]
>
>Rationals can be converted to floats by float(rational) , and to
>integers by int(rational).
>
>The module will define and at times raise the following exceptions:
>
>- DivisionByZero: divide by zero
>- OverflowError: overflow attempting to convert to a float.[/color]
I wonder if forced conversion to float or complex from some operation shouldn't
be an exception too. The result could be passed in the exception object, so it
would be easy to wrap risky operations in try/except. Or is a test for
isinstance(x, (float, complex)) the way to go? Is inexactness an exception w.r.t rational?[color=blue]
>
>Implementati on
>============ ==
>
>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
>implementati ns so that a ''best of breed'' implementation may be
>chosen.
>
>
>References
>==========
>
>.. [#PEP-239] Adding a Rational Type to Python, Craig, Zadka
> (http://www.python.org/peps/pep-0239.html)
>.. [#PEP-240] Adding a Rational Literal to Python, Craig, Zadka
> (http://www.python.org/peps/pep-0240.html)
>.. [#PEP-327] Decimal Data Type, Batista
> (http://www.python.org/peps/pep-0327.html)
>.. [#PEP-239-implicit] PEP 240 adds a new literal type to Pytbon,
> PEP 239 implies that division of integers would
> change to return rationals.
>
>
>Copyright
>=========
>
>This document has been placed in the public domain.
>
>
>
>..
> Local Variables:
> mode: indented-text
> indent-tabs-mode: nil
> sentence-end-double-space: t
> fill-column: 70
> End:[/color]

Regards,
Bengt Richter