--> Tired of decyphering the Perl code you wrote last week?

--> Frustrated with Bourne shell syntax?

--> Spent too much time staring at core dumps lately?

Maybe you should try Python, the next generation object-oriented
scripting and prototyping language, with a *readable* syntax.  Python
has been used by hundreds of happy users all over the world during the
past three years, and is now ready for prime time.

Python is an interpreted language, and has the usual advantages of
such languages, such as run-time checks (e.g. bounds checking),
execution of dynamically generated code, automatic memory allocation,
high level operations on strings, lists and dictionaries (associative
arrays), and a fast edit-compile-run cycle.  Additionally, it features
modules, classes, exceptions, and dynamic linking of extensions
written in C or C++.  It has arbitrary precision integers.

Python can be run interactively, and there is an extensive Emacs
editing mode which includes the capability to execute regions of code.
For the truly desperate there is a source level debugger (written in
Python, of course :-).

Python comes with a large library of standard modules and classes, as
well as an extensive set of demo programs.  It has interfaces to most
Unix system calls and library functions, and there exist extensions
that interface to window systems and graphics libraries like X and
SGI's GL.

Python's source (in C) and documentation (in LaTeX and PostScript) are
freely available on the Internet.  It builds without intervention on
most Unix platforms: error-free builds have been confirmed for SGI
IRIX 4 and 5, Sun SunOS 4 and Solaris 2, HP-UX, DEC Ultrix and OSF/1,
IBM AIX, and SCO ODT 3.0.  A Macintosh binary is also available -- a
DOS binary is in the works.

If you have a WWW viewer (e.g. Mosaic), you can see all Python
documentation on-line: point your viewer at the URL
http://www.cwi.nl/~guido/Python.html.

The source and documentation are available by anonymous ftp from the
following sites -- please pick the one closest to you:

Site                    IP address      Directory

ftp.cwi.nl                192.16.184.180        /pub/python
gatekeeper.dec.com      16.1.0.2        /pub/plan/python/cwi
ftp.uu.net              192.48.96.9     /languages/python
ftp.fu-berlin.de        130.133.4.50    /pub/unix/languages/python

The file is called python1.0.0.tar.Z (some mirror sites convert it to
a .gz file or split it up in separate parts).  See the INDEX file for
other goodies: FAQ, NEWS, PostScript, Emacs info, Mac binary, etc.
(Please don't ask me to mail it to you -- at 1.76 Megabytes it is
unwieldy at least...)

There's a mailing list; write to <pytho...@cwi.nl> to subscribe (no
LISTSERV commands please).  A FAQ list is regularly posted to
comp.lang.misc.  A newsgroup may be created in the near future.

[Excuse the hype -- Python really is a neat language, if I may say so.
Please direct all followups to comp.lang.misc only.]

--Guido van Rossum, CWI, Amsterdam <Guido.va...@cwi.nl>
URL:  <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>

Just took a look at the reference manual and had a question. Since:

  -- there is no limit on the size of a long integer and
  -- floats are implemented as C doubles and
  -- the first arithmetic conversion is to convert to a float

what happens when a long integer that is beyond the range of a C double
is used with a float ? Is some exception raised reliably ?

It seems more reasonable to add a rational type which is a ratio of two
long integers and convert floats to that type. The current conversion
of a less restrictive type to a more restrictive type seems rather
unsatisfactory.

Ram (r...@aqm.com)
p.s. This posting is unrelated to my employer

gu...@cwi.nl (Guido van Rossum) writes:

>r...@imagen.com (M.V.S. Ramanath) writes:

>What will happen is that you get a random float value, as there is
>currently no check for overflow.  There should be one, though, and
>there will be one as soon as I figure out a portable way to do it.

>Python does not have a rational type.  They're not that useful (at
>least far less essential than arbitrary precision integers), and
>easily implemented in Python once you have arbitrary precision
>integers -- see Demo/classes/Rat.py for a first shot.  (It's in the
>Demo directory because it's not complete and lacking in usability, but
>it shows how you could do such a thing.)

>Even if there were a rational type, I don't think that it would be a
>good idea to convert the float to rational -- I think it is better to
>convert the rational to float, and raise an error if it doesn't fit.

    I guess I don't see the wisdom of aborting a calculation when
    there is no need to.

>My reasoning is that float is the only *inexact* type -- for the
>other types, results are exact if they can be computed at all.  (At
>least in an ideal system -- python comes pretty close here.)  When
>mixing exact and inexact numbers, I believe that the result should be
>labeled inexact.

    I have no problems with "labelling" the resulting rational as
    "inexact" whatever that means from an implementation point of view.

    The general rule ought to be: don't abort when you don't have to.
    I still believe that converting a less restrictive type to a more
    restrictive one is unwise. A user who gets an approximate answer
    (and one using floats surely expects this) is likely to be happier
    than one who gets no results at all.

>Hope this answers your question,

    Shows that there's more than one point of view anyway. Good work on
    the language.

    Ram

In article <CKCEu...@cwi.nl> gu...@cwi.nl (Guido van Rossum) writes:
>r...@imagen.com (M.V.S. Ramanath) writes:

>>what happens when a long integer that is beyond the range of a C double
>>is used with a float ? Is some exception raised reliably ?
>>
>>It seems more reasonable to add a rational type which is a ratio of two
>>long integers and convert floats to that type. The current conversion
>>of a less restrictive type to a more restrictive type seems rather
>>unsatisfactory.

>...

>Python does not have a rational type.

>...

>Even if there were a rational type, I don't think that it would be a
>good idea to convert the float to rational -- I think it is better to
>convert the rational to float, and raise an error if it doesn't fit.

>My reasoning is that float is the only *inexact* type

I think this is a "rational" thing to do. It seems to coincide with the
Scheme programming language's approach to exact and inexact numbers. And
the authors of Scheme seem to be near the forefront of this area.

From the Revised^4 Report on Scheme, section 6.5.2:

"If the operation is unable to produce an exact result, then it may either
report the violation of an implementation restriction or it may silently
coerce its result to an inexact value."

--
pa...@goldfish.mitron.tek.com

r...@imagen.com (M.V.S. Ramanath) writes:

What will happen is that you get a random float value, as there is

currently no check for overflow.  There should be one, though, and
there will be one as soon as I figure out a portable way to do it.

Python does not have a rational type.  They're not that useful (at
least far less essential than arbitrary precision integers), and
easily implemented in Python once you have arbitrary precision
integers -- see Demo/classes/Rat.py for a first shot.  (It's in the
Demo directory because it's not complete and lacking in usability, but
it shows how you could do such a thing.)

Even if there were a rational type, I don't think that it would be a

good idea to convert the float to rational -- I think it is better to
convert the rational to float, and raise an error if it doesn't fit.

My reasoning is that float is the only *inexact* type -- for the
other types, results are exact if they can be computed at all.  (At
least in an ideal system -- python comes pretty close here.)  When
mixing exact and inexact numbers, I believe that the result should be
labeled inexact.

Hope this answers your question,

--Guido van Rossum, CWI, Amsterdam <Guido.va...@cwi.nl>
URL:  <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>