[ python-Bugs-1289210 ] PyDoc crashes at os.py line 133
Bugs item #1289210, was opened at 2005-09-12 20:23 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: PyDoc crashes at os.py line 133 Initial Comment: Details of the attempted runs are given below: C:\Python24\Lib>python pydoc.py sys Help on built-in module sys: NAME sys FILE (built-in) MODULE DOCS http://www.python.org/doc/current/lib/module-sys.html etc. etc. The above works OK but the following - advertised in the PyDoc.py comment - fails. --- C:\Python24\Lib>pydoc sys 'import site' failed; use -v for traceback Traceback (most recent call last): File "C:\Python24\Lib\pydoc.py", line 54, in ? import sys, imp, os, re, types, inspect, __builtin__ File "C:\Python24\Lib\os.py", line 133 from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, ^ SyntaxError: invalid syntax Lines 132 to 134 of os.py: sys.modules['os.path'] = path from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, devnull) The above "from X import" usage appears legitimate. Colin W. -- >Comment By: Colin J. Williams (cjwhrh) Date: 2005-09-13 07:15 Message: Logged In: YES user_id=285587 Response to R Hettinger 2005-09-13 00:10 I do have Python 2.4 and 2.3 installed but the environment variable PYTHON is set to C:\Python24. I have checked to see that no Python process is running before repeating the test this morning. I get the same results. Is there any other check I should make? Colin W. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-13 00:10 Message: Logged In: YES user_id=80475 This is probably invalid. It looks like you may have multiple python versions running on your system and that the pydoc batch file is invoking an earlier version of the interpreter that doesn't understand multiline imports). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1289210 ] PyDoc crashes at os.py line 133
Bugs item #1289210, was opened at 2005-09-12 19:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: PyDoc crashes at os.py line 133 Initial Comment: Details of the attempted runs are given below: C:\Python24\Lib>python pydoc.py sys Help on built-in module sys: NAME sys FILE (built-in) MODULE DOCS http://www.python.org/doc/current/lib/module-sys.html etc. etc. The above works OK but the following - advertised in the PyDoc.py comment - fails. --- C:\Python24\Lib>pydoc sys 'import site' failed; use -v for traceback Traceback (most recent call last): File "C:\Python24\Lib\pydoc.py", line 54, in ? import sys, imp, os, re, types, inspect, __builtin__ File "C:\Python24\Lib\os.py", line 133 from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, ^ SyntaxError: invalid syntax Lines 132 to 134 of os.py: sys.modules['os.path'] = path from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, devnull) The above "from X import" usage appears legitimate. Colin W. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-13 07:02 Message: Logged In: YES user_id=80475 When you write, "pydoc sys", your relying on a file association for py files to get run by python23. The association is not controlled by the PYTHON environment variable. Anyway, it is evident from the initial report that there is not a bug. When "python pydoc.py sys" runs fine, it means that your sys file is okay. When it fails using "pydoc sys" it means an earlier version of the interpreter is being run on the Py2.4 sys file. To convince yourself, change to c:\python23\lib and run "pydoc sys". -- Comment By: Colin J. Williams (cjwhrh) Date: 2005-09-13 06:15 Message: Logged In: YES user_id=285587 Response to R Hettinger 2005-09-13 00:10 I do have Python 2.4 and 2.3 installed but the environment variable PYTHON is set to C:\Python24. I have checked to see that no Python process is running before repeating the test this morning. I get the same results. Is there any other check I should make? Colin W. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 23:10 Message: Logged In: YES user_id=80475 This is probably invalid. It looks like you may have multiple python versions running on your system and that the pydoc batch file is invoking an earlier version of the interpreter that doesn't understand multiline imports). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1290333 ] cjkcodec compile error under AIX 5.2 on symbol 100_encode
Bugs item #1290333, was opened at 2005-09-13 13:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Deron Meranda (dmeranda)
Assigned to: Nobody/Anonymous (nobody)
Summary: cjkcodec compile error under AIX 5.2 on symbol 100_encode
Initial Comment:
Trying to compile Python 2.4.1 under AIX 5.2 with the
native cc compiler. When compiling the module
cjkcodecs the compiler will fail with these errors on
the source file Modules/cjkcodecs/_codecs_cn.c
building '_codecs_cn' extension
cc -DNDEBUG -O -I.
-I/home/psgtools/aix52/build/Python-2.4.1/./Include
-I/opt/cmax/psgtools/include
-I/home/psgtools/aix52/build/Python-2.4.1/Include
-I/home/psgtools/aix52/build/Python-2.4.1 -c
/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c
-o build/temp.aix-5.2-2.4/_codecs_cn.o
"/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c",
line 431.3: 1506-206 (S) Suffix of integer constant
100_encode is not valid.
"/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c",
line 431.3: 1506-196 (W) Initialization between types
"int(*)(union {...}*,const void*,const unsigned
long**,unsigned long,unsigned char**,unsigned
long,int)" and "int" is not allowed.
and so on.
This is happening because of the "hz" codec. Due to
the way the source file uses the C preprocessor macro,
and the fact that the preprocessor symbol "hz" is
predefined as 100 on this platform, it is producing
invalid lecical symbols such as "100_encode".
The simple solution is to insert the following line in
the source file immediately before the first reference
to the name "hz":
#undef hz
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1080727 ] Add encoding to DocFileSuite
Feature Requests item #1080727, was opened at 2004-12-07 11:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) >Assigned to: Edward Loper (edloper) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. -- >Comment By: Tim Peters (tim_one) Date: 2005-09-13 14:59 Message: Logged In: YES user_id=31435 Ed, can you make time to review this patch? If not, please unassign it again. -- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 13:05 Message: Logged In: YES user_id=1032069 Uploaded new patch, which adds the possibility to specify an encoding to testfile as well, since I assume this is desirable. -- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 09:08 Message: Logged In: YES user_id=1032069 Added patch for Tim to review. -- Comment By: Tim Peters (tim_one) Date: 2004-12-14 22:09 Message: Logged In: YES user_id=31435 Unassigned myself -- can't make time to work on it. I'll be happy to review a patch (code/tests/docs) if one appears. I approve of the idea . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1290382 ] --no-compile option has no effect
Bugs item #1290382, was opened at 2005-09-13 15:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290382&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: --no-compile option has no effect Initial Comment: ZODB ships with a .py file containing a syntax error (that's intentional, it's part of a test of the zope.testing component). So, whenever somone does setup.py install they see a complaint about this file, like byte-compiling /home/tim/glom/lib/python2.4/site- packages/zope/testing/testrunner- ex/sample2/sampletests_i.py to sampletests_i.pyc File "/home/tim/glom/lib/python2.4/site- packages/zope/testing/testrunner- ex/sample2/sampletests_i.py", line 15 importx unittest ^ SyntaxError: invalid syntax That's fine. The problem is that doing setup.py install --no-compile makes no difference -- it still tries to compile everything to .pyc. True at least in Python 2.3.5 and 2.4.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290382&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1290382 ] --no-compile option has no effect
Bugs item #1290382, was opened at 2005-09-13 15:03 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290382&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: --no-compile option has no effect Initial Comment: ZODB ships with a .py file containing a syntax error (that's intentional, it's part of a test of the zope.testing component). So, whenever somone does setup.py install they see a complaint about this file, like byte-compiling /home/tim/glom/lib/python2.4/site- packages/zope/testing/testrunner- ex/sample2/sampletests_i.py to sampletests_i.pyc File "/home/tim/glom/lib/python2.4/site- packages/zope/testing/testrunner- ex/sample2/sampletests_i.py", line 15 importx unittest ^ SyntaxError: invalid syntax That's fine. The problem is that doing setup.py install --no-compile makes no difference -- it still tries to compile everything to .pyc. True at least in Python 2.3.5 and 2.4.1. -- >Comment By: Tim Peters (tim_one) Date: 2005-09-13 15:20 Message: Logged In: YES user_id=31435 Closing this as invalid -- it appears to be unique to setup.py thingies created by Zope's zpkgtools. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290382&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1080727 ] Add encoding to DocFileSuite
Feature Requests item #1080727, was opened at 2004-12-07 17:47 Message generated for change (Comment added) made by bjoti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) Assigned to: Edward Loper (edloper) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. -- >Comment By: Bjorn Tillenius (bjoti) Date: 2005-09-13 22:12 Message: Logged In: YES user_id=1032069 Attaching new version of the patch that will apply cleanly against latest CVS -- Comment By: Tim Peters (tim_one) Date: 2005-09-13 20:59 Message: Logged In: YES user_id=31435 Ed, can you make time to review this patch? If not, please unassign it again. -- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 19:05 Message: Logged In: YES user_id=1032069 Uploaded new patch, which adds the possibility to specify an encoding to testfile as well, since I assume this is desirable. -- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 15:08 Message: Logged In: YES user_id=1032069 Added patch for Tim to review. -- Comment By: Tim Peters (tim_one) Date: 2004-12-15 04:09 Message: Logged In: YES user_id=31435 Unassigned myself -- can't make time to work on it. I'll be happy to review a patch (code/tests/docs) if one appears. I approve of the idea . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-504219 ] locale.resetlocale is broken
Bugs item #504219, was opened at 2002-01-15 20:56
Message generated for change (Comment added) made by meonkeys
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Syver Enstad (syvere)
Assigned to: Mark Hammond (mhammond)
Summary: locale.resetlocale is broken
Initial Comment:
locale.setlocale doesn't recognize the the format that
locale.py uses to set the locale, ie. no_NO and
friends.
The only way I've succeeded in setting the locale on
Python 2.1 is to use the format described in the
Visual C++ C-runtime library docs for setlocale where
a more verbose format is used to set the locale.
--
Comment By: Adam Monsen (meonkeys)
Date: 2005-09-13 15:27
Message:
Logged In: YES
user_id=259388
I'm seeing this error on Fedora Core 4:
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import locale; locale.getdefaultlocale()
('en_US', 'utf')
>>> locale.resetlocale()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/locale.py", line 389, in resetlocale
_setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 11:04
Message:
Logged In: YES
user_id=1188172
As this is not Windows specific, setting Category to Library.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-08 10:59
Message:
Logged In: YES
user_id=469548
Still reproducible with Python 2.4:
Python 2.4b2 (#19, Nov 8 2004, 11:15:07)
[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import locale
>>> locale.getdefaultlocale()
['en_US', 'utf']
>>> locale.resetlocale()
Traceback (most recent call last):
File "", line 1, in ?
File "/home/johannes/python/Lib/locale.py", line 389, in
resetlocale
_setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting
Note that if I run python with 'LANG=nl_NL python', the
error does not occur.
http://python.org/sf/813449 seems to be the same bug, BTW.
--
Comment By: Syver Enstad (syvere)
Date: 2002-01-16 05:39
Message:
Logged In: YES
user_id=428736
Sorry, I forgot to mention the testcase I am using. The
test case that fails is the locale module itself, when
running it as a standalone application that is.
To be more specific:
File "d:\devtools\python21\lib\locale.py", line 384, in
resetlocale
_setlocale(category, _build_localename(getdefaultlocale
()))
locale.Error: locale setting not supported
And to clarify what input getdefaultlocale returns on my
machine:
>>> locale.getdefaultlocale()
('no_NO', 'cp1252')
and:
>>> locale._build_localename(locale.getdefaultlocale())
'no_NO.cp1252'
By the way, is this bug fixed in python 2.2?
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-01-16 03:50
Message:
Logged In: YES
user_id=21627
Can you provide a detailed test case? AFAIK, no_NO is indeed
no supported locale name on Windows, and I don't think
Python aanywhere uses it without the application explicitly
saying so.
--
Comment By: Tim Peters (tim_one)
Date: 2002-01-15 21:07
Message:
Logged In: YES
user_id=31435
Mark, know anything about this? I don't.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1290505 ] strptime(): can't switch locales more than once
Bugs item #1290505, was opened at 2005-09-13 15:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Monsen (meonkeys)
Assigned to: Nobody/Anonymous (nobody)
Summary: strptime(): can't switch locales more than once
Initial Comment:
After calling strptime() once, it appears that
subsequent efforts to modify the locale settings (so
dates strings in different locales can be parsed) throw
a ValueError. I'm pasting everything here since spacing
is irrelevant:
import locale, time
print locale.getdefaultlocale()# ('en_US', 'utf')
print locale.getlocale(locale.LC_TIME) # (None, None)
# save old locale
old_loc = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, 'nl_NL')
print locale.getlocale(locale.LC_TIME) # ('nl_NL',
'ISO8859-1')
# parse local date
date = '10 augustus 2005 om 17:26'
format = '%d %B %Y om %H:%M'
dateTuple = time.strptime(date, format)
# switch back to previous locale
locale.setlocale(locale.LC_TIME, old_loc)
print locale.getlocale(locale.LC_TIME) # (None, None)
date = '10 August 2005 at 17:26'
format = '%d %B %Y at %H:%M'
dateTuple = time.strptime(date, format)
The output I get from this script is:
('en_US', 'utf')
(None, None)
('nl_NL', 'ISO8859-1')
(None, None)
Traceback (most recent call last):
File "switching.py", line 17, in ?
dateTuple = time.strptime(date, format)
File "/usr/lib/python2.4/_strptime.py", line 292, in
strptime
raise ValueError("time data did not match format:
data=%s fmt=%s" %
ValueError: time data did not match format: data=10
August 2005 at 17:26 fmt=%d %B %Y at %H:%M
One workaround I found is by manually busting the
regular expression cache in _strptime:
import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()
If I do all that, I can change the LC_TIME part of the
locale as many times as I choose.
If this isn't a bug, this should at least be in the
documentation for the locale module and/or strptime().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1290505 ] strptime(): can't switch locales more than once
Bugs item #1290505, was opened at 2005-09-13 15:50
Message generated for change (Comment added) made by meonkeys
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Monsen (meonkeys)
Assigned to: Nobody/Anonymous (nobody)
Summary: strptime(): can't switch locales more than once
Initial Comment:
After calling strptime() once, it appears that
subsequent efforts to modify the locale settings (so
dates strings in different locales can be parsed) throw
a ValueError. I'm pasting everything here since spacing
is irrelevant:
import locale, time
print locale.getdefaultlocale()# ('en_US', 'utf')
print locale.getlocale(locale.LC_TIME) # (None, None)
# save old locale
old_loc = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, 'nl_NL')
print locale.getlocale(locale.LC_TIME) # ('nl_NL',
'ISO8859-1')
# parse local date
date = '10 augustus 2005 om 17:26'
format = '%d %B %Y om %H:%M'
dateTuple = time.strptime(date, format)
# switch back to previous locale
locale.setlocale(locale.LC_TIME, old_loc)
print locale.getlocale(locale.LC_TIME) # (None, None)
date = '10 August 2005 at 17:26'
format = '%d %B %Y at %H:%M'
dateTuple = time.strptime(date, format)
The output I get from this script is:
('en_US', 'utf')
(None, None)
('nl_NL', 'ISO8859-1')
(None, None)
Traceback (most recent call last):
File "switching.py", line 17, in ?
dateTuple = time.strptime(date, format)
File "/usr/lib/python2.4/_strptime.py", line 292, in
strptime
raise ValueError("time data did not match format:
data=%s fmt=%s" %
ValueError: time data did not match format: data=10
August 2005 at 17:26 fmt=%d %B %Y at %H:%M
One workaround I found is by manually busting the
regular expression cache in _strptime:
import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()
If I do all that, I can change the LC_TIME part of the
locale as many times as I choose.
If this isn't a bug, this should at least be in the
documentation for the locale module and/or strptime().
--
>Comment By: Adam Monsen (meonkeys)
Date: 2005-09-13 15:57
Message:
Logged In: YES
user_id=259388
I think there were some long lines in my code. Attaching
test case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1290505 ] strptime(): can't switch locales more than once
Bugs item #1290505, was opened at 2005-09-13 15:50
Message generated for change (Settings changed) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Monsen (meonkeys)
>Assigned to: Brett Cannon (bcannon)
Summary: strptime(): can't switch locales more than once
Initial Comment:
After calling strptime() once, it appears that
subsequent efforts to modify the locale settings (so
dates strings in different locales can be parsed) throw
a ValueError. I'm pasting everything here since spacing
is irrelevant:
import locale, time
print locale.getdefaultlocale()# ('en_US', 'utf')
print locale.getlocale(locale.LC_TIME) # (None, None)
# save old locale
old_loc = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, 'nl_NL')
print locale.getlocale(locale.LC_TIME) # ('nl_NL',
'ISO8859-1')
# parse local date
date = '10 augustus 2005 om 17:26'
format = '%d %B %Y om %H:%M'
dateTuple = time.strptime(date, format)
# switch back to previous locale
locale.setlocale(locale.LC_TIME, old_loc)
print locale.getlocale(locale.LC_TIME) # (None, None)
date = '10 August 2005 at 17:26'
format = '%d %B %Y at %H:%M'
dateTuple = time.strptime(date, format)
The output I get from this script is:
('en_US', 'utf')
(None, None)
('nl_NL', 'ISO8859-1')
(None, None)
Traceback (most recent call last):
File "switching.py", line 17, in ?
dateTuple = time.strptime(date, format)
File "/usr/lib/python2.4/_strptime.py", line 292, in
strptime
raise ValueError("time data did not match format:
data=%s fmt=%s" %
ValueError: time data did not match format: data=10
August 2005 at 17:26 fmt=%d %B %Y at %H:%M
One workaround I found is by manually busting the
regular expression cache in _strptime:
import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()
If I do all that, I can change the LC_TIME part of the
locale as many times as I choose.
If this isn't a bug, this should at least be in the
documentation for the locale module and/or strptime().
--
Comment By: Adam Monsen (meonkeys)
Date: 2005-09-13 15:57
Message:
Logged In: YES
user_id=259388
I think there were some long lines in my code. Attaching
test case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
