[ python-Bugs-1109602 ] Need some setup.py sanity

[SourceForge.net]

Bugs item #1109602, was opened at 2005-01-26 04:28
Message generated for change (Comment added) made by mforbes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109602&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need some setup.py sanity

Initial Comment:
Python's setup.py has grown way out of control.  I'm
trying to build and install Python 2.4.0 on a Solaris
system with Tcl/Tk installed in a non-standard place and
I can't figure out the incantation to tell setup.py to look
where they are installed.  I have tried:

  * setting LDFLAGS and CPPFLAGS on the make and
  configure command lines

  * running "setup.py --help" and "setup.py build --help"

  * reading the setup.py source

It's not at all obvious to me from any of this if there is
any way to point setup.py at a non-standard place.

Over time setup.py has grown into the Python
equivalent of a configure script, but there's been
precious little refactoring, so there is stuff all over the
place to add this directory on that platform or try
different ad hoc solutions for various external packages
based upon common installation practices.  I think it's
time to rethink the function and organization of setup.py.

This might be an excellent sprint topic for PyCon.


--

Comment By: Michael Forbes (mforbes)
Date: 2007-03-28 11:12

Message:
Logged In: YES 
user_id=253921
Originator: NO

Something like this works with Python 2.5
./configure LDFLAGS="-L/myplace/tcl8.4.14_gcc/lib/"\
  CPPFLAGS="-I/myplace/tcl8.4.14_gcc/include/"

(Both tcl and tk librarys and headers are installed in these
directories.)



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109602&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2

[SourceForge.net]

Bugs item #1689617, was opened at 2007-03-28 06:26
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Forbes (mforbes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Intel icc build fails with optimizations -O2

Initial Comment:
When building python 2.5 with the free Intel compilers for non-commercial use 
(icc), the build works without optimizations, but fails when optimizations -O2 
and -O3 are used.

The compilation proceedes without errors (though there are lot's of warnings 
and remarks) and makes a python executable, but when the python setup starts, 
the intepreter cannot import certain packages and cannot add two strings.

case $MAKEFLAGS in \
*-s*)  CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 
-Ob2 -w1' ./python -E ./setup.py -q build;; \
*)  CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 
-w1' ./python -E ./setup.py build;; \
esac
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in 
import sys, os, imp, re, optparse
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in 

import textwrap
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in 

import string, re
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in 
letters = lowercase + uppercase
SystemError: error return without exception set
make: *** [sharedmods] Error 1

For example:
$ ./python
'import site' failed; use -v for traceback
Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) 
[GCC Intel(R) C++ gcc 3.4 mode] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "123"
>>> a + "12"
Traceback (most recent call last):
  File "", line 1, in 
SystemError: error return without exception set
>>> 

Note that both the import of the site file fails and the addition fails.

Python was configured with the following options:
./configure --with-gcc=icc\
--with-cxx-main=icc\
--prefix=/int/apps/mmf/apps/Python-2.5_intel/\
OPT="-g -O2 -Ob2 -w1"

When compiled with fewer optimiztions, everything seems to work.
./configure --with-gcc=icc\
--with-cxx-main=icc\
--prefix=/int/apps/mmf/apps/Python-2.5_intel/\
OPT="-g -O1 -Ob2 -w1"



--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-28 13:32

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you debug this further to determine a specific problem? It could be a
compiler bug also, for all I can tell.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1685775 ] msvccompiler.py doesn't recongnize VS2005

[SourceForge.net]

Bugs item #1685775, was opened at 2007-03-22 08:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685775&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.5
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Minmin Gong (gongminmin)
Assigned to: Nobody/Anonymous (nobody)
Summary: msvccompiler.py doesn't recongnize VS2005

Initial Comment:
I'm trying to compile some python extensions by VS2005. However, it seems that 
msvccompiler.py doesn't recongnize VS2005. Only VC6/VS2003 is supported. When 
will distutils fix this? 

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-28 13:35

Message:
Logged In: YES 
user_id=21627
Originator: NO

You should not be using VS2005 to build Python extensions, unless you know
exactly what you are doing. If you do, you should set DISTUTILS_USE_SDK and
MSSdk.

Closing as 'works for me'.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685775&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-894599 ] Win32 installer should add python's directory to system path

[SourceForge.net]

Bugs item #894599, was opened at 2004-02-10 20:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894599&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: Installation
Group: Platform-specific
>Status: Pending
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win32 installer should add python's directory to system path

Initial Comment:
Win32 installer should add python's base directory to 
the system path to allow executing Python.exe 
anywhere. If you use an editor like SciTE a hotkey (F5) 
will start your script with a command line like:

pythonw.exe your_script.py

The system path must be set correctly to allow this 
command. This setting must be done on each machine 
with python installed. In a while classroom with 30 
machines it can be very cumbersome. An installation 
option would be useful in most cases, especially 
with "yes" default.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-28 13:54

Message:
Logged In: YES 
user_id=21627
Originator: NO

complex, can you confirm that the problem is fixed? The script should be
started with simply "your_script.py", which, in turn, should invoke the
shell's mechanisms to find Python by extension. Prefixing with pythonw.exe
should not be necessary.

--

Comment By: Kent Johnson (kjohnson)
Date: 2005-10-20 17:53

Message:
Logged In: YES 
user_id=49695

IIRC this worked in Python 2.3 and was broken in 2.4

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894599&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1180193 ] broken pyc files

[SourceForge.net]

Bugs item #1180193, was opened at 2005-04-10 15:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&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 Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken pyc files

Initial Comment:
In a number of situations, the .pyc files can become "corrupted" in a subtle 
way: the co_filename attribute of the code objects it contains become wrong.  
This can occur if we move or rename directories, or if we access the same set 
of files from two different locations (e.g. over NFS).

This corruption doesn't prevent the .pyc files from working, but the 
interpreter looses the reference to the source file.  It causes trouble in 
tracebacks, in the inspect module, etc.

A simple fix would be to use the following logic when importing a .py file: if 
there is a corresponding .pyc file, in addition to checking the timestamp, 
check the co_filename attribute of the loaded object.  If it doesn't point to 
the original .py file, discard the code object and ignore the .pyc file.

Alternatively, we could force all co_filenames to point to the .py file when 
loading the .pyc file.

I'll write a patch for whichever alternative seems better.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-28 14:01

Message:
Logged In: YES 
user_id=21627
Originator: NO

I fail to see the corruption. It is quite desirable and normal to only
ship pyc files - that the file name they refer to is actually present is
not a requirement at all.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1180193 ] broken pyc files

[SourceForge.net]

Bugs item #1180193, was opened at 2005-04-10 13:10
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&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 Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken pyc files

Initial Comment:
In a number of situations, the .pyc files can become "corrupted" in a subtle 
way: the co_filename attribute of the code objects it contains become wrong.  
This can occur if we move or rename directories, or if we access the same set 
of files from two different locations (e.g. over NFS).

This corruption doesn't prevent the .pyc files from working, but the 
interpreter looses the reference to the source file.  It causes trouble in 
tracebacks, in the inspect module, etc.

A simple fix would be to use the following logic when importing a .py file: if 
there is a corresponding .pyc file, in addition to checking the timestamp, 
check the co_filename attribute of the loaded object.  If it doesn't point to 
the original .py file, discard the code object and ignore the .pyc file.

Alternatively, we could force all co_filenames to point to the .py file when 
loading the .pyc file.

I'll write a patch for whichever alternative seems better.

--

>Comment By: Armin Rigo (arigo)
Date: 2007-03-28 13:40

Message:
Logged In: YES 
user_id=4771
Originator: YES

What I called "corruption" is the situation
where both the .py and the .pyc files are
present, but the filename stored in the .pyc
co_filenames is no longer the valid absolute
path of the corresponding .py file, for any
reason (renaming, NFS views, etc.).

This situation causes the tracebacks and the
inspect module to fail to locate the .py file,
which I consider a bug.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-03-28 12:01

Message:
Logged In: YES 
user_id=21627
Originator: NO

I fail to see the corruption. It is quite desirable and normal to only
ship pyc files - that the file name they refer to is actually present is
not a requirement at all.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1615275 ] tempile.TemporaryFile differences between linux and windows

[SourceForge.net]

Bugs item #1615275, was opened at 2006-12-13 16:20
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&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: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: hirzel (hirzel)
Assigned to: Nobody/Anonymous (nobody)
Summary: tempile.TemporaryFile differences between linux and windows

Initial Comment:
This bug came up when trying to write a numpy array to a 
tempfile.TemporaryFile() using the numpy 'tofile' method on windows using 
python 2.4.  

with a numpy array 'a', and a TemporaryFile 'f', 
on windows:
>>> a.tofile(f)

throws an IOError, where on Linux it does not.
On windows, you must use a.tofile(f.file)

The cause of this difference is that in windows, tempfile.TemporaryFile() 
returns  that has a 'file'  attribute of , 
whereas in linux tempfile.TemporaryFile() returns  and there is no 
'file' attribute.  

Ideally, the windows version would align with linux, and the module 
documentation and TemporaryFile() would return a .  If this is not 
possible, it seems like the linux version and docs should be changed to match 
the windows version to align cross-platform behavior.  At least, that seems to 
be the shared opinion of this thread from the mailing list: numpy-discussion.  
http://www.mail-archive.com/numpy-discussion@scipy.org/msg00271.html

To my knowledge, while platform differences in tempfile have been reported in 
the past, this one has not.



--

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-03-28 10:43

Message:
Logged In: YES 
user_id=984087
Originator: NO


I used the following code to reproduce the problem on windows XP.

--
import array
import tempfile

testarray = array.array('B')
testarray.fromstring("\x00\x00\x00")
f = tempfile.TemporaryFile()
testarray.tofile(f)
---

This works fine on linux but on windows, it gives the following error:

-
Traceback (most recent call last):
  File "c:\rags\tofile.py", line 7, in 
testarray.tofile(f)
TypeError: arg must be open file
-

Changing "f" to "f.file" seems to work, though, as explained in the
initial post. So this may be the same problem as OP reported even though I
am getting TypeError and he mentioned IOError. 

I tested with 2.4 and 2.5 as I don't know how to set up python development
environment on windows (yet). I will see if I can set that up first before
working on the "fix". 

Raghu.





--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1508864 ] threading.Timer/timeouts break on change of win32 local time

[SourceForge.net]

Bugs item #1508864, was opened at 2006-06-19 19:53
Message generated for change (Comment added) made by jtate
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Russell Warren (qopit)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Timer/timeouts break on change of win32 local time

Initial Comment:
THE ISSUE...
---
threading.py imports time.time as _time.

On win32 systems, time.time() periodically reads the
system time to figure out when to fire an Event.

System time can change while waiting for an Event!

eg:  If the system time is changed while a
threading.Timer is pending, the execution time is
affected by the time change.  eg: set a pending Timer
and then change the clock back an hour - this causes
your Timer to fire an hour later.  This is clearly not
desirable.


A FIX...
---
A fix for this is to use time.clock() on win32 systems
instead.  Once I found the problem, I currently just
fix it by overriding threading._time to be time.clock.
 Right now I do this in every file that uses
threading.Timer.


COMMENTS...
---
The penalty for this is that there will be a rollover
problem eventaully... when the 64-bit performance
counter rolls over in 30+ years of continuous pc
operation.  I'd much rather have this near impossible
event than the very likely system time change.

This is a general problem I find with the time module
and I often have to switch between time() and clock()
dependent on operating system, but I only work with
win32 and Linux.  The issue is that if you want a high
resolution and extended rollover counter, it is a
different call on each system.



--

Comment By: Joseph Tate (jtate)
Date: 2007-03-28 15:07

Message:
Logged In: YES 
user_id=55276
Originator: NO

On Linux time.clock() is CPU time.  And has no bearing at all on real
time.  On windows time.clock() is real time since CPU time is not available
from the operating system.

What if instead of replacing time.time() with time.clock(), the Queue and
Event wait loops just kicked out if "remaining time" was larger than the
initial wait time?  Let the outer loop continue, and the next time wait is
called, the "remaining time" will be calculated correctly.

Otherwise, we could compare "remaining time" between one loop iteration
and the subsequent and then *approximate* how much the time has changed to
adjust the "end time" appropriately.


--

Comment By: Joseph Tate (jtate)
Date: 2006-10-09 13:59

Message:
Logged In: YES 
user_id=55276

This is also currently a problem under Linux when the clock
is set back.

--

Comment By: Russell Warren (qopit)
Date: 2006-06-27 20:01

Message:
Logged In: YES 
user_id=1542586

No - just stating that clock() is definitely a better
solution for win32.

As you say, any system should just use a time-indpendent
uptime counter that is as high resolution as possible.  I
don't know how to get this on linux, but I do seem to recall
that, on linux, time() is higher resolution than clock() for
some reason.

If linux has no performance counter equivalent (isn't it a
hardware thing anyway?) I have no clue which is worse... low
resolution, or local time change issues.  The first is
limiting all the time, the second results in wacky and
sporadic errors that people might not expect.


--

Comment By: Jim Jewett (jimjjewett)
Date: 2006-06-27 15:04

Message:
Logged In: YES 
user_id=764593

Logically, these calls should always use clock, since they 
don't care about the actual time; they only want a baseline 
for computing elapsed time.

Are you saying that they should still use clock-time on 
linux anyway, because of resolution issues?


--

Comment By: Russell Warren (qopit)
Date: 2006-06-26 21:59

Message:
Logged In: YES 
user_id=1542586

This is an issue for anything that uses threading.py's _time
function.

This includes _Condition.wait(), which screws up both
Conditions and Events, which then screw up (for example) the
core Queue.Queue timeout implementation.

threading.Thread.join also uses the _time call, so it could
also get screwed by changes to the local time on Win32.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470
___
Python-bugs-list mailing li

[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace

[SourceForge.net]

Bugs item #1599254, was opened at 2006-11-19 11:03
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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.5
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: David Watson (baikie)
Assigned to: A.M. Kuchling (akuchling)
Summary: mailbox: other programs' messages can vanish without trace

Initial Comment:
The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement 
the flush() method by writing the new mailbox contents into a temporary file 
which is then renamed over the original. Unfortunately, if another program 
tries to deliver messages while mailbox.py is working, and uses only fcntl() 
locking, it will have the old file open and be blocked waiting for the lock to 
become available. Once mailbox.py has replaced the old file and closed it, 
making the lock available, the other program will write its messages into the 
now-deleted "old" file, consigning them to oblivion.

I've caused Postfix on Linux to lose mail this way (although I did have to turn 
off its use of dot-locking to do so).

A possible fix is attached.  Instead of new_file being renamed, its contents 
are copied back to the original file.  If file.truncate() is available, the 
mailbox is then truncated to size.  Otherwise, if truncation is required, it's 
truncated to zero length beforehand by reopening self._path with mode wb+.  In 
the latter case, there's a check to see if the mailbox was replaced while we 
weren't looking, but there's still a race condition.  Any alternative ideas?

Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the 
replacement file as it had the execute bit set.


--

>Comment By: A.M. Kuchling (akuchling)
Date: 2007-03-28 12:56

Message:
Logged In: YES 
user_id=11375
Originator: NO

Created a branch in SVN at
svn+ssh://[EMAIL PROTECTED]/python/branches/amk-mailbox to work on
this for 2.5.1.  I've committed the unified2 module patch and the
test_concurrent_ad() test.


--

Comment By: A.M. Kuchling (akuchling)
Date: 2007-01-24 15:48

Message:
Logged In: YES 
user_id=11375
Originator: NO

I've strengthened the warning again.

The MH bug in unified2 is straightforward: MH.remove() opens a file
object, locks it, closes the file object, and then tries to unlock it. 
Presumably the MH test case never bothered locking the mailbox before
making changes before.


--

Comment By: David Watson (baikie)
Date: 2007-01-22 15:24

Message:
Logged In: YES 
user_id=1504904
Originator: YES

So what you propose to commit for 2.5 is basically mailbox-unified2
(your mailbox-unified-patch, minus the _toc clearing)?


--

Comment By: A.M. Kuchling (akuchling)
Date: 2007-01-22 10:46

Message:
Logged In: YES 
user_id=11375
Originator: NO

This would be an API change, and therefore out-of-bounds for 2.5.

I suggest giving up on this for 2.5.1 and only fixing it in 2.6.   I'll
add another warning to the docs, and maybe to the module as well.



--

Comment By: David Watson (baikie)
Date: 2007-01-21 17:10

Message:
Logged In: YES 
user_id=1504904
Originator: YES

Hold on, I have a plan.  If _toc is only regenerated on locking, or at
the end of a flush(), then the only way self._pending can be set at
that time is if the application has made modifications before calling
lock().  If we make that an exception-raising offence, then we can
assume that self._toc is a faithful representation of the last known
contents of the file.  That means we can preserve the existing message
keys on a reread without any of that _user_toc nonsense.

Diff attached, to apply on top of mailbox-unified2.  It's probably had
even less review and testing than the previous version, but it appears
to pass all the regression tests and doesn't change any existing
semantics.

File Added: mailbox-update-toc-new.diff

--

Comment By: A.M. Kuchling (akuchling)
Date: 2007-01-20 22:16

Message:
Logged In: YES 
user_id=11375
Originator: NO

  I'm starting to lose track of all the variations on the bug. 
Maybe we should just add more warnings to the documentation about locking
the mailbox when modifying it and not try to fix this at all.


--

Comment By: David Watson (baikie)
Date: 2007-01-20 13:20

Message:
Logged In: YES 
user_id=15049

[ python-Bugs-1290505 ] strptime(): can't switch locales more than once

[SourceForge.net]

Bugs item #1290505, was opened at 2005-09-13 15:50
Message generated for change (Comment added) 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.5
>Status: Open
>Resolution: None
Priority: 5
Private: No
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: Brett Cannon (bcannon)
Date: 2007-03-28 11:39

Message:
Logged In: YES 
user_id=357491
Originator: NO

kovan, can you please apply the patch I have uploaded to your copy of
_strptime and let me know if that fixes it?  I am oS X and switching
locales doesn't work for me so I don't have an easy way to test this.
File Added: strptime_cache.diff

--

Comment By: kovan (kovan)
Date: 2007-03-28 00:06

Message:
Logged In: YES 
user_id=1426755
Originator: NO

This is the code:

def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7
21:08:52

locale.setlocale(locale.LC_TIME, ('en_US','UTF8'))
format = "%Y " + format
strTime = str(datetime.now().year) + " " +strTime

import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()

tuple = strptime(strTime, format) 
return datetime(*tuple[0:6])


If I remove the code to clear the cache and add "print
format_regex.pattern" statement to _strptime.py after "format_regex =
time_re.compile(format)", I get 

(?P\d\d\d\d)\s*(?Pmi\�\�|s\�\�b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]|

[1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d)

which is in my system's locale (es), and it should be in english.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-27 19:35

Message:
Logged In: YES 
user_id=357491
Originator: NO

Can you show some code that recreatess the problem?

--

Comment By: kovan (kovan)
Date: 2007-03-27 18:06

Message:
Logged In: YES 
user_id=1426755
Originator: NO

I think I'm having this issue with Python 2.5, as I can only make strptime
take into account locale.setlocale() calls if I clear strptime's internal
regexp cache between the calls to setlocal() and strptime().

--

Comment By: Brett Cannon (bcannon)
Date: 2005-09-14 19:42

Message:
Logged In: YES 
user_id=357491

OK, the problem was that the cache for the locale
information in terms of dates and time was being invalidated
and recreated, but the regex cache was not being touched.  I
has now been fixed in re

[ python-Bugs-1690103 ] trace module borks __file__

[SourceForge.net]

Bugs item #1690103, was opened at 2007-03-28 14:05
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=1690103&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: trace module borks __file__

Initial Comment:
Stick this in a file (say, printfile.py):

print __file__

If I run it as "python printfile.py" using Python 2.4, 2.5 or 2.6 it prints as 
expected, e.g.:

% python ~/tmp/printfile.py
/Users/skip/tmp/printfile.py

If, however, I run it under control of the trace module I get something 
entirely different:

% python -m trace --count ~/tmp/printfile.py
/Users/skip/local/lib/python2.6/trace.py
% python -m trace --trace ~/tmp/printfile.py
 --- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
 --- modulename: trace, funcname: 
(1):   --- modulename: trace, funcname: 
printfile.py(1): print __file__
/Users/skip/local/lib/python2.6/trace.py

Definitely looks buggy to me...


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1690103 ] trace module borks __file__

[SourceForge.net]

Bugs item #1690103, was opened at 2007-03-28 14:05
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: trace module borks __file__

Initial Comment:
Stick this in a file (say, printfile.py):

print __file__

If I run it as "python printfile.py" using Python 2.4, 2.5 or 2.6 it prints as 
expected, e.g.:

% python ~/tmp/printfile.py
/Users/skip/tmp/printfile.py

If, however, I run it under control of the trace module I get something 
entirely different:

% python -m trace --count ~/tmp/printfile.py
/Users/skip/local/lib/python2.6/trace.py
% python -m trace --trace ~/tmp/printfile.py
 --- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
 --- modulename: trace, funcname: 
(1):   --- modulename: trace, funcname: 
printfile.py(1): print __file__
/Users/skip/local/lib/python2.6/trace.py

Definitely looks buggy to me...


--

>Comment By: Skip Montanaro (montanaro)
Date: 2007-03-28 15:01

Message:
Logged In: YES 
user_id=44345
Originator: YES

I believe this is because the trace module calls execfile()
to run the file.  I'm not sure if there's an easy fix for
this problem.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1690103 ] trace module borks __file__

[SourceForge.net]

Bugs item #1690103, was opened at 2007-03-28 14:05
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: trace module borks __file__

Initial Comment:
Stick this in a file (say, printfile.py):

print __file__

If I run it as "python printfile.py" using Python 2.4, 2.5 or 2.6 it prints as 
expected, e.g.:

% python ~/tmp/printfile.py
/Users/skip/tmp/printfile.py

If, however, I run it under control of the trace module I get something 
entirely different:

% python -m trace --count ~/tmp/printfile.py
/Users/skip/local/lib/python2.6/trace.py
% python -m trace --trace ~/tmp/printfile.py
 --- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
 --- modulename: trace, funcname: 
(1):   --- modulename: trace, funcname: 
printfile.py(1): print __file__
/Users/skip/local/lib/python2.6/trace.py

Definitely looks buggy to me...


--

>Comment By: Skip Montanaro (montanaro)
Date: 2007-03-28 15:38

Message:
Logged In: YES 
user_id=44345
Originator: YES

Hmmm...  Maybe not so hard after all.  See attached diff.  Does anyone see
a problem with simply overwriting the trace module's __file__ attribute?

File Added: trace.diff

--

Comment By: Skip Montanaro (montanaro)
Date: 2007-03-28 15:01

Message:
Logged In: YES 
user_id=44345
Originator: YES

I believe this is because the trace module calls execfile()
to run the file.  I'm not sure if there's an easy fix for
this problem.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-223616 ] compiler package needs better documentation.

[SourceForge.net]

Bugs item #223616, was opened at 2000-11-27 15:33
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223616&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: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler package needs better documentation.

Initial Comment:
The compiler package is not documented; this needs to be done before tools are 
likely to be written on top of it.

--

>Comment By: Facundo Batista (facundobatista)
Date: 2007-03-28 18:00

Message:
Logged In: YES 
user_id=752496
Originator: NO

This is one of the oldest bugs we have...

As the compiler package surely got revised with the inclusion of AST, and
the bug was only to remember about polishing... this still needs to be
open?


--

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 19:38

Message:
Logged In: YES 
user_id=31392

jeremy, get your butt in gear on this!


--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-21 15:19

Message:
Logged In: YES 
user_id=3066

I'll note that Jeremy has written basic docs, and they are
in the Library Reference.  But he really needs to polish
them a bit as well, so this stays open but gets a new summary.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-10 18:56

Message:
Logged In: YES 
user_id=3066

Jeremy said he'd work on this next week, so I'm bumping the
priority as a reminder.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-08 00:48

Message:
Jeremy -- is there anything that can be done to make it easier for you to
get this done?  I think these should really be documented and moved into
the library.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223616&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes

[SourceForge.net]

Bugs item #1687163, was opened at 2007-03-23 17:51
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&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 Interpreter Core
Group: Python 3000
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Collin Winter (collinwinter)
Summary: Inconsistent Exceptions for Readonly Attributes

Initial Comment:
Attempting assignment to a readonly attribute raises an Attribute error for 
pure Python attributes but raises a TypeError for C readonly attributes.  I 
think the AttributeError is the correct exception.



>>> class A(object):
... _x = []
...
... @property
... def x(self):
... return self._x
... 
>>> a = A()
>>> a.x = None

Traceback (most recent call last):
a.x = None
AttributeError: can't set attribute




>>> def f():
... yield None
>>> g = f()
>>> g.gi_frame = None

Traceback (most recent call last):
g.gi_frame = None
TypeError: readonly attribute

--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-28 17:45

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Fixed in r54602.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-26 16:18

Message:
Logged In: YES 
user_id=80475
Originator: YES

Collin, would you please apply this to the Py3K code.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-23 19:52

Message:
Logged In: YES 
user_id=80475
Originator: YES

Here's the one line change:

Index: Python/structmember.c
===
--- Python/structmember.c   (revision 54557)
+++ Python/structmember.c   (working copy)
@@ -160,7 +160,7 @@

if ((l->flags & READONLY) || l->type == T_STRING)
{
-   PyErr_SetString(PyExc_TypeError, "readonly attribute");
+   PyErr_SetString(PyExc_AttributeError, "readonly
attribute");



Four of the tests will need to be updated:
test_csv test_descr test_generators test_os


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-23 18:16

Message:
Logged In: YES 
user_id=80475
Originator: YES

Readonly methods throw an AttributeError, but readonly members (anything
defined in PyMemberDef with an RO or READONLY flag) raise a TypeError.

--

Comment By: Jack Diederich (jackdied)
Date: 2007-03-23 18:12

Message:
Logged In: YES 
user_id=591932
Originator: NO

I think this has something peculiar to frames, for instance:

Python 2.5 (r25:51908, Sep 25 2006, 17:50:07) 
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = 'asdf'
>>> f.strip = 42
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'str' object attribute 'strip' is read-only
>>> 


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1688564 ] os.path.join.__doc__ should mention absolute paths

[SourceForge.net]

Bugs item #1688564, was opened at 2007-03-26 13:12
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688564&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: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eugene Kramer (zdes)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.join.__doc__ should mention absolute paths

Initial Comment:
Currently, automatically generated docs from os.path.join do not mention that 
all paths prior to the last absolute path are discarded.

The __doc__ says:
"Join two or more pathname components, inserting '/' as needed"

>From this documentation, it is not obvious that os.path.join("abc", "/cde", 
>"fgh") results in "/cde/fgh".

--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-28 17:48

Message:
Logged In: YES 
user_id=1344176
Originator: NO

"""Join two or more pathname components, inserting '/' as needed. If any
component is an absolute path, all previous path components will be
discarded."""

Does that work for you? Could you come up with language that you'd prefer
to see?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688564&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1689458 ] pdb unable to jump to first statement

[SourceForge.net]

Bugs item #1689458, was opened at 2007-03-27 17:07
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gotgenes (gotgenes)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb unable to jump to first statement

Initial Comment:
The Python debugger is unable to "jump" back to the first executable statement 
in a frame once that statement has been executed. For example:

[EMAIL PROTECTED]:~/development/playground$ python -m pdb simple.py 
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) next
> /home/chris/development/playground/simple.py(4)?()
-> b = 2
(Pdb) jump 3
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) list
  1 #!/usr/bin/env python
  2  
  3 a = 1
  4  -> b = 2
  5  
  6 c = a + b
  7  
  8 print c
[EOF]
(Pdb) next
> /home/chris/development/playground/simple.py(6)?()
-> c = a + b

One can see that after supposedly "jump"ing to line 3 at the second command, 
when "list"ing the line, the debugger is actually at line 4. The "next" command 
further demonstrates this since it re-executes line 4 and moves to line 6.

This issue was raised on comp.lang.python. (For example, see

or if that link is munged, refer to


Duncan Booth offers the following:
[quote]
I verified (with a print statement in pdb) that assigning to 
self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti 
incorrectly

...

The problem looks to be in frameobject.c:

addr = 0;
line = f->f_code->co_firstlineno;
new_lasti = -1;
for (offset = 0; offset < lnotab_len; offset += 2) {
addr += lnotab[offset];
line += lnotab[offset+1];
if (line >= new_lineno) {
new_lasti = addr;
new_lineno = line;
break;
}
}

The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 
1). If line==f->f_code->co_firstlineno it should set new_lasti=0, 
new_lineno=line but the loop still executes once which increments new_lasti and 
new_lineno to the next line (6, 4).
[/quote]

And Rocky Bernstein offers the following:
[quote]
Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle 
the "jump" command by changing the frame f_lineno value. When the corresponding 
code pointer has offset 0 (or equivalently and more simlply as you put it, is 
the first statement) this doesn't seem to work properly.
[/quote]

--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-28 17:54

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Could you work up a full test case for this? Or better yet, a patch?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1681984 ] unittest documentation is incomplete

[SourceForge.net]

Bugs item #1681984, was opened at 2007-03-16 06:17
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&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: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: STINNER Victor (haypo)
Assigned to: Collin Winter (collinwinter)
Summary: unittest documentation is incomplete

Initial Comment:
When I tried to write a test suite using many test cases, I read the 
documentation (docs.python.org) but it does work because I was unable to run my 
test suite. Using Google I realised that documentation is incomplete! In Python 
binding of gstreamer, I found a "TextTestRunner"!

So, would it be possible to update the doc?

--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-28 18:05

Message:
Logged In: YES 
user_id=1344176
Originator: NO

I don't see the need to document TestProgram or TextTestRunner; the former
is an implementation detail of the module (and a messy detail, to boot),
not meant to be used in third-party code; the only time you'd come across
the latter is when implementing custom test runners, in which case you're
to the point of reading the module's source anyway.

As for an example of how to use test runners and test suites, why?
"unittest.main()" means most users never need to know about these things.
Totally comprehensive documentation is an easy thing to get lost in.

--

Comment By: STINNER Victor (haypo)
Date: 2007-03-18 22:00

Message:
Logged In: YES 
user_id=365388
Originator: YES

"Could you please state what exactly is missing from the documentation, in
your opinion?"

Well, when I ready Python documentation I expect to have the full list of
"builtin" modules, functions and classes. But if you check unittest module,
documentation only list TestCase, TestSuite, TestResult and TestLoader.
Whereas dir(unittest) gives TestCase, TestLoader, *TestProgram*,
TestResult, TestSuite, *TextTestRunner*.

So information about TestProgram and TextTestRunner is missing.

I also expect a small example showing how to use a test runner and a test
suite.

I'm using:
-- 8< ---

from unittest import TestSuite, TestLoader, TextTestRunner
from sys import exit

def loadTests(loader):
"""Generator listing all test cases"""
...

def main():
loader = TestLoader()

suite = TestSuite()
for test in loadTests(loader.loadTestsFromTestCase):
suite.addTests(test)

runner = TextTestRunner(descriptions=2, verbosity=2)
result = runner.run(suite)
if result.failures or result.errors:
exit(1)

-- 8< ---

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-16 09:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

Could you please state what exactly is missing from the documentation, in
your opinion?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&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

[SourceForge.net]

Bugs item #1290505, was opened at 2005-09-14 00:50
Message generated for change (Comment added) made by kovan
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.5
Status: Open
Resolution: None
Priority: 5
Private: No
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: kovan (kovan)
Date: 2007-03-29 00:55

Message:
Logged In: YES 
user_id=1426755
Originator: NO

I applied the patch, and it works now :). 
Thanks bcannon for the quick responses.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-28 20:39

Message:
Logged In: YES 
user_id=357491
Originator: NO

kovan, can you please apply the patch I have uploaded to your copy of
_strptime and let me know if that fixes it?  I am oS X and switching
locales doesn't work for me so I don't have an easy way to test this.
File Added: strptime_cache.diff

--

Comment By: kovan (kovan)
Date: 2007-03-28 09:06

Message:
Logged In: YES 
user_id=1426755
Originator: NO

This is the code:

def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7
21:08:52

locale.setlocale(locale.LC_TIME, ('en_US','UTF8'))
format = "%Y " + format
strTime = str(datetime.now().year) + " " +strTime

import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()

tuple = strptime(strTime, format) 
return datetime(*tuple[0:6])


If I remove the code to clear the cache and add "print
format_regex.pattern" statement to _strptime.py after "format_regex =
time_re.compile(format)", I get 

(?P\d\d\d\d)\s*(?Pmi\�\�|s\�\�b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]|

[1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d)

which is in my system's locale (es), and it should be in english.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-28 04:35

Message:
Logged In: YES 
user_id=357491
Originator: NO

Can you show some code that recreatess the problem?

--

Comment By: kovan (kovan)
Date: 2007-03-28 03:06

Message:
Logged In: YES 
user_id=1426755
Originator: NO

I think I'm having this issue with Python 2.5, as I can only make strptime
take into account locale.setlocale() calls if I clear strptime's internal
regexp cache between the calls to setlocal() and strptime().

--

Comment By: Brett Cannon (bcannon)
Date

[ python-Feature Requests-1634034 ] Show "expected" token on syntax error

[SourceForge.net]

Feature Requests item #1634034, was opened at 2007-01-12 13:03
Message generated for change (Comment added) made by sean_gillespie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634034&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: Parser/Compiler
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Oliver Gramberg (oliver_gramberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Show "expected" token on syntax error

Initial Comment:

I suggest that the parser, when reporting a syntax
error, should make use of its knowlegde of which token
type is expected at the position where the error
occurred. This results in more helpful error messages:

-
>>> for a in (8,9)
  File "", line 1
for a in (8,9)
 ^
SyntaxError: invalid syntax - COLON expected
-
>>> for a in (8,9: print a,
  File "", line 1
for a in (8,9: print a,
 ^
SyntaxError: invalid syntax: RPAR expected
-

I tried the following patch (for pythonrun.c). It works
well in the shell both interactively and in scripts,
as well as in IDLE. But it's not complete:
- It doesn't always print useful messages (only for
fixed-size terminal token types, I assume.)
- There sure are cases where more than one token type
is allowed in a position. I believe I have seen that
this information is available too somewhere in the
parser, but it is not forwarded to the err_input
routine.

It's even nicer to show "')'" instead of "RPAR"...

-
/* Set the error appropriate to the given input error code (see errcode.h) */

static void
err_input(perrdetail *err)
{
PyObject *v, *w, *errtype;
PyObject* u = NULL;
char *msg = NULL;
errtype = PyExc_SyntaxError;
switch (err->error) {
case E_SYNTAX:
errtype = PyExc_IndentationError;
if (err->expected == INDENT)
msg = "expected an indented block";
else if (err->token == INDENT)
msg = "unexpected indent";
else if (err->token == DEDENT)
msg = "unexpected unindent";
else {
char buf[50];
errtype = PyExc_SyntaxError;
if(err->expected != -1) {
snprintf(buf, 48, "invalid syntax - %.16s 
expected\0",
_PyParser_TokenNames[err->expected]);
msg = buf;
} else {
msg = "invalid syntax";
}
}
break;
...
-

I am willing to help work on this.

Regards
-Oliver


--

Comment By: Sean Gillespie (sean_gillespie)
Date: 2007-03-28 23:37

Message:
Logged In: YES 
user_id=1744567
Originator: NO

Your patch seems to work.

I agree that showing the token (as in ")") would indeed be much more
useful, and it would be pretty easy to implement.

However, I think that you should generate a diff for your patch.  Its
incredibly hard to read over SF.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634034&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

[SourceForge.net]

Bugs item #1290505, was opened at 2005-09-13 15:50
Message generated for change (Comment added) 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.5
Status: Open
Resolution: None
Priority: 5
Private: No
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: Brett Cannon (bcannon)
Date: 2007-03-28 16:40

Message:
Logged In: YES 
user_id=357491
Originator: NO

The power of procrastination in the morning.  =)  I am going to try to
come up with a test case for this.  I might ask, kovan, if you can run the
test case to make sure it works.

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-28 15:55

Message:
Logged In: YES 
user_id=1426755
Originator: NO

I applied the patch, and it works now :). 
Thanks bcannon for the quick responses.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-28 11:39

Message:
Logged In: YES 
user_id=357491
Originator: NO

kovan, can you please apply the patch I have uploaded to your copy of
_strptime and let me know if that fixes it?  I am oS X and switching
locales doesn't work for me so I don't have an easy way to test this.
File Added: strptime_cache.diff

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-28 00:06

Message:
Logged In: YES 
user_id=1426755
Originator: NO

This is the code:

def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7
21:08:52

locale.setlocale(locale.LC_TIME, ('en_US','UTF8'))
format = "%Y " + format
strTime = str(datetime.now().year) + " " +strTime

import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()

tuple = strptime(strTime, format) 
return datetime(*tuple[0:6])


If I remove the code to clear the cache and add "print
format_regex.pattern" statement to _strptime.py after "format_regex =
time_re.compile(format)", I get 

(?P\d\d\d\d)\s*(?Pmi\�\�|s\�\�b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]|

[1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d)

which is in my system's locale (es), and it should be in english.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-27 19:35

Message:
Logged In: YES 
user_id=357491
Originator: NO

Can you show some code that recreatess the problem?

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-2

[ python-Bugs-1290505 ] strptime(): can't switch locales more than once

[SourceForge.net]

Bugs item #1290505, was opened at 2005-09-14 00:50
Message generated for change (Comment added) made by kovan
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.5
Status: Pending
Resolution: None
Priority: 5
Private: No
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: Javier Sanz (kovan)
Date: 2007-03-29 01:44

Message:
Logged In: YES 
user_id=1426755
Originator: NO

I'll be glad to help in whatever I can.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-29 01:40

Message:
Logged In: YES 
user_id=357491
Originator: NO

The power of procrastination in the morning.  =)  I am going to try to
come up with a test case for this.  I might ask, kovan, if you can run the
test case to make sure it works.

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-29 00:55

Message:
Logged In: YES 
user_id=1426755
Originator: NO

I applied the patch, and it works now :). 
Thanks bcannon for the quick responses.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-28 20:39

Message:
Logged In: YES 
user_id=357491
Originator: NO

kovan, can you please apply the patch I have uploaded to your copy of
_strptime and let me know if that fixes it?  I am oS X and switching
locales doesn't work for me so I don't have an easy way to test this.
File Added: strptime_cache.diff

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-28 09:06

Message:
Logged In: YES 
user_id=1426755
Originator: NO

This is the code:

def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7
21:08:52

locale.setlocale(locale.LC_TIME, ('en_US','UTF8'))
format = "%Y " + format
strTime = str(datetime.now().year) + " " +strTime

import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()

tuple = strptime(strTime, format) 
return datetime(*tuple[0:6])


If I remove the code to clear the cache and add "print
format_regex.pattern" statement to _strptime.py after "format_regex =
time_re.compile(format)", I get 

(?P\d\d\d\d)\s*(?Pmi\�\�|s\�\�b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]|

[1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d)

which is in my system's locale (es), and it should be in english.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-28 04:35

Me

[ python-Bugs-1682403 ] docutils clarification request for "rest"

[SourceForge.net]

Bugs item #1682403, was opened at 2007-03-16 15:58
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&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: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: j vickroy (jvickroy)
Assigned to: Nobody/Anonymous (nobody)
Summary: docutils clarification request for "rest"

Initial Comment:
>From the definition of long_description:
 
 *'long string'*
 Multiple lines of plain text in reStructuredText format (see 
http://docutils.sf.net/).
 
in:

  http://docs.python.org/dist/meta-data.html

I incorrectly concluded that the the bdist_wininst installer would provide 
visual markup for long_description specified in restructured text.

According to Thomas Heller, that is not the case.

I wish to suggest adding this clarification to the distutils documentation 
perhaps in one or both of the following documents:

 http://docs.python.org/dist/postinstallation-script.html
 http://docs.python.org/dist/meta-data.html

Thanks,

-- jv

--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-28 19:46

Message:
Logged In: YES 
user_id=1344176
Originator: NO

I'm not quite sure what the problem is. What kind of "visual markup" did
you expect?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&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

[SourceForge.net]

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.5
>Status: Pending
Resolution: None
Priority: 5
Private: No
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: Brett Cannon (bcannon)
Date: 2007-03-28 16:40

Message:
Logged In: YES 
user_id=357491
Originator: NO

The power of procrastination in the morning.  =)  I am going to try to
come up with a test case for this.  I might ask, kovan, if you can run the
test case to make sure it works.

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-28 15:55

Message:
Logged In: YES 
user_id=1426755
Originator: NO

I applied the patch, and it works now :). 
Thanks bcannon for the quick responses.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-28 11:39

Message:
Logged In: YES 
user_id=357491
Originator: NO

kovan, can you please apply the patch I have uploaded to your copy of
_strptime and let me know if that fixes it?  I am oS X and switching
locales doesn't work for me so I don't have an easy way to test this.
File Added: strptime_cache.diff

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-28 00:06

Message:
Logged In: YES 
user_id=1426755
Originator: NO

This is the code:

def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7
21:08:52

locale.setlocale(locale.LC_TIME, ('en_US','UTF8'))
format = "%Y " + format
strTime = str(datetime.now().year) + " " +strTime

import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()

tuple = strptime(strTime, format) 
return datetime(*tuple[0:6])


If I remove the code to clear the cache and add "print
format_regex.pattern" statement to _strptime.py after "format_regex =
time_re.compile(format)", I get 

(?P\d\d\d\d)\s*(?Pmi\�\�|s\�\�b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]|

[1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d)

which is in my system's locale (es), and it should be in english.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-27 19:35

Message:
Logged In: YES 
user_id=357491
Originator: NO

Can you show some code that recreatess the problem?

--

Comment By: Javier Sanz (kovan)
Date: 200

[ python-Bugs-1689458 ] pdb unable to jump to first statement

[SourceForge.net]

Bugs item #1689458, was opened at 2007-03-27 16:07
Message generated for change (Comment added) made by gotgenes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gotgenes (gotgenes)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb unable to jump to first statement

Initial Comment:
The Python debugger is unable to "jump" back to the first executable statement 
in a frame once that statement has been executed. For example:

[EMAIL PROTECTED]:~/development/playground$ python -m pdb simple.py 
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) next
> /home/chris/development/playground/simple.py(4)?()
-> b = 2
(Pdb) jump 3
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) list
  1 #!/usr/bin/env python
  2  
  3 a = 1
  4  -> b = 2
  5  
  6 c = a + b
  7  
  8 print c
[EOF]
(Pdb) next
> /home/chris/development/playground/simple.py(6)?()
-> c = a + b

One can see that after supposedly "jump"ing to line 3 at the second command, 
when "list"ing the line, the debugger is actually at line 4. The "next" command 
further demonstrates this since it re-executes line 4 and moves to line 6.

This issue was raised on comp.lang.python. (For example, see

or if that link is munged, refer to


Duncan Booth offers the following:
[quote]
I verified (with a print statement in pdb) that assigning to 
self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti 
incorrectly

...

The problem looks to be in frameobject.c:

addr = 0;
line = f->f_code->co_firstlineno;
new_lasti = -1;
for (offset = 0; offset < lnotab_len; offset += 2) {
addr += lnotab[offset];
line += lnotab[offset+1];
if (line >= new_lineno) {
new_lasti = addr;
new_lineno = line;
break;
}
}

The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 
1). If line==f->f_code->co_firstlineno it should set new_lasti=0, 
new_lineno=line but the loop still executes once which increments new_lasti and 
new_lineno to the next line (6, 4).
[/quote]

And Rocky Bernstein offers the following:
[quote]
Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle 
the "jump" command by changing the frame f_lineno value. When the corresponding 
code pointer has offset 0 (or equivalently and more simlply as you put it, is 
the first statement) this doesn't seem to work properly.
[/quote]

--

>Comment By: gotgenes (gotgenes)
Date: 2007-03-28 20:24

Message:
Logged In: YES 
user_id=1180453
Originator: YES

Truthfully, I don't have enough know-how to write a full test case or a
patch. I have put forth a request on the comp.lang.python thread (link in
original report) for those that would to please do so.

--

Comment By: Collin Winter (collinwinter)
Date: 2007-03-28 16:54

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Could you work up a full test case for this? Or better yet, a patch?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1508864 ] threading.Timer/timeouts break on change of win32 local time

[SourceForge.net]

Bugs item #1508864, was opened at 2006-06-19 14:53
Message generated for change (Comment added) made by xiaowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Russell Warren (qopit)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Timer/timeouts break on change of win32 local time

Initial Comment:
THE ISSUE...
---
threading.py imports time.time as _time.

On win32 systems, time.time() periodically reads the
system time to figure out when to fire an Event.

System time can change while waiting for an Event!

eg:  If the system time is changed while a
threading.Timer is pending, the execution time is
affected by the time change.  eg: set a pending Timer
and then change the clock back an hour - this causes
your Timer to fire an hour later.  This is clearly not
desirable.


A FIX...
---
A fix for this is to use time.clock() on win32 systems
instead.  Once I found the problem, I currently just
fix it by overriding threading._time to be time.clock.
 Right now I do this in every file that uses
threading.Timer.


COMMENTS...
---
The penalty for this is that there will be a rollover
problem eventaully... when the 64-bit performance
counter rolls over in 30+ years of continuous pc
operation.  I'd much rather have this near impossible
event than the very likely system time change.

This is a general problem I find with the time module
and I often have to switch between time() and clock()
dependent on operating system, but I only work with
win32 and Linux.  The issue is that if you want a high
resolution and extended rollover counter, it is a
different call on each system.



--

Comment By: xiaowen (xiaowen)
Date: 2007-03-28 20:41

Message:
Logged In: YES 
user_id=251143
Originator: NO

Patch implementing what jtate described:

--- python/Lib/threading.py 2007-03-29 09:13:53.0 +0800
+++ python/Lib/threading.py.new 2007-03-29 09:26:44.0 +0800
@@ -222,15 +222,19 @@
 # than 20 times per second (or the timeout time
remaining).
 endtime = _time() + timeout
 delay = 0.0005 # 500 us -> initial delay of 1 ms
+remaining = max(timeout, 0)
 while True:
 gotit = waiter.acquire(0)
 if gotit:
 break
-remaining = endtime - _time()
 if remaining <= 0:
 break
 delay = min(delay * 2, remaining, .05)
 _sleep(delay)
+if endtime - _time() > remaining:
+# Time must have been moved back, so readjust
endtime.
+endtime = _time() + remaining - delay
+remaining = endtime - _time()
 if not gotit:
 if __debug__:
 self._note("%s.wait(%s): timed out", self,
timeout)
--- python/Lib/Queue.py 2007-01-01 00:38:56.0 +0800
+++ python/Lib/Queue.py.new 2007-01-01 00:42:14.0 +0800
@@ -127,7 +127,7 @@
 endtime = _time() + timeout
 while self._full():
 remaining = endtime - _time()
-if remaining <= 0.0:
+if remaining <= 0.0 or remaining > timeout:
 raise Full
 self.not_full.wait(remaining)
 self._put(item)
@@ -169,7 +169,7 @@
 endtime = _time() + timeout
 while self._empty():
 remaining = endtime - _time()
-if remaining <= 0.0:
+if remaining <= 0.0 or remaining > timeout:
 raise Empty
 self.not_empty.wait(remaining)
 item = self._get()


--

Comment By: Joseph Tate (jtate)
Date: 2007-03-28 10:07

Message:
Logged In: YES 
user_id=55276
Originator: NO

On Linux time.clock() is CPU time.  And has no bearing at all on real
time.  On windows time.clock() is real time since CPU time is not available
from the operating system.

What if instead of replacing time.time() with time.clock(), the Queue and
Event wait loops just kicked out if "remaining time" was larger than the
initial wait time?  Let the outer loop continue, and the next time wait is
called, the "remaining time" will be calculated correctly.

Otherwise, we could compare "remaining time" between one loop iteration
and the subsequent and then *approximate* how much the time has changed to
adjus

[ python-Bugs-1290505 ] strptime(): can't switch locales more than once

[SourceForge.net]

Bugs item #1290505, was opened at 2005-09-13 15:50
Message generated for change (Comment added) 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.5
Status: Pending
Resolution: None
Priority: 5
Private: No
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: Brett Cannon (bcannon)
Date: 2007-03-28 19:07

Message:
Logged In: YES 
user_id=357491
Originator: NO

I have uploaded a patch for test_strptime that adds a test to make sure
that the TimeRE instance is recreated if the locale changes (went with
en_US and de_DE, but could easily be other locales if there are other ones
that are more common).  Let me know if the test runs fine and works.  Even
better is if it fails without the fix.
File Added: strptime_timere_test.diff

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-28 16:44

Message:
Logged In: YES 
user_id=1426755
Originator: NO

I'll be glad to help in whatever I can.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-28 16:40

Message:
Logged In: YES 
user_id=357491
Originator: NO

The power of procrastination in the morning.  =)  I am going to try to
come up with a test case for this.  I might ask, kovan, if you can run the
test case to make sure it works.

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-28 15:55

Message:
Logged In: YES 
user_id=1426755
Originator: NO

I applied the patch, and it works now :). 
Thanks bcannon for the quick responses.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-28 11:39

Message:
Logged In: YES 
user_id=357491
Originator: NO

kovan, can you please apply the patch I have uploaded to your copy of
_strptime and let me know if that fixes it?  I am oS X and switching
locales doesn't work for me so I don't have an easy way to test this.
File Added: strptime_cache.diff

--

Comment By: Javier Sanz (kovan)
Date: 2007-03-28 00:06

Message:
Logged In: YES 
user_id=1426755
Originator: NO

This is the code:

def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7
21:08:52

locale.setlocale(locale.LC_TIME, ('en_US','UTF8'))
format = "%Y " + format
strTime = str(datetime.now().year) + " " +strTime

import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()

tuple = strptime(strTime, format) 
return datetime(*tuple[0:6])


If I remove the c

[ python-Bugs-1572084 ] .eml attachments in email

[SourceForge.net]

Bugs item #1572084, was opened at 2006-10-06 05:23
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&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.5
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: rainwolf8472 (rainwolf8472)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: .eml attachments in email

Initial Comment:
I think there's a bug somewhere in the email package. 
I wanted to write a 
script to send emails with certain attachments using
libgmail, and found 
this one, http://pramode.net/articles/lfy/fuse/4.txt ,
it works fine with 
most files, but it fails with .eml files, and what i
can't understand is 
that if I change the extension of those .eml files to
.txt, the script works 
fine.  However, when trying to mail a simple textfile
containing "hello", en 
changing the extension to .eml before sending, it fails
again. it doesn't 
fail when I don't change the extension to .eml.
Any help please? I pasted the output I get (over and
over again) in the attached textfile.

--

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-03-28 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

--

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-13 22:04

Message:
Logged In: YES 
user_id=12800
Originator: NO

I'll need more information in order to debug this.  Please try to create a
small, standalone, reproducible test case.  I don't have libgmail available
so please don't write a test case that depends on that.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1690324 ] Typographical Error

[SourceForge.net]

Bugs item #1690324, was opened at 2007-03-29 10:44
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=1690324&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: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mervyn Yeo (myeo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typographical Error

Initial Comment:
Python Tutorial
8.3 Handling Exceptions
"One my also instantiate an exception first before raising it and add any 
attributes to it as desired."

'my' should be 'may' instead.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1690324 ] Typographical Error

[SourceForge.net]

Bugs item #1690324, was opened at 2007-03-29 10:44
Message generated for change (Settings changed) made by myeo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&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: Documentation
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 1
Private: No
Submitted By: Mervyn Yeo (myeo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typographical Error

Initial Comment:
Python Tutorial
8.3 Handling Exceptions
"One my also instantiate an exception first before raising it and add any 
attributes to it as desired."

'my' should be 'may' instead.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1690324 ] Typographical Error

[SourceForge.net]

Bugs item #1690324, was opened at 2007-03-29 11:44
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&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: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Out of Date
Priority: 1
Private: No
Submitted By: Mervyn Yeo (myeo)
>Assigned to: George Yoshida (quiver)
Summary: Typographical Error

Initial Comment:
Python Tutorial
8.3 Handling Exceptions
"One my also instantiate an exception first before raising it and add any 
attributes to it as desired."

'my' should be 'may' instead.

--

>Comment By: George Yoshida (quiver)
Date: 2007-03-29 14:11

Message:
Logged In: YES 
user_id=671362
Originator: NO

This is a known issue and already fixed in the subversion(see r52048 and
r52049).
Thanks for the report anyway.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com