[Python-ideas] syntax for set

[Steven D'Aprano]

Masklinn wrote:
> On 2010-11-24, at 11:57 , Carl M. Johnson wrote:
>> On Wed, Nov 24, 2010 at 12:05 AM, Mike Meyer <
>> mwm-keyword-python.b4bdba at mired.org> wrote:
>>> "Masklinn" <masklinn at masklinn.net> wrote:
>>>> As an alternative, I would modestly propose banning integer literals
>>>> altogether in favor of english-spelled constants: `ONE` can hardly be
>>>> confused with the letter `l`, and having to write `FIVE HUNDRED
>>>> FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY
>>>> ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would
>>>> surely reduce the usage of redundant magic numbers in the code.
>> +1 If it's good enough for my banker when writing checks, it should be good
>> enough for Python. But it might be safer if we required the Arabic numerals
>> in parentheses following the English. If the two don't match, we could raise
>> a CheckingError. Seems to be a basically self-documenting error type to me.
> 
> But then we're back with the possible confusion between arabic numerals and ascii characters.
> 
> Still, I think this idea is a good one, we need some kind of checksum. Maybe it could be merged with Mike's proposal: the "basic english" number is followed by the same number written using roman numerals and the two versions are checked against one another to ensure consistency.

Is this thread happening four months early or eight months late?

But in the spirit of this discussion, can I propose that Python require 
all numeric literals be written out in full English words, followed by 
the binary expansion in brackets, so as to ensure that the value 
generated by Python matches the programmers expectation?

n = ONE THOUSAND FOUR HUNDRED AND FIFTY SEVEN (10110110001)

This will especially be useful for float literals, since the programmer 
will no longer be able to feign ignorance of the complexities of binary 
floating point, but will have to deal with them explicitly:

x = FORTY-TWO POINT ONE \
     (100000001000101000011001100110011001100110011001100110011001101)

Never again will we have to answer questions about why Python's floating 
point maths is inaccurate!

Should we enter the binary expansion in big-endian or little-endian format?



-- 
Steven