STINNER Victor victor.stin...@gmail.com added the comment:
Either the code is incorrect in 3.1
or the documentation should be updated.
Leaving LC_CTYPE unchanged (use the C locale, which is ASCII in most
cases) at Python startup would be a major change in Python 3. I don't
want to change
Petri Lehtinen pe...@digip.org added the comment:
If the thread safety of setlocale() is a problem, does anybody know how
portable uselocale() is? It sets the locale of the current thread only, so it's
safe to temporarily change the locale and then set it back.
--
nosy:
Alexis Metaireau ale...@notmyidea.org added the comment:
I see two different things here:
1) the fact that getlocale() doesn't return (None, None) on some python
versions
2) the fact that having it returning (None, None) by default is a bit
misleading as users may think that getlocale() is
R. David Murray rdmur...@bitdance.com added the comment:
Yes a new issue would be more appropriate.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6203
___
Alexis Metaireau ale...@notmyidea.org added the comment:
Maybe could it be useful to specify in the documentation that getlocale() is
not intended to be used to get information about what is the locale of the
system?
It's not explained currently and thus it's a bit weird to have getlocale
R. David Murray rdmur...@bitdance.com added the comment:
This issue is about the fact that it doesn't return (None, None). We should
probably decide what we are going to do about that before changing the docs if
they need it.
--
___
Python tracker
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment:
User lemburg pointed me to this, but no, i've posted msg127416 to Issue 11022.
--
nosy: +sdaoden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6203
Marc-Andre Lemburg m...@egenix.com added the comment:
Python can be embedded into other applications and unconditionally
changing the locale (esp. the LC_CTYPE) is not good practice, since
it's not thread-safe and affects the entire process. An application
may have set LC_CTYPE (or the locale)
Martin v. Löwis mar...@v.loewis.de added the comment:
An clean alternative would be adding LC_* variable parsing code to
Python to avoid the setlocale() call altogether.
That would be highly non-portable, and repeat the mistakes of
getdefaultlocale.
--
title: 3.x locale does not
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
An clean alternative would be adding LC_* variable parsing code to
Python to avoid the setlocale() call altogether.
That would be highly non-portable, and
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
title: 3.x locale does not default to C,contrary to the documentation
and to 2.x behavior - 3.x locale does not default to C, contrary to the
documentation and to 2.x behavior
Martin v. Löwis mar...@v.loewis.de added the comment:
That would be highly non-portable, and repeat the mistakes of
getdefaultlocale.
You say that often, but I don't really know why. It's certainly portable
between various Unix platforms, perhaps not Windows, but then i18n
on Windows is a
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
Martin v. Löwis:
It seems that your web browser replaces , with ,\t in the title (where
\t is a tab character) each time you add a comment.
--
___
Python tracker
Martin v. Löwis mar...@v.loewis.de added the comment:
More likely, it's my email reader. Sorry about that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6203
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
To add a little bit more analysis: posix.device_encoding requires that
the LC_CTYPE is set. Setting it just in this function would not be
possible, as setlocale is not thread-safe.
open() does indirectly
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6203
___
Changes by R. David Murray rdmur...@bitdance.com:
--
versions: +Python 3.2 -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6203
___
___
Martin v. Löwis mar...@v.loewis.de added the comment:
To add a little bit more analysis: posix.device_encoding requires that
the LC_CTYPE is set. Setting it just in this function would not be
possible, as setlocale is not thread-safe.
So for 3.1, it seems that Python must set LC_CTYPE. If
Changes by Antoine Pitrou pit...@free.fr:
--
assignee: - georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6203
___
___
Python-bugs-list
Georg Brandl ge...@python.org added the comment:
Deferring to Martin which one is correct :)
--
assignee: georg.brandl - loewis
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6203
R. David Murray rdmur...@bitdance.com added the comment:
This is definately a bug in 3.1, for the same reason that a C program
uses the C locale until an explicit setlocale is done: otherwise, a
non-locale-aware program can run into bugs resulting from locale issues
when run under a different
Antoine Pitrou pit...@free.fr added the comment:
For some reason only LC_CTYPE is affected:
locale.getlocale(locale.LC_CTYPE)
('fr_FR', 'UTF8')
locale.getlocale(locale.LC_MESSAGES)
(None, None)
locale.getlocale(locale.LC_TIME)
(None, None)
locale.getlocale(locale.LC_NUMERIC)
(None, None)
R. David Murray rdmur...@bitdance.com added the comment:
Ah, I can tell you exactly why that is, then. I noticed this in
pythonrun.c while grepping the source:
#ifdef HAVE_SETLOCALE
/* Set up the LC_CTYPE locale, so we can obtain
the locale's charset without having to switch
Antoine Pitrou pit...@free.fr added the comment:
It would still be better it is was unset afterwards. Third-party
extensions could have LC_CTYPE-dependent behaviour.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6203
Martin v. Löwis mar...@v.loewis.de added the comment:
It would still be better it is was unset afterwards. Third-party
extensions could have LC_CTYPE-dependent behaviour.
In principle, they could, yes - but what specific behavior might that
be? What will change is character classification,
Antoine Pitrou pit...@free.fr added the comment:
In principle, they could, yes - but what specific behavior might that
be? What will change is character classification, which I consider
fairly harmless. Also, multi-byte conversion routines will change, which
is the primary reason for leaving
R. David Murray rdmur...@bitdance.com added the comment:
Since it controls what is considered to be whitespace, it is possible
this will lead to subtle bugs, but I agree that it seems relatively
benign, especially considering 3.x's unicode orientation. So, this
becomes a doc bug...
--
Ezio Melotti ezio.melo...@gmail.com added the comment:
Confirmed for 3.1, 3.0 still returns (None, None).
--
components: +Library (Lib)
nosy: +ezio.melotti
priority: - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6203
New submission from Ned Deily n...@acm.org:
In the Library Reference section 22.2.1 for locale, it states:
Initially, when a program is started, the locale is the C locale, no
matter what the user’s preferred locale is. The program must explicitly
say that it wants the user’s preferred locale
29 matches
Mail list logo
