>> - In 3.0, we don't want an exception. With floats and decimals,
>> leading zeroes are allowed (i.e. 0.123). In 3.0, I would like the
>> leading zero distinction to disappear from our collective memory.
>> Somelike like eval('00987') should give 987, not an exception.
>> The use cases for zfill() correspond to the cases where leading zeroes
>> are meaningfully interpreted as decimals (this includes phone and
>> social security numbers, account numbers, and whatnot).
[Pat]
>This is the only part I'm not sure I agree with.
Leading zeroes are not a syntax error. Excel supports them for both input and
output formats because accountants (like me) ocassionally need them. Schoolkids
have an expectation that leading zeroes do not change the value. Your pocket
calculator accepts leading zeroes. I do not support adding yet another
SyntaxError to the language -- that will not improve its ease of use. With
decimal and float literals supporting lead zeroes, it would be a wart to
introduce a syntax error for ints.
>In fact, I would go so far as to argue that the behavior of int()
>should be changed as well:
>
> int('012') -> exception (used to return 12)
Gratuitous breakage.
Major inconvenience when parsing zfilled inputs (which are ubiquitous).
hour, minutes, seconds = map(int, '08:30:00'.split(':'))
Raymond
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
