On Friday 27 July 2001 12:57 pm, Guido van Rossum wrote:
> Michael,
>
> Your PEP doesn't spell out what happens when a binary and a decimal
> number are the input for a numerical operator. I believe you said
> that this would be an unconditional error.
>
> But I foresee serious problems. Most standard library modules use
> numbers. Most of the modules using numbers occasionally use a literal
> (e.g. 0 or 1). According to your PEP, literals in module files ending
> with .py default to binary. This means that almost any use of a
> standard library module from your "dpython" will fail as soon as a
> literal is used.
No, because the '.py' file will generate bytecodes for a number literals as
binary number when the module is compiled. If a '.dp' file imports the
contents of a '.py' file the binary numbers will be imported as binary
numbers. If the '.dp' file will need to use the binary number in a
calculation with a decimal number the binary number will have to be cast it
to a decimal number.
---------------------
#gui.py
BLUE = 155
x_axis = 1024
y_axis = 768
--------------------
#calculator.dp
import gui
ytd_interest = 0.04
# ytd_interest is now a decimal number
win = gui.open_window(gui.bg, x_size=gui.x_axis, y_size=gui.y_axis)
app = win.dialog("Bank Balance", bankbalance_callback)
bb = app.get_bankbalance()
# bb now contains a string
newbalance = decimal(bb) *ytd_interest
# now update the display
app.set_bankbalance(str(newbalance))
-------------------
In the example the gui module was used in the calculator module, but they
were alway handled as binary numbers. The parser did not convert them to
decimal numbers because they had been parsed into a gui.pyc file prior to
being loaded into calculator.dp.
> I can't believe that this will work satisfactorily.
I think it will. There will be some cases where it might be necessary to add
modules of convenience functions to make it easier to to use applications
that cross boundaries, but I think these cases will be rare.
Immediately following the introduction of the decimal number types all binary
modules will work as the work today. There will be no additional pain to
continue using those module. There will be no decimal modules, so there is
no problem with making them work with the binary modules. As decimal module
users start developing applications they will develop techniques for working
with the binary modules. Initially it may require a significant effort, but
eventually bondaries will be created and they two domains will coexists.
> Another example of the kind of problem your approach runs into: what
> should the type of len("abc") be? 3d or 3b? Should it depend on the
> default mode?
That is an interesting question. With my current proposal the following
would be required:
stlen = decimal(len("abc"))
A dlen() function could be added, or perhaps allowing the automatic promotion
of int to a decimal would be a reasonable exception. That is one case were
there is no chance of data loss. I'm not apposed to automatic conversions if
there is no danger of errors being introduced.
> I suppose sequence indexing has to accept decimal as well as binary
> integers as indexes -- certainly in a decimal program you will want to
> be able to use decimal integers for indexes.
That is how I would expect it to work.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4