Comment on PEP-0238

[Emile van Sebille]

----- Original Message -----
From: "Guido van Rossum" <guido at python.org>
Newsgroups: comp.lang.python
Sent: Sunday, July 08, 2001 5:27 AM
Subject: Re: Comment on PEP-0238


> Your examples don't show what should happen in this example:
>
>   precision 0
>   x = 2/7
>   precision 4
>   print x

0

>
> In other words, is the precision a property of the printing or a
> property of the value stored?
>

The value stored.  For example:
>>> precision 8
>>> x = 2/7
>>> print x
 .28571429
>>> precision 3
>>> print x
 .286
>>> precision 5
>>> print x
 .28571
>>> precision 14
>>> print x
 .28571429
>>> x = 2/7
>>> print x
 .28571428571429

> There are lots of other ways to get this effect for printing ("%.4f"%x
> comes to mind); if you intended the effect to apply to computation
> results, there are questions about the scope of the calculation.  If I
> write
>
>   precision 3
>   x = f() # some function that uses int division
>
> should every calculation in f() be affected by the precision
> statement?
>

No.  I'd imagine that precision would live in the current namespace.  f()
would use whatever level of precision it needs.  The namespace invoking f()
does likewise, as would the namespace containing f().  If you write a module
containing functions that only require 4 decimal places and set precision to
4 at the module level, all calculations, variable creation and passing (eg
def xxx(a,b,c)), interim calculations, and results returned would work at
precision 4.  The assignment of the return value to x in the local namespace
should be at the local precision, but I can see where this might cause some
implementation concerns, particularly if a composite is returned.  Perhaps
the initial creation of the object fixes the precision, and use of the
number is controlled by the encompassing namespace.


> Etc., etc.
>

I'll give this some thought.  ;-)

> This is exactly why I was asking you to write a PEP.  I don't mean
> that you have to write an implementation.  (Despite the seeming
> requirement in PEP 2, that's not a requirement before a PEP is
> accepted for review -- that's only required before a standard PEP is
> finally approved for inclusion in the language.  There are plenty of
> PEPs without a shred of implementation.)

Good.  I'll see if I can't further consider some of these isssues and put
one together over the next week or ten days.

>
> --Guido van Rossum (home page: http://www.python.org/~guido/)


Emile van Sebille
emile at fenx.com

---------