[issue6595] Make Decimal constructor accept all unicode decimal digits in input.

2009-08-02 Thread Mark Dickinson

Mark Dickinson  added the comment:

Backported to trunk and release26-maint in r74281 and r74282.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6595] Make Decimal constructor accept all unicode decimal digits in input.

2009-08-02 Thread Mark Dickinson

Mark Dickinson  added the comment:

Committed to py3k in r74279, release31-maint in r74280.  Leaving open for 
backport to 2.x.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6595] Make Decimal constructor accept all unicode decimal digits in input.

2009-07-31 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

I like the str(int(...))  approach because it guarantees handling that
is consistent with other types.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6595] Make Decimal constructor accept all unicode decimal digits in input.

2009-07-30 Thread Mark Dickinson

Mark Dickinson  added the comment:

Thanks for the feedback;  I've added 2.6, 2.7, 3.1 to the
versions and will backport.

[Eric]
> Since you're calling int() on the result, can't this code:
> self._int = str(int((intpart+fracpart).lstrip('0') or '0'))
> just be:
> self._int = str(int(intpart+fracpart))
> ?

Yes!  Thank you.  I'm not sure what (if anything) I was thinking here.

The str(int(...)) hack is quite an ugly way to normalize a string;  it 
also has the drawback of taking time quadratic in the length of the 
input.  In its defence: (a) I can't think of anything better; (b) this 
change seems to have no noticeable effect on the time to run the test-
suite, and (c) since all the arithmetic operations use string <-> int 
conversions anyway the quadratic time behaviour doesn't really make 
things any worse than they already are.

> And here, you already know diag is not None, so do you need the "or 
'0'"
> part?
> self._int = str(int(diag or '0')).lstrip('0')

I think *something* like this is needed, since diag can legitimately be 
the empty string.  It might be clearer as a proper if block, though:  
'if diag: ...  else: ...'.

--
versions: +Python 2.6, Python 2.7, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6595] Make Decimal constructor accept all unicode decimal digits in input.

2009-07-29 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

+1

Also, I would like to see this backported.  We've long promised that any
variance with the spec will be treated as a bugfix.  The change won't
break any existing code.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6595] Make Decimal constructor accept all unicode decimal digits in input.

2009-07-29 Thread Eric Smith

Eric Smith  added the comment:

Since you're calling int() on the result, can't this code:
self._int = str(int((intpart+fracpart).lstrip('0') or '0'))
just be:
self._int = str(int(intpart+fracpart))
?

And here, you already know diag is not None, so do you need the "or '0'"
part?
self._int = str(int(diag or '0')).lstrip('0')

And, in both calls to .lstrip('0'), what happens if you have a
non-European leading '0', like '\uff10'?

Otherwise, the patch looks good to me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6595] Make Decimal constructor accept all unicode decimal digits in input.

2009-07-29 Thread Eric Smith

Eric Smith  added the comment:

+1

The standard recommends it, and the other numeric types support it, so
Decimal should as well.

--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6595] Make Decimal constructor accept all unicode decimal digits in input.

2009-07-29 Thread Mark Dickinson

Mark Dickinson  added the comment:

Here's a patch

--
keywords: +patch
Added file: http://bugs.python.org/file14593/issue6595.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6595] Make Decimal constructor accept all unicode decimal digits in input.

2009-07-29 Thread Mark Dickinson

New submission from Mark Dickinson :

Ezio Melotti asked (on #python-dev) why the Decimal constructor doesn't 
accept decimal digits other than 0-9.  As far as I can tell there's no 
good reason for it not to.  Moreover, the standard on which the decimal 
module is based says[1]:

"""It is recommended that implementations also provide additional number 
formatting routines (including some which are locale-dependent), and if 
available should accept non-European decimal digits in strings."""

All other builtin or standard library numeric types already accept such 
digits:

Python 3.2a0 (py3k:74247, Jul 29 2009, 09:28:12) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> from decimal import Decimal
>>> x = '\uff11\uff10\uff15\uff18\uff15'
>>> x
'10585'
>>> int(x)
10585
>>> float(x)
10585.0
>>> complex(x)
(10585+0j)
>>> Fraction(x)
Fraction(10585, 1)
>>> Decimal(x)
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 548, in 
__new__
"Invalid literal for Decimal: %r" % value)
  File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 3816, in 
_raise_error
raise error(explanation)
decimal.InvalidOperation: Invalid literal for Decimal: '10585'

I propose adding support for this in Python 3.2 and (possibly) 2.7.  The 
change would be for input only:  no record of the original form of the 
digits would be kept by the Decimal object itself, so that e.g.,
str(Decimal('10585')) would still be '10585'.

[1] See http://speleotrove.com/decimal/daconvs.html

--
assignee: marketdickinson
components: Library (Lib)
messages: 91030
nosy: ezio.melotti, marketdickinson
severity: normal
status: open
title: Make Decimal constructor accept all unicode decimal digits in input.
type: feature request
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com