Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10581
___
___
Python-bugs-list
Alexander Belopolsky added the comment:
Martin v. Löwis wrote at #18236 (msg191687):
int conversion ultimately uses Py_ISSPACE, which conceptually could
deviate from the Unicode properties (as it is byte-based). This is not
really an issue, since they indeed match.
Py_ISSPACE matches Unicode
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10581
___
___
Serhiy Storchaka added the comment:
For the last discrepancy see issue16741. It have a patch which should fix this.
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10581
Alexander Belopolsky added the comment:
I took another look at the library reference and it looks like when it comes to
non-ascii digits support, the reference contradicts itself. On one hand,
int(x, base=10)
If x is not a number or if base is given, then x must be a string, bytes, or
Alexander Belopolsky added the comment:
i opened issue18236 to address the issue of surrounding whitespace.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10581
___
Alexander Belopolsky added the comment:
I have started a rough prototype for what I plan to eventually reimplement in C
and propose as a patch here.
https://bitbucket.org/alexander_belopolsky/misc/src/c175171cc76e/utoi.py?at=master
Comments welcome.
--
Marc-Andre Lemburg added the comment:
On 14.06.2013 03:43, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
PEP 393 implementation has already added the fast path to decimal encoding:
http://hg.python.org/cpython/diff/8beaa9a37387/Objects/unicodeobject.c#l1.3735
Nick Coghlan added the comment:
I think PEP 393 gives us a quick way to fast parsing: if the max char is 128,
just roll straight into normal processing, otherwise do the normalisation and
all decimal digits are from the same script steps.
There are almost certainly better ways to do the
Alexander Belopolsky added the comment:
PEP 393 implementation has already added the fast path to decimal encoding:
http://hg.python.org/cpython/diff/8beaa9a37387/Objects/unicodeobject.c#l1.3735
What we can do, however, is improve performance of converting non-ascii
numerals by looking up
Marc-Andre Lemburg added the comment:
On 12.06.2013 07:32, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
It looks like we a approaching consensus on some points:
1. Mixed script numerals should be disallowed.
2. '\N{MINUS SIGN}' should be accepted as an
Marc-Andre Lemburg added the comment:
I've changed my mind :-)
Restricting the decimal encoder to only accept code points from one of the
possible decimal digit ranges is a good idea. Let's do that.
--
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky added the comment:
It looks like we a approaching consensus on some points:
1. Mixed script numerals should be disallowed.
2. '\N{MINUS SIGN}' should be accepted as an alternative to '\N{HYPHEN-MINUS}'
Open question: should we accept fullwidth + and -, sub/superscript
Changes by Chris Rebert pyb...@rebertia.com:
--
nosy: +cvrebert
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10581
___
___
Python-bugs-list
Mark Dickinson dicki...@gmail.com added the comment:
I find it convenient to use int(), float() etc. for data validation.
Me too. This is why I'd still be happiest with int and float not accepting
non-ASCII digits at all. (And also why the recent suggestions to allow extra
underscores in
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sat, May 7, 2011 at 11:25 AM, Éric Araujo rep...@bugs.python.org wrote:
.. On one hand, I tend to agree that mixing Hindi/Arab numerals with Bengali
does not make sense;
on the other hand, rejecting it means that the
Éric Araujo mer...@netwok.org added the comment:
I may be in minority, but I find it convenient to use int(), float()
etc. for data validation.
A number of libraries agree: argparse, HTML form handling libs, etc.
I may be too strict, but I don't think anyone would want to see
columns with a
New submission from Alexander Belopolsky belopol...@users.sourceforge.net:
I am opening a new report to continue work on the issues raised in #10557 that
are either feature requests or documentation bugs.
The rest is my reply to the relevant portions of Marc's comment at msg122785.
On Mon,
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
See also issue 9574 for a somewhat related discussion.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10581
___
19 matches
Mail list logo
