Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Bugs

[issue6456] locale.D_* and .T_* are int, not string

 

 

Python bugs RSS feed   Index | Next | Previous | View Threaded


report at bugs

Jul 10, 2009, 3:27 AM

Post #1 of 6 (399 views)
Permalink
[issue6456] locale.D_* and .T_* are int, not string

New submission from dauerbaustelle <jonas [at] lophus>:

The locale.D_* and locale.T_* attributes are ints with weird values
instead of strings (see documentation[1]).

Example:


>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.utf8')
'en_US.utf8'
>>> locale.D_T_FMT
131112
>>> locale.D_FMT
131113
>>> locale.T_FMT
131114
>>> locale.T_FMT_AMPM
131115

It seems like the .DAY_* stuff is also broken:
>>> locale.DAY_1
131079
>>> locale.DAY_2
131080
>>> locale.DAY_7
131085

And many other variables:
>>> locale.THOUSEP
65537

The documentation says that every of these variables should be strings.

Regards,
db

[1]http://docs.python.org/library/locale.html#locale.D_T_FMT

----------
components: Library (Lib)
messages: 90384
nosy: dauerbaustelle
severity: normal
status: open
title: locale.D_* and .T_* are int, not string
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue6456>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 10, 2009, 3:52 AM

Post #2 of 6 (385 views)
Permalink
[issue6456] locale.D_* and .T_* are int, not string [In reply to]

R. David Murray <rdmurray [at] bitdance> added the comment:

If you look a little further up in the page you will see:

"The nl_langinfo() function accepts one of the following keys. Most
descriptions are taken from the corresponding description in the GNU C
library."

I agree that the descriptions of the constants are a bit confusing, but
the fact that it says "return" instead of saying that it is _is_ a
string should be a clue that the item itself is not a string.

A doc patch would certainly be considered if you see a way to make it
more obvious.

----------
nosy: +r.david.murray
priority: -> normal
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue6456>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 10, 2009, 4:09 AM

Post #3 of 6 (390 views)
Permalink
[issue6456] locale.D_* and .T_* are int, not string [In reply to]

dauerbaustelle <jonas [at] lophus> added the comment:

I would suggest to make those constants be strings. There's no need for
those int values; in most cases, you want the strings and not the int
values.

Until then, I would put that nl_langinfo() stuff in a warning or info
box (or highlight it somehow differently).

Regards

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue6456>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 10, 2009, 4:35 AM

Post #4 of 6 (379 views)
Permalink
[issue6456] locale.D_* and .T_* are int, not string [In reply to]

Amaury Forgeot d'Arc <amauryfa [at] gmail> added the comment:

The description of each of these constants could start like this:
"""
When passed to :func:`nl_langinfo`, return a string ...
"""

+ the "Example:" paragraph should be moved in a more prominent place,
near the top of the file for example.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue6456>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 10, 2009, 1:30 PM

Post #5 of 6 (381 views)
Permalink
[issue6456] locale.D_* and .T_* are int, not string [In reply to]

R. David Murray <rdmurray [at] bitdance> added the comment:

They can't be static string constants because they aren't constants.
They depend on the current locale settings.

I'm reopening this as a doc bug.

----------
assignee: -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl
resolution: invalid ->
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue6456>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 11, 2009, 3:51 AM

Post #6 of 6 (376 views)
Permalink
[issue6456] locale.D_* and .T_* are int, not string [In reply to]

Georg Brandl <georg [at] python> added the comment:

I moved the constants' description into the nl_langinfo() description
and clarified their use in r73945.

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

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue6456>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Python bugs RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.