Nick Coghlan wrote:
> On Mon, Nov 29, 2010 at 1:39 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>> I agree that Python should make it easy for the programmer to get
>> numerical values of native numeric strings, but it's not at all clear
>> to me that there is any point to having float() recognize them by
>> default.
>
> Indeed, as someone else suggested earlier in the thread, supporting
> non-ASCII digits sounds more like a job for the locale module than for
> the builtin types.
>
> Deprecating non-ASCII support in the latter, while ensuring it is
> properly supported in the former sounds like a better way forward than
> maintaining the status quo (starting in 3.3 though, with the first
> beta just around the corner, we don't want to be monkeying with this
> in 3.2)
Since when do we only support certain Unicode features in specific
locales ?
If we would go down that road, we would also have to disable other
Unicode features based on locale, e.g. whether to apply non-ASCII
case mappings, what to consider whitespace, etc.
We don't do that for a good reason: Unicode is supposed to be
universal and not limited to a single locale.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Nov 29 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
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