Comment on PEP-0238

[Emile van Sebille]

Parts of it.  (You do mean PEP 242?)  That and working in Tim's/Aahz's
FixedPoint/Decimal concepts.  In general, if a keyword precision were to be
added to the language, it could serve to set the context in which *all*
calculations are made within the defining scope.  For example:

# default setting
precision 0    # everything behaves as it does now
print 2 / 7    # -> 0, ie to precision 0 decimal places
print 2/7.0   # -> 0.285714285714

precision 1    # all calculations yield 1 decimal point precision interim
results
print 2 / 7    # -> 0.2, ie to precision 1 decimal places

precision 2
print 2 / 7    # -> 0.28, ie to precision 2 decimal places

precision 3
print 2 / 7    # -> 0.285, ie to precision 3 decimal places

This seems to me to break no existing code other than where precision is
currently used as a label, and allows us to teach others, when they get
stung by unexpected results, that they need to set precision appropriately.
Once explained, integer division would not be a surprise to newbies, nor
would the precision of floating point be lost to those who understand and
benefit from its use.  And those of us that just want to write business
accounting applications will be able to set precision 2 at the top of each
module and be done with it.

<new topic>

  But now that I've been asked to PEP up...

Let me quote from PEP0002:

    There are two kinds of PEPs.  A standards track PEP describes a
    new feature or implementation for Python.

Which is what I'd like to see and was referring to.  Later, in PEP0002:

    Standards track PEPs consists of two parts, a design document and
    a reference implementation.

Now, being a user of Python, and not an implementor of changes to python, I
feel that the PEP process is biased to produce what language *writers* want
to see in a language, not what *users* necessarily need or want.  This might
be likened to doing XP without the customer.  For me to start a PEP I would
need to be capable of creating a reference implementation (otherwise who
would do it?).  This will not happen, as I have neither the intimate
internals knowledge nor language development experience to do it.  If a
change were made to the PEP process with a nod to the XP philosophy, whereby
programmers/users/customers wrote stories, python-dev/implementors/BDFL
assigned costs/effort/impact and finally BDFL/community selected which to do
next, then perhaps more stories would come out of how python could be wider
deployed, break through open-glass ceilings, and increase the money being
spent on python solutions.

>From my perspective, being that I still support programs I originally wrote
in the mid '70s, and that these still run on current platforms and versions
of the development language, and do so with minimal maintenance, backward
compatibility is *everything*.  I fully expect the next version of that
application will be written in Python.  As a user of python, I will adapt to
the continued changes.  As a developer with a 25 year line of sight I am
concerned that code I develop today will maintain its viability in 25 years.

Anyone-want-to-implement-my-PEP?-(didn't-think-so-;-)-ly y'rs

--

Emile van Sebille
emile at fenx.com

---------
"Skip Montanaro" <skip at pobox.com> wrote in message
news:mailman.994531918.7040.python-list at python.org...
>
>     Guido> "Emile van Sebille" <emile at fenx.com> writes:
>     >> If you're going to add keywords, why not add precision and allow
>     >> those who want non-integer division to set it to the level of
>     >> precision they require.  That breaks no more code (presumably) than
>     >> adding div or yield does.
>
>     Guido> I'm not sure what you're asking about.  If you're serious,
please
>     Guido> submit a PEP!  This is the time to do it.  Posting to the
>     Guido> newsgroup is *not* sufficient to let an idea be heard by me --
>     Guido> you *have* to mail it to me directly or to python-dev.  (While
I
>     Guido> like to read c.l.py sometimes, I cannot guarantee that I see
>     Guido> every post.)
>
> Isn't this similar to Paul DuBois' floating point ideas?
>
> Skip
>
>