[ python-Bugs-1508564 ] "...." (four dots) confuses doctest's ellipsis matching

2006-06-19 Thread SourceForge.net 
Bugs item #1508564, was opened at 2006-06-19 21:42
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=1508564&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
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: "" (four dots) confuses doctest's ellipsis matching

Initial Comment:
Consider this snippet:

from doctest import OutputChecker, ELLIPSIS
print OutputChecker().check_output('AAA',
'AAA.BBB', ELLIPSIS)

I expect that to print True, but instead it prints False.


--

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

[ python-Bugs-1508564 ] "...." (four dots) confuses doctest's ellipsis matching

2006-06-19 Thread SourceForge.net 
Bugs item #1508564, was opened at 2006-06-19 07:42
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508564&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
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: "" (four dots) confuses doctest's ellipsis matching

Initial Comment:
Consider this snippet:

from doctest import OutputChecker, ELLIPSIS
print OutputChecker().check_output('AAA',
'AAA.BBB', ELLIPSIS)

I expect that to print True, but instead it prints False.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-06-19 08:20

Message:
Logged In: YES 
user_id=31435

Sorry, but this won't change.  As in most simple parsers, a
"maximal munch" rule is at work for recognizing
multi-character tokens:  your pattern gets parsed as

"AAA"  "."

not as

"AAA." 

or as

"AAA"

Therefore it matches all and only those strings that begin
with "AAA" and end with ".".

The maximal-munch rules gives an easy-to-predict way of
resolving ambiguous inputs, but you're stuck with the way it
 picks.  Because of this, there is no direct way to use
ELLIPSIS to get the effect I'm guessing you want (i.e., I'm
guessing you want it parsed as

"AAA." 

).

--

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

[ python-Bugs-1472251 ] pdb 'run' crashes when the it's first argument is non-string

2006-06-19 Thread SourceForge.net 
Bugs item #1472251, was opened at 2006-04-18 12:16
Message generated for change (Settings changed) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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: 3
Submitted By: Kuba Kończyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string

Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions: 

Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)

>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
return self.dispatch_line(frame)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
if self.quitting: raise BdbQuit
bdb.BdbQuit

The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.

--

>Comment By: Kuba Kończyk (jakamkon)
Date: 2006-06-19 13:48

Message:
Logged In: YES 
user_id=1491175

You're right,but don't you think that this kind of switching
between namespaces could confuse users?

--

Comment By: Ilya Sandler (isandler)
Date: 2006-05-23 03:36

Message:
Logged In: YES 
user_id=971153


Well, I don't see anything in bdb's run which could
overwrite your namespace..

What seems to be happenning in your example is that bdb's
first line event happens while bdb is still in run(), so you
when you see pdb's prompt, are in bdb's namespace not in
yours.. If you do "next" you will get where you should be..

 bagira:~> python2.4
 Python 2.4.1 (#2, May  5 2005, 11:32:06) 
 >>> def x(): print "in x"
 >>> import pdb
 >>> pdb.run( x())
 in x
 TypeError: unsupported operand type(s) for +: 'NoneType'
and 'str'
 >>> pdb.run( 'x()' )
 > /usr/lib/python2.4/pdb.py(987)run()
 -> Pdb().run(statement, globals, locals)
 (Pdb) n  #now you are back in your namespace
 > (1)?()
 (Pdb) p x#and you get your symbols back
 
 (Pdb) p pdb
 
 (Pdb) n
 in x
 --Return--
 > (1)?()->None


What do you think?

--

Comment By: Kuba Kończyk (jakamkon)
Date: 2006-05-22 09:20

Message:
Logged In: YES 
user_id=1491175

The point is that when you want to invoke pdb.run correctly
(with string argument) after getting TypeError as in above
example,
your namespace is probably overwritten or deleted so that
you don't have access to previously defined symbols.

>>> def x():pass
>>> import pdb
>>> pdb.run(x())
TypeError
>>> pdb.run('x()')
> /home/jkk/python-svn/Lib/pdb.py(1122)run()
-> Pdb().run(statement, globals, locals)
(Pdb) pdb
*** NameError: name 'pdb' is not defined
(Pdb) x
*** NameError: name 'x' is not defined


--

Comment By: Ilya Sandler (isandler)
Date: 2006-05-21 23:25

Message:
Logged In: YES 
user_id=971153


I would not classify your example as a crash. You passed a
wrong value (None in your case) into pdb.run() and got back
a TypeError...Isn't it an expected response?

E.g if you do:  >>>max(13)

You'll also get: "TypeError"


Am I missing something? Could you clarify?



--

Comment By: Kuba Kończyk (jakamkon)
Date: 2006-04-18 12:36

Message:
Logged In: YES 
user_id=1491175

Patch is in #1472257

--

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

[ python-Bugs-1508564 ] "...." (four dots) confuses doctest's ellipsis matching

2006-06-19 Thread SourceForge.net 
Bugs item #1508564, was opened at 2006-06-19 11:42
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508564&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: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: "" (four dots) confuses doctest's ellipsis matching

Initial Comment:
Consider this snippet:

from doctest import OutputChecker, ELLIPSIS
print OutputChecker().check_output('AAA',
'AAA.BBB', ELLIPSIS)

I expect that to print True, but instead it prints False.


--

Comment By: Tim Peters (tim_one)
Date: 2006-06-19 12:20

Message:
Logged In: YES 
user_id=31435

Sorry, but this won't change.  As in most simple parsers, a
"maximal munch" rule is at work for recognizing
multi-character tokens:  your pattern gets parsed as

"AAA"  "."

not as

"AAA." 

or as

"AAA"

Therefore it matches all and only those strings that begin
with "AAA" and end with ".".

The maximal-munch rules gives an easy-to-predict way of
resolving ambiguous inputs, but you're stuck with the way it
 picks.  Because of this, there is no direct way to use
ELLIPSIS to get the effect I'm guessing you want (i.e., I'm
guessing you want it parsed as

"AAA." 

).

--

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

[ python-Bugs-1508369 ] logging module formatter problem with %(filename)s

2006-06-19 Thread SourceForge.net 
Bugs item #1508369, was opened at 2006-06-19 02:08
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&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: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: David Hess (david_k_hess)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: logging module formatter problem with %(filename)s

Initial Comment:

With Python 2.4.3 installed via the .dmg on to MacOS, when the python 
modules are compiled, they are compiled by specifying the path in such a 
way that it contains a double slash. This causes the logging module to not 
be able to figure out which module is the correct one to replace for %
(filename)s.

The following is the crux of the issue:

>>> logging.debug.func_code.co_filename
'/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/
logging/__init__.py'
>>> logging.__file__
'/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/
logging/__init__.pyc'
>>> 

These two strings need to match for %(filename)s to work.

I deleted /Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/logging/__init__.pyc and recompiled it by just importing 
logging. That fixed the problem.

I assume the fix will be in the installer somewhere.



--

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

[ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation

2006-06-19 Thread SourceForge.net 
Bugs item #1501934, was opened at 2006-06-07 01:57
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&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.5
Status: Open
Resolution: None
Priority: 8
Submitted By: Thomas Wouters (twouters)
Assigned to: Jeremy Hylton (jhylton)
Summary: incorrect LOAD/STORE_GLOBAL generation

Initial Comment:
Python 2.5 compiles the following piece of code
differently than Python 2.4:

g = 1
def f():
g += 1

In Python 2.4, this raises an UnboundLocalError. In
current svn trunk, it will increment the global g by 1.
(dis.dis shows that it actually compiles into
LOAD/STORE_GLOBAL opcodes.) It seems the compiler
doesn't treat augmented assignment as assignment for
the purpose of determining locals, as this still fails
correctly:

g = 1
def f():
g += 1
g = 5

I can't find where this optimization happens nowadays,
but it feels like a short fix.


--

>Comment By: Thomas Wouters (twouters)
Date: 2006-06-19 19:44

Message:
Logged In: YES 
user_id=34209

Possibly related is the discovery of free variables (used
when forming closures) and optimized-out codeblocks:

>>> def foo(x):
... def bar():
... if 0:
... print x
... return bar

In 2.4, there is no closure:
>>> foo.func_code.co_cellvars
()
>>> foo(5).func_closure
>>>

In 2.5, there is:
>>> foo.func_code.co_cellvars
('x',)
>>> foo(5).func_closure
(,)

(I don't think it's unreasonable to declare the old
behaviour bugged, though :-)


--

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

[ python-Bugs-1508833 ] os.spawnv fails when argv is a length 1 tuple

2006-06-19 Thread SourceForge.net 
Bugs item #1508833, was opened at 2006-06-19 11:48
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=1508833&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ncloud (ncloud)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.spawnv fails when argv is a length 1 tuple

Initial Comment:
os.spawnv fails when argv is a length 1 tuple.


For example, this will fail:
os.spawnv (os.P_WAIT, '/bin/pwd', ('/bin/pwd'))


Bug exists on Python 2.4.3 on FreeBSD.
Bug exists on Python 2.3.5 on Gentoo Linux.


Longer example:

$ cat test.py
import os

path = '/bin/pwd'

print

print 'calling os.spawnv with length 1 tuple...'
print 'exit code:', os.spawnv ( os.P_WAIT, path, ( path ) )

print

print 'calling os.spawnv with length 1 list...'
print 'exit code:', os.spawnv ( os.P_WAIT, path, [ path ] )

print





$ python test.py

calling os.spawnv with length 1 tuple...
exit code: 127

calling os.spawnv with length 1 list...
/home/private
exit code: 0



--

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

[ python-Bugs-1508848 ] failed to load tuxedo libs

2006-06-19 Thread SourceForge.net 
Bugs item #1508848, was opened at 2006-06-19 19:20
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=1508848&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: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: William Ding (dingwen_ca)
Assigned to: Nobody/Anonymous (nobody)
Summary: failed to load tuxedo libs

Initial Comment:
we have a tuxedo(BEA) python extension, the extension 
works very well under solaris/AIX, it has issue with 
HPUX(PA-RISC or ITANINM)
with python 2.3.2 and 2.3.5

>>> import tuxedo
# /usr1/arbor/3p/terrapin/HPUX/python/modules/tuxedo.p
yc has bad mtime
import tuxedo # 
from /usr1/arbor/3p/terrapin/HPUX/python/modules/tuxed
o.py
# can't 
create /usr1/arbor/3p/terrapin/HPUX/python/modules/tux
edo.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/re.pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/re.py
import re # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/re.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.py
import sre # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_compile.
pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_co
mpile.py
import sre_compile # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_compi
le.pyc
import _sre # builtin
# /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_constant
s.pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_co
nstants.py
import sre_constants # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_const
ants.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_parse.py
c 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_pa
rse.py
import sre_parse # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_parse
.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/string.pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/string
.py
import string # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/string.py
c
shl_load /usr1/arbor/3ppython/HPUX/lib/python2.3/lib-
dynload/strop.so
shl_findsym initstrop
import strop # dynamically loaded 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/lib-
dynload/strop.so
shl_load _tuxedowsnmodule.so
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_strpresend' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_strencdec' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_sfilter' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_sformat' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_finit' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.


_tuxedowsnmodule.so is our python interface lib, 
from 'ldd -r' output, the lib itself should not have 
any issue,
but when we tried to load it to python, it complained,

bash-3.00$ ldd _tuxedowsnmodule.so
libwsc.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libwsc.sl
libbuft.sl 
=>   /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl
libgpnet.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl
libfml.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl
libfml32.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl
libengine.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl
libpthread.so.1 
=>  /usr/lib/hpux64/libpthread.so.1
libnsl.so.1 =>  /usr/lib/hpux64/libnsl.so.1
libm.so.1 =>/usr/lib/hpux64/libm.so.1
libc.so.1 =>/usr/lib/hpux64/libc.so.1
libbuft.sl 
=>   /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl
libgpnet.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl
libgiconv.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libgiconv.sl
libfml.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl
libfml32.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl
libengine.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl
libengine.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl
libengine.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl
libxti.so.1 =>  /usr/lib/hpux64/libxti.so.1
libdl.so.1 =>   /usr/lib/hpux64/libdl.so.1

bash-3.00$ ldd -r _tuxedowsnmodule.so
libwsc.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libwsc.sl
libbuft.sl 
=>   /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl
libgpnet.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl
libfml.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl
libfml32.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl
libengine.sl 
=> /usr1/arbor/3p/

[ python-Bugs-1508864 ] threading.Timer breaks when you change system time on win32

2006-06-19 Thread SourceForge.net 
Bugs item #1508864, was opened at 2006-06-19 14:53
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=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
Submitted By: Russell Warren (qopit)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Timer breaks when you change system time on win32

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.



--

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

[ python-Bugs-1508833 ] os.spawnv fails when argv is a length 1 tuple

2006-06-19 Thread SourceForge.net 
Bugs item #1508833, was opened at 2006-06-19 11:48
Message generated for change (Settings changed) made by ncloud
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508833&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: ncloud (ncloud)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.spawnv fails when argv is a length 1 tuple

Initial Comment:
os.spawnv fails when argv is a length 1 tuple.


For example, this will fail:
os.spawnv (os.P_WAIT, '/bin/pwd', ('/bin/pwd'))


Bug exists on Python 2.4.3 on FreeBSD.
Bug exists on Python 2.3.5 on Gentoo Linux.


Longer example:

$ cat test.py
import os

path = '/bin/pwd'

print

print 'calling os.spawnv with length 1 tuple...'
print 'exit code:', os.spawnv ( os.P_WAIT, path, ( path ) )

print

print 'calling os.spawnv with length 1 list...'
print 'exit code:', os.spawnv ( os.P_WAIT, path, [ path ] )

print





$ python test.py

calling os.spawnv with length 1 tuple...
exit code: 127

calling os.spawnv with length 1 list...
/home/private
exit code: 0



--

>Comment By: ncloud (ncloud)
Date: 2006-06-19 13:00

Message:
Logged In: YES 
user_id=1542556

My apologies.  I'm new to python and had not realize that

( x )

is not a tuple, while

( x, ) 

is a tuple.

--

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

[ python-Bugs-1508833 ] os.spawnv fails when argv is a length 1 tuple

2006-06-19 Thread SourceForge.net 
Bugs item #1508833, was opened at 2006-06-19 18:48
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508833&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: Invalid
Priority: 5
Submitted By: ncloud (ncloud)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.spawnv fails when argv is a length 1 tuple

Initial Comment:
os.spawnv fails when argv is a length 1 tuple.


For example, this will fail:
os.spawnv (os.P_WAIT, '/bin/pwd', ('/bin/pwd'))


Bug exists on Python 2.4.3 on FreeBSD.
Bug exists on Python 2.3.5 on Gentoo Linux.


Longer example:

$ cat test.py
import os

path = '/bin/pwd'

print

print 'calling os.spawnv with length 1 tuple...'
print 'exit code:', os.spawnv ( os.P_WAIT, path, ( path ) )

print

print 'calling os.spawnv with length 1 list...'
print 'exit code:', os.spawnv ( os.P_WAIT, path, [ path ] )

print





$ python test.py

calling os.spawnv with length 1 tuple...
exit code: 127

calling os.spawnv with length 1 list...
/home/private
exit code: 0



--

Comment By: ncloud (ncloud)
Date: 2006-06-19 20:00

Message:
Logged In: YES 
user_id=1542556

My apologies.  I'm new to python and had not realize that

( x )

is not a tuple, while

( x, ) 

is a tuple.

--

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

[ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat

2006-06-19 Thread SourceForge.net 
Bugs item #1295808, was opened at 2005-09-19 21:44
Message generated for change (Comment added) made by tmick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Trent Mick (tmick)
Assigned to: Martin v. Löwis (loewis)
Summary: expat symbols should be namespaced in pyexpat

Initial Comment:
The Problem:
- you embed Python in some app
- the app dynamically loads libexpat of version X
- the embedded Python imports pyexpat (which was built
against
  libexpat version X+n)
--> pyexpat gets the expat symbols from the already
loaded and *older*
libexpat: crash (Specifically the crash we observed
was in
getting an old XML_ErrorString (from xmlparse.c)
and then calling
it with newer values in the XML_Error enum:

  // pyexpat.c, line 1970
  ...
  // Added in Expat 1.95.7.
  MYCONST(XML_ERROR_UNBOUND_PREFIX);
  ...


The Solution:
Prefix all a exported symbols with "PyExpat_". This is
similar to
what Mozilla does for some common libs:
http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115


I'll attach the gdb backtrace that we were getting and
a patch.

--

>Comment By: Trent Mick (tmick)
Date: 2006-06-19 23:59

Message:
Logged In: YES 
user_id=34892

SendingModules/expat/expat_external.h
Adding Modules/expat/pyexpatns.h
Transmitting file data ..
Committed revision 47034.


I upgraded Python's expat to 2.0.0 immediately before and
checked that no new symbols where added (i.e. no new
#define's necessary for the patch).

--

Comment By: Trent Mick (tmick)
Date: 2006-03-19 00:25

Message:
Logged In: YES 
user_id=34892

As well, *possibly* the same should be done for Python's
bz2.so, although the only relevant exported symbol is
Util_UnivNewlineRead

  nm bz2.so \
| grep -v " [a-zBUA] " \
| grep -v "_fini\|_init\|initbz2"



--

Comment By: Trent Mick (tmick)
Date: 2006-03-18 23:58

Message:
Logged In: YES 
user_id=34892

Attempted summary to get this patch into Python 2.5:

As Neal points out this is a duplicate of
. The patch on *that* bug
fixes the specific issue, but does not solve the general
problem (as  'mwh' pointed out in the comments there).

I think we should 
1. apply this patch
2. then perhaps update our expat version (see
http://python.org/sf/1433435,
http://mail.python.org/pipermail/python-dev/2006-March/062287.html),
3. then update Modules/expat/pyexpatns.h (that this patch
adds) for any new symbols in the new version of Expat.

Neal, Martin, Michael, what do you think?


--

Comment By: Trent Mick (tmick)
Date: 2006-01-24 23:34

Message:
Logged In: YES 
user_id=34892

> This seems to be a duplicate of bug #1075984. 

You are right.

> Trent, is this patch sufficient to meet your embedding
> needs so that nothing else needs to be done?

Yes.

> I do not think this patch can be applied to 2.4.

That's fine. Getting this into Python >=2.5 would be good
enough.

Martin,
Have you had a chance to review this?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:01

Message:
Logged In: YES 
user_id=33168

This seems to be a duplicate of bug #1075984.  I like this
patch better, but perhaps both patches (the one here and the
other bug report) should be implemented?

I think Martin helps maintain pyexpat.  Maybe he has some
ideas about either or both of these bugs/patches.  Martin,
do you think these are safe to apply?  I can apply the
patch(es) if you think it's safe.

Trent, is this patch sufficient to meet your embedding needs
so that nothing else needs to be done?

I do not think this patch can be applied to 2.4.

--

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

[ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat

2006-06-19 Thread SourceForge.net 
Bugs item #1295808, was opened at 2005-09-19 21:44
Message generated for change (Settings changed) made by tmick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&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: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Trent Mick (tmick)
>Assigned to: Trent Mick (tmick)
Summary: expat symbols should be namespaced in pyexpat

Initial Comment:
The Problem:
- you embed Python in some app
- the app dynamically loads libexpat of version X
- the embedded Python imports pyexpat (which was built
against
  libexpat version X+n)
--> pyexpat gets the expat symbols from the already
loaded and *older*
libexpat: crash (Specifically the crash we observed
was in
getting an old XML_ErrorString (from xmlparse.c)
and then calling
it with newer values in the XML_Error enum:

  // pyexpat.c, line 1970
  ...
  // Added in Expat 1.95.7.
  MYCONST(XML_ERROR_UNBOUND_PREFIX);
  ...


The Solution:
Prefix all a exported symbols with "PyExpat_". This is
similar to
what Mozilla does for some common libs:
http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115


I'll attach the gdb backtrace that we were getting and
a patch.

--

Comment By: Trent Mick (tmick)
Date: 2006-06-19 23:59

Message:
Logged In: YES 
user_id=34892

SendingModules/expat/expat_external.h
Adding Modules/expat/pyexpatns.h
Transmitting file data ..
Committed revision 47034.


I upgraded Python's expat to 2.0.0 immediately before and
checked that no new symbols where added (i.e. no new
#define's necessary for the patch).

--

Comment By: Trent Mick (tmick)
Date: 2006-03-19 00:25

Message:
Logged In: YES 
user_id=34892

As well, *possibly* the same should be done for Python's
bz2.so, although the only relevant exported symbol is
Util_UnivNewlineRead

  nm bz2.so \
| grep -v " [a-zBUA] " \
| grep -v "_fini\|_init\|initbz2"



--

Comment By: Trent Mick (tmick)
Date: 2006-03-18 23:58

Message:
Logged In: YES 
user_id=34892

Attempted summary to get this patch into Python 2.5:

As Neal points out this is a duplicate of
. The patch on *that* bug
fixes the specific issue, but does not solve the general
problem (as  'mwh' pointed out in the comments there).

I think we should 
1. apply this patch
2. then perhaps update our expat version (see
http://python.org/sf/1433435,
http://mail.python.org/pipermail/python-dev/2006-March/062287.html),
3. then update Modules/expat/pyexpatns.h (that this patch
adds) for any new symbols in the new version of Expat.

Neal, Martin, Michael, what do you think?


--

Comment By: Trent Mick (tmick)
Date: 2006-01-24 23:34

Message:
Logged In: YES 
user_id=34892

> This seems to be a duplicate of bug #1075984. 

You are right.

> Trent, is this patch sufficient to meet your embedding
> needs so that nothing else needs to be done?

Yes.

> I do not think this patch can be applied to 2.4.

That's fine. Getting this into Python >=2.5 would be good
enough.

Martin,
Have you had a chance to review this?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:01

Message:
Logged In: YES 
user_id=33168

This seems to be a duplicate of bug #1075984.  I like this
patch better, but perhaps both patches (the one here and the
other bug report) should be implemented?

I think Martin helps maintain pyexpat.  Maybe he has some
ideas about either or both of these bugs/patches.  Martin,
do you think these are safe to apply?  I can apply the
patch(es) if you think it's safe.

Trent, is this patch sufficient to meet your embedding needs
so that nothing else needs to be done?

I do not think this patch can be applied to 2.4.

--

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

[ python-Feature Requests-1509060 ] Interrupt/kill threads w/exception

2006-06-19 Thread SourceForge.net 
Feature Requests item #1509060, was opened at 2006-06-20 04:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509060&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: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Oliver Bock (oliverbock)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interrupt/kill threads w/exception

Initial Comment:
When unsophisticated (but not evil) users write Python
macros, they occasionally write infinite loops.  It
would be nice if it was possible to interrupt threads
to break these loops.  The safety of rasing an
exception in another thread was noted in

http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470

Anton Wilson wrote a patch for this some time ago:

http://mail.python.org/pipermail/python-list/2003-February/148999.html

Note that this won't help if the thread is blocked on I/O.

--

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

[ python-Bugs-1508848 ] failed to load tuxedo libs

2006-06-19 Thread SourceForge.net 
Bugs item #1508848, was opened at 2006-06-19 12:20
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508848&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: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: William Ding (dingwen_ca)
Assigned to: Nobody/Anonymous (nobody)
Summary: failed to load tuxedo libs

Initial Comment:
we have a tuxedo(BEA) python extension, the extension 
works very well under solaris/AIX, it has issue with 
HPUX(PA-RISC or ITANINM)
with python 2.3.2 and 2.3.5

>>> import tuxedo
# /usr1/arbor/3p/terrapin/HPUX/python/modules/tuxedo.p
yc has bad mtime
import tuxedo # 
from /usr1/arbor/3p/terrapin/HPUX/python/modules/tuxed
o.py
# can't 
create /usr1/arbor/3p/terrapin/HPUX/python/modules/tux
edo.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/re.pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/re.py
import re # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/re.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.py
import sre # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_compile.
pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_co
mpile.py
import sre_compile # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_compi
le.pyc
import _sre # builtin
# /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_constant
s.pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_co
nstants.py
import sre_constants # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_const
ants.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_parse.py
c 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_pa
rse.py
import sre_parse # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_parse
.pyc
# /usr1/arbor/3ppython/HPUX/lib/python2.3/string.pyc 
matches /usr1/arbor/3ppython/HPUX/lib/python2.3/string
.py
import string # precompiled 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/string.py
c
shl_load /usr1/arbor/3ppython/HPUX/lib/python2.3/lib-
dynload/strop.so
shl_findsym initstrop
import strop # dynamically loaded 
from /usr1/arbor/3ppython/HPUX/lib/python2.3/lib-
dynload/strop.so
shl_load _tuxedowsnmodule.so
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_strpresend' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_strencdec' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_sfilter' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_sformat' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.
/usr/lib/hpux64/dld.so: Unsatisfied code 
symbol '_finit' in load 
module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'.


_tuxedowsnmodule.so is our python interface lib, 
from 'ldd -r' output, the lib itself should not have 
any issue,
but when we tried to load it to python, it complained,

bash-3.00$ ldd _tuxedowsnmodule.so
libwsc.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libwsc.sl
libbuft.sl 
=>   /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl
libgpnet.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl
libfml.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl
libfml32.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl
libengine.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl
libpthread.so.1 
=>  /usr/lib/hpux64/libpthread.so.1
libnsl.so.1 =>  /usr/lib/hpux64/libnsl.so.1
libm.so.1 =>/usr/lib/hpux64/libm.so.1
libc.so.1 =>/usr/lib/hpux64/libc.so.1
libbuft.sl 
=>   /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl
libgpnet.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl
libgiconv.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libgiconv.sl
libfml.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl
libfml32.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl
libengine.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl
libengine.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl
libengine.sl 
=> /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl
libxti.so.1 =>  /usr/lib/hpux64/libxti.so.1
libdl.so.1 =>   /usr/lib/hpux64/libdl.so.1

bash-3.00$ ldd -r _tuxedowsnmodule.so
libwsc.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libwsc.sl
libbuft.sl 
=>   /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl
libgpnet.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl
libfml.sl 
=>/usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl
libfml32.sl 
=>  /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl
libengine.sl 
=> /usr1/arbor/3p/t

[ python-Feature Requests-1433435 ] Use new expat version 2.0

2006-06-19 Thread SourceForge.net 
Feature Requests item #1433435, was opened at 2006-02-17 09:16
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&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: XML
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Wolfgang Langner (tds33)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use new expat version 2.0

Initial Comment:
New expat version 2.0 is released. This one schould be
used in the next python release (2.5).

I checked the repository and feature request and there
is no note about usage of new expat versions.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-20 06:25

Message:
Logged In: YES 
user_id=849994

The patch was applied in rev. 47033.

--

Comment By: Žiga Seilnacht (zseil)
Date: 2006-04-07 13:26

Message:
Logged In: YES 
user_id=1326842

There is a patch now:
#1462338 upgrade pyexpat to expat 2.0.0
http://www.python.org/sf/1462338

--

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