[ python-Bugs-1685773 ] tarfile file names under win32

[SourceForge.net]

Bugs item #1685773, was opened at 2007-03-22 08:12
Message generated for change (Comment added) made by indi4source
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&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: ralf (indi4source)
Assigned to: Lars Gustäbel (gustaebel)
Summary: tarfile file names under win32

Initial Comment:
the tarfile module uses normpath() to store the file name in the archive. Under 
win32 this results in pathes with backslashes and possible a leading "\". This 
confuses the  unix tar command.

I suppose the following commands instead of 
just normpath():
path = normpath (path)
path = path.replace ("\\", "/")
path = path.lstrip ("/")

--

>Comment By: ralf (indi4source)
Date: 2007-03-27 10:25

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

Sorry, I was using an derived class of TarFile and didn't realize that
tarfile has defined its own
normpath() function.
When using tarfile.normpath() in my class it is working, too.

--

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-03-23 11:36

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

tarfile already attempts to manage backslashes well, using
os.path.normpath(path).replace(os.sep, "/")
Can you provide a small script demonstrating the failure?


--

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

[ python-Bugs-1495754 ] os.listdir(): inconsistent behavior with trailing spaces

[SourceForge.net]

Bugs item #1495754, was opened at 2006-05-26 23:28
Message generated for change (Comment added) made by jerrykhan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495754&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: Wont Fix
Priority: 5
Private: No
Submitted By: Kenneth J. Pronovici (pronovic)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.listdir(): inconsistent behavior with trailing spaces

Initial Comment:
I've noticed some inconsistent behavior around 
os.listdir() and paths that contain trailing spaces on 
the Windows platform.

Take this example code:

   import os
   import tempfile
   tmpdir = tempfile.mkdtemp()
   newdir = os.path.join(tmpdir, " collect dir ")
   os.mkdir(newdir)
   print os.path.exists(newdir)
   print os.listdir(newdir)

If I run this code on Windows 2000 Pro using Python 
2.4.2, I get this:

True
[Errno 3] The system cannot find the path 
specified: 'c:\\docume~1\\a0clu0~1.bcb\\locals~1
\\temp\\tmpfd7j3t\\ collect dir /*.*'

It seems to me that if os.path.exists() tells me that 
a file or directory exists, that os.listdir() should 
be able to operate on it.

--

Comment By: JerryKhan (jerrykhan)
Date: 2007-03-27 13:41

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

I agree with the fact that this inconsistent behaviour is disturbing.
I tried it with a simple example "lib ", if it exists, we must be able to
browse it.

Example: open the idle, 
import os
os.path.exists("lib ")   ==> True
os.path.listdir('lib ')

Traceback (most recent call last):
  File "", line 1, in -toplevel-
os.listdir('lib ')
WindowsError: [Errno 3] Le chemin d'accès spécifié est introuvable:
'lib /*.*'

os.stat('lib ') works ...
os.stat(' lib') does not work (that ok to me) 

I disagree with the argument that since Windows is bugged then Python is
bugged too.
It should be possible to rightstrip the folder name before asking for the
resolution of
 abspath/the_dir_with_space_at_the_end /*.*
Or to deactivate the rightstriping done on the stat builtin function.

I imagine that this is located in nt builtin module.
I have done it in my own program .. but this should be coded in interfaces
modules.

Jerrykhan

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 22:59

Message:
Logged In: YES 
user_id=849994

Since Python only calls the underlying Win32 function
FindFirstFile, I think there can nothing be done since that
function seems to be buggy in this respect.

--

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

[ python-Bugs-1668596 ] distutils chops the first character of filenames

[SourceForge.net]

Bugs item #1668596, was opened at 2007-02-25 17:15
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sam Pointon (freecondiments)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils chops the first character of filenames

Initial Comment:
Python 2.5c1, Windows XP SP2.

distutils chops the first character from some filenames if the package_data key 
is ''.

Minimal example:
The setup.py attached, and a directory named 'doc' in the same directory as 
setup.py with files in it. Running "python setup.py bdist" triggers the error.

On my box, this fails with:
running bdist
running bdist_dumb
running build
running build_py
error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file

http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html 
describes the same problem, and 
http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a 
commentary on the code in distutils/commands/build_py.py which causes the error.

On lines 117-122, it tries to chop the directory path from the files it has 
found, using len() and slicing. This job is better done by os.path.split (and 
is probably more portable, too).

--

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-03-27 12:19

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


Hi,

I reproduced the problem with the latest build on linux. The "fix" may be
trivial but I am not entirely sure if there is a problem in the first
place. The distutils document does not mention about having null value for
package_dir as is the case in your setup.py. I may be missing something
here but can you please explain the conclusion that "" is a perfectly valid
value for package_dir (as mentioned in one of the threads in mailing list)?
I am assuming that you mean "distribution root" directory by "". If this is
found to be valid usage, the  document should be updated along with the
code fix. Otherwise, a check can be put in to disallow null values. 

Raghu.




--

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

--

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-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.4
Status: Closed
Resolution: Fixed
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-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: 2005-09-15 04: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 rev. 1.41 for 2.5 and in rev. 1.38.2.3
for 2.4 .

Thanks for reporting this, Adam.

--

Comment By: Adam Monsen (meonkeys)
Date: 2005-09-14 00: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

[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.4
Status: Closed
Resolution: Fixed
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-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 rev. 1.41 for 2.5 and in rev. 1.38.2.3
for 2.4 .

Thanks for reporting this, Adam.

--

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-471432 ] __cdecl / __stdcall unspecified in *.h

[SourceForge.net]

Bugs item #471432, was opened at 2001-10-15 12:18
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&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: Platform-specific
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Mark Hammond (mhammond)
Summary: __cdecl / __stdcall unspecified in *.h

Initial Comment:

Currently, the win32 function call convention
(__stdcall vs __cdecl)  is never specified in the
function prototypes contained in the .h header files.

The call convention is therefore left up to the
configuration of the compiler incluing the header files
(__cdecl by default on VC++).

However, there are situations in which the compiler
default call convention must be set to __stdcall (/Gz
option on VC++'s cl.exe), and this makes the link fail;
until __cdecl keywords are manually insterted in the
Python.h function prototypes required for linking.

[For instance, /Gz is required when using typedef
definitions on function pointers, later passed as
arguments on __stdcall functions (the default on
Microsoft/commercial libraries)].

Besides, Microsoft recommands, it the VC++
documentation,  that the __stdcall convention be used
by default for function with fixed numbers of arguments
(smaller code size and better performances); __cdecl
being limited for use with functions with variable
number of args ('...').

A solution would consist in defining:
#ifdef _MS_VER
#define FIXARGCALL __stdcall
#define VARARGCALL __cdecl
#else
...
#endif

and sticking FIXARGCALL / VARARGCALL in front of all
DLL_IMPORT(), macro calls associated to a an exported
function prototype, across all Python .h files.

Frederic Giacometti


--

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

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

No one has cared for a week, so closing as out of date.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-03-20 15:05

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

This is a rather old bug.  =)  If no one cares to fix this then it should
be closed.

--

Comment By: Frederic Giacometti (giacometti)
Date: 2001-10-16 10:19

Message:
Logged In: YES 
user_id=93657

The fault is not in the other libraries.

In MS Windows, 'well-behaved' libraries define explicitely
the calling conventions for each function in their header
file. This is all.

There's nobody's guts loosely hanging out in this ;).

FG

--

Comment By: Tim Peters (tim_one)
Date: 2001-10-15 20:00

Message:
Logged In: YES 
user_id=31435

I guess my first question is, if library X needs something 
other than the default, why isn't it X's responsibility to 
force *their* non-default behavior where needed?  After 
all, they're the oddballs.  Some days I get real tired of 
cleaing up after everyone else's loose bowels <0.9 wink>.

--

Comment By: Mark Hammond (mhammond)
Date: 2001-10-15 18:45

Message:
Logged In: YES 
user_id=14198

This does make sense to me, and I have even been bitten by 
it.

There are some strange libraries out there that need to be 
compiled with a different calling convention than the 
default.  Trying to extend Python with such a library can 
be difficult.  Having the calling convention specified in 
the prototypes would solve the problem.

I have never been brave enough to do it, given the small 
number of times it has been reported as a problem.  
However, I would be happy to help come up with a reasonable 
scheme.

--

Comment By: Frederic Giacometti (giacometti)
Date: 2001-10-15 12:46

Message:
Logged In: YES 
user_id=93657

As far as MS Windows / dll stuff is concerned, you're
already swimming in non-C-ANSI fishtank anyway (e.g.
DLL_IMPORT() macros...).
Just try to keep the right fishes in the tank :))

FG


--

Comment By: Tim Peters (tim_one)
Date: 2001-10-15 12:34

Message:
Logged In: YES 
user_id=31435

Mark, does this make sense to you?  Any notion that we 
*have* to add non-standard decorations seems inherently 
fishy to me.

--

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

[ python-Bugs-1688393 ] sock.recvfrom(-24) crashes

[SourceForge.net]

Bugs item #1688393, was opened at 2007-03-26 11:13
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688393&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andrew Bennetts (spiv)
>Assigned to: Facundo Batista (facundobatista)
Summary: sock.recvfrom(-24) crashes

Initial Comment:
Actually sock.recvfrom(x) crashes or causes memory corruption for all values in 
-sizeof(PyStringObject) <= x < 0, I think.

This script demonstrates the problem:

import socket, sys
s1 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s1.bind(('127.0.0.1', ))
s2 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s2.sendto('fdsjkldsfkj', ('127.0.0.1', ))
print s1.recvfrom(-24)

Try e.g. -1 instead of -24 as well.

I'm attaching a patch that fixes this bug, and adds a simple test for it too.

Other sock_recv* functions in socketmodule.c seem to already catch negative 
recvlen values and raise ValueError, but for some reason recvfrom missed out.

--

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

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

Applied this to the trunk, let's see if we should backport it to 2.5.x
before close this bug.

--

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



--

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-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.4
Status: Closed
Resolution: Fixed
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-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: 2005-09-15 04: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 rev. 1.41 for 2.5 and in rev. 1.38.2.3
for 2.4 .

Thanks for reporting this, Adam.

--

Comment By: Adam Monsen (meonkeys)
Date: 2005-09-14 00: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:/