From noreply at sourceforge.net  Tue Mar  1 05:36:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 05:36:16 2005
Subject: [ python-Bugs-1153163 ] reflected operator not used when operands
	have the same type
Message-ID: <E1D5z7F-00078c-Oy@sc8-sf-web3.sourceforge.net>

Bugs item #1153163, was opened at 2005-02-27 20:09
Message generated for change (Comment added) made by hughsw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Hugh Secker-Walker (hughsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: reflected operator not used when operands have the same type

Initial Comment:

The reflected operators, e.g. __radd__, are used when
the left operand does not have the non-reflected
operator, *unless* the right operand is of the same type.

The documentation on the "Emulating numeric types" page
doesn't mention this peculiar exclusion.  Of the
reflected operators it says:
"These methods are called to implement the binary
arithmetic operations (+, -, *, /, %, divmod(), pow(),
**, <<, >>, &, ^, |) with reflected (swapped) operands.
These functions are only called if the left operand
does not support the corresponding operation. For
instance, to evaluate the expression x-y, where y is an
instance of a class that has an __rsub__() method,
y.__rsub__(x) is called."

This code demonstrates the correct behavior and then
the problem:

class A(object):
    def __radd__(self, other):
        return '__radd__', other

print None + A()
print A() + A()

giving....

('__radd__', None)

Traceback (most recent call last):
  File "C:/Temp/reflectedbug.py", line 6, in -toplevel-
    print A() + A()
TypeError: unsupported operand type(s) for +: 'A' and 'A'

I've replaced None in the first print statement with
many kinds of builtin objects, instances of other
classes, and with instances of subclasses of A.  In all
these cases the __radd__ operator is used as
documented.  I've only seen the problem when the two
operands are of the same type.

This problem also occurs during the backing-off to
plain operators that occurs when augmented operators,
e.g. __iadd__, aren't implemented by the type and the
operands are of the same type.

This problem is present in 2.4 on Linux and Windows,
and in the current CVS version (2.5a0, 27-Feb-05) on Linux.


----------------------------------------------------------------------

>Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 23:36

Message:
Logged In: YES 
user_id=1146279

The problem is in the SLOT1BINFULL() macro near line 4020 in
typeobject.c.  In two places it ensures that the reflected
(reversed, swapped, rop<blah>, you name it) operator won't
be called if the two operands are of the same type. 
Removing these two exclusions fixes the problem.  

However, this being my third day ever modifying Python
source code, for all intents and purposes, I have no idea
why the exclusions were there (efficiency?).  And,
elsewhere, I saw high-level code that had a similar check on
operands having the same type with a comment that talked
about avoiding an infinite loop that could happen if there's
coercion and other subtly involved....

FWIW, with the changes I made, 256 tests are OK and 35 tests
are skipped -- as is usual on my Linux system.

I can post a trivial patch and figure out how to add a
regression test, but expert analysis is needed.

Also, the code in this macro (and perhaps helped by
abstract.c) implements curious and
not-documented-on-the-Emulating-numeric-types-page
semantics: if the operand on the right is a subtype of the
operand on the left and if  the right operand overloads the
reflected operator, then the reflected operator will be
called, even if the left-hand operand implements the regular
operator!  This is either a bug or it should be documented,
preferably with some rationale. E.g.

class A(object):
    def __add__(self, other):
        return 'A.__add__', other
class B(A):
    def __radd__(self, other):
        return 'B.__radd__', other

>>> B()+A()
('A.__add__', <__main__.A object at 0x00B65A30>)
>>> B()+B()
('A.__add__', <__main__.B object at 0x00B836F0>)
>>> 1+B()
('B.__radd__', 1)
>>> A()+B()
('B.__radd__', <__main__.A object at 0x00B65A30>)

Where the last one is what's curious or a bug.

-Hugh


----------------------------------------------------------------------

Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 01:09

Message:
Logged In: YES 
user_id=1146279

I've looked into this a little.  Newbie that I am, I don't
know where the 
 x = slotw(v, w);
call goes (in binary_op1() in abstract.c near line 377)....
 AFAICT, this code in abstract.c behaves reasonably, so
problem would seem to be in the tp_as_number slot-function
that's getting called.  And whereever that is, it's not the
binary-op functions in classobject.c that I thought it would
be....


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 06:08:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 06:08:11 2005
Subject: [ python-Bugs-1153163 ] reflected operator not used when operands
	have the same type
Message-ID: <E1D5zc8-00050N-O1@sc8-sf-web2.sourceforge.net>

Bugs item #1153163, was opened at 2005-02-27 20:09
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Hugh Secker-Walker (hughsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: reflected operator not used when operands have the same type

Initial Comment:

The reflected operators, e.g. __radd__, are used when
the left operand does not have the non-reflected
operator, *unless* the right operand is of the same type.

The documentation on the "Emulating numeric types" page
doesn't mention this peculiar exclusion.  Of the
reflected operators it says:
"These methods are called to implement the binary
arithmetic operations (+, -, *, /, %, divmod(), pow(),
**, <<, >>, &, ^, |) with reflected (swapped) operands.
These functions are only called if the left operand
does not support the corresponding operation. For
instance, to evaluate the expression x-y, where y is an
instance of a class that has an __rsub__() method,
y.__rsub__(x) is called."

This code demonstrates the correct behavior and then
the problem:

class A(object):
    def __radd__(self, other):
        return '__radd__', other

print None + A()
print A() + A()

giving....

('__radd__', None)

Traceback (most recent call last):
  File "C:/Temp/reflectedbug.py", line 6, in -toplevel-
    print A() + A()
TypeError: unsupported operand type(s) for +: 'A' and 'A'

I've replaced None in the first print statement with
many kinds of builtin objects, instances of other
classes, and with instances of subclasses of A.  In all
these cases the __radd__ operator is used as
documented.  I've only seen the problem when the two
operands are of the same type.

This problem also occurs during the backing-off to
plain operators that occurs when augmented operators,
e.g. __iadd__, aren't implemented by the type and the
operands are of the same type.

This problem is present in 2.4 on Linux and Windows,
and in the current CVS version (2.5a0, 27-Feb-05) on Linux.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:08

Message:
Logged In: YES 
user_id=593130

I believe Python's designer(s) intend that if A()+A() is valid, then 
A will have an __add__ method.  __rxxx__ is only intended for 
backup use with mixed types.  So your example sends a mixed 
message to the interpreter.

If the current behavior is both intended and still necessary, the 
manual sentence
"These functions are only called if the left operand
does not support the corresponding operation"
could be augmented with 
"and has a different type than the right operand"


----------------------------------------------------------------------

Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 23:36

Message:
Logged In: YES 
user_id=1146279

The problem is in the SLOT1BINFULL() macro near line 4020 in
typeobject.c.  In two places it ensures that the reflected
(reversed, swapped, rop<blah>, you name it) operator won't
be called if the two operands are of the same type. 
Removing these two exclusions fixes the problem.  

However, this being my third day ever modifying Python
source code, for all intents and purposes, I have no idea
why the exclusions were there (efficiency?).  And,
elsewhere, I saw high-level code that had a similar check on
operands having the same type with a comment that talked
about avoiding an infinite loop that could happen if there's
coercion and other subtly involved....

FWIW, with the changes I made, 256 tests are OK and 35 tests
are skipped -- as is usual on my Linux system.

I can post a trivial patch and figure out how to add a
regression test, but expert analysis is needed.

Also, the code in this macro (and perhaps helped by
abstract.c) implements curious and
not-documented-on-the-Emulating-numeric-types-page
semantics: if the operand on the right is a subtype of the
operand on the left and if  the right operand overloads the
reflected operator, then the reflected operator will be
called, even if the left-hand operand implements the regular
operator!  This is either a bug or it should be documented,
preferably with some rationale. E.g.

class A(object):
    def __add__(self, other):
        return 'A.__add__', other
class B(A):
    def __radd__(self, other):
        return 'B.__radd__', other

>>> B()+A()
('A.__add__', <__main__.A object at 0x00B65A30>)
>>> B()+B()
('A.__add__', <__main__.B object at 0x00B836F0>)
>>> 1+B()
('B.__radd__', 1)
>>> A()+B()
('B.__radd__', <__main__.A object at 0x00B65A30>)

Where the last one is what's curious or a bug.

-Hugh


----------------------------------------------------------------------

Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 01:09

Message:
Logged In: YES 
user_id=1146279

I've looked into this a little.  Newbie that I am, I don't
know where the 
 x = slotw(v, w);
call goes (in binary_op1() in abstract.c near line 377)....
 AFAICT, this code in abstract.c behaves reasonably, so
problem would seem to be in the tp_as_number slot-function
that's getting called.  And whereever that is, it's not the
binary-op functions in classobject.c that I thought it would
be....


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 06:30:43 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 06:30:47 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D5zxz-0000Ly-Fc@sc8-sf-web4.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 11:48
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 07:36:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 07:36:46 2005
Subject: [ python-Bugs-1153226 ] string interpolation breaks with %d and
	large float
Message-ID: <E1D60zp-0007qg-Ba@sc8-sf-web1.sourceforge.net>

Bugs item #1153226, was opened at 2005-02-27 21:10
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: string interpolation breaks with %d and large float

Initial Comment:
We have experienced a problem recently when wanting to
render a large float as a string. Converting the float
to an int/long manuall was required. 

'%d' % f
throws an exception for all floats f, f >= 2**31

Expected output, shown with 'int()' and 'long()':
>>> '%d %d' % (long(float(2**31)), int(float(2**31)))
'2147483648 2147483648'

Non-Working Example.
>>> '%d' % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

Tested on:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40) 
Python 2.4.1a0 (#2, Feb  9 2005, 22:42:24)

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-02-28 22:36

Message:
Logged In: YES 
user_id=341410

Note that it will also raise a TypeError when the float f, f
< -2**31

Is this a bug?  I don't know.  I tend to not pass floats
when string interpolation is expecting integers.  Maybe the
documentation should be cleared up.

If you really want a truncated float, perhaps "%.0f" is the
format you are looking for, to save you the effort of using
int() or long().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 09:40:33 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 09:40:38 2005
Subject: [ python-Bugs-1149804 ] macostools.mkdirs: not thread-safe
Message-ID: <E1D62vh-0007Ve-Q0@sc8-sf-web3.sourceforge.net>

Bugs item #1149804, was opened at 2005-02-23 14:26
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149804&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
Assigned to: Jack Jansen (jackjansen)
Summary: macostools.mkdirs: not thread-safe

Initial Comment:
Here is an easily fixable semi-bug in macostools:
When two threads are creating the same directory structure, one 
of them will fail as soon as the other thread made a directory.
This is trivially fixable by ignoring the error, but I'm not sure if it is 
worth it, like this:

def mkdirs(dst):
    """Make directories leading to 'dst' if they don't exist yet"""
    if dst == '' or os.path.exists(dst):
        return
    head, tail = os.path.split(dst)
    if os.sep == ':' and not ':' in head:
        head = head + ':'
    mkdirs(head)
    try: os.mkdir(dst, 0777)
    except OSError, err:
	if err.errno==17: #file exists
		#someone else has created the directory in the 
meantime. That's fine with me!
		pass
	else: raise
- Jurjen

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2005-03-01 09:40

Message:
Logged In: YES 
user_id=92689

Hm, macostools.mkdirs() also isn't portable: it only works on OS9 
MacPython. Why don't you use os.makedirs() instead? (Which appears to 
have the same threads issue, though.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149804&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 09:49:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 09:49:52 2005
Subject: [ python-Bugs-1149804 ] macostools.mkdirs: not thread-safe
Message-ID: <E1D634f-0005Qm-Ak@sc8-sf-web1.sourceforge.net>

Bugs item #1149804, was opened at 2005-02-23 14:26
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149804&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
Assigned to: Jack Jansen (jackjansen)
Summary: macostools.mkdirs: not thread-safe

Initial Comment:
Here is an easily fixable semi-bug in macostools:
When two threads are creating the same directory structure, one 
of them will fail as soon as the other thread made a directory.
This is trivially fixable by ignoring the error, but I'm not sure if it is 
worth it, like this:

def mkdirs(dst):
    """Make directories leading to 'dst' if they don't exist yet"""
    if dst == '' or os.path.exists(dst):
        return
    head, tail = os.path.split(dst)
    if os.sep == ':' and not ':' in head:
        head = head + ':'
    mkdirs(head)
    try: os.mkdir(dst, 0777)
    except OSError, err:
	if err.errno==17: #file exists
		#someone else has created the directory in the 
meantime. That's fine with me!
		pass
	else: raise
- Jurjen

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2005-03-01 09:49

Message:
Logged In: YES 
user_id=92689

Oops, disregard that portability remark, it does work correctly in non-OS9 
Python as well. I _think_ macostools.mkdirs() predates os.makedirs(), it's 
probably best considered deprecated.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2005-03-01 09:40

Message:
Logged In: YES 
user_id=92689

Hm, macostools.mkdirs() also isn't portable: it only works on OS9 
MacPython. Why don't you use os.makedirs() instead? (Which appears to 
have the same threads issue, though.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149804&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 10:11:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 10:11:08 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D63PE-0000Id-4z@sc8-sf-web4.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 17:48
Message generated for change (Comment added) made by yorick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

>Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 10:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 06:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 12:59:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 12:59:09 2005
Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault,
	EXAMPLE ATTACHED
Message-ID: <E1D661n-0006TG-Fb@sc8-sf-web2.sourceforge.net>

Bugs item #1120452, was opened at 2005-02-11 01:04
Message generated for change (Comment added) made by amauryf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470

Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED

Initial Comment:
Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org

This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug.

This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly.

Thanks for 2.4.1.

----------------------------------------------------------------------

Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2005-03-01 12:59

Message:
Logged In: YES 
user_id=389140

I can reliably reproduce the problem on w2k using 2.4.0,
debug build under Purify.
Here is the testcase (using the files in the attached example):
>>> import re,PyMeld
>>> s=file("player.html").read()
>>> print re.search(PyMeld.openIDTagRE,s)

Applying the patch for bug #1072259 (_sre.c 2.110) causes
the bug to disappear, and Purify does not complain.
I suggest to consider this as a duplicate for bug #1072259

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-02-24 04:24

Message:
Logged In: YES 
user_id=149084

The IDLE subprocess does different things with memory
because it's threaded, with one thread minding the sockets
and the other executing user code.  So I'd stay away from
IDLE when working on this.  (Also, the debug traces are
excessively complex.)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2005-02-24 01:32

Message:
Logged In: YES 
user_id=35752

I can reproduce the crash on my machine if I revert the
patch for bug #1072259 (_sre.c 2.110).  Here's what gdb says:
0x0810342a in sre_match (state=0xbfffca80, pattern=0x81bfbf2)
    at ../Modules/_sre.c:854
854                         state->mark[j++] = NULL;
(gdb) p j
$7 = -1209149847
(gdb) p &(state->mark)
$8 = (void *(*)[200]) 0xbfffcaa8
(gdb) p &j
$9 = (int *) 0xbfffc9c0

Either the bug has been fixed or _sre has been changed
enough that the test no longer triggers a crash.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-02-23 00:58

Message:
Logged In: YES 
user_id=764593

It probably is a memory scribble bug, though it might not be in 
re.  For instance, the __getattr__ and __setattr__ try to do 
some shortcuts saving position, and they may cause the out-
of-bounds.

The crashes are very dependent on order.

I wasn't kidding when I said it ran fine and printed None if run 
as a whole, but crashed when the same lines were input one 
by one.  (Which gave idle a chance to do different things with 
memory in between, and didn't define a function object.)  

Also note that the second attribute access (even to a 
previously OK attribute) could cause a crash, unless it had 
had a chance to clear things up first -- but then it raised a 
MemoryError, when I almost certainly wasn't yet out of RAM.


----------------------------------------------------------------------

Comment By: Viktor Ferenczi (complex)
Date: 2005-02-22 16:19

Message:
Logged In: YES 
user_id=142612

Some additional information and summary:

My machine is a 3.0Hz Intel P4 with 1Gbyte memory, without
overclocking. I use 2 antivirus (1 active) and 3 antispyware
apps + firewall. The memory has been tested for 6 hours with
Knoppix's memtest without any error, so my machine can be
considered to be stable.

The attached script can crash python 2.4.0 at least for me
and jumjjewett. Do not run the script from IDLE, since it
can hide the segfault. I usually run my scripts from SciTE
(see: www.scintilla.org ).

The bug can be reproduced on stock Python 2.4.0 (MSI
installer). PyMeld is pure python (uses only the standard
library), no C extension modules used. I did not test this
bug with the latest CVS versions of Python 2.4. Is produces
segfault under Linux.

I'll try to narrow down this bug for specific regex patterns.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-22 15:51

Message:
Logged In: YES 
user_id=6656

Well, I still can't make it crash.  Can one of you provide a crashing driver 
script?  Better still would be finding which regexp and which input is the 
problem.

(Unless it's a memory-scribble random crasher type bug...)

----------------------------------------------------------------------

Comment By: Viktor Ferenczi (complex)
Date: 2005-02-22 14:07

Message:
Logged In: YES 
user_id=142612

This bug is a segfault, a real crash using only the stock 2.4.0. It has been reproduced correctly by jimjjewett. It seems to be a regexp related bug. I've changed the category to pass this bug to a regexp expert. Thanks for any help. - Complex

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-02-20 02:56

Message:
Logged In: YES 
user_id=149084

The restart in IDLE will occur if the subprocess is terminated or
segfaults.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-02-11 20:55

Message:
Logged In: YES 
user_id=764593

__gettattr__ alone can provoke the crash, if used several 
times, and on sub-melds.

I can print both StreamURL1 and StreamURL2.

If I ask it for p.StreamURL2.src and p.StreamURL1.value, 
it prints whichever one I ask for first, and then crashes on 
the second.  I did get it to print both (not assign, just 
__getattr__) by first getting several other attributes from 
p.StreamURL1, including some that didn't exist, so that 
there was a raise AttributeError in between.  Doing this a 
half dozen times, I provoked a MemoryError.

"""
>>> p.StreamURL1.value
'mss://stream.url'
>>> p.StreamURL2.src

Traceback (most recent call last):
  File "<pyshell#68>", line 1, in -toplevel-
    p.StreamURL2.src
  File "C:\Python24\Lib\site-packages\segfault240\PyMeld.
py", line 475, in __getattr__
    start = self._findElementFromID(name)
  File "C:\Python24\Lib\site-packages\segfault240\PyMeld.
py", line 425, in _findElementFromID
    match = _findIDMatch(nodeID, subset)
  File "C:\Python24\Lib\site-packages\segfault240\PyMeld.
py", line 282, in _findIDMatch
    match = re.search(thisRE, text)
  File "C:\Python24\lib\sre.py", line 134, in search
    return _compile(pattern, flags).search(string)
MemoryError
>>> 
"""



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-02-11 20:36

Message:
Logged In: YES 
user_id=764593

Partially reproduced on Windows XP.  (Using the stock 2.4.
0 msi)  

Just loading it in IDLE and hitting F5 (run), it prints None, 
as though it had succeeded perfectly.

Typing in the commands from index.py by hand, I can get 
it to give me the "encountered an error;  Tell Microsoft?" 
box, but IDLE only restarts instead of actually crashing.

There seems to a problem between the __getattr__ and 
the __setattr__ in PyMeld.  

"""
>>> p=Meld(open('player.html','rb').read())
>>> p.StreamURL1.value
'mss://stream.url'
>>> p.StreamURL2
<PyMeld.Meld instance at 0x00B455F8>
>>> p.StreamURL2.src
'mms://stream.url'

>>> v=Video()
>>> v.stream
's'
>>> p.StreamURL1.value=v.stream
>>> p.StreamURL1.value

>>> ================================ 
RESTART 
================================
>>> 
"""


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-11 15:57

Message:
Logged In: YES 
user_id=6656

What do you do to make it crash?  "python index.py"?

It doesn't fail for me with CVS HEAD.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 14:21:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 14:21:29 2005
Subject: [ python-Bugs-1153226 ] string interpolation breaks with %d and
	large float
Message-ID: <E1D67JW-0004Uq-R8@sc8-sf-web1.sourceforge.net>

Bugs item #1153226, was opened at 2005-02-28 15:10
Message generated for change (Comment added) made by jerub
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: string interpolation breaks with %d and large float

Initial Comment:
We have experienced a problem recently when wanting to
render a large float as a string. Converting the float
to an int/long manuall was required. 

'%d' % f
throws an exception for all floats f, f >= 2**31

Expected output, shown with 'int()' and 'long()':
>>> '%d %d' % (long(float(2**31)), int(float(2**31)))
'2147483648 2147483648'

Non-Working Example.
>>> '%d' % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

Tested on:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40) 
Python 2.4.1a0 (#2, Feb  9 2005, 22:42:24)

----------------------------------------------------------------------

>Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 23:21

Message:
Logged In: YES 
user_id=100823

My immediate reaction is, yes. This is a bug. 

Either floats should work with %d, or they should not at
all. Having a platform dependant upper bound on the size of
the float allowed is a bug.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-03-01 16:36

Message:
Logged In: YES 
user_id=341410

Note that it will also raise a TypeError when the float f, f
< -2**31

Is this a bug?  I don't know.  I tend to not pass floats
when string interpolation is expecting integers.  Maybe the
documentation should be cleared up.

If you really want a truncated float, perhaps "%.0f" is the
format you are looking for, to save you the effort of using
int() or long().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 16:38:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 16:38:14 2005
Subject: [ python-Bugs-1153226 ] string interpolation breaks with %d and
	large float
Message-ID: <E1D69Rr-00063w-7l@sc8-sf-web4.sourceforge.net>

Bugs item #1153226, was opened at 2005-02-27 23:10
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: string interpolation breaks with %d and large float

Initial Comment:
We have experienced a problem recently when wanting to
render a large float as a string. Converting the float
to an int/long manuall was required. 

'%d' % f
throws an exception for all floats f, f >= 2**31

Expected output, shown with 'int()' and 'long()':
>>> '%d %d' % (long(float(2**31)), int(float(2**31)))
'2147483648 2147483648'

Non-Working Example.
>>> '%d' % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

Tested on:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40) 
Python 2.4.1a0 (#2, Feb  9 2005, 22:42:24)

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2005-03-01 09:38

Message:
Logged In: YES 
user_id=44345

This is probably a corner case that got missed in the
int/long convergence.  Still, is there a reason not to use
%.f when you know you are passing a float and want to
display it with no fractional component?

>>> '%.f' % 2**50 
'1125899906842624'

or %ld if you expect the range to exceed the integer limits of
your hardware?

>>> '%ld' % 2**50
'1125899906842624'

I agree the documentation could probably be improved
in this area.


----------------------------------------------------------------------

Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 07:21

Message:
Logged In: YES 
user_id=100823

My immediate reaction is, yes. This is a bug. 

Either floats should work with %d, or they should not at
all. Having a platform dependant upper bound on the size of
the float allowed is a bug.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-03-01 00:36

Message:
Logged In: YES 
user_id=341410

Note that it will also raise a TypeError when the float f, f
< -2**31

Is this a bug?  I don't know.  I tend to not pass floats
when string interpolation is expecting integers.  Maybe the
documentation should be cleared up.

If you really want a truncated float, perhaps "%.0f" is the
format you are looking for, to save you the effort of using
int() or long().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 17:26:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 17:26:04 2005
Subject: [ python-Feature Requests-1154351 ] add get_current_dir_name() to
	os module
Message-ID: <E1D6AC9-0007Ly-Qf@sc8-sf-web2.sourceforge.net>

Feature Requests item #1154351, was opened at 2005-03-01 16:26
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=1154351&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: add get_current_dir_name() to os module

Initial Comment:
os.getcwd() does not use the contents of the PWD
environment variable, much as the glibc getcwd() does
not. This means that if a user sets the path using a
symbolic link, it will be dereferenced before being
passed by os.getcwd().

I propose that get_current_dir_name() be added, either
as a call to the glibc get_current_dir_name(), which
uses the PWD environment variable and therefore will
not dereference symbolic links in the path, or as a
fallback to this Pure Python function:

def get_current_dir_name():
    cwd = os.getcwd()
    
    try:
        pwd = os.environ["PWD"]
    except KeyError:
        return cwd

    cwd_stat, pwd_stat = map(os.stat, [cwd, pwd])

    if cwd_stat.st_dev == pwd_stat.st_dev and
cwd_stat.st_ino == pwd_stat.st_ino:
        return pwd
    else:
        return cwd


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 17:27:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 17:27:23 2005
Subject: [ python-Feature Requests-1154351 ] add get_current_dir_name() to
	os module
Message-ID: <E1D6ADQ-00006i-7k@sc8-sf-web1.sourceforge.net>

Feature Requests item #1154351, was opened at 2005-03-01 16:26
Message generated for change (Comment added) made by hoffmanm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: add get_current_dir_name() to os module

Initial Comment:
os.getcwd() does not use the contents of the PWD
environment variable, much as the glibc getcwd() does
not. This means that if a user sets the path using a
symbolic link, it will be dereferenced before being
passed by os.getcwd().

I propose that get_current_dir_name() be added, either
as a call to the glibc get_current_dir_name(), which
uses the PWD environment variable and therefore will
not dereference symbolic links in the path, or as a
fallback to this Pure Python function:

def get_current_dir_name():
    cwd = os.getcwd()
    
    try:
        pwd = os.environ["PWD"]
    except KeyError:
        return cwd

    cwd_stat, pwd_stat = map(os.stat, [cwd, pwd])

    if cwd_stat.st_dev == pwd_stat.st_dev and
cwd_stat.st_ino == pwd_stat.st_ino:
        return pwd
    else:
        return cwd


----------------------------------------------------------------------

>Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-01 16:27

Message:
Logged In: YES 
user_id=987664

Hmmm... my indentation seems to have gone by the wayside.
Still you can probably figure out what the code is supposed
to do <wink>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 18:29:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 18:29:56 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D6BBv-0005qB-Gb@sc8-sf-web3.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 11:48
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 12:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 04:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 18:41:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 18:41:48 2005
Subject: [ python-Bugs-1153027 ] http_error_302() crashes with 'HTTP/1.1 400
	Bad Request
Message-ID: <E1D6BNR-0006ba-Cc@sc8-sf-web3.sourceforge.net>

Bugs item #1153027, was opened at 2005-02-27 14:16
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153027&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: pristine777 (pristine777)
Assigned to: Nobody/Anonymous (nobody)
Summary: http_error_302() crashes with 'HTTP/1.1 400 Bad Request

Initial Comment:
I was able to get to a website by using both IE and 
FireFox but my Python code kept giving HTTP 400 Bad 
request error. To debug, I set set_http_debuglevel(1) as 
in the following code:

hh = urllib2.HTTPHandler() 
hh.set_http_debuglevel(1)
opener = urllib2.build_opener
(hh,urllib2.HTTPCookieProcessor(self.cj))

The printed debug messages show that this crash 
happens when there is a space in the redirected 
location. Here's a cut-and-paste of the relevant debug 
messages (note the line starting with send that 
http_error_302 is sending):

reply: 'HTTP/1.1 302 Moved Temporarily\r\n'
header: Connection: close
header: Date: Sun, 27 Feb 2005 19:52:51 GMT
header: Server: Microsoft-IIS/6.0
<---other header data-->
send: 'GET /myEmail/User?asOf=02/26/2005 11:38:12 
PM&
ddn=87cb51501730
<---remaining header data-->
reply: 'HTTP/1.1 400 Bad Request\r\n'
header: Content-Type: text/html
header: Date: Sun, 27 Feb 2005 19:56:45 GMT
header: Connection: close
header: Content-Length: 20

To fix this, I first tried to encode the redirected location 
in the function http_error_302() in urllib2 using the 
methods urllib.quote and urllib.urlencode but to no avail 
(they encode other data as well). 

A temporary solution that works is to replace any space 
in the redirected URL by'%20'. Below is a snippet of the 
function http_error_302 in urllib2 with this suggested fix:


def http_error_302(self, req, fp, code, msg, headers):
        # Some servers (incorrectly) return multiple 
Location headers
        # (so probably same goes for URI).  Use first 
header.
        if 'location' in headers:
            newurl = headers.getheaders('location')[0]
        elif 'uri' in headers:
            newurl = headers.getheaders('uri')[0]
        else:
            return
        newurl=newurl.replace(' ','%20') # <<< TEMP FIX - 
inserting this line temporarily fixes this problem
        newurl = urlparse.urljoin(req.get_full_url(), newurl)
       <--- remainder of this function -->


Thanks!



----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 11:41

Message:
Logged In: YES 
user_id=2772

When the server sends the 302 response with 'Location:
http://example.com/url%20with%20whitespace', urllib2 seems
to work just fine.

I believe based on reading rfc2396 that a URL that contains
spaces must contain quoted spaces (%20) not literal spaces,
because space is not an "unreserved character" [2.3] and
"[d]ata must be escaped if it does not have a representation
using an unreserved character" [2.4].

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153027&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 19:26:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 19:26:33 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D6C4l-0008DC-Ka@sc8-sf-web4.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 17:48
Message generated for change (Comment added) made by yorick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

>Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 19:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 18:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 10:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 06:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 20:15:25 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 20:15:28 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1D6Cq5-0002b4-CD@sc8-sf-web1.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 15:55
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 13:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Tue Mar  1 21:18:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  1 21:18:53 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1D6DpS-0005w6-HF@sc8-sf-web1.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 21:55
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-01 20:18

Message:
Logged In: YES 
user_id=6656

I wonder if Guido owes Armin a beer (read typeobject.c around line 5230).  
Well, not really, but it's that code that is making the difference.

However, reversing the order of dict and object is sufficient to make 2.2 
crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting 
code chopped out which gives the error jelper observes on the original).

I wonder what to do about this.  Removing the ability to customize the mro 
from user code is one obvious approach -- I don't know how much code 
uses this feature though.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 00:16:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 00:16:21 2005
Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault,
	EXAMPLE ATTACHED
Message-ID: <E1D6Gb7-0007at-E4@sc8-sf-web1.sourceforge.net>

Bugs item #1120452, was opened at 2005-02-11 00:04
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470

Category: Regular Expressions
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 7
Submitted By: Viktor Ferenczi (complex)
>Assigned to: Neil Schemenauer (nascheme)
Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED

Initial Comment:
Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org

This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug.

This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly.

Thanks for 2.4.1.

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-03-01 23:16

Message:
Logged In: YES 
user_id=35752

Closed as a duplicate of #1072259.  The fix has already been
backported to release24-maint.

----------------------------------------------------------------------

Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2005-03-01 11:59

Message:
Logged In: YES 
user_id=389140

I can reliably reproduce the problem on w2k using 2.4.0,
debug build under Purify.
Here is the testcase (using the files in the attached example):
>>> import re,PyMeld
>>> s=file("player.html").read()
>>> print re.search(PyMeld.openIDTagRE,s)

Applying the patch for bug #1072259 (_sre.c 2.110) causes
the bug to disappear, and Purify does not complain.
I suggest to consider this as a duplicate for bug #1072259

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-02-24 03:24

Message:
Logged In: YES 
user_id=149084

The IDLE subprocess does different things with memory
because it's threaded, with one thread minding the sockets
and the other executing user code.  So I'd stay away from
IDLE when working on this.  (Also, the debug traces are
excessively complex.)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2005-02-24 00:32

Message:
Logged In: YES 
user_id=35752

I can reproduce the crash on my machine if I revert the
patch for bug #1072259 (_sre.c 2.110).  Here's what gdb says:
0x0810342a in sre_match (state=0xbfffca80, pattern=0x81bfbf2)
    at ../Modules/_sre.c:854
854                         state->mark[j++] = NULL;
(gdb) p j
$7 = -1209149847
(gdb) p &(state->mark)
$8 = (void *(*)[200]) 0xbfffcaa8
(gdb) p &j
$9 = (int *) 0xbfffc9c0

Either the bug has been fixed or _sre has been changed
enough that the test no longer triggers a crash.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-02-22 23:58

Message:
Logged In: YES 
user_id=764593

It probably is a memory scribble bug, though it might not be in 
re.  For instance, the __getattr__ and __setattr__ try to do 
some shortcuts saving position, and they may cause the out-
of-bounds.

The crashes are very dependent on order.

I wasn't kidding when I said it ran fine and printed None if run 
as a whole, but crashed when the same lines were input one 
by one.  (Which gave idle a chance to do different things with 
memory in between, and didn't define a function object.)  

Also note that the second attribute access (even to a 
previously OK attribute) could cause a crash, unless it had 
had a chance to clear things up first -- but then it raised a 
MemoryError, when I almost certainly wasn't yet out of RAM.


----------------------------------------------------------------------

Comment By: Viktor Ferenczi (complex)
Date: 2005-02-22 15:19

Message:
Logged In: YES 
user_id=142612

Some additional information and summary:

My machine is a 3.0Hz Intel P4 with 1Gbyte memory, without
overclocking. I use 2 antivirus (1 active) and 3 antispyware
apps + firewall. The memory has been tested for 6 hours with
Knoppix's memtest without any error, so my machine can be
considered to be stable.

The attached script can crash python 2.4.0 at least for me
and jumjjewett. Do not run the script from IDLE, since it
can hide the segfault. I usually run my scripts from SciTE
(see: www.scintilla.org ).

The bug can be reproduced on stock Python 2.4.0 (MSI
installer). PyMeld is pure python (uses only the standard
library), no C extension modules used. I did not test this
bug with the latest CVS versions of Python 2.4. Is produces
segfault under Linux.

I'll try to narrow down this bug for specific regex patterns.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-22 14:51

Message:
Logged In: YES 
user_id=6656

Well, I still can't make it crash.  Can one of you provide a crashing driver 
script?  Better still would be finding which regexp and which input is the 
problem.

(Unless it's a memory-scribble random crasher type bug...)

----------------------------------------------------------------------

Comment By: Viktor Ferenczi (complex)
Date: 2005-02-22 13:07

Message:
Logged In: YES 
user_id=142612

This bug is a segfault, a real crash using only the stock 2.4.0. It has been reproduced correctly by jimjjewett. It seems to be a regexp related bug. I've changed the category to pass this bug to a regexp expert. Thanks for any help. - Complex

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-02-20 01:56

Message:
Logged In: YES 
user_id=149084

The restart in IDLE will occur if the subprocess is terminated or
segfaults.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-02-11 19:55

Message:
Logged In: YES 
user_id=764593

__gettattr__ alone can provoke the crash, if used several 
times, and on sub-melds.

I can print both StreamURL1 and StreamURL2.

If I ask it for p.StreamURL2.src and p.StreamURL1.value, 
it prints whichever one I ask for first, and then crashes on 
the second.  I did get it to print both (not assign, just 
__getattr__) by first getting several other attributes from 
p.StreamURL1, including some that didn't exist, so that 
there was a raise AttributeError in between.  Doing this a 
half dozen times, I provoked a MemoryError.

"""
>>> p.StreamURL1.value
'mss://stream.url'
>>> p.StreamURL2.src

Traceback (most recent call last):
  File "<pyshell#68>", line 1, in -toplevel-
    p.StreamURL2.src
  File "C:\Python24\Lib\site-packages\segfault240\PyMeld.
py", line 475, in __getattr__
    start = self._findElementFromID(name)
  File "C:\Python24\Lib\site-packages\segfault240\PyMeld.
py", line 425, in _findElementFromID
    match = _findIDMatch(nodeID, subset)
  File "C:\Python24\Lib\site-packages\segfault240\PyMeld.
py", line 282, in _findIDMatch
    match = re.search(thisRE, text)
  File "C:\Python24\lib\sre.py", line 134, in search
    return _compile(pattern, flags).search(string)
MemoryError
>>> 
"""



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-02-11 19:36

Message:
Logged In: YES 
user_id=764593

Partially reproduced on Windows XP.  (Using the stock 2.4.
0 msi)  

Just loading it in IDLE and hitting F5 (run), it prints None, 
as though it had succeeded perfectly.

Typing in the commands from index.py by hand, I can get 
it to give me the "encountered an error;  Tell Microsoft?" 
box, but IDLE only restarts instead of actually crashing.

There seems to a problem between the __getattr__ and 
the __setattr__ in PyMeld.  

"""
>>> p=Meld(open('player.html','rb').read())
>>> p.StreamURL1.value
'mss://stream.url'
>>> p.StreamURL2
<PyMeld.Meld instance at 0x00B455F8>
>>> p.StreamURL2.src
'mms://stream.url'

>>> v=Video()
>>> v.stream
's'
>>> p.StreamURL1.value=v.stream
>>> p.StreamURL1.value

>>> ================================ 
RESTART 
================================
>>> 
"""


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-11 14:57

Message:
Logged In: YES 
user_id=6656

What do you do to make it crash?  "python index.py"?

It doesn't fail for me with CVS HEAD.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 00:53:10 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 00:53:13 2005
Subject: [ python-Bugs-1153226 ] string interpolation breaks with %d and
	large float
Message-ID: <E1D6HAs-00018h-6D@sc8-sf-web1.sourceforge.net>

Bugs item #1153226, was opened at 2005-02-28 15:10
Message generated for change (Comment added) made by jerub
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: string interpolation breaks with %d and large float

Initial Comment:
We have experienced a problem recently when wanting to
render a large float as a string. Converting the float
to an int/long manuall was required. 

'%d' % f
throws an exception for all floats f, f >= 2**31

Expected output, shown with 'int()' and 'long()':
>>> '%d %d' % (long(float(2**31)), int(float(2**31)))
'2147483648 2147483648'

Non-Working Example.
>>> '%d' % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

Tested on:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40) 
Python 2.4.1a0 (#2, Feb  9 2005, 22:42:24)

----------------------------------------------------------------------

>Comment By: Stephen Thorne (jerub)
Date: 2005-03-02 09:53

Message:
Logged In: YES 
user_id=100823

%ld doesn't help. see the following example:

>>> "%.f" % float(2**31)
'2147483648'
>>> "%ld" % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-03-02 01:38

Message:
Logged In: YES 
user_id=44345

This is probably a corner case that got missed in the
int/long convergence.  Still, is there a reason not to use
%.f when you know you are passing a float and want to
display it with no fractional component?

>>> '%.f' % 2**50 
'1125899906842624'

or %ld if you expect the range to exceed the integer limits of
your hardware?

>>> '%ld' % 2**50
'1125899906842624'

I agree the documentation could probably be improved
in this area.


----------------------------------------------------------------------

Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 23:21

Message:
Logged In: YES 
user_id=100823

My immediate reaction is, yes. This is a bug. 

Either floats should work with %d, or they should not at
all. Having a platform dependant upper bound on the size of
the float allowed is a bug.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-03-01 16:36

Message:
Logged In: YES 
user_id=341410

Note that it will also raise a TypeError when the float f, f
< -2**31

Is this a bug?  I don't know.  I tend to not pass floats
when string interpolation is expecting integers.  Maybe the
documentation should be cleared up.

If you really want a truncated float, perhaps "%.0f" is the
format you are looking for, to save you the effort of using
int() or long().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 01:15:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 01:15:39 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D6HWa-0001Ob-09@sc8-sf-web4.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 16:48
Message generated for change (Comment added) made by bbange
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 00:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 18:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 17:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 09:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 05:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 01:20:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 01:20:47 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D6HbU-0002UD-85@sc8-sf-web1.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 16:48
Message generated for change (Comment added) made by bbange
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 00:20

Message:
Logged In: YES 
user_id=1230541

Obviously I forgot a statement in my previous comment's 
code example. So here's the complete version:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your 
expected implementation?


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 00:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 18:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 17:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 09:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 05:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 01:42:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 01:42:37 2005
Subject: [ python-Bugs-1153226 ] string interpolation breaks with %d and
	large float
Message-ID: <E1D6Hwe-0003d8-RB@sc8-sf-web1.sourceforge.net>

Bugs item #1153226, was opened at 2005-02-27 23:10
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: string interpolation breaks with %d and large float

Initial Comment:
We have experienced a problem recently when wanting to
render a large float as a string. Converting the float
to an int/long manuall was required. 

'%d' % f
throws an exception for all floats f, f >= 2**31

Expected output, shown with 'int()' and 'long()':
>>> '%d %d' % (long(float(2**31)), int(float(2**31)))
'2147483648 2147483648'

Non-Working Example.
>>> '%d' % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

Tested on:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40) 
Python 2.4.1a0 (#2, Feb  9 2005, 22:42:24)

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2005-03-01 18:42

Message:
Logged In: YES 
user_id=44345

Sorry, I got corn-fused and misinterpreted 2**50 as 2e50.


----------------------------------------------------------------------

Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 17:53

Message:
Logged In: YES 
user_id=100823

%ld doesn't help. see the following example:

>>> "%.f" % float(2**31)
'2147483648'
>>> "%ld" % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-03-01 09:38

Message:
Logged In: YES 
user_id=44345

This is probably a corner case that got missed in the
int/long convergence.  Still, is there a reason not to use
%.f when you know you are passing a float and want to
display it with no fractional component?

>>> '%.f' % 2**50 
'1125899906842624'

or %ld if you expect the range to exceed the integer limits of
your hardware?

>>> '%ld' % 2**50
'1125899906842624'

I agree the documentation could probably be improved
in this area.


----------------------------------------------------------------------

Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 07:21

Message:
Logged In: YES 
user_id=100823

My immediate reaction is, yes. This is a bug. 

Either floats should work with %d, or they should not at
all. Having a platform dependant upper bound on the size of
the float allowed is a bug.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-03-01 00:36

Message:
Logged In: YES 
user_id=341410

Note that it will also raise a TypeError when the float f, f
< -2**31

Is this a bug?  I don't know.  I tend to not pass floats
when string interpolation is expecting integers.  Maybe the
documentation should be cleared up.

If you really want a truncated float, perhaps "%.0f" is the
format you are looking for, to save you the effort of using
int() or long().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 04:25:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 04:25:08 2005
Subject: [ python-Bugs-1153163 ] reflected operator not used when operands
	have the same type
Message-ID: <E1D6KTx-0000WE-Cb@sc8-sf-web2.sourceforge.net>

Bugs item #1153163, was opened at 2005-02-27 20:09
Message generated for change (Comment added) made by hughsw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Hugh Secker-Walker (hughsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: reflected operator not used when operands have the same type

Initial Comment:

The reflected operators, e.g. __radd__, are used when
the left operand does not have the non-reflected
operator, *unless* the right operand is of the same type.

The documentation on the "Emulating numeric types" page
doesn't mention this peculiar exclusion.  Of the
reflected operators it says:
"These methods are called to implement the binary
arithmetic operations (+, -, *, /, %, divmod(), pow(),
**, <<, >>, &, ^, |) with reflected (swapped) operands.
These functions are only called if the left operand
does not support the corresponding operation. For
instance, to evaluate the expression x-y, where y is an
instance of a class that has an __rsub__() method,
y.__rsub__(x) is called."

This code demonstrates the correct behavior and then
the problem:

class A(object):
    def __radd__(self, other):
        return '__radd__', other

print None + A()
print A() + A()

giving....

('__radd__', None)

Traceback (most recent call last):
  File "C:/Temp/reflectedbug.py", line 6, in -toplevel-
    print A() + A()
TypeError: unsupported operand type(s) for +: 'A' and 'A'

I've replaced None in the first print statement with
many kinds of builtin objects, instances of other
classes, and with instances of subclasses of A.  In all
these cases the __radd__ operator is used as
documented.  I've only seen the problem when the two
operands are of the same type.

This problem also occurs during the backing-off to
plain operators that occurs when augmented operators,
e.g. __iadd__, aren't implemented by the type and the
operands are of the same type.

This problem is present in 2.4 on Linux and Windows,
and in the current CVS version (2.5a0, 27-Feb-05) on Linux.


----------------------------------------------------------------------

>Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-03-01 22:25

Message:
Logged In: YES 
user_id=1146279

Upon reflection and offline discussion it appears to me that
Python is behaving as designed and that the documentation is
buggy in that it fails to mention the special cases
demonstrated in this bug report.

The two special cases that the documentation should mention are:

1) The reflected operator is never used if the two operands
are of the same type, regardless of whether the
non-reflected operator exists.  

The necessity of this isn't clear to me.

2) If the type of the right-hand operand is a subclass of
the type of the left-hand operand, and if the right-hand
operand overloads the reflected operator from whatever is
(or isn't) implemented by the left-hand operand, then the
reflected operator of the right-hand operand will be used,
regardless of the presence of the non-reflected operator for
either type.  This behavior is necessary for subclasses to
overload parent class operators. 

-Hugh



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:08

Message:
Logged In: YES 
user_id=593130

I believe Python's designer(s) intend that if A()+A() is valid, then 
A will have an __add__ method.  __rxxx__ is only intended for 
backup use with mixed types.  So your example sends a mixed 
message to the interpreter.

If the current behavior is both intended and still necessary, the 
manual sentence
"These functions are only called if the left operand
does not support the corresponding operation"
could be augmented with 
"and has a different type than the right operand"


----------------------------------------------------------------------

Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 23:36

Message:
Logged In: YES 
user_id=1146279

The problem is in the SLOT1BINFULL() macro near line 4020 in
typeobject.c.  In two places it ensures that the reflected
(reversed, swapped, rop<blah>, you name it) operator won't
be called if the two operands are of the same type. 
Removing these two exclusions fixes the problem.  

However, this being my third day ever modifying Python
source code, for all intents and purposes, I have no idea
why the exclusions were there (efficiency?).  And,
elsewhere, I saw high-level code that had a similar check on
operands having the same type with a comment that talked
about avoiding an infinite loop that could happen if there's
coercion and other subtly involved....

FWIW, with the changes I made, 256 tests are OK and 35 tests
are skipped -- as is usual on my Linux system.

I can post a trivial patch and figure out how to add a
regression test, but expert analysis is needed.

Also, the code in this macro (and perhaps helped by
abstract.c) implements curious and
not-documented-on-the-Emulating-numeric-types-page
semantics: if the operand on the right is a subtype of the
operand on the left and if  the right operand overloads the
reflected operator, then the reflected operator will be
called, even if the left-hand operand implements the regular
operator!  This is either a bug or it should be documented,
preferably with some rationale. E.g.

class A(object):
    def __add__(self, other):
        return 'A.__add__', other
class B(A):
    def __radd__(self, other):
        return 'B.__radd__', other

>>> B()+A()
('A.__add__', <__main__.A object at 0x00B65A30>)
>>> B()+B()
('A.__add__', <__main__.B object at 0x00B836F0>)
>>> 1+B()
('B.__radd__', 1)
>>> A()+B()
('B.__radd__', <__main__.A object at 0x00B65A30>)

Where the last one is what's curious or a bug.

-Hugh


----------------------------------------------------------------------

Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 01:09

Message:
Logged In: YES 
user_id=1146279

I've looked into this a little.  Newbie that I am, I don't
know where the 
 x = slotw(v, w);
call goes (in binary_op1() in abstract.c near line 377)....
 AFAICT, this code in abstract.c behaves reasonably, so
problem would seem to be in the tp_as_number slot-function
that's getting called.  And whereever that is, it's not the
binary-op functions in classobject.c that I thought it would
be....


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 05:53:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 05:54:01 2005
Subject: [ python-Bugs-1154811 ] Duplicate output with unbuffered IO after
	fork
Message-ID: <E1D6Lry-0004GG-Be@sc8-sf-web2.sourceforge.net>

Bugs item #1154811, was opened at 2005-03-02 04: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=1154811&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Aivazis (aivazis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Duplicate output with unbuffered IO after fork

Initial Comment:
When doing unbuffered IO, I get the same output twice
after a fork. If I open my file with no buffering, this
problem does not occur. If I don't fork, the problem
goies away also. 

The bug is present in 2.3 and 2.4. Haven't tried 2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1154811&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 06:00:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 06:00:52 2005
Subject: [ python-Bugs-1154811 ] Duplicate output with unbuffered IO after
	fork
Message-ID: <E1D6Lyb-0006L3-3d@sc8-sf-web1.sourceforge.net>

Bugs item #1154811, was opened at 2005-03-02 04:53
Message generated for change (Comment added) made by aivazis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1154811&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Aivazis (aivazis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Duplicate output with unbuffered IO after fork

Initial Comment:
When doing unbuffered IO, I get the same output twice
after a fork. If I open my file with no buffering, this
problem does not occur. If I don't fork, the problem
goies away also. 

The bug is present in 2.3 and 2.4. Haven't tried 2.5.

----------------------------------------------------------------------

>Comment By: Michael Aivazis (aivazis)
Date: 2005-03-02 05:00

Message:
Logged In: YES 
user_id=30635

OS info: Linux version 2.6.7 (root@amalfi) (gcc version
3.3.5 (Debian 1:3.3.5-6)) #2 Wed Jan 26 07:20:32 PST 2005



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1154811&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 06:17:22 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 06:17:23 2005
Subject: [ python-Bugs-1154811 ] Duplicate output with unbuffered IO after
	fork
Message-ID: <E1D6MEc-0006jH-2o@sc8-sf-web3.sourceforge.net>

Bugs item #1154811, was opened at 2005-03-01 23:53
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1154811&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Aivazis (aivazis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Duplicate output with unbuffered IO after fork

Initial Comment:
When doing unbuffered IO, I get the same output twice
after a fork. If I open my file with no buffering, this
problem does not occur. If I don't fork, the problem
goies away also. 

The bug is present in 2.3 and 2.4. Haven't tried 2.5.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-02 00:17

Message:
Logged In: YES 
user_id=31435

I really don't know what you mean, but what happens if you 
try the same thing in C?  Python defers to the platform C 
libraries for all I/O, so if a program in C does the same thing, 
that's the cause.

----------------------------------------------------------------------

Comment By: Michael Aivazis (aivazis)
Date: 2005-03-02 00:00

Message:
Logged In: YES 
user_id=30635

OS info: Linux version 2.6.7 (root@amalfi) (gcc version
3.3.5 (Debian 1:3.3.5-6)) #2 Wed Jan 26 07:20:32 PST 2005



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1154811&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 06:40:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 06:40:04 2005
Subject: [ python-Bugs-1154811 ] Duplicate output with unbuffered IO after
	fork
Message-ID: <E1D6MaX-0007gB-Gx@sc8-sf-web3.sourceforge.net>

Bugs item #1154811, was opened at 2005-03-01 20:53
Message generated for change (Comment added) made by aivazis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1154811&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Michael Aivazis (aivazis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Duplicate output with unbuffered IO after fork

Initial Comment:
When doing unbuffered IO, I get the same output twice
after a fork. If I open my file with no buffering, this
problem does not occur. If I don't fork, the problem
goies away also. 

The bug is present in 2.3 and 2.4. Haven't tried 2.5.

----------------------------------------------------------------------

>Comment By: Michael Aivazis (aivazis)
Date: 2005-03-01 21:40

Message:
Logged In: YES 
user_id=30635

I really botched this one. Long day. My apologies

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-01 21:17

Message:
Logged In: YES 
user_id=31435

I really don't know what you mean, but what happens if you 
try the same thing in C?  Python defers to the platform C 
libraries for all I/O, so if a program in C does the same thing, 
that's the cause.

----------------------------------------------------------------------

Comment By: Michael Aivazis (aivazis)
Date: 2005-03-01 21:00

Message:
Logged In: YES 
user_id=30635

OS info: Linux version 2.6.7 (root@amalfi) (gcc version
3.3.5 (Debian 1:3.3.5-6)) #2 Wed Jan 26 07:20:32 PST 2005



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1154811&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 17:42:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 17:42:54 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D6Wvy-0004rf-MK@sc8-sf-web1.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 17:48
Message generated for change (Comment added) made by yorick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

>Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-02 17:42

Message:
Logged In: YES 
user_id=432579

No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 01:20

Message:
Logged In: YES 
user_id=1230541

Obviously I forgot a statement in my previous comment's 
code example. So here's the complete version:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your 
expected implementation?


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 01:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 19:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 18:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 10:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 06:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 17:55:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 17:55:56 2005
Subject: [ python-Bugs-1155207 ] getElementsbyTagName('*') in dom.minidom
Message-ID: <E1D6X8b-0002js-Cj@sc8-sf-web4.sourceforge.net>

Bugs item #1155207, was opened at 2005-03-02 16:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155207&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: bugmenot (bugmenot)
Assigned to: Nobody/Anonymous (nobody)
Summary: getElementsbyTagName('*') in dom.minidom

Initial Comment:
According to the level 1 DOM, getElementsByTagName('*')
on an element node should return all descendants of the
element from which the method is called that are
element nodes.

When i tried it however, the returned nodeList
contained all elements that appear after the original
element in the soruce, regardless of whether or not
they are descendants.

Python 2.4 for windows

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155207&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 18:03:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 18:03:28 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1D6XFs-0002oU-J7@sc8-sf-web2.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 21:55
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2005-03-02 17:03

Message:
Logged In: YES 
user_id=4771

To solve the problem, as hinted in the title of this tracker, I 
think that PyXxx_Check() should simply not trust any mro.  
What PyInt_Check() really means at the C level is to check if 
an object memory layout is compatible with PyIntObject.  This 
is easy to figure out by walking the "solid base" chain, 
tp_base.

As a side note, PyPy gives the same error as Python 2.2.  
However, both in PyPy and in Python 2.2, you can still build 
an instance of the strange class X as follows:

>>> x = object.__new__(X)

Still, all the methods of x are resolved via the dict type.  In 
PyPy we get a clean TypeError because the methods thus 
found don't apply to non-dict objects.  In Python 2.2 you can 
crash the interpreter just as in more recent Python releases, 
e.g. with x[5]=6.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-01 20:18

Message:
Logged In: YES 
user_id=6656

I wonder if Guido owes Armin a beer (read typeobject.c around line 5230).  
Well, not really, but it's that code that is making the difference.

However, reversing the order of dict and object is sufficient to make 2.2 
crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting 
code chopped out which gives the error jelper observes on the original).

I wonder what to do about this.  Removing the ability to customize the mro 
from user code is one obvious approach -- I don't know how much code 
uses this feature though.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 18:05:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 18:05:05 2005
Subject: [ python-Bugs-1155207 ] getElementsbyTagName('*') in dom.minidom
Message-ID: <E1D6XHS-0003Fc-QJ@sc8-sf-web4.sourceforge.net>

Bugs item #1155207, was opened at 2005-03-02 16:55
Message generated for change (Settings changed) made by bugmenot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155207&group_id=5470

Category: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: bugmenot (bugmenot)
Assigned to: Nobody/Anonymous (nobody)
Summary: getElementsbyTagName('*') in dom.minidom

Initial Comment:
According to the level 1 DOM, getElementsByTagName('*')
on an element node should return all descendants of the
element from which the method is called that are
element nodes.

When i tried it however, the returned nodeList
contained all elements that appear after the original
element in the soruce, regardless of whether or not
they are descendants.

Python 2.4 for windows

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155207&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 21:11:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 21:11:59 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1D6aCK-0004dL-0i@sc8-sf-web4.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 21:55
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-02 20:11

Message:
Logged In: YES 
user_id=6656

Hmm, yeah, that works.  It wasn't totally clear to me that the user couldn't 
maliciously influence tp_base, but I don't think they can...

A helper function is presumably in order, unless PyType_IsSubtype should 
be changed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-02 17:03

Message:
Logged In: YES 
user_id=4771

To solve the problem, as hinted in the title of this tracker, I 
think that PyXxx_Check() should simply not trust any mro.  
What PyInt_Check() really means at the C level is to check if 
an object memory layout is compatible with PyIntObject.  This 
is easy to figure out by walking the "solid base" chain, 
tp_base.

As a side note, PyPy gives the same error as Python 2.2.  
However, both in PyPy and in Python 2.2, you can still build 
an instance of the strange class X as follows:

>>> x = object.__new__(X)

Still, all the methods of x are resolved via the dict type.  In 
PyPy we get a clean TypeError because the methods thus 
found don't apply to non-dict objects.  In Python 2.2 you can 
crash the interpreter just as in more recent Python releases, 
e.g. with x[5]=6.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-01 20:18

Message:
Logged In: YES 
user_id=6656

I wonder if Guido owes Armin a beer (read typeobject.c around line 5230).  
Well, not really, but it's that code that is making the difference.

However, reversing the order of dict and object is sufficient to make 2.2 
crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting 
code chopped out which gives the error jelper observes on the original).

I wonder what to do about this.  Removing the ability to customize the mro 
from user code is one obvious approach -- I don't know how much code 
uses this feature though.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 22:03:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 22:03:18 2005
Subject: [ python-Bugs-1155362 ] Bugs in parsedate_tz
Message-ID: <E1D6azz-00076Z-Ag@sc8-sf-web2.sourceforge.net>

Bugs item #1155362, was opened at 2005-03-02 21:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs in parsedate_tz

Initial Comment:
The parsing in emails is incomplete in both rfc822.py
and _parseaddr.py.

For example, "Wed, 02 Mar 2005 09:26:53+0800" is parsed
but "Wed, 02 Mar 2005 09:26:53-0800" is not.

The problem is clear by watching the code : only "+"
timezones are corrected.
Following a patch :

Index : _parseaddr.py
----------------------------------------------------------------
@@ -60,7 +66,11 @@ def parsedate_tz(data):
         if i > 0:
             data[3:] = [s[:i], s[i+1:]]
         else:
-            data.append('') # Dummy tz
+           i = s.find('-')
+           if i > 0:
+               data[3:] = [s[:i], s[i:]]
+           else:
+               data.append('') # Dummy tz
     if len(data) < 5:
         return None
     data = data[:5]
----------------------------------------------------------------

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 22:14:33 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 22:14:35 2005
Subject: [ python-Bugs-1155362 ] Bugs in parsedate_tz
Message-ID: <E1D6bAv-0007dq-K4@sc8-sf-web2.sourceforge.net>

Bugs item #1155362, was opened at 2005-03-02 16:03
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Bugs in parsedate_tz

Initial Comment:
The parsing in emails is incomplete in both rfc822.py
and _parseaddr.py.

For example, "Wed, 02 Mar 2005 09:26:53+0800" is parsed
but "Wed, 02 Mar 2005 09:26:53-0800" is not.

The problem is clear by watching the code : only "+"
timezones are corrected.
Following a patch :

Index : _parseaddr.py
----------------------------------------------------------------
@@ -60,7 +66,11 @@ def parsedate_tz(data):
         if i > 0:
             data[3:] = [s[:i], s[i+1:]]
         else:
-            data.append('') # Dummy tz
+           i = s.find('-')
+           if i > 0:
+               data[3:] = [s[:i], s[i:]]
+           else:
+               data.append('') # Dummy tz
     if len(data) < 5:
         return None
     data = data[:5]
----------------------------------------------------------------

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
From noreply at sourceforge.net  Wed Mar  2 23:59:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  2 23:59:18 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D6coF-0006Ea-LS@sc8-sf-web3.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 11:48
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-02 17:59

Message:
Logged In: YES 
user_id=593130

No, this issue is not specific to either eval or lambda:

>>> def f(g):
...   exec 'def h(x): return g(x)'
...   return h
...
>>> f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in h
NameError: global name 'g' is not defined

It is specific to creating a function at top-level in a separate 
execution environment, as done, by design, by both eval and 
exec, and with either a def statement or lambda abbreviation 
thereof.

In Python, lexical scoping works because nested functions are 
compiled along with the outer function, so that scoped variables 
can be identified and both functions adjusted so that the coupling 
works.  In particular, the scoped variable has to not be deleted 
when the outer function returns.  Eval/exec compile their string 
only later, when the function is called.

"it works that way because it is the way it works".
Those are your words, not mine.  If you want Python to work 
differently, write a PEP or a patch, or raise the question in the 
newsgroup/mailing list. I'm done discussing it here.

----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-02 11:42

Message:
Logged In: YES 
user_id=432579

No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-01 19:20

Message:
Logged In: YES 
user_id=1230541

Obviously I forgot a statement in my previous comment's 
code example. So here's the complete version:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your 
expected implementation?


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 13:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 12:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 04:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 00:48:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 00:48:56 2005
Subject: [ python-Feature Requests-1155485 ] file() on a file
Message-ID: <E1D6daH-0008IQ-Rp@sc8-sf-web3.sourceforge.net>

Feature Requests item #1155485, was opened at 2005-03-02 23:48
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=1155485&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Felix Lee (felixlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: file() on a file

Initial Comment:
it would be nice if file(f) worked when f is already a
file, either by returning f or by constructing a new
file that refers to the same thing.  that would make it
easy to write functions that can take either a file or
a filename as an argument, like so:
    def p(f): print list(file(f))
which is kind of like using int() as a cast operation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 08:22:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 08:22:26 2005
Subject: [ python-Bugs-1155638 ] self.length shield exception in httplib
Message-ID: <E1D6kfA-00050Q-8J@sc8-sf-web2.sourceforge.net>

Bugs item #1155638, was opened at 2005-03-03 07:22
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=1155638&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew P. Lentvorski, Jr. (bsder)
Assigned to: Nobody/Anonymous (nobody)
Summary: self.length shield exception in httplib

Initial Comment:
Under certain conditions (I'm trying to open a
Shoutcast stream), I wind up with the following
exception from httplib:

 Traceback (most recent call last):
  File "/home/devel/lib/python2.4/threading.py", line
442, in __bootstrap
    self.run()
  File "avalanche.py", line 86, in run
    streamData = streamResponse.read(256)
  File "/home/devel/lib/python2.4/httplib.py", line
478, in read
    self.length -= len(s)
TypeError: unsupported operand type(s) for -=: 'str'
and 'int'

Normally, self.length has many shields of the form "if
self.length is None:"; however, self.length gets
initialize to _UNKNOWN which is the string "UNKNOWN"
rather than None.  As such, all of the shields are useless.

Am I using a deprecated library or something?  I'm
really surprised no one else has bumped into this.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155638&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 09:38:10 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 09:38:17 2005
Subject: [ python-Bugs-1110242 ] gzip.GzipFile.flush() does not flush all
	internal buffers
Message-ID: <E1D6lqU-0001XR-Lq@sc8-sf-web3.sourceforge.net>

Bugs item #1110242, was opened at 2005-01-26 22:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110242&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: David Schnepper (dschnepper)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.GzipFile.flush() does not flush all internal buffers

Initial Comment:
flush() is expected to output all pending data stored
in internal buffers.

gzip.GzipFile.flush() does perform a flush on its
fileobj, but does not flush the state of its compressobj
prior to the IO flush.

This results in being able to use gzip.GzipFile to zip 
output to a socket and having the other side unzip it
in sync with originators flush calls.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 09:38

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. I believe it does not fully fix the
bug reported: not all input data are flushed with
Z_SYNC_FLUSH, but only some (up to an output byte boundary
or some such). I also believe that a "complete" fix for the
bug is not possible, as flushing all input data would
require Z_FINISH, and then no more additional data could be
written into the stream.

As this is still an improvement over the current status, I
committed it as

gzip.py 1.43
NEWS 1.1251


----------------------------------------------------------------------

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-02-27 05:33

Message:
Logged In: YES 
user_id=1115903

This patch appears to fix the bug as described, and running
the regression tests on Python 2.5a0 (CVS HEAD) plus this
patch turns up no problems.  Since the documentation says
that a GzipFile "simulates most of the methods of a file
object," I would expect GzipFile.flush() to act in the way
that David described in the first paragraph of the bug
report, and his patch seems to provide that as far as I can
tell.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110242&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 09:39:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 09:39:40 2005
Subject: [ python-Bugs-1110242 ] gzip.GzipFile.flush() does not flush all
	internal buffers
Message-ID: <E1D6lrm-0004Cs-6g@sc8-sf-web1.sourceforge.net>

Bugs item #1110242, was opened at 2005-01-26 22:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110242&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Schnepper (dschnepper)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.GzipFile.flush() does not flush all internal buffers

Initial Comment:
flush() is expected to output all pending data stored
in internal buffers.

gzip.GzipFile.flush() does perform a flush on its
fileobj, but does not flush the state of its compressobj
prior to the IO flush.

This results in being able to use gzip.GzipFile to zip 
output to a socket and having the other side unzip it
in sync with originators flush calls.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 09:39

Message:
Logged In: YES 
user_id=21627

Ah, put the "committed" message into the wrong tracker item.
As I said, I don't think the bug is fully fixed, but I don't
think it can be fully fixed, either, so closing it as fixed.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 09:38

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. I believe it does not fully fix the
bug reported: not all input data are flushed with
Z_SYNC_FLUSH, but only some (up to an output byte boundary
or some such). I also believe that a "complete" fix for the
bug is not possible, as flushing all input data would
require Z_FINISH, and then no more additional data could be
written into the stream.

As this is still an improvement over the current status, I
committed it as

gzip.py 1.43
NEWS 1.1251


----------------------------------------------------------------------

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-02-27 05:33

Message:
Logged In: YES 
user_id=1115903

This patch appears to fix the bug as described, and running
the regression tests on Python 2.5a0 (CVS HEAD) plus this
patch turns up no problems.  Since the documentation says
that a GzipFile "simulates most of the methods of a file
object," I would expect GzipFile.flush() to act in the way
that David described in the first paragraph of the bug
report, and his patch seems to provide that as far as I can
tell.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110242&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 10:34:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 10:34:16 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1D6mih-0004PO-A8@sc8-sf-web3.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 21:55
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2005-03-03 09:34

Message:
Logged In: YES 
user_id=4771

The PyXxx_Check() macros are #defined with
PyObject_TypeCheck().  Should we change all these #defines to
use a new PyObject_LayoutCheck() or something, and document
to C extension writers that they should also switch to the
new function?  More generally, should we review *all* usages
of PyObject_TypeCheck() and decide if they really meant that
or PyObject_LayoutCheck()?  Do we care about types that are
solid subclasses of 'int' but don't have it in their MRO? 
Should we just forget the whole idea and sanity-check the
user-defined mro, which after all would just add another
strange undocumented condition to typeobject.c? :-)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-02 20:11

Message:
Logged In: YES 
user_id=6656

Hmm, yeah, that works.  It wasn't totally clear to me that the user couldn't 
maliciously influence tp_base, but I don't think they can...

A helper function is presumably in order, unless PyType_IsSubtype should 
be changed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-02 17:03

Message:
Logged In: YES 
user_id=4771

To solve the problem, as hinted in the title of this tracker, I 
think that PyXxx_Check() should simply not trust any mro.  
What PyInt_Check() really means at the C level is to check if 
an object memory layout is compatible with PyIntObject.  This 
is easy to figure out by walking the "solid base" chain, 
tp_base.

As a side note, PyPy gives the same error as Python 2.2.  
However, both in PyPy and in Python 2.2, you can still build 
an instance of the strange class X as follows:

>>> x = object.__new__(X)

Still, all the methods of x are resolved via the dict type.  In 
PyPy we get a clean TypeError because the methods thus 
found don't apply to non-dict objects.  In Python 2.2 you can 
crash the interpreter just as in more recent Python releases, 
e.g. with x[5]=6.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-01 20:18

Message:
Logged In: YES 
user_id=6656

I wonder if Guido owes Armin a beer (read typeobject.c around line 5230).  
Well, not really, but it's that code that is making the difference.

However, reversing the order of dict and object is sufficient to make 2.2 
crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting 
code chopped out which gives the error jelper observes on the original).

I wonder what to do about this.  Removing the ability to customize the mro 
from user code is one obvious approach -- I don't know how much code 
uses this feature though.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 10:50:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 10:50:10 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1D6my7-0007Z9-Cf@sc8-sf-web1.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 21:55
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-03 09:50

Message:
Logged In: YES 
user_id=6656

Certainly some more checking of what the user-defined MRO contains 
would be good -- check the attached, which dumps core at class definition 
time...

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-03 09:34

Message:
Logged In: YES 
user_id=4771

The PyXxx_Check() macros are #defined with
PyObject_TypeCheck().  Should we change all these #defines to
use a new PyObject_LayoutCheck() or something, and document
to C extension writers that they should also switch to the
new function?  More generally, should we review *all* usages
of PyObject_TypeCheck() and decide if they really meant that
or PyObject_LayoutCheck()?  Do we care about types that are
solid subclasses of 'int' but don't have it in their MRO? 
Should we just forget the whole idea and sanity-check the
user-defined mro, which after all would just add another
strange undocumented condition to typeobject.c? :-)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-02 20:11

Message:
Logged In: YES 
user_id=6656

Hmm, yeah, that works.  It wasn't totally clear to me that the user couldn't 
maliciously influence tp_base, but I don't think they can...

A helper function is presumably in order, unless PyType_IsSubtype should 
be changed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-02 17:03

Message:
Logged In: YES 
user_id=4771

To solve the problem, as hinted in the title of this tracker, I 
think that PyXxx_Check() should simply not trust any mro.  
What PyInt_Check() really means at the C level is to check if 
an object memory layout is compatible with PyIntObject.  This 
is easy to figure out by walking the "solid base" chain, 
tp_base.

As a side note, PyPy gives the same error as Python 2.2.  
However, both in PyPy and in Python 2.2, you can still build 
an instance of the strange class X as follows:

>>> x = object.__new__(X)

Still, all the methods of x are resolved via the dict type.  In 
PyPy we get a clean TypeError because the methods thus 
found don't apply to non-dict objects.  In Python 2.2 you can 
crash the interpreter just as in more recent Python releases, 
e.g. with x[5]=6.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-01 20:18

Message:
Logged In: YES 
user_id=6656

I wonder if Guido owes Armin a beer (read typeobject.c around line 5230).  
Well, not really, but it's that code that is making the difference.

However, reversing the order of dict and object is sufficient to make 2.2 
crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting 
code chopped out which gives the error jelper observes on the original).

I wonder what to do about this.  Removing the ability to customize the mro 
from user code is one obvious approach -- I don't know how much code 
uses this feature though.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 10:51:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 10:51:46 2005
Subject: [ python-Bugs-531205 ] Bugs in rfc822.parseaddr()
Message-ID: <E1D6mze-0007dq-Tl@sc8-sf-web1.sourceforge.net>

Bugs item #531205, was opened at 2002-03-18 06:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Ben Gertzfield (che_fox)
Summary: Bugs in rfc822.parseaddr()

Initial Comment:
This bug is in rfc822.parseaddr(), and thus inherited
into email.Utils.parseaddr() since the latter does a
straight include of the former.  It has a nasty bug
when the email address contains embedded spaces: it
collapses the spaces:

&gt;&gt;&gt; from email.Utils import parseaddr
&gt;&gt;&gt; parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
&gt;&gt;&gt; parseaddr('&lt;foo bar@wooz.org&gt;')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more
involved to implement in an RFC 2822 compliant way, but
it would be very cool.

Note that I'm reporting this bug here instead of the
mimelib project because it's actually in rfc822.py. 
Once solution might include fixing it in the email
package only.




----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 10:51

Message:
Logged In: YES 
user_id=21627

I'm going to follow anadelonbrin's recommendation: the
current behaviour is actually correct.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2005-01-31 00:43

Message:
Logged In: YES 
user_id=552329

IMO, the current behaviour should be retained for the
reasons outlined by Tim Roberts, or extra code should be
added to strip spaces around periods and the @, and if there
are others then ('', '') should be returned.  The latter is
probably more correct, but there doesn't seem to be any
pressing reason for the former.

As such, recommend closing "Won't fix".  If the latter
behaviour is desired, then I could work up a patch for it.

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-25 02:29

Message:
Logged In: YES 
user_id=752496

Reassigning it as a Py2.4 bug.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-11-08 21:49

Message:
Logged In: YES 
user_id=113328

This issue still exists in Python 2.3.4 and Python 2.4b2.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-22 20:30

Message:
Logged In: YES 
user_id=469548

Well, the docs say "unless the parse fails, in which case a
2-tuple of ('', '') is returned". I think it's reasonable to
say that non-compliant addresses like this should fail to
parse and thus that parseaddr('foo bar@wooz.org') should
returns ('', '')

----------------------------------------------------------------------

Comment By: Tim Roberts (timroberts)
Date: 2002-08-12 23:40

Message:
Logged In: YES 
user_id=265762

Interesting to note that RFC 822 (but not 2822) allows spaces 
around any periods in the address without quoting (2822 does 
allow spaces around the @), and those spaces are to be 
removed.  Section A.1.4 gives the example 
   Wilt  .  Chamberlain@NBA.US
and says it should be parsed as &quot;Wilt.Chamberlain&quot;.

Given that, it's hard for me to see that the current behavior 
should be changed at all, since there is no correct way to 
parse this non-compliant address.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-04-15 19:18

Message:
Logged In: YES 
user_id=12800

Note further that &quot;foo bar&quot;@wooz.org is properly parsed. 
The question is, what should parseaddr() do in this
non-compliant situation?  I can think of a couple of things:

- it could raise an exception
- it could return ('', 'bar@wooz.org')
- it could return ('foo', 'bar@wooz.org')
- it could return ('' '&quot;foo bar&quot;@wooz.org')

I'm not sure what the right thing to do is.  I'm assigning
to Ben Gertzfield to get his opinion.  Ben, feel free to add
a comment and re-assign the bug to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 10:52:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 10:52:20 2005
Subject: [ python-Bugs-768419 ] Subtle bug in os.path.realpath on Cygwin
Message-ID: <E1D6n0D-0002DO-3p@sc8-sf-web4.sourceforge.net>

Bugs item #768419, was opened at 2003-07-09 14:38
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768419&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: Subtle bug in os.path.realpath on Cygwin

Initial Comment:
Cygwin allows mounting directories within other mount
points.  This can cause os.path.realpath to expand some
symlinks that it shouldn't.  For example:

$ cd /
$ mkdir X
$ mkdir X/Y
$ ln -s X Z
$ mount C:/ /Z/Y
$ ls Z/Y
[...contents of C:\...]
$ ls X/Y
[empty directory]

$ python -c &quot;import os; print os.path.realpath('Z/Y')&quot;
/X/Y
[bad because /X/Y is empty yet the original Z/Y has files]

In Cygwin, the correct answer would be either 'C:\' or
'/cygdrive/c/'.

Conceivably this problem can happen in UNIces other
than Cygwin.  It would be rather annoying to fix,
because it would require looking at the mount table. 
But I thought I would mention it anyway...

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 10:52

Message:
Logged In: YES 
user_id=21627

Closing as suggested.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2005-01-31 00:57

Message:
Logged In: YES 
user_id=552329

I agree with Sjoerd - this is a Cygwin bug, not a Python one.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-07-09 15:33

Message:
Logged In: YES 
user_id=43607

I'd think this is rather a Cygwin bug than a Python bug.

Before the mount, /X/Y and /Z/Y refer to the same directory,
and on Unix they have the same device/inode combination. 
And that combination is the all-important factor when doing
a mount on that directory.
If you do this on Unix (I used an NFS mount instead of the
mount shown in the report), both /X/Y and /Z/Y contain the
mounted directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768419&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 11:08:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 11:08:25 2005
Subject: [ python-Bugs-803413 ] uu.decode prints to stderr
Message-ID: <E1D6nFk-0004BR-Dj@sc8-sf-web2.sourceforge.net>

Bugs item #803413, was opened at 2003-09-09 22:31
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803413&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sami Hangaslammi (shang)
Assigned to: Nobody/Anonymous (nobody)
Summary: uu.decode prints to stderr

Initial Comment:

Python 2.3 final

The standard library function uu.decode prints a
warning message to stderr if there is an error when
decoding the file. This feels like an incorrect
behaviour for a library function.

The warning message can be supressed by providing a
quiet=True parameter, but this is not currently documented.

The relevant line in uu.py is 138

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 11:08

Message:
Logged In: YES 
user_id=21627

I think documenting the quiet parameter is the right
solution. Fixed in libuu.tex 1.14 and 1.12.20.2

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2005-01-31 01:15

Message:
Logged In: YES 
user_id=552329

Printing to stderr outside of debugging is uncommon for the
standard library, but there are other modules (ftplib,
asyncore) that do it.  In this case, it only happens when
there is an error (which can be recovered from), so printing
to stderr seems fairly appropriate.  An alternative would be
to call warnings.warn(), although by default that will have
the same effect.

Documenting the 'quiet' parameter seems reasonable, however,
and would be a simple change to libuu.tex.  I can produce
such a patch, if desired.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803413&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 11:21:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 11:21:06 2005
Subject: [ python-Bugs-1090076 ] Defaults in ConfigParser.get overrides
	section values
Message-ID: <E1D6nS3-0000gP-JF@sc8-sf-web1.sourceforge.net>

Bugs item #1090076, was opened at 2004-12-22 23:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090076&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defaults in ConfigParser.get overrides section values

Initial Comment:
ConfigParser.get has an optional argument vars that -
according to the docstring- "which must be a dictionary 
whose contents overrides any pre-existing defaults."
I understand that it overrides the default values, but 
should not override an actual value existing in the file. 
That is, given this contents:

[DEFAULT]
key1=default1

[section]
key2=value2

vars={'key1:vars1','key2:vars2'}

cfg.get('section','key1',0,vars) gives 'vars1' (ok)

cfg.get('section','key2',0,vars) gives 'vars2' (wrong, 
should be 'value2', since key2 is actually in the section 
and no default is needed).

To correct this behavior, simply move this two lines of 
code up in ConfigParser.get (ConfigParser.py), just below 
the first line and before the first try/except:

        # Update with the entry specific variables
        if vars is not None:
            d.update(vars)


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 11:21

Message:
Logged In: YES 
user_id=21627

I believe the current behaviour is there ever since revision
1.6, when the vars parameter was first introduced. The
commit message says

date: 1999/01/26 19:29:25;  author: guido;  state: Exp; 
lines: +17 -6
Patch by Chris Petrilli (not really tested since I don't
know this
module myself) to accept an option keyword argument (vars)
that is
substituted on top of the defaults that were setup in
__init__.  The
patch also fixes the problem where you can't have recusive
references
inside your configuration file.

We might want to ask Petrilli what the intention of this
feature was, or just proceed with changing the documentation
(and docstrings); contributions in that direction are
welcome. I agree with  anadelonbrin that the proposed change
is probably not adequate.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2005-01-31 01:42

Message:
Logged In: YES 
user_id=552329

This is indeed what happens.  However, changing this could
break existing code, so an alternative fix would be to
change the documentation to "overrides any pre-existing
values.".  I am not sure what the desired behaviour is - if
it is what is current, then recommend updating the
documentation.  If the desired behaviour is what the
documentation currently says, then recommend applying the
above patch (although the code is not exactly the same
anymore, the effect is).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090076&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 12:13:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 12:13:39 2005
Subject: [ python-Bugs-1086603 ] segfault in readline
Message-ID: <E1D6oGu-0000Pu-5T@sc8-sf-web3.sourceforge.net>

Bugs item #1086603, was opened at 2004-12-16 19:02
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: DSM (dsm001)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in readline

Initial Comment:
It's possible to produce segfaults using two functions
from the
readline module by giving them negative values (GNU
readline 4.3-10),
at least in some circumstances.  

Python 2.5a0 (#10, Dec 15 2004, 19:53:33) 
[GCC 3.3.3 (Debian 20040401)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import readline
[25290 refs]
>>> readline.remove_history_item(-1)
Segmentation fault

>>> readline.replace_history_item(-1,'abc')
Segmentation fault

gdb reveals it happens because the (external)
remove_history and replace_history_entry don't return
NULL in these cases.  I'm not sure whether we're
responsible for checking the sanity of inputs or the
GNU code should be returning NULL and isn't, but at
least sometimes it doesn't.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 12:13

Message:
Logged In: YES 
user_id=21627

This should be now fixed with patch 1093585.

----------------------------------------------------------------------

Comment By: Bj?rn Lindqvist (sonderblade)
Date: 2005-01-12 00:07

Message:
Logged In: YES 
user_id=51702

I can confirm the bug with readline 4.3 and Python 2.5a0
(#1, Jan 11 2005, 23:22:16). dsm001's patch fixes it.

----------------------------------------------------------------------

Comment By: DSM (dsm001)
Date: 2004-12-31 03:32

Message:
Logged In: YES 
user_id=1175690

This one being simple enough for the likes of me to patch, I
did so -- 1093585.  Let the school of hard knocks begin!

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2004-12-20 11:57

Message:
Logged In: YES 
user_id=671362

I'm +1 for sanity checking rather than waiting for the GNU
readline to return NULL in these functions.

It's just adding a few lines of code right after 
PyArg_ParseTuple :

  if (entry_number < 0) {
    PyErr_SetString(PyExc_ValueError,
                    "index cannot be a negative value");
    return NULL;
  }

Then you can work around the problem without worrying 
about the return value of remove_history nor 
replace_history_entry.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-12-19 17:41

Message:
Logged In: YES 
user_id=6656

Do you want to fix it then? :)  I can't imagine it's that hard, but it would 
be easier for someone who can test that their fix helps...

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2004-12-18 11:45

Message:
Logged In: YES 
user_id=671362

FYI, I can reproduce this with :

- Python 2.4 & readline 4.3 under SuSE 9.1
- Python 2.5(snapshot as of 2004-12-17) & readline 4.3 under 
SuSE 9.1
- Python 2.4 & readline 4.3.5(?) under Cygwin



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-12-17 15:18

Message:
Logged In: YES 
user_id=6656

Hmm.  I can't reproduce this (also with readline 4.3).  Odd.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 12:16:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 12:16:45 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D6oJu-0003Ph-5N@sc8-sf-web1.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 17:48
Message generated for change (Comment added) made by yorick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

>Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-03 12:16

Message:
Logged In: YES 
user_id=432579

>No, this issue is not specific to either eval or lambda:

Right, so let me rephrase: The bug occurs when explicitly
evaluating a lambda expression or function definition
statement using eval or exec. (This is an artifact of
Python's strong separation of statements and expressions.)

If this is done "by design", why cannot I find anything
anywhere describing this? If this is just a documentation
oversight, please say so, but then I would also like to have
an explanation of the behaviour.

The fact remains that

    def f(x): eval('x')

works as expected and

    def f(g): eval('lambda x: g(x)')

does not. Why? Both are evaluated at the same time and use
the same environment to look up their variables. The fact
that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping, because that is how
lambda expressions work.

>If you want Python to work 
>differently, write a PEP or a patch, or raise the question in
>the newsgroup/mailing list.

www.python.org told me that this is the place to report bugs
in Python. If that is wrong, we should change the web site.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-02 23:59

Message:
Logged In: YES 
user_id=593130

No, this issue is not specific to either eval or lambda:

>>> def f(g):
...   exec 'def h(x): return g(x)'
...   return h
...
>>> f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in h
NameError: global name 'g' is not defined

It is specific to creating a function at top-level in a separate 
execution environment, as done, by design, by both eval and 
exec, and with either a def statement or lambda abbreviation 
thereof.

In Python, lexical scoping works because nested functions are 
compiled along with the outer function, so that scoped variables 
can be identified and both functions adjusted so that the coupling 
works.  In particular, the scoped variable has to not be deleted 
when the outer function returns.  Eval/exec compile their string 
only later, when the function is called.

"it works that way because it is the way it works".
Those are your words, not mine.  If you want Python to work 
differently, write a PEP or a patch, or raise the question in the 
newsgroup/mailing list. I'm done discussing it here.

----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-02 17:42

Message:
Logged In: YES 
user_id=432579

No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 01:20

Message:
Logged In: YES 
user_id=1230541

Obviously I forgot a statement in my previous comment's 
code example. So here's the complete version:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your 
expected implementation?


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 01:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 19:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 18:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 10:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 06:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 16:29:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 16:29:24 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D6sGL-0003rw-Rl@sc8-sf-web4.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 11:48
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

>Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
>Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-03 10:29

Message:
Logged In: YES 
user_id=80475

Jeremy, would you update the pep and docs to cover the OP's
examples.



----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-03 06:16

Message:
Logged In: YES 
user_id=432579

>No, this issue is not specific to either eval or lambda:

Right, so let me rephrase: The bug occurs when explicitly
evaluating a lambda expression or function definition
statement using eval or exec. (This is an artifact of
Python's strong separation of statements and expressions.)

If this is done "by design", why cannot I find anything
anywhere describing this? If this is just a documentation
oversight, please say so, but then I would also like to have
an explanation of the behaviour.

The fact remains that

    def f(x): eval('x')

works as expected and

    def f(g): eval('lambda x: g(x)')

does not. Why? Both are evaluated at the same time and use
the same environment to look up their variables. The fact
that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping, because that is how
lambda expressions work.

>If you want Python to work 
>differently, write a PEP or a patch, or raise the question in
>the newsgroup/mailing list.

www.python.org told me that this is the place to report bugs
in Python. If that is wrong, we should change the web site.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-02 17:59

Message:
Logged In: YES 
user_id=593130

No, this issue is not specific to either eval or lambda:

>>> def f(g):
...   exec 'def h(x): return g(x)'
...   return h
...
>>> f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in h
NameError: global name 'g' is not defined

It is specific to creating a function at top-level in a separate 
execution environment, as done, by design, by both eval and 
exec, and with either a def statement or lambda abbreviation 
thereof.

In Python, lexical scoping works because nested functions are 
compiled along with the outer function, so that scoped variables 
can be identified and both functions adjusted so that the coupling 
works.  In particular, the scoped variable has to not be deleted 
when the outer function returns.  Eval/exec compile their string 
only later, when the function is called.

"it works that way because it is the way it works".
Those are your words, not mine.  If you want Python to work 
differently, write a PEP or a patch, or raise the question in the 
newsgroup/mailing list. I'm done discussing it here.

----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-02 11:42

Message:
Logged In: YES 
user_id=432579

No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-01 19:20

Message:
Logged In: YES 
user_id=1230541

Obviously I forgot a statement in my previous comment's 
code example. So here's the complete version:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your 
expected implementation?


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 13:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 12:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 04:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 16:43:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 16:43:04 2005
Subject: [ python-Bugs-1155938 ] yield in __init__ causes broken new-style
	class
Message-ID: <E1D6sTd-0004lh-W3@sc8-sf-web4.sourceforge.net>

Bugs item #1155938, was opened at 2005-03-03 17: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=1155938&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield in __init__ causes broken new-style class

Initial Comment:

 class Foo(object):
 
     def __init__(self):
         print "foo"
         raise RuntimeError
         yield 23

 Foo()

With a classic class, this correctly fails saying
"__init__ must return None".  With a new-style class,
the class suite works, and Foo() is called without
reporting an error, but also without printing "foo".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155938&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 17:02:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 17:02:19 2005
Subject: [ python-Bugs-1155938 ] yield in __init__ causes broken new-style
	class
Message-ID: <E1D6smG-0000bJ-9W@sc8-sf-web3.sourceforge.net>

Bugs item #1155938, was opened at 2005-03-03 15:42
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155938&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield in __init__ causes broken new-style class

Initial Comment:

 class Foo(object):
 
     def __init__(self):
         print "foo"
         raise RuntimeError
         yield 23

 Foo()

With a classic class, this correctly fails saying
"__init__ must return None".  With a new-style class,
the class suite works, and Foo() is called without
reporting an error, but also without printing "foo".


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-03 16:02

Message:
Logged In: YES 
user_id=6656

You don't have to be that cute:

>>> class Foo(object):
...  def __init__(self):
...   return "foo"
... 

where did that check go?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155938&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 17:37:35 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 17:37:39 2005
Subject: [ python-Bugs-1155938 ] yield in __init__ causes broken new-style
	class
Message-ID: <E1D6tKR-0006IT-RY@sc8-sf-web1.sourceforge.net>

Bugs item #1155938, was opened at 2005-03-03 10:42
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155938&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: yield in __init__ causes broken new-style class

Initial Comment:

 class Foo(object):
 
     def __init__(self):
         print "foo"
         raise RuntimeError
         yield 23

 Foo()

With a classic class, this correctly fails saying
"__init__ must return None".  With a new-style class,
the class suite works, and Foo() is called without
reporting an error, but also without printing "foo".


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-03 11:02

Message:
Logged In: YES 
user_id=6656

You don't have to be that cute:

>>> class Foo(object):
...  def __init__(self):
...   return "foo"
... 

where did that check go?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155938&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 17:46:00 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 17:46:04 2005
Subject: [ python-Bugs-1155938 ] yield in __init__ causes broken new-style
	class
Message-ID: <E1D6tSa-00089e-UM@sc8-sf-web4.sourceforge.net>

Bugs item #1155938, was opened at 2005-03-03 17:42
Message generated for change (Comment added) made by stevea_zope
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155938&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Raymond Hettinger (rhettinger)
Summary: yield in __init__ causes broken new-style class

Initial Comment:

 class Foo(object):
 
     def __init__(self):
         print "foo"
         raise RuntimeError
         yield 23

 Foo()

With a classic class, this correctly fails saying
"__init__ must return None".  With a new-style class,
the class suite works, and Foo() is called without
reporting an error, but also without printing "foo".


----------------------------------------------------------------------

>Comment By: Steve Alexander (stevea_zope)
Date: 2005-03-03 18:46

Message:
Logged In: YES 
user_id=492001

Albertas Agejevas has pointed out that:

1. New style classes don't care what is returned from __init__.

2. If __init__ contains a yield, the code in __init__ won't
be called until the generator that is returned has its
'.next()' method called.

Which all makes sense.  However, someone I work with was
trying for ages to work out what a particular __init__
method was not being called.  The __init__ method was rather
long, and there was a yield, copy-pasted from some other
code, hidden behind a raise.

So, the behaviour may be correct, but I don't think it is
very helpful. 

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-03 18:02

Message:
Logged In: YES 
user_id=6656

You don't have to be that cute:

>>> class Foo(object):
...  def __init__(self):
...   return "foo"
... 

where did that check go?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155938&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 17:56:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 17:56:47 2005
Subject: [ python-Bugs-1155938 ] yield in __init__ causes broken new-style
	class
Message-ID: <E1D6tcy-0003aa-MT@sc8-sf-web3.sourceforge.net>

Bugs item #1155938, was opened at 2005-03-03 10:42
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155938&group_id=5470

Category: Type/class unification
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Raymond Hettinger (rhettinger)
Summary: yield in __init__ causes broken new-style class

Initial Comment:

 class Foo(object):
 
     def __init__(self):
         print "foo"
         raise RuntimeError
         yield 23

 Foo()

With a classic class, this correctly fails saying
"__init__ must return None".  With a new-style class,
the class suite works, and Foo() is called without
reporting an error, but also without printing "foo".


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-03 11:56

Message:
Logged In: YES 
user_id=80475

Fixed.
See typeobject.c 2.264 and 2.264.2.1.

----------------------------------------------------------------------

Comment By: Steve Alexander (stevea_zope)
Date: 2005-03-03 11:46

Message:
Logged In: YES 
user_id=492001

Albertas Agejevas has pointed out that:

1. New style classes don't care what is returned from __init__.

2. If __init__ contains a yield, the code in __init__ won't
be called until the generator that is returned has its
'.next()' method called.

Which all makes sense.  However, someone I work with was
trying for ages to work out what a particular __init__
method was not being called.  The __init__ method was rather
long, and there was a yield, copy-pasted from some other
code, hidden behind a raise.

So, the behaviour may be correct, but I don't think it is
very helpful. 

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-03 11:02

Message:
Logged In: YES 
user_id=6656

You don't have to be that cute:

>>> class Foo(object):
...  def __init__(self):
...   return "foo"
... 

where did that check go?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155938&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 18:17:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 18:17:17 2005
Subject: [ python-Bugs-1103350 ] send/recv SEGMENT_SIZE should be used more
	in socketmodule
Message-ID: <E1D6twp-0004fT-1n@sc8-sf-web3.sourceforge.net>

Bugs item #1103350, was opened at 2005-01-16 16:01
Message generated for change (Comment added) made by irmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103350&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: send/recv SEGMENT_SIZE should be used more in socketmodule

Initial Comment:
socketmodule.c contains a SEGMENT_SIZE define that is
used to limit the send/recv buffer size on VMS.

But IMO there are two problems:
1) it should also be used on windows, because windows
doesn't like a large send/recv buffer either,
2) it should be used in more places: at least sendall,
but perhaps also recvfrom, sendto

ad 1: see also this bug: http://www.python.org/sf/853507

----------------------------------------------------------------------

>Comment By: Irmen de Jong (irmen)
Date: 2005-03-03 18:17

Message:
Logged In: YES 
user_id=129426

Btw: I'm not too experienced with Win32 programming and so I
don't have a very good argumentation for the buffer size issue
on this platform. If there is somebody with better understanding
of the issues involved here, please advise.
(it's just empirical knowledge that I have that leads me to
believe that win32's tcp implementation suffers from similar
recv/send size problems as VMS does-- for which a special
case was made in the code)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103350&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 21:43:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 21:43:06 2005
Subject: [ python-Bugs-1156179 ] Calls from VBScript clobber passed args
Message-ID: <E1D6x9z-00075J-Ux@sc8-sf-web3.sourceforge.net>

Bugs item #1156179, was opened at 2005-03-03 15: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=1156179&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Rose (grincheroo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calls from VBScript clobber passed args

Initial Comment:
I'm using Python 2.4.0 and VBScript under ASP on IIS 5. If I call a 
Python function from VBScript AND pass a local var as the first 
parameter AND don't use the return value, then the local var I 
passed in is, upon the function's return, set to Null.

If I store the return value (even if there isn't one) OR pass the return 
value to another function, this doesn't happen. I'm attaching some 
snippets that demonstrate and work around the bug.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 21:53:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 21:53:08 2005
Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow
Message-ID: <E1D6xJh-0006pF-Rs@sc8-sf-web2.sourceforge.net>

Bugs item #1124637, was opened at 2005-02-17 12:10
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Peter ?strand (astrand)
Summary: test_subprocess is far too slow

Initial Comment:
test_subprocess takes multiple minutes.  I'm pretty
sure it's "test_no_leaking".  It should either be sped
up or only tested when some -u argument is passed to
regrtest.

----------------------------------------------------------------------

>Comment By: Peter ?strand (astrand)
Date: 2005-03-03 21:53

Message:
Logged In: YES 
user_id=344921

Fixed in HEAD revisions:
regrtest.py: 1.166
1.19

Fixed in 2.4 revisions:
regrtest.py: 1.165.2.1
test_subprocess.py: 1.15.2.2


----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-02-17 16:17

Message:
Logged In: YES 
user_id=344921

tim_one: test_subprocess only creates 65 processes on
Windows, compared to 1026 for UNIX. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-02-17 16:13

Message:
Logged In: YES 
user_id=31435

Peculiar -- test_subprocess takes about 8 seconds on my 
WinXP box release build, about 10 seconds debug build, and 
Windows is notorious for slow process creation.  That's a 
zippy 3.4 GHz P4, but clock rate alone can't account for such 
a large speed difference.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-02-17 14:16

Message:
Logged In: YES 
user_id=29957

I'm with mwh. This test should be enabled with an option -
I'd noticed that test_subprocess took a long time, but
hadn't bothered to track it down.

Before releases (and at other times) I always try to make
sure that I run 'make testall', but for day-to-day use, this
is too slow.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-17 13:09

Message:
Logged In: YES 
user_id=6656

Bog standard linux pc -- p3 933, 384 megs of ram.

"$ time ./python ../Lib/test/regrtest.py test_subprocess"
reports 2 minutes 7.  This is a debug build, a release build
might be quicker.  A run of the entire test suite takes a
hair over nine minutes, so 20-odd % of the time seems to be
test_subprocess.

It also takes ages on my old-ish ibook (600 Mhz G3, also 384
megs of ram), but that's at home and I can't time it.

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-02-17 12:50

Message:
Logged In: YES 
user_id=344921

Tell me a bit about your type of OS and hardware. On my
machine (P4 2.66 GHz with Linux), the test takes 28 seconds. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 21:54:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 21:54:53 2005
Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow
Message-ID: <E1D6xLM-0007fp-1W@sc8-sf-web3.sourceforge.net>

Bugs item #1124637, was opened at 2005-02-17 12:10
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Peter ?strand (astrand)
Summary: test_subprocess is far too slow

Initial Comment:
test_subprocess takes multiple minutes.  I'm pretty
sure it's "test_no_leaking".  It should either be sped
up or only tested when some -u argument is passed to
regrtest.

----------------------------------------------------------------------

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-03-03 21:54

Message:
Logged In: YES 
user_id=1188172

Shouldn't it be closed then?

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-03-03 21:53

Message:
Logged In: YES 
user_id=344921

Fixed in HEAD revisions:
regrtest.py: 1.166
1.19

Fixed in 2.4 revisions:
regrtest.py: 1.165.2.1
test_subprocess.py: 1.15.2.2


----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-02-17 16:17

Message:
Logged In: YES 
user_id=344921

tim_one: test_subprocess only creates 65 processes on
Windows, compared to 1026 for UNIX. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-02-17 16:13

Message:
Logged In: YES 
user_id=31435

Peculiar -- test_subprocess takes about 8 seconds on my 
WinXP box release build, about 10 seconds debug build, and 
Windows is notorious for slow process creation.  That's a 
zippy 3.4 GHz P4, but clock rate alone can't account for such 
a large speed difference.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-02-17 14:16

Message:
Logged In: YES 
user_id=29957

I'm with mwh. This test should be enabled with an option -
I'd noticed that test_subprocess took a long time, but
hadn't bothered to track it down.

Before releases (and at other times) I always try to make
sure that I run 'make testall', but for day-to-day use, this
is too slow.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-17 13:09

Message:
Logged In: YES 
user_id=6656

Bog standard linux pc -- p3 933, 384 megs of ram.

"$ time ./python ../Lib/test/regrtest.py test_subprocess"
reports 2 minutes 7.  This is a debug build, a release build
might be quicker.  A run of the entire test suite takes a
hair over nine minutes, so 20-odd % of the time seems to be
test_subprocess.

It also takes ages on my old-ish ibook (600 Mhz G3, also 384
megs of ram), but that's at home and I can't time it.

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-02-17 12:50

Message:
Logged In: YES 
user_id=344921

Tell me a bit about your type of OS and hardware. On my
machine (P4 2.66 GHz with Linux), the test takes 28 seconds. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 21:58:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 21:58:09 2005
Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow
Message-ID: <E1D6xOV-0007qs-HG@sc8-sf-web3.sourceforge.net>

Bugs item #1124637, was opened at 2005-02-17 12:10
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Peter ?strand (astrand)
Summary: test_subprocess is far too slow

Initial Comment:
test_subprocess takes multiple minutes.  I'm pretty
sure it's "test_no_leaking".  It should either be sped
up or only tested when some -u argument is passed to
regrtest.

----------------------------------------------------------------------

>Comment By: Peter ?strand (astrand)
Date: 2005-03-03 21:58

Message:
Logged In: YES 
user_id=344921

Forgot to close. 

----------------------------------------------------------------------

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-03-03 21:54

Message:
Logged In: YES 
user_id=1188172

Shouldn't it be closed then?

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-03-03 21:53

Message:
Logged In: YES 
user_id=344921

Fixed in HEAD revisions:
regrtest.py: 1.166
1.19

Fixed in 2.4 revisions:
regrtest.py: 1.165.2.1
test_subprocess.py: 1.15.2.2


----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-02-17 16:17

Message:
Logged In: YES 
user_id=344921

tim_one: test_subprocess only creates 65 processes on
Windows, compared to 1026 for UNIX. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-02-17 16:13

Message:
Logged In: YES 
user_id=31435

Peculiar -- test_subprocess takes about 8 seconds on my 
WinXP box release build, about 10 seconds debug build, and 
Windows is notorious for slow process creation.  That's a 
zippy 3.4 GHz P4, but clock rate alone can't account for such 
a large speed difference.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-02-17 14:16

Message:
Logged In: YES 
user_id=29957

I'm with mwh. This test should be enabled with an option -
I'd noticed that test_subprocess took a long time, but
hadn't bothered to track it down.

Before releases (and at other times) I always try to make
sure that I run 'make testall', but for day-to-day use, this
is too slow.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-17 13:09

Message:
Logged In: YES 
user_id=6656

Bog standard linux pc -- p3 933, 384 megs of ram.

"$ time ./python ../Lib/test/regrtest.py test_subprocess"
reports 2 minutes 7.  This is a debug build, a release build
might be quicker.  A run of the entire test suite takes a
hair over nine minutes, so 20-odd % of the time seems to be
test_subprocess.

It also takes ages on my old-ish ibook (600 Mhz G3, also 384
megs of ram), but that's at home and I can't time it.

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-02-17 12:50

Message:
Logged In: YES 
user_id=344921

Tell me a bit about your type of OS and hardware. On my
machine (P4 2.66 GHz with Linux), the test takes 28 seconds. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 22:22:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 22:22:15 2005
Subject: [ python-Bugs-1138653 ] subprocesss module retains older license
	header
Message-ID: <E1D6xls-0005L3-WD@sc8-sf-web1.sourceforge.net>

Bugs item #1138653, was opened at 2005-02-17 23:46
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tres Seaver (tseaver)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocesss module retains older license header

Initial Comment:
The header of the file seems to imply that the module
is licensed
separately from the standard Python license:


# subprocess - Subprocesses with accessible I/O streams
#
# For more information about this module, see PEP 324.
#
# Copyright (c) 2003-2004 by Peter Astrand
<astrand@lysator.liu.se>
#
# By obtaining, using, and/or copying this software
and/or its
# associated documentation, you agree that you have
read, understood,
# and will comply with the following terms and conditions:
#
# Permission to use, copy, modify, and distribute this
software and
# its associated documentation for any purpose and
without fee is
# hereby granted, provided that the above copyright
notice appears in
# all copies, and that both that copyright notice and
this permission
# notice appear in supporting documentation, and that
the name of the
# author not be used in advertising or publicity
pertaining to
# distribution of the software without specific,
written prior
# permission.
#
# THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE,
# INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS.
# IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
SPECIAL, INDIRECT OR
# CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS
# OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT,
# NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION
# WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.


----------------------------------------------------------------------

>Comment By: Peter ?strand (astrand)
Date: 2005-03-03 22:22

Message:
Logged In: YES 
user_id=344921

How should the license header look like, then? Basically,
I've used xmlrpclib.py as an example. Many other modules
have no license header at all, but this might be a problem
when subprocess.py is distributed separately from Python. Or?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 22:26:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 22:26:03 2005
Subject: [ python-Bugs-1121579 ] subprocess example missing "stdout=PIPE"
Message-ID: <E1D6xpZ-0000oD-20@sc8-sf-web3.sourceforge.net>

Bugs item #1121579, was opened at 2005-02-13 01:27
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121579&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Monte Davidoff (mdavidoff)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess example missing "stdout=PIPE"

Initial Comment:
In the Python Library Reference, section 6.8.3.2, the
Popen for p2 is missing "stdout=PIPE". Correct line is:

p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)

This typo also occurs in subprocess.py line 232. The
executable example on line 1118 is correct.

Python 2.4, Red Hat Linux 9.

----------------------------------------------------------------------

>Comment By: Peter ?strand (astrand)
Date: 2005-03-03 22:26

Message:
Logged In: YES 
user_id=344921

Duplicate of 1073790. Already fixed in CVS. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121579&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 22:28:35 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 22:28:36 2005
Subject: [ python-Bugs-1083895 ] functions replaced by subprocess should
	point to its docs
Message-ID: <E1D6xs3-0005hG-4N@sc8-sf-web1.sourceforge.net>

Bugs item #1083895, was opened at 2004-12-12 17:06
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Peter ?strand (astrand)
Summary: functions replaced by subprocess should point to its docs

Initial Comment:
We should either move or copy the "Replacing Older
Functions with the subprocess Module" section to the
documentation of the functions that are replaced by
subprocess.

See
http://mail.python.org/pipermail/python-dev/2004-December/050266.html,
for non-subprocess specific rationale.

----------------------------------------------------------------------

>Comment By: Peter ?strand (astrand)
Date: 2005-03-03 22:28

Message:
Logged In: YES 
user_id=344921

If anyone else wants to work on this bug, that's fine with
me. Currenly, I'm not in "documentation mood". 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 23:29:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 23:29:58 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1D6ypO-0003vx-2y@sc8-sf-web3.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
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=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Thu Mar  3 23:50:33 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  3 23:50:36 2005
Subject: [ python-Bugs-1153417 ] os.remove error on Solaris
Message-ID: <E1D6z9N-0003rx-IX@sc8-sf-web2.sourceforge.net>

Bugs item #1153417, was opened at 2005-02-28 12:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153417&group_id=5470

>Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Philips (rphilips)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove error on Solaris

Initial Comment:
According to the documentation, when os.remove is
applied to a directory, OSError should be raised.

On Solaris, this is not the case: the directory is
removed BUT the link count on the parent directory does
NOT change.  File system corruption is the result.

Python details:
Python 2.3.4 (#3, Jun 18 2004, 10:14:55)
[GCC 3.2.2] on sunos5

Solaris details:

Number of CPUs is        2
CPU Type is              sparcv9+vis2
CPU Speed is             750 MHz
App Architecture is      sparc
Kernel Architecture is   sun4u
Kernel Bit Size is       64
OS Name is               SunOS
OS Version is            5.8
OS Distribution is       Solaris 8 7/01 s28s_u5wos_08 SPARC
Libc Name is             libc
Libc Version is          1
Kernel Version is        SunOS Release 5.8 Version
Generic_108528-20 64-bit


 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-03 23:50

Message:
Logged In: YES 
user_id=21627

This seems to be a bug report, not a patch, so I'm
reclassifying it.

Is there any chance that you tried os.remove as a superuser?
Python invokes unlink; according to the OS man page, unlink
gives EPERM when the file to remove is a directory.

I consider this a bug in the operating system: it should not
be possible, not even for the superuser, to corrupt the file
system using standard system calls. I don't know what the
rationale is for this behaviour.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153417&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 00:06:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 00:06:27 2005
Subject: [ python-Bugs-1156280 ] cmd.Cmd().cmdloop() can't read from file
Message-ID: <E1D6zOk-0004c3-Ao@sc8-sf-web2.sourceforge.net>

Bugs item #1156280, was opened at 2005-03-03 15:06
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=1156280&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: jamesthiele (jamesthiele)
Assigned to: Nobody/Anonymous (nobody)
Summary: cmd.Cmd().cmdloop() can't read from file

Initial Comment:
cmd.Cmd() takes three parameters, the second of which is a file to 
use instead of standard input by resetting self.stdin. The substitute 
input is never used.

The problem is that 'use_rawinput' is set to 1 and not changed. This 
means that raw_input() is always used and self.stdin.readline() is 
never used.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156280&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 00:16:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 00:16:49 2005
Subject: [ python-Bugs-1100429 ] TarFile iteration can break (on Windows) if
	file has links
Message-ID: <E1D6zYi-00061l-VK@sc8-sf-web3.sourceforge.net>

Bugs item #1100429, was opened at 2005-01-11 21:54
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100429&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: TarFile iteration can break (on Windows) if file has links

Initial Comment:
I ran into this with a simple loop trying to detar
Pyrex-0.9.3:

for info in tarfile:
    tarfile.extract(info)

I called the above immediately after calling
tarfile.open, so the returned iterator was an instance
of TarIter.  The problem is that Pyrex includes some
symbolic links.  When TarFile.makelink finds that
os.symlink is missing (on Windows) it then does
getmember to find the info for the referenced file. 
The getmember method results in a call to getmembers,
which loads all the infos into the members list. 
However, this breaks the TarIter, since it assumes the
members have not yet been loaded.

Not sure what the best fix for this is; in my script, I
switched over to using getmembers rather than the iterator.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-04 00:16

Message:
Logged In: YES 
user_id=21627

Fixed with said patch.

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2005-01-16 18:40

Message:
Logged In: YES 
user_id=642936

I wrote a patch (#1103407) that should fix this.
Thank you for pointing that out.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100429&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 00:17:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 00:17:48 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1D6zZc-000596-Uc@sc8-sf-web2.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
>Assigned to: Martin v. L?wis (loewis)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 01:02:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 01:02:06 2005
Subject: [ python-Bugs-1088077 ] [PATCH] tty needs a way to restore the
	terminal mode.
Message-ID: <E1D70GY-0004cq-TD@sc8-sf-web1.sourceforge.net>

Bugs item #1088077, was opened at 2004-12-19 22:24
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088077&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Meyer (mwm)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] tty needs a way to restore the terminal mode.

Initial Comment:
tty provides a nice, simple interface for setting the terminal to raw
or cbreak modes. However, it doesn't provide a way to put the terminal
back in the mode it was in before that change. Every responsible
application should leave the terminal in the mode it found it in -
unless the application is called sttty, of course. tty needs a
"setsane" function.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-04 01:02

Message:
Logged In: YES 
user_id=21627

As the proposed patch shows, the requested feature is
already there: the application merely needs to invoke the
tcgetattr function at the beginning, and tcsetattr at the end.

----------------------------------------------------------------------

Comment By: Mike Meyer (mwm)
Date: 2004-12-19 22:28

Message:
Logged In: YES 
user_id=93910

The patch to add the setsane method is in patch #1088078.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088077&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 01:28:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 01:28:56 2005
Subject: [ python-Bugs-1108992 ] idle freezes when run over ssh
Message-ID: <E1D70gT-0005QM-FG@sc8-sf-web4.sourceforge.net>

Bugs item #1108992, was opened at 2005-01-25 05:44
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Poolman (mgpoolman)
Assigned to: Nobody/Anonymous (nobody)
Summary: idle freezes when run over ssh

Initial Comment:
Python 2.3.4 (#2, Aug 13 2004, 00:36:58) 
[GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2
IDLE 1.0.3      

When running idle over an ssh link, idle freezes after
an unpredictable length of time. Over 3 days the
longest it has stayed allive for is ~4hrs, but a few
minutes before freezing is the norm. Niether idle nor
python are consuming cpu time once frozen. I can find
no definete recipie to bring about the freeze, although
(I think) there has always been at least one editor
window open when it happens. There is no output on
stderr, or other diagnostics that I can see.

ssh server(ubuntu warty):
OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL
0.9.7d 17 Mar 2004

ssh client (RH9):
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

/best/*

Mark

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2005-03-03 19:28

Message:
Logged In: YES 
user_id=149084

There have been recent reports on idle-dev regarding
IDLE freezing on Debian Sid.  Since ubuntu is Debian
derived, I assume there may be a relationship.

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-02-02 13:50

Message:
Logged In: YES 
user_id=993923

>0.8 doesn't have the problem.  Are you sure?

Can't be certain as haven't used it for extended periods on
that box, but I'll look into it. I've used IDLE daily for
about 4 years on various RH and Suse, and never seen a
problem until now. 

> What else is the ubuntu box doing?  Is the load heavy?
Almost nothing, it's there to evaluate ubuntu as a desktop
w/s, and my main activity is getting some in-house python
s/w ported to it.

gdb results to follow. 

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-02-02 12:21

Message:
Logged In: YES 
user_id=149084

To keep things simple, please start IDLE with the
-n switch directly on your ubuntu box for the
purposes of future investigations on this issue.

Can you attach to the frozen IDLE with gdb and then
use 'bt' to get a backtrace and find out what was
going at at the time of the freeze?  If so, is it
repeatable?  

It's occasionally reported that IDLE freezes.  I've never
seen it myself, running IDLE for many days on OpenBSD,
Debian, RH, and Arch Linux, WindowsXP, W2K, and W98,
over a period of many years, so it's hard for me to figure
out what's going on.  But it's peculiar that 0.8 doesn't have
the problem.  Are you sure?

What else is the ubuntu box doing?  Is the load heavy?

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-02-01 08:35

Message:
Logged In: YES 
user_id=993923

> So if I follow correctly,  IDLE -n freezes on your
ubuntu box without using ssh tunneling.

That is correct. The problem appears exactly the same when
run over ssh though, which, I guess rules out any
gnome/metacity/X wierdness.


> I suspect a hardware problem
I' sceptical about that. There's nothing in dmesg or
/var/log to suggest it, and absolutely no other problems
with the machine in question.

 >Are you starting IDLE from the command line
Yes, but no messages are shown.

> How much memory
255MB, IDLE uses about 3.5% of that on startup, grew to 5.7%
at time of last  crash

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-31 21:01

Message:
Logged In: YES 
user_id=149084

Right, there is no subprocess when you use the -n
switch.  It causes IDLE to run like IDLE 0.8.

So if I follow correctly,  IDLE -n freezes on your
ubuntu box without using ssh tunneling.  I suspect
a hardware problem with that system.

Are you starting IDLE on the ubuntu box from the
command line?  If so, are there any messages left
in the command line window?

How much memory does the ubuntu box have? 
Does 'top' show increasing memory requirement for
the IDLE -n process?

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-01-31 11:46

Message:
Logged In: YES 
user_id=993923

2 - erm forgive me for sounding stupid, but with the -n
switch I see no sub-process, only the Idle process. It still
freezes though, and killing it just kills it.

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-01-31 11:27

Message:
Logged In: YES 
user_id=993923

1 - OK It's not ssh it's ubuntu.

2 - I'll try this with ububtu.
...And by frozen, I assume ...
All Idle windows are unresponsive to screen and kbd events.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-31 01:26

Message:
Logged In: YES 
user_id=149084

Please try two things:
1. Run IDLE directly on the ubuntu machine long
enough to assure there is no problem standalone.

2. Run IDLE on the xclient but start it with the
-n switch so it runs without the subprocess.

When IDLE freezes, walk over to the server and
kill the subprocess.  It should restart itself.  Is the
system still frozen?  And by frozen, I assume you
mean all screen and keyboard events are
unresponsive.

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-01-30 15:06

Message:
Logged In: YES 
user_id=993923


Yes, I've used Idle on that (although only ~ 1 hour) and not
seen the problem there.  

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-01-30 14:43

Message:
Logged In: YES 
user_id=341410

Do you have physical access to the ubuntu warty machine, and
if so, does Idle run very well locally on that machine, not
X forwarded?

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-01-30 12:02

Message:
Logged In: YES 
user_id=993923

Yes, exactly. I'm pretty sure it's not an X/ssh/network problem,
everything else works fine (including Idle 0.8).


Mark

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-01-29 15:23

Message:
Logged In: YES 
user_id=341410

It has been a while since I ran Idle, but I am curious as to
what you mean by "run over ssh".

Do you mean that you have an SSH tunnel to a remote machine,
which forwards X-Windows sessions, and when running Idle
over this, it locks up?

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-01-26 04:15

Message:
Logged In: YES 
user_id=993923

PS - You don't need an editor window open to get the freeze.

M

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 03:45:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 03:45:26 2005
Subject: [ python-Bugs-1138653 ] subprocesss module retains older license
	header
Message-ID: <E1D72oe-0001vr-4o@sc8-sf-web1.sourceforge.net>

Bugs item #1138653, was opened at 2005-02-17 14:46
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tres Seaver (tseaver)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocesss module retains older license header

Initial Comment:
The header of the file seems to imply that the module
is licensed
separately from the standard Python license:


# subprocess - Subprocesses with accessible I/O streams
#
# For more information about this module, see PEP 324.
#
# Copyright (c) 2003-2004 by Peter Astrand
<astrand@lysator.liu.se>
#
# By obtaining, using, and/or copying this software
and/or its
# associated documentation, you agree that you have
read, understood,
# and will comply with the following terms and conditions:
#
# Permission to use, copy, modify, and distribute this
software and
# its associated documentation for any purpose and
without fee is
# hereby granted, provided that the above copyright
notice appears in
# all copies, and that both that copyright notice and
this permission
# notice appear in supporting documentation, and that
the name of the
# author not be used in advertising or publicity
pertaining to
# distribution of the software without specific,
written prior
# permission.
#
# THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE,
# INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS.
# IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
SPECIAL, INDIRECT OR
# CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS
# OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT,
# NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION
# WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-03 18:45

Message:
Logged In: YES 
user_id=357491

Have you signed a contributor agreement yet, Peter?  If you have your 
code has already been relicensed to the PSF under the PSF license.  If 
you haven't you will be asked to eventually and that will retroactively 
relicense your code over to the PSF, essentially negating all of this pre-
existing license.

You can replace the above license if you have signed the contributor 
agreement with:

Copyright 2005 by Peter ?strand.
Licensed to PSF under a Contributor Agreement

Assuming I am right.  =)  You can double-check by emailing 
psf@python.org or ask at PyCon if you are attending.

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-03-03 13:22

Message:
Logged In: YES 
user_id=344921

How should the license header look like, then? Basically,
I've used xmlrpclib.py as an example. Many other modules
have no license header at all, but this might be a problem
when subprocess.py is distributed separately from Python. Or?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 03:55:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 03:55:11 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D72xz-0004Ce-GR@sc8-sf-web2.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 11:48
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-03 21:55

Message:
Logged In: YES 
user_id=593130

After more carefully reading the eval doc in Lib Ref 2.1, I agree 
that it needs improvement.  My suggestions (assuming that my 
experiment-based inferences are correct):

In 
"The expression argument is parsed and evaluated as a Python 
expression (technically speaking, a condition list) using the 
globals and locals dictionaries as global and local name space."
insert "in a new top-level environment" before 'using'. This says 
right-off, even if indirectly, that lexical scoping does not work 
across the eval call.

In
"If the locals dictionary is omitted it defaults to the globals 
dictionary."
insert "only" after "If'.  If both are omitted, it does not so default.  
Add a comma after 'omitted', as in the next sentence.

In
"If both dictionaries are omitted, the expression is executed in 
the environment where eval is called."
replace  "the expression ... is called", which I believe to be 
incorrect as well as misleading, with something like "they default 
to current globals() and locals()."  This parallels the previous 
sentence and is, I believe, more correct.  Within a function, 
locals() is not the current local namespace, and the following 
shows that the difference can make a visible difference:

>>> def g1(): return op.setitem(locals(), 'x', 1), x
...
>>> g1()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in g1
NameError: global name 'x' is not defined
>>> def h1(): return eval("op.setitem(locals(), 'x', 1), x")
...
>>> h1()
(None, 1)

After
"The return value is the result of the evaluated expression. "
add something like
It does not depend on the lexical position of the eval call and 
hence the expression should not contain names that require 
lexical scoping reaching outside the eval call to be valid."

Note that eval scope blocking, the OP's pseudobug, does not 
require a lambda within the eval-ed expression:
>>> def f(x): return lambda: x
...
>>> f(1)()
1
>>> def g(x): return lambda: eval('x')
...
>>> g(1)()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in <lambda>
  File "<string>", line 0, in ?
NameError: name 'x' is not defined

This might be another example for the PEP.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-03 10:29

Message:
Logged In: YES 
user_id=80475

Jeremy, would you update the pep and docs to cover the OP's
examples.



----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-03 06:16

Message:
Logged In: YES 
user_id=432579

>No, this issue is not specific to either eval or lambda:

Right, so let me rephrase: The bug occurs when explicitly
evaluating a lambda expression or function definition
statement using eval or exec. (This is an artifact of
Python's strong separation of statements and expressions.)

If this is done "by design", why cannot I find anything
anywhere describing this? If this is just a documentation
oversight, please say so, but then I would also like to have
an explanation of the behaviour.

The fact remains that

    def f(x): eval('x')

works as expected and

    def f(g): eval('lambda x: g(x)')

does not. Why? Both are evaluated at the same time and use
the same environment to look up their variables. The fact
that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping, because that is how
lambda expressions work.

>If you want Python to work 
>differently, write a PEP or a patch, or raise the question in
>the newsgroup/mailing list.

www.python.org told me that this is the place to report bugs
in Python. If that is wrong, we should change the web site.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-02 17:59

Message:
Logged In: YES 
user_id=593130

No, this issue is not specific to either eval or lambda:

>>> def f(g):
...   exec 'def h(x): return g(x)'
...   return h
...
>>> f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in h
NameError: global name 'g' is not defined

It is specific to creating a function at top-level in a separate 
execution environment, as done, by design, by both eval and 
exec, and with either a def statement or lambda abbreviation 
thereof.

In Python, lexical scoping works because nested functions are 
compiled along with the outer function, so that scoped variables 
can be identified and both functions adjusted so that the coupling 
works.  In particular, the scoped variable has to not be deleted 
when the outer function returns.  Eval/exec compile their string 
only later, when the function is called.

"it works that way because it is the way it works".
Those are your words, not mine.  If you want Python to work 
differently, write a PEP or a patch, or raise the question in the 
newsgroup/mailing list. I'm done discussing it here.

----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-02 11:42

Message:
Logged In: YES 
user_id=432579

No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-01 19:20

Message:
Logged In: YES 
user_id=1230541

Obviously I forgot a statement in my previous comment's 
code example. So here's the complete version:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your 
expected implementation?


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 13:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 12:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 04:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 04:00:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 04:00:39 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D733M-0001uH-Fk@sc8-sf-web4.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-03 20:00
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=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 04:46:27 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 04:46:33 2005
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda
	bodies correctly
Message-ID: <E1D73lj-0006uO-2C@sc8-sf-web3.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 11:48
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-03 22:46

Message:
Logged In: YES 
user_id=593130

"   def f(x): eval('x') works as expected and
    def f(g): eval('lambda x: g(x)') does not. Why?"

For the same reason
  def f(g,s): return eval(s)
 f(lambda x: x, 'lambda x: g(x)')(1)
and
  def g(x): return lambda: eval('x')
do not 'work'.  eval is a builtin C function whose behavior 
depends on its arguments (including the somewhat magical 
defaulting to globals(), local()) and not on its lexical position.

" Both are evaluated at the same time and use
the same environment to look up their variables."

No, the lambda in your second example introduces a new local 
namespace that is different from the one passed in.

" The fact that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping"

The delay and change of scoping are correlated. Evaluation is 
delayed because g is inside a lambda function def which 
introduces a new local scope which does not contain g, even 
though the original one did. 


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-03 21:55

Message:
Logged In: YES 
user_id=593130

After more carefully reading the eval doc in Lib Ref 2.1, I agree 
that it needs improvement.  My suggestions (assuming that my 
experiment-based inferences are correct):

In 
"The expression argument is parsed and evaluated as a Python 
expression (technically speaking, a condition list) using the 
globals and locals dictionaries as global and local name space."
insert "in a new top-level environment" before 'using'. This says 
right-off, even if indirectly, that lexical scoping does not work 
across the eval call.

In
"If the locals dictionary is omitted it defaults to the globals 
dictionary."
insert "only" after "If'.  If both are omitted, it does not so default.  
Add a comma after 'omitted', as in the next sentence.

In
"If both dictionaries are omitted, the expression is executed in 
the environment where eval is called."
replace  "the expression ... is called", which I believe to be 
incorrect as well as misleading, with something like "they default 
to current globals() and locals()."  This parallels the previous 
sentence and is, I believe, more correct.  Within a function, 
locals() is not the current local namespace, and the following 
shows that the difference can make a visible difference:

>>> def g1(): return op.setitem(locals(), 'x', 1), x
...
>>> g1()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in g1
NameError: global name 'x' is not defined
>>> def h1(): return eval("op.setitem(locals(), 'x', 1), x")
...
>>> h1()
(None, 1)

After
"The return value is the result of the evaluated expression. "
add something like
It does not depend on the lexical position of the eval call and 
hence the expression should not contain names that require 
lexical scoping reaching outside the eval call to be valid."

Note that eval scope blocking, the OP's pseudobug, does not 
require a lambda within the eval-ed expression:
>>> def f(x): return lambda: x
...
>>> f(1)()
1
>>> def g(x): return lambda: eval('x')
...
>>> g(1)()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in <lambda>
  File "<string>", line 0, in ?
NameError: name 'x' is not defined

This might be another example for the PEP.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-03 10:29

Message:
Logged In: YES 
user_id=80475

Jeremy, would you update the pep and docs to cover the OP's
examples.



----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-03 06:16

Message:
Logged In: YES 
user_id=432579

>No, this issue is not specific to either eval or lambda:

Right, so let me rephrase: The bug occurs when explicitly
evaluating a lambda expression or function definition
statement using eval or exec. (This is an artifact of
Python's strong separation of statements and expressions.)

If this is done "by design", why cannot I find anything
anywhere describing this? If this is just a documentation
oversight, please say so, but then I would also like to have
an explanation of the behaviour.

The fact remains that

    def f(x): eval('x')

works as expected and

    def f(g): eval('lambda x: g(x)')

does not. Why? Both are evaluated at the same time and use
the same environment to look up their variables. The fact
that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping, because that is how
lambda expressions work.

>If you want Python to work 
>differently, write a PEP or a patch, or raise the question in
>the newsgroup/mailing list.

www.python.org told me that this is the place to report bugs
in Python. If that is wrong, we should change the web site.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-02 17:59

Message:
Logged In: YES 
user_id=593130

No, this issue is not specific to either eval or lambda:

>>> def f(g):
...   exec 'def h(x): return g(x)'
...   return h
...
>>> f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in h
NameError: global name 'g' is not defined

It is specific to creating a function at top-level in a separate 
execution environment, as done, by design, by both eval and 
exec, and with either a def statement or lambda abbreviation 
thereof.

In Python, lexical scoping works because nested functions are 
compiled along with the outer function, so that scoped variables 
can be identified and both functions adjusted so that the coupling 
works.  In particular, the scoped variable has to not be deleted 
when the outer function returns.  Eval/exec compile their string 
only later, when the function is called.

"it works that way because it is the way it works".
Those are your words, not mine.  If you want Python to work 
differently, write a PEP or a patch, or raise the question in the 
newsgroup/mailing list. I'm done discussing it here.

----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-02 11:42

Message:
Logged In: YES 
user_id=432579

No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-01 19:20

Message:
Logged In: YES 
user_id=1230541

Obviously I forgot a statement in my previous comment's 
code example. So here's the complete version:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your 
expected implementation?


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 13:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 12:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 04:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 05:11:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 05:11:06 2005
Subject: [ python-Bugs-1156430 ] doctest should support -m
Message-ID: <E1D749W-0004gt-UY@sc8-sf-web1.sourceforge.net>

Bugs item #1156430, was opened at 2005-03-03 22:11
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=1156430&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Bicking (ianbicking)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest should support -m

Initial Comment:
It would be nice if "python -m doctest a_file.py" would
run doctest on that file (either a Python module or a
text file).  Right now it runs doctests on itself.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156430&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 05:44:10 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 05:44:13 2005
Subject: [ python-Bugs-1156441 ] Solaris and Python/pykota
Message-ID: <E1D74fa-0000QW-Dx@sc8-sf-web3.sourceforge.net>

Bugs item #1156441, was opened at 2005-03-04 12: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=1156441&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kelly Ormsby (ormsbyka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris and Python/pykota

Initial Comment:
I have a Solaris 9 system that I have installed Python
2.4 on with the following modules:
egenix-mx-base 2.0.6
jaxml3.0.1
python-snmp 3.4.3
psyco 1.4
reportlab 1.20
and postgresql 3.6.1
net-snmp 5.2.1
which are all required by pykota (a print quota
management system)

I am having the issue that when pykota is plugged in to
my cups system, and I try to print, the print job is
put on hold and printing to that printer is stopped.

I tried running the pykota software from the command
line to see what is causing the problem and from what I
(and Jerome Alet from librelogiciel.com) can work out
it is a problem with the solaris build of python.

I have used gcc 3.3 and binutils 2.14 to build python.

The following is what happens when I try running from
the command line:

#python /usr/local/pykota/pykota/pdlanalyzer.py --debug
~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped)
# pkpgcounter --debug ~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped) 

I have attached the pdlanalyzer.py file for you to look at.

Please let me know what I should do.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 09:24:46 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 09:24:48 2005
Subject: [ python-Feature Requests-1156499 ] __getattr__ and __setattr__
	methods for modules
Message-ID: <E1D7874-0003jb-9x@sc8-sf-web4.sourceforge.net>

Feature Requests item #1156499, was opened at 2005-03-04 09:24
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=1156499&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Reinhold Birkenfeld (birkenfeld)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getattr__ and __setattr__ methods for modules

Initial Comment:
Wouldn't it be a good addition if modules supported
__getattr__ and __setattr__?

In this way, one could easily write modules that
dispatch calls to different objects and/or modules,
such as a "global" module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1156499&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 10:56:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 10:56:12 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1D79XO-0000nV-Tn@sc8-sf-web1.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Martin v. L?wis (loewis)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56

Message:
Logged In: YES 
user_id=38388

This is obviously related to the buffer logic that Walter added
to support .readline().

In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 11:17:14 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 11:17:25 2005
Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow
Message-ID: <E1D79ru-00040I-Er@sc8-sf-web2.sourceforge.net>

Bugs item #1124637, was opened at 2005-02-17 11:10
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Peter ?strand (astrand)
Summary: test_subprocess is far too slow

Initial Comment:
test_subprocess takes multiple minutes.  I'm pretty
sure it's "test_no_leaking".  It should either be sped
up or only tested when some -u argument is passed to
regrtest.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-04 10:17

Message:
Logged In: YES 
user_id=6656

Thank you!

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-03-03 20:58

Message:
Logged In: YES 
user_id=344921

Forgot to close. 

----------------------------------------------------------------------

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-03-03 20:54

Message:
Logged In: YES 
user_id=1188172

Shouldn't it be closed then?

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-03-03 20:53

Message:
Logged In: YES 
user_id=344921

Fixed in HEAD revisions:
regrtest.py: 1.166
1.19

Fixed in 2.4 revisions:
regrtest.py: 1.165.2.1
test_subprocess.py: 1.15.2.2


----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-02-17 15:17

Message:
Logged In: YES 
user_id=344921

tim_one: test_subprocess only creates 65 processes on
Windows, compared to 1026 for UNIX. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-02-17 15:13

Message:
Logged In: YES 
user_id=31435

Peculiar -- test_subprocess takes about 8 seconds on my 
WinXP box release build, about 10 seconds debug build, and 
Windows is notorious for slow process creation.  That's a 
zippy 3.4 GHz P4, but clock rate alone can't account for such 
a large speed difference.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-02-17 13:16

Message:
Logged In: YES 
user_id=29957

I'm with mwh. This test should be enabled with an option -
I'd noticed that test_subprocess took a long time, but
hadn't bothered to track it down.

Before releases (and at other times) I always try to make
sure that I run 'make testall', but for day-to-day use, this
is too slow.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-17 12:09

Message:
Logged In: YES 
user_id=6656

Bog standard linux pc -- p3 933, 384 megs of ram.

"$ time ./python ../Lib/test/regrtest.py test_subprocess"
reports 2 minutes 7.  This is a debug build, a release build
might be quicker.  A run of the entire test suite takes a
hair over nine minutes, so 20-odd % of the time seems to be
test_subprocess.

It also takes ages on my old-ish ibook (600 Mhz G3, also 384
megs of ram), but that's at home and I can't time it.

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-02-17 11:50

Message:
Logged In: YES 
user_id=344921

Tell me a bit about your type of OS and hardware. On my
machine (P4 2.66 GHz with Linux), the test takes 28 seconds. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 11:34:10 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 11:34:14 2005
Subject: [ python-Bugs-1156441 ] Solaris and Python/pykota
Message-ID: <E1D7A8I-0000WP-NB@sc8-sf-web4.sourceforge.net>

Bugs item #1156441, was opened at 2005-03-04 04:44
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kelly Ormsby (ormsbyka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris and Python/pykota

Initial Comment:
I have a Solaris 9 system that I have installed Python
2.4 on with the following modules:
egenix-mx-base 2.0.6
jaxml3.0.1
python-snmp 3.4.3
psyco 1.4
reportlab 1.20
and postgresql 3.6.1
net-snmp 5.2.1
which are all required by pykota (a print quota
management system)

I am having the issue that when pykota is plugged in to
my cups system, and I try to print, the print job is
put on hold and printing to that printer is stopped.

I tried running the pykota software from the command
line to see what is causing the problem and from what I
(and Jerome Alet from librelogiciel.com) can work out
it is a problem with the solaris build of python.

I have used gcc 3.3 and binutils 2.14 to build python.

The following is what happens when I try running from
the command line:

#python /usr/local/pykota/pykota/pdlanalyzer.py --debug
~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped)
# pkpgcounter --debug ~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped) 

I have attached the pdlanalyzer.py file for you to look at.

Please let me know what I should do.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-04 10:34

Message:
Logged In: YES 
user_id=6656

Well, that's kind of a large module for us to pick at...

Does it only crash on certain postscript files?  Can you run
it under a debugger/analyze a core file to see where it's
crashing?  Does it only crash with 2.4.0 -- can you try
2.3/release24-maint from CVS/CVS HEAD?

It doesn't crash for me with any of the ps files I happen to
have lying around with release24-maint head (what will soon
be 2.4.1) on linux.  I don't have a version 2.4.0 lying
around though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 12:44:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 12:45:01 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1D7BEl-0003M3-Or@sc8-sf-web4.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Martin v. L?wis (loewis)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-04 12:44

Message:
Logged In: YES 
user_id=89016

How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56

Message:
Logged In: YES 
user_id=38388

This is obviously related to the buffer logic that Walter added
to support .readline().

In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 15:41:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 15:41:52 2005
Subject: [ python-Bugs-925152 ] buffer problem in
	pyexpat.c(xmlparse_GetInputContext)
Message-ID: <E1D7Dzv-0000g7-9q@sc8-sf-web3.sourceforge.net>

Bugs item #925152, was opened at 2004-03-29 08:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925152&group_id=5470

Category: XML
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 7
Submitted By: Tobias Sargeant (tobiasjs)
Assigned to: Martin v. L?wis (loewis)
Summary: buffer problem in pyexpat.c(xmlparse_GetInputContext)

Initial Comment:
xmlparse_GetInputContext doesn't adjust the bounds of the 
substring it returns, leading to the python string result hanging off 
one or more ends of the buffer & associated nastiness.

2 line fix attached.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-04 15:41

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. This was just resubmitted as #1118602,
which I have
applied. Your patch also checks whether offset is negative;
I believe this cannot happen.

Committed as

pyexpat.c 2.90 and 2.89.2.1
NEWS 1.1264 and 1.1193.2.31

Sorry this took so long; it would have caught my attention
earlier if it was in the patches tracker, not the bugs tracker.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925152&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 16:53:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 16:53:42 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D7F7Q-0002zO-Mv@sc8-sf-web2.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-04 13:00
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-05 01:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 17:11:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 17:11:39 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D7FOq-00064Z-5F@sc8-sf-web3.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-03 20:00
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

>Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 09:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 08:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 19:05:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 19:05:56 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D7HBR-0000Vv-DP@sc8-sf-web2.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-04 03:00
Message generated for change (Comment added) made by orenti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2005-03-04 18:05

Message:
Logged In: YES 
user_id=562624

"The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple."

You might like to rephrase that. It gives the impression
that __new__ somehow makes it possible to modify the value
of an immutable object. In fact, it only allows customized
creation of new instances.


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 16:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 15:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 21:15:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 21:15:43 2005
Subject: [ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Message-ID: <E1D7JD2-0000yD-6R@sc8-sf-web3.sourceforge.net>

Bugs item #1105699, was opened at 2005-01-20 01:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470

Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Warnings in Python.h with gcc 4.0.0

Initial Comment:
(this happens for every file that includes Python.h)

In file included from ../Include/Python.h:55,
                 from ../Objects/intobject.c:4:
../Include/pyport.h:396: warning: 'struct winsize' declared inside 
parameter list
../Include/pyport.h:397: warning: 'struct winsize' declared inside 
parameter list

The source lines look like this:
extern int openpty(int *, int *, char *, struct termios *, struct 
winsize *);
extern int forkpty(int *, char *, struct termios *, struct winsize *);

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-04 21:15

Message:
Logged In: YES 
user_id=21627

What operating system is this on? struct winsize should have
been included through <termios.h>. Then, the mentioning of
it in the propotypes is not a declaration, just a reference.

So if you get this warning, it probably indicates a problem
with your system headers.

----------------------------------------------------------------------

Comment By: Richard Kettlewell (rjk1002)
Date: 2005-01-31 16:43

Message:
Logged In: YES 
user_id=217390

C does guarantee that all struct pointers share the same
*representation* (section 6.2.5 of C99).  That's not what
the compiler is complaining about here.
Rather, a struct declared inside a parameter list is
restricted in scope to that parameter list, and so is not
the same structure as one declared outside it, even if the
tag is the same.
The solution is to forward-declare the struct (as an
incomplete type, i.e. just "struct winsize;") before any of
the declarations that use it.  Then the struct tag will mean
the same thing in every scope.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-01-21 00:13

Message:
Logged In: YES 
user_id=31435

The warning almost certainly means that there's no 
declaration of struct winsize in scope when these externs are 
declared.  That's bad, because C doesn't guarantee that all 
pointers are the same size (although they are on all Python 
platforms I'm aware of).

Some quality time with Google suggested that other projects 
wormed around this by #include'ing <termio.h> instead of 
<termios.h>, because the former but not the latter #include's 
<sys/ioctl.h> where the winsize struct was defined.  Beats 
me -- ain't a Windows problem <wink>.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-01-20 23:49

Message:
Logged In: YES 
user_id=139309

Beats me, it's probably just "bad style".

It's a problem because it shows up a lot in the output, so we should at 
least figure out how to disable this warning so that it doesn't become 
annoying.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-01-20 16:18

Message:
Logged In: YES 
user_id=6656

Why is this a problem?  Is it not valid C or something?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470
From noreply at sourceforge.net  Fri Mar  4 21:19:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  4 21:19:29 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D7JGg-0001A5-I9@sc8-sf-web3.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-03 20:00
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

>Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 13:19

Message:
Logged In: YES 
user_id=945502

Good point.  How about:

"The __new__ staticmethod is intended mainly to allow you,
in a subclass of an immutable type (like int, long, float,
complex, str, unicode, or tuple), to customize instance
creation."

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2005-03-04 11:05

Message:
Logged In: YES 
user_id=562624

"The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple."

You might like to rephrase that. It gives the impression
that __new__ somehow makes it possible to modify the value
of an immutable object. In fact, it only allows customized
creation of new instances.


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 09:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 08:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Sat Mar  5 05:02:38 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  5 05:02:42 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D7QUw-00025C-2X@sc8-sf-web4.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-04 13:00
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-05 14:02

Message:
Logged In: YES 
user_id=1038590

Close, but the phrasing's a bit awkward. Getting rid of the
commas seems to fix that:

"The __new__ staticmethod is intended mainly to allow you to
customize instance creation in a subclass of an immutable
type (like int, long, float, complex, str, unicode, or tuple)."

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-05 06:19

Message:
Logged In: YES 
user_id=945502

Good point.  How about:

"The __new__ staticmethod is intended mainly to allow you,
in a subclass of an immutable type (like int, long, float,
complex, str, unicode, or tuple), to customize instance
creation."

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2005-03-05 04:05

Message:
Logged In: YES 
user_id=562624

"The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple."

You might like to rephrase that. It gives the impression
that __new__ somehow makes it possible to modify the value
of an immutable object. In fact, it only allows customized
creation of new instances.


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-05 02:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-05 01:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Sat Mar  5 09:14:28 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  5 09:14:32 2005
Subject: [ python-Bugs-1157169 ] csv Sniffer returns bad dialect?
Message-ID: <E1D7UQe-0004lH-Pr@sc8-sf-web1.sourceforge.net>

Bugs item #1157169, was opened at 2005-03-05 08:14
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=1157169&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Nobody/Anonymous (nobody)
Summary: csv Sniffer returns bad dialect?

Initial Comment:

>>> d = csv.Sniffer().sniff('abc', ['\t', ','])
>>> csv.reader(['abc'], d)       
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation

If the 'delimiters' argument to sniff() is left out
then the TypeError is not raised.  Not sure what's
going on here.

A few other nits:

sniff() seems to be misdocumented.  It cannot return None.

What's the point of the Sniff class?  Why isn't sniff()
a module level function?

The library manual does not state what the iterator
returned by reader() returns.  It should state that
generates lists of strings.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157169&group_id=5470
From noreply at sourceforge.net  Sat Mar  5 14:23:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  5 14:23:09 2005
Subject: [ python-Bugs-1157255 ] PEP 328 and Python 2.4 error
Message-ID: <E1D7ZFK-0007Zk-P9@sc8-sf-web3.sourceforge.net>

Bugs item #1157255, was opened at 2005-03-05 13:23
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=1157255&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 328 and Python 2.4 error

Initial Comment:
PEP 328 says that 
from __future__ import absolute_import

will be part of Python 2.4, but it is not:

D:\Projects\CB>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
 >>> from __future__ import absolute_import
  File "<stdin>", line 1
SyntaxError: future feature absolute_import is not defined

The PEP should be updated to reflect this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157255&group_id=5470
From noreply at sourceforge.net  Sat Mar  5 17:11:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  5 17:11:35 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D7bsJ-0004ap-SV@sc8-sf-web1.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-03 22:00
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-05 11:11

Message:
Logged In: YES 
user_id=14422

I think that last paragraph can be written even more concisely:

"The __new__ staticmethod is intended mainly to allow
subclasses of immutable types (like int, str, or tuple) to
customize instance creation."

Also, the usual convention when talking about methods and
functions is to write "__new__()", not "__new__".  At least
that's how the 2.3.3 language ref which I have on my PC looks.

Finally, this bug is in the "Python 2.5" group -- surely
there's no harm in checking this in to the 2.4 docs and
merging forward?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 23:02

Message:
Logged In: YES 
user_id=1038590

Close, but the phrasing's a bit awkward. Getting rid of the
commas seems to fix that:

"The __new__ staticmethod is intended mainly to allow you to
customize instance creation in a subclass of an immutable
type (like int, long, float, complex, str, unicode, or tuple)."

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 15:19

Message:
Logged In: YES 
user_id=945502

Good point.  How about:

"The __new__ staticmethod is intended mainly to allow you,
in a subclass of an immutable type (like int, long, float,
complex, str, unicode, or tuple), to customize instance
creation."

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2005-03-04 13:05

Message:
Logged In: YES 
user_id=562624

"The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple."

You might like to rephrase that. It gives the impression
that __new__ somehow makes it possible to modify the value
of an immutable object. In fact, it only allows customized
creation of new instances.


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 11:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 10:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Sat Mar  5 17:34:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  5 17:34:14 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D7cEF-000635-GM@sc8-sf-web3.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-03 22:00
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-05 11:34

Message:
Logged In: YES 
user_id=14422

Here's an alternative text -- a bit tighter, hopefully a tad
more accurate and clearer:

__new__(cls[, ...])

Called to create a new instance of class 'cls'.  __new__()
is a static method (special-cased so you need not declare it
as such) that takes the class to create an instance of as
the first argument.  The remaining arguments are those
passed to the object constructor expression.  The return
value of __new__() should be the new object instance.

Typical usage is to create a new instance of the class by
invoking the superclass's __new__() method using
"super(currentclass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if necessary, and
then returning it.  If the returned value is an instance of
'cls', its __init__() will be invoked like
"__init__(self[, ...])", where the extra arguments are the
same as were passed to __new__().

You do need not to return an instance of 'cls', but if you
do not, the new instance's __init__() method will not be
invoked.

__new__() is intended mainly to allow subclasses of
immutable types (like int, str, or tuple) to customize
instance creation.


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-05 11:11

Message:
Logged In: YES 
user_id=14422

I think that last paragraph can be written even more concisely:

"The __new__ staticmethod is intended mainly to allow
subclasses of immutable types (like int, str, or tuple) to
customize instance creation."

Also, the usual convention when talking about methods and
functions is to write "__new__()", not "__new__".  At least
that's how the 2.3.3 language ref which I have on my PC looks.

Finally, this bug is in the "Python 2.5" group -- surely
there's no harm in checking this in to the 2.4 docs and
merging forward?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 23:02

Message:
Logged In: YES 
user_id=1038590

Close, but the phrasing's a bit awkward. Getting rid of the
commas seems to fix that:

"The __new__ staticmethod is intended mainly to allow you to
customize instance creation in a subclass of an immutable
type (like int, long, float, complex, str, unicode, or tuple)."

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 15:19

Message:
Logged In: YES 
user_id=945502

Good point.  How about:

"The __new__ staticmethod is intended mainly to allow you,
in a subclass of an immutable type (like int, long, float,
complex, str, unicode, or tuple), to customize instance
creation."

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2005-03-04 13:05

Message:
Logged In: YES 
user_id=562624

"The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple."

You might like to rephrase that. It gives the impression
that __new__ somehow makes it possible to modify the value
of an immutable object. In fact, it only allows customized
creation of new instances.


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 11:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 10:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Sat Mar  5 17:54:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  5 17:54:09 2005
Subject: [ python-Bugs-818006 ] ossaudiodev FileObject does not support
	closed const
Message-ID: <E1D7cXV-0006kr-Kh@sc8-sf-web3.sourceforge.net>

Bugs item #818006, was opened at 2003-10-05 02:30
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470

Category: Extension Modules
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Greg Ward (gward)
Summary: ossaudiodev FileObject does not support closed const

Initial Comment:
fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2003-10-05 16:32

Message:
Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
&quot;&quot;&quot; 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
&quot;&quot; 
 
&quot;Should be&quot; when they &quot;make sense&quot;  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO &quot;should&quot; 
have worked.  : P 
 
Other attributes that &quot;should be&quot; implemented  (mode and 
name) because they &quot;make sense&quot; may also be missing...I 
haven't checked.  
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-10-05 16:16

Message:
Logged In: YES 
user_id=593130

>From Lib Ref 14.11 ossaudiodev &quot;open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
&quot;
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470
From noreply at sourceforge.net  Sat Mar  5 19:08:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  5 19:08:42 2005
Subject: [ python-Bugs-818006 ] ossaudiodev FileObject does not support
	closed const
Message-ID: <E1D7dhc-0000vQ-GF@sc8-sf-web3.sourceforge.net>

Bugs item #818006, was opened at 2003-10-05 02:30
Message generated for change (Comment added) made by dcinege
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Greg Ward (gward)
Summary: ossaudiodev FileObject does not support closed const

Initial Comment:
fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

----------------------------------------------------------------------

>Comment By: Dave Cinege (dcinege)
Date: 2005-03-05 13:08

Message:
Logged In: YES 
user_id=314434

That was the point of the bug report. It has no closed 
or other file-like attributes. According the python docs 
then and current: 
'File objects also offer a number of other interesting 
attributes. These are not required for file-like objects, 
but should be implemented if they make sense for 
the particular object. ' 
 
I take that to mean these attributes are mandatory, 
unless it does not make sense to implement them. 
 
In the case of file-like Audio Device Objects, they 
make sense, and thus should be there.  
 
Either this statement of file-like object policy is a bug, 
or the lack of such attributes in Audio Device Objects 
is a bug.  
 

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2003-10-05 16:32

Message:
Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
&quot;&quot;&quot; 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
&quot;&quot; 
 
&quot;Should be&quot; when they &quot;make sense&quot;  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO &quot;should&quot; 
have worked.  : P 
 
Other attributes that &quot;should be&quot; implemented  (mode and 
name) because they &quot;make sense&quot; may also be missing...I 
haven't checked.  
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-10-05 16:16

Message:
Logged In: YES 
user_id=593130

>From Lib Ref 14.11 ossaudiodev &quot;open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
&quot;
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470
From noreply at sourceforge.net  Sat Mar  5 21:30:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  5 21:31:01 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D7fvO-0006xc-H8@sc8-sf-web4.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-03 20:00
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

>Comment By: Steven Bethard (bediviere)
Date: 2005-03-05 13:30

Message:
Logged In: YES 
user_id=945502

Looks pretty good to me.  Only one change:
    "super(currentclass, cls).__new__([...])"
should look like:
    "super(currentclass, cls).__new__(cls[, ...])"
Sorry I didn't catch this earlier.  But, since it's a
staticmethod, of course you need to pass 'cls' manually.


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-05 09:34

Message:
Logged In: YES 
user_id=14422

Here's an alternative text -- a bit tighter, hopefully a tad
more accurate and clearer:

__new__(cls[, ...])

Called to create a new instance of class 'cls'.  __new__()
is a static method (special-cased so you need not declare it
as such) that takes the class to create an instance of as
the first argument.  The remaining arguments are those
passed to the object constructor expression.  The return
value of __new__() should be the new object instance.

Typical usage is to create a new instance of the class by
invoking the superclass's __new__() method using
"super(currentclass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if necessary, and
then returning it.  If the returned value is an instance of
'cls', its __init__() will be invoked like
"__init__(self[, ...])", where the extra arguments are the
same as were passed to __new__().

You do need not to return an instance of 'cls', but if you
do not, the new instance's __init__() method will not be
invoked.

__new__() is intended mainly to allow subclasses of
immutable types (like int, str, or tuple) to customize
instance creation.


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-05 09:11

Message:
Logged In: YES 
user_id=14422

I think that last paragraph can be written even more concisely:

"The __new__ staticmethod is intended mainly to allow
subclasses of immutable types (like int, str, or tuple) to
customize instance creation."

Also, the usual convention when talking about methods and
functions is to write "__new__()", not "__new__".  At least
that's how the 2.3.3 language ref which I have on my PC looks.

Finally, this bug is in the "Python 2.5" group -- surely
there's no harm in checking this in to the 2.4 docs and
merging forward?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 21:02

Message:
Logged In: YES 
user_id=1038590

Close, but the phrasing's a bit awkward. Getting rid of the
commas seems to fix that:

"The __new__ staticmethod is intended mainly to allow you to
customize instance creation in a subclass of an immutable
type (like int, long, float, complex, str, unicode, or tuple)."

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 13:19

Message:
Logged In: YES 
user_id=945502

Good point.  How about:

"The __new__ staticmethod is intended mainly to allow you,
in a subclass of an immutable type (like int, long, float,
complex, str, unicode, or tuple), to customize instance
creation."

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2005-03-04 11:05

Message:
Logged In: YES 
user_id=562624

"The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple."

You might like to rephrase that. It gives the impression
that __new__ somehow makes it possible to modify the value
of an immutable object. In fact, it only allows customized
creation of new instances.


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 09:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 08:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Sat Mar  5 21:48:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  5 21:48:24 2005
Subject: [ python-Bugs-818006 ] ossaudiodev FileObject does not support
	closed const
Message-ID: <E1D7gCC-0005tr-1E@sc8-sf-web3.sourceforge.net>

Bugs item #818006, was opened at 2003-10-05 02:30
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Greg Ward (gward)
Summary: ossaudiodev FileObject does not support closed const

Initial Comment:
fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-05 15:48

Message:
Logged In: YES 
user_id=593130

I am not sure who your last comment is aimed at.  As near as I 
can tell, Greg merely updated the group to Py2.4, implying that 
this issue is still relevant.

In Pythonese, should is advisory; only must is mandatory.  So I 
see this as a request for a pre-approved enhancement.  Since 
ossaudiodevice directly wraps an OS open file descripter, rather 
than a Python file object, the patch is more than a triviality.

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-05 13:08

Message:
Logged In: YES 
user_id=314434

That was the point of the bug report. It has no closed 
or other file-like attributes. According the python docs 
then and current: 
'File objects also offer a number of other interesting 
attributes. These are not required for file-like objects, 
but should be implemented if they make sense for 
the particular object. ' 
 
I take that to mean these attributes are mandatory, 
unless it does not make sense to implement them. 
 
In the case of file-like Audio Device Objects, they 
make sense, and thus should be there.  
 
Either this statement of file-like object policy is a bug, 
or the lack of such attributes in Audio Device Objects 
is a bug.  
 

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2003-10-05 16:32

Message:
Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
&quot;&quot;&quot; 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
&quot;&quot; 
 
&quot;Should be&quot; when they &quot;make sense&quot;  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO &quot;should&quot; 
have worked.  : P 
 
Other attributes that &quot;should be&quot; implemented  (mode and 
name) because they &quot;make sense&quot; may also be missing...I 
haven't checked.  
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-10-05 16:16

Message:
Logged In: YES 
user_id=593130

>From Lib Ref 14.11 ossaudiodev &quot;open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
&quot;
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 05:31:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 05:31:15 2005
Subject: [ python-Bugs-1157576 ] pickle errors
Message-ID: <E1D7nQ7-0007Nv-Rg@sc8-sf-web3.sourceforge.net>

Bugs item #1157576, was opened at 2005-03-05 23:31
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=1157576&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Laxori666 (laxori666)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle errors

Initial Comment:
pickle is giving me an error while I'm trying to
serialize a dictionary.
Here is the dictionary:
>>> a
{' ': (0, 2), '(': (858, 10), ',': (480, 9), '0': (327,
9), '4': (1393, 11), '8': (1396, 11), '@': (3496, 13),
'D': (212, 8), 'H': (1749, 12), 'L': (328, 9), 'P':
(344, 9), 'T': (215, 8), 'X': (4041, 12), '\': (859,
10), 'd': (16, 5), 'h': (61, 6), 'l': (17, 5), 'p':
(19, 6), 't': (5, 4), 'x': (83, 7), '#': (2632, 12),
"'": (330, 9), '+': (2633, 12), '/': (160, 8), '3':
(697, 10), '7': (2796, 12), '?': (2634, 12), 'C': (175,
8), 'G': (659, 10), 'K': (5571, 13), 'O': (173, 8),
'S': (241, 8), 'W': (662, 10), '[': (144, 9), 'c': (8,
5), 'g': (127, 7), 'k': (161, 8), 'o': (9, 4), 's':
(22, 5), 'w': (104, 7), '\n': (14, 5), '"': (162, 8),
'.': (26, 6), '2': (219, 9), '6': (1399, 11), ':':
(253, 8), 'B': (108, 8), 'F': (426, 9), 'J': (3497,
13), 'N': (146, 9), 'R': (326, 9), 'V': (875, 11), 'Z':
(8080, 13), 'b': (105, 7), 'f': (42, 6), '\xe9': (5570,
13), 'j': (8081, 13), 'n': (27, 5), 'r': (23, 5), 'v':
(37, 7), 'z': (663, 10), '~': (2635, 12), '\t': (2021,
11), '!': (1397, 11), '%': (2784, 12), ')': (1008, 10),
'-': (55, 7), '1': (1009, 10), '5': (4046, 12), '9':
(2797, 12), '=': (15, 5), 'A': (428, 9), 'E': (147, 9),
'I': (481, 9), 'M': (427, 9), 'Q': (436, 10), 'U':
(345, 9), 'Y': (2022, 11), ']': (145, 9), 'a': (29, 5),
'e': (12, 4), 'i': (28, 5), 'm': (62, 6), 'q': (4047,
12), 'u': (12, 5), 'y': (121, 7)}
Here is the series of commands I issue, resulting in an
error:

>>> afile = open("afile", "wb")
>>> p=pickle.Pickler(afile)
>>> p.save(a)
>>> afile.close()
>>> afile = open("afile", "rb")
>>> p=pickle.Unpickler(afile)
>>> a2 = p.load()
Traceback (most recent call last):
  File "<pyshell#69>", line 1, in ?
    a2 = p.load()
  File "H:\Python24\lib\pickle.py", line 872, in load
    dispatch[key](self)
  File "H:\Python24\lib\pickle.py", line 894, in load_eof
    raise EOFError
EOFError

Am I doing something wrong or is this pickle's fault?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157576&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 05:34:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 05:34:50 2005
Subject: [ python-Bugs-1157576 ] pickle errors
Message-ID: <E1D7nTb-0007ou-GE@sc8-sf-web1.sourceforge.net>

Bugs item #1157576, was opened at 2005-03-05 23:31
Message generated for change (Comment added) made by laxori666
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157576&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Laxori666 (laxori666)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle errors

Initial Comment:
pickle is giving me an error while I'm trying to
serialize a dictionary.
Here is the dictionary:
>>> a
{' ': (0, 2), '(': (858, 10), ',': (480, 9), '0': (327,
9), '4': (1393, 11), '8': (1396, 11), '@': (3496, 13),
'D': (212, 8), 'H': (1749, 12), 'L': (328, 9), 'P':
(344, 9), 'T': (215, 8), 'X': (4041, 12), '\': (859,
10), 'd': (16, 5), 'h': (61, 6), 'l': (17, 5), 'p':
(19, 6), 't': (5, 4), 'x': (83, 7), '#': (2632, 12),
"'": (330, 9), '+': (2633, 12), '/': (160, 8), '3':
(697, 10), '7': (2796, 12), '?': (2634, 12), 'C': (175,
8), 'G': (659, 10), 'K': (5571, 13), 'O': (173, 8),
'S': (241, 8), 'W': (662, 10), '[': (144, 9), 'c': (8,
5), 'g': (127, 7), 'k': (161, 8), 'o': (9, 4), 's':
(22, 5), 'w': (104, 7), '\n': (14, 5), '"': (162, 8),
'.': (26, 6), '2': (219, 9), '6': (1399, 11), ':':
(253, 8), 'B': (108, 8), 'F': (426, 9), 'J': (3497,
13), 'N': (146, 9), 'R': (326, 9), 'V': (875, 11), 'Z':
(8080, 13), 'b': (105, 7), 'f': (42, 6), '\xe9': (5570,
13), 'j': (8081, 13), 'n': (27, 5), 'r': (23, 5), 'v':
(37, 7), 'z': (663, 10), '~': (2635, 12), '\t': (2021,
11), '!': (1397, 11), '%': (2784, 12), ')': (1008, 10),
'-': (55, 7), '1': (1009, 10), '5': (4046, 12), '9':
(2797, 12), '=': (15, 5), 'A': (428, 9), 'E': (147, 9),
'I': (481, 9), 'M': (427, 9), 'Q': (436, 10), 'U':
(345, 9), 'Y': (2022, 11), ']': (145, 9), 'a': (29, 5),
'e': (12, 4), 'i': (28, 5), 'm': (62, 6), 'q': (4047,
12), 'u': (12, 5), 'y': (121, 7)}
Here is the series of commands I issue, resulting in an
error:

>>> afile = open("afile", "wb")
>>> p=pickle.Pickler(afile)
>>> p.save(a)
>>> afile.close()
>>> afile = open("afile", "rb")
>>> p=pickle.Unpickler(afile)
>>> a2 = p.load()
Traceback (most recent call last):
  File "<pyshell#69>", line 1, in ?
    a2 = p.load()
  File "H:\Python24\lib\pickle.py", line 872, in load
    dispatch[key](self)
  File "H:\Python24\lib\pickle.py", line 894, in load_eof
    raise EOFError
EOFError

Am I doing something wrong or is this pickle's fault?

----------------------------------------------------------------------

>Comment By: Laxori666 (laxori666)
Date: 2005-03-05 23:34

Message:
Logged In: YES 
user_id=1209371

NOTE: doing this using cPickle works without a problem. Also
note that the file is 2KB smaller under cPickle. If they are
supposed to be using the same stream, I think that is a
problem (the same protocol argument was used for both)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157576&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 06:04:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 06:04:45 2005
Subject: [ python-Bugs-1157576 ] pickle errors
Message-ID: <E1D7nwY-000844-OZ@sc8-sf-web2.sourceforge.net>

Bugs item #1157576, was opened at 2005-03-05 23:31
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157576&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Laxori666 (laxori666)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle errors

Initial Comment:
pickle is giving me an error while I'm trying to
serialize a dictionary.
Here is the dictionary:
>>> a
{' ': (0, 2), '(': (858, 10), ',': (480, 9), '0': (327,
9), '4': (1393, 11), '8': (1396, 11), '@': (3496, 13),
'D': (212, 8), 'H': (1749, 12), 'L': (328, 9), 'P':
(344, 9), 'T': (215, 8), 'X': (4041, 12), '\': (859,
10), 'd': (16, 5), 'h': (61, 6), 'l': (17, 5), 'p':
(19, 6), 't': (5, 4), 'x': (83, 7), '#': (2632, 12),
"'": (330, 9), '+': (2633, 12), '/': (160, 8), '3':
(697, 10), '7': (2796, 12), '?': (2634, 12), 'C': (175,
8), 'G': (659, 10), 'K': (5571, 13), 'O': (173, 8),
'S': (241, 8), 'W': (662, 10), '[': (144, 9), 'c': (8,
5), 'g': (127, 7), 'k': (161, 8), 'o': (9, 4), 's':
(22, 5), 'w': (104, 7), '\n': (14, 5), '"': (162, 8),
'.': (26, 6), '2': (219, 9), '6': (1399, 11), ':':
(253, 8), 'B': (108, 8), 'F': (426, 9), 'J': (3497,
13), 'N': (146, 9), 'R': (326, 9), 'V': (875, 11), 'Z':
(8080, 13), 'b': (105, 7), 'f': (42, 6), '\xe9': (5570,
13), 'j': (8081, 13), 'n': (27, 5), 'r': (23, 5), 'v':
(37, 7), 'z': (663, 10), '~': (2635, 12), '\t': (2021,
11), '!': (1397, 11), '%': (2784, 12), ')': (1008, 10),
'-': (55, 7), '1': (1009, 10), '5': (4046, 12), '9':
(2797, 12), '=': (15, 5), 'A': (428, 9), 'E': (147, 9),
'I': (481, 9), 'M': (427, 9), 'Q': (436, 10), 'U':
(345, 9), 'Y': (2022, 11), ']': (145, 9), 'a': (29, 5),
'e': (12, 4), 'i': (28, 5), 'm': (62, 6), 'q': (4047,
12), 'u': (12, 5), 'y': (121, 7)}
Here is the series of commands I issue, resulting in an
error:

>>> afile = open("afile", "wb")
>>> p=pickle.Pickler(afile)
>>> p.save(a)
>>> afile.close()
>>> afile = open("afile", "rb")
>>> p=pickle.Unpickler(afile)
>>> a2 = p.load()
Traceback (most recent call last):
  File "<pyshell#69>", line 1, in ?
    a2 = p.load()
  File "H:\Python24\lib\pickle.py", line 872, in load
    dispatch[key](self)
  File "H:\Python24\lib\pickle.py", line 894, in load_eof
    raise EOFError
EOFError

Am I doing something wrong or is this pickle's fault?

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-06 00:04

Message:
Logged In: YES 
user_id=31435

I'm confused by why you're using the Pickler.save() method.  
That's an internal method, not even documented.  If you use 
the documented Pickler.dump() method instead, this should 
work fine with pickle.py.

There's no guarantee about the size or content of pickle 
strings, BTW, and cPickle does play tricks not available to 
pickle.py.

----------------------------------------------------------------------

Comment By: Laxori666 (laxori666)
Date: 2005-03-05 23:34

Message:
Logged In: YES 
user_id=1209371

NOTE: doing this using cPickle works without a problem. Also
note that the file is 2KB smaller under cPickle. If they are
supposed to be using the same stream, I think that is a
problem (the same protocol argument was used for both)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157576&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 06:57:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 06:57:44 2005
Subject: [ python-Bugs-1157576 ] pickle errors
Message-ID: <E1D7olp-0000op-TB@sc8-sf-web1.sourceforge.net>

Bugs item #1157576, was opened at 2005-03-05 23:31
Message generated for change (Comment added) made by laxori666
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157576&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Laxori666 (laxori666)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle errors

Initial Comment:
pickle is giving me an error while I'm trying to
serialize a dictionary.
Here is the dictionary:
>>> a
{' ': (0, 2), '(': (858, 10), ',': (480, 9), '0': (327,
9), '4': (1393, 11), '8': (1396, 11), '@': (3496, 13),
'D': (212, 8), 'H': (1749, 12), 'L': (328, 9), 'P':
(344, 9), 'T': (215, 8), 'X': (4041, 12), '\': (859,
10), 'd': (16, 5), 'h': (61, 6), 'l': (17, 5), 'p':
(19, 6), 't': (5, 4), 'x': (83, 7), '#': (2632, 12),
"'": (330, 9), '+': (2633, 12), '/': (160, 8), '3':
(697, 10), '7': (2796, 12), '?': (2634, 12), 'C': (175,
8), 'G': (659, 10), 'K': (5571, 13), 'O': (173, 8),
'S': (241, 8), 'W': (662, 10), '[': (144, 9), 'c': (8,
5), 'g': (127, 7), 'k': (161, 8), 'o': (9, 4), 's':
(22, 5), 'w': (104, 7), '\n': (14, 5), '"': (162, 8),
'.': (26, 6), '2': (219, 9), '6': (1399, 11), ':':
(253, 8), 'B': (108, 8), 'F': (426, 9), 'J': (3497,
13), 'N': (146, 9), 'R': (326, 9), 'V': (875, 11), 'Z':
(8080, 13), 'b': (105, 7), 'f': (42, 6), '\xe9': (5570,
13), 'j': (8081, 13), 'n': (27, 5), 'r': (23, 5), 'v':
(37, 7), 'z': (663, 10), '~': (2635, 12), '\t': (2021,
11), '!': (1397, 11), '%': (2784, 12), ')': (1008, 10),
'-': (55, 7), '1': (1009, 10), '5': (4046, 12), '9':
(2797, 12), '=': (15, 5), 'A': (428, 9), 'E': (147, 9),
'I': (481, 9), 'M': (427, 9), 'Q': (436, 10), 'U':
(345, 9), 'Y': (2022, 11), ']': (145, 9), 'a': (29, 5),
'e': (12, 4), 'i': (28, 5), 'm': (62, 6), 'q': (4047,
12), 'u': (12, 5), 'y': (121, 7)}
Here is the series of commands I issue, resulting in an
error:

>>> afile = open("afile", "wb")
>>> p=pickle.Pickler(afile)
>>> p.save(a)
>>> afile.close()
>>> afile = open("afile", "rb")
>>> p=pickle.Unpickler(afile)
>>> a2 = p.load()
Traceback (most recent call last):
  File "<pyshell#69>", line 1, in ?
    a2 = p.load()
  File "H:\Python24\lib\pickle.py", line 872, in load
    dispatch[key](self)
  File "H:\Python24\lib\pickle.py", line 894, in load_eof
    raise EOFError
EOFError

Am I doing something wrong or is this pickle's fault?

----------------------------------------------------------------------

>Comment By: Laxori666 (laxori666)
Date: 2005-03-06 00:57

Message:
Logged In: YES 
user_id=1209371

Oh, silly me. I should've noticed something was strange when
cPickle didn't have a save method. I don't know, I must've
stumbled into it and thought it was the right one. Thanks
for your help.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-06 00:04

Message:
Logged In: YES 
user_id=31435

I'm confused by why you're using the Pickler.save() method.  
That's an internal method, not even documented.  If you use 
the documented Pickler.dump() method instead, this should 
work fine with pickle.py.

There's no guarantee about the size or content of pickle 
strings, BTW, and cPickle does play tricks not available to 
pickle.py.

----------------------------------------------------------------------

Comment By: Laxori666 (laxori666)
Date: 2005-03-05 23:34

Message:
Logged In: YES 
user_id=1209371

NOTE: doing this using cPickle works without a problem. Also
note that the file is 2KB smaller under cPickle. If they are
supposed to be using the same stream, I think that is a
problem (the same protocol argument was used for both)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157576&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 07:41:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 07:41:51 2005
Subject: [ python-Bugs-1157576 ] pickle errors
Message-ID: <E1D7pSX-0001Dd-SZ@sc8-sf-web3.sourceforge.net>

Bugs item #1157576, was opened at 2005-03-05 23:31
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157576&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Laxori666 (laxori666)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle errors

Initial Comment:
pickle is giving me an error while I'm trying to
serialize a dictionary.
Here is the dictionary:
>>> a
{' ': (0, 2), '(': (858, 10), ',': (480, 9), '0': (327,
9), '4': (1393, 11), '8': (1396, 11), '@': (3496, 13),
'D': (212, 8), 'H': (1749, 12), 'L': (328, 9), 'P':
(344, 9), 'T': (215, 8), 'X': (4041, 12), '\': (859,
10), 'd': (16, 5), 'h': (61, 6), 'l': (17, 5), 'p':
(19, 6), 't': (5, 4), 'x': (83, 7), '#': (2632, 12),
"'": (330, 9), '+': (2633, 12), '/': (160, 8), '3':
(697, 10), '7': (2796, 12), '?': (2634, 12), 'C': (175,
8), 'G': (659, 10), 'K': (5571, 13), 'O': (173, 8),
'S': (241, 8), 'W': (662, 10), '[': (144, 9), 'c': (8,
5), 'g': (127, 7), 'k': (161, 8), 'o': (9, 4), 's':
(22, 5), 'w': (104, 7), '\n': (14, 5), '"': (162, 8),
'.': (26, 6), '2': (219, 9), '6': (1399, 11), ':':
(253, 8), 'B': (108, 8), 'F': (426, 9), 'J': (3497,
13), 'N': (146, 9), 'R': (326, 9), 'V': (875, 11), 'Z':
(8080, 13), 'b': (105, 7), 'f': (42, 6), '\xe9': (5570,
13), 'j': (8081, 13), 'n': (27, 5), 'r': (23, 5), 'v':
(37, 7), 'z': (663, 10), '~': (2635, 12), '\t': (2021,
11), '!': (1397, 11), '%': (2784, 12), ')': (1008, 10),
'-': (55, 7), '1': (1009, 10), '5': (4046, 12), '9':
(2797, 12), '=': (15, 5), 'A': (428, 9), 'E': (147, 9),
'I': (481, 9), 'M': (427, 9), 'Q': (436, 10), 'U':
(345, 9), 'Y': (2022, 11), ']': (145, 9), 'a': (29, 5),
'e': (12, 4), 'i': (28, 5), 'm': (62, 6), 'q': (4047,
12), 'u': (12, 5), 'y': (121, 7)}
Here is the series of commands I issue, resulting in an
error:

>>> afile = open("afile", "wb")
>>> p=pickle.Pickler(afile)
>>> p.save(a)
>>> afile.close()
>>> afile = open("afile", "rb")
>>> p=pickle.Unpickler(afile)
>>> a2 = p.load()
Traceback (most recent call last):
  File "<pyshell#69>", line 1, in ?
    a2 = p.load()
  File "H:\Python24\lib\pickle.py", line 872, in load
    dispatch[key](self)
  File "H:\Python24\lib\pickle.py", line 894, in load_eof
    raise EOFError
EOFError

Am I doing something wrong or is this pickle's fault?

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-06 01:41

Message:
Logged In: YES 
user_id=31435

No problem -- thanks for the followup!  I'll close this now.

If you ever want to subclass Pickler, then studying the 
source for save() may be helpful.  Otherwise it's best avoided.

----------------------------------------------------------------------

Comment By: Laxori666 (laxori666)
Date: 2005-03-06 00:57

Message:
Logged In: YES 
user_id=1209371

Oh, silly me. I should've noticed something was strange when
cPickle didn't have a save method. I don't know, I must've
stumbled into it and thought it was the right one. Thanks
for your help.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-06 00:04

Message:
Logged In: YES 
user_id=31435

I'm confused by why you're using the Pickler.save() method.  
That's an internal method, not even documented.  If you use 
the documented Pickler.dump() method instead, this should 
work fine with pickle.py.

There's no guarantee about the size or content of pickle 
strings, BTW, and cPickle does play tricks not available to 
pickle.py.

----------------------------------------------------------------------

Comment By: Laxori666 (laxori666)
Date: 2005-03-05 23:34

Message:
Logged In: YES 
user_id=1209371

NOTE: doing this using cPickle works without a problem. Also
note that the file is 2KB smaller under cPickle. If they are
supposed to be using the same stream, I think that is a
problem (the same protocol argument was used for both)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157576&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 12:11:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 12:11:07 2005
Subject: [ python-Bugs-1157665 ] RuntimeWarning: unfiltered RuntimeWarning
Message-ID: <E1D7tf7-000773-CX@sc8-sf-web2.sourceforge.net>

Bugs item #1157665, was opened at 2005-03-06 12:11
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=1157665&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Grzegorz Makarewicz (makaron)
Assigned to: Nobody/Anonymous (nobody)
Summary: RuntimeWarning: unfiltered RuntimeWarning

Initial Comment:
after updating to latest cvs version for 2.4 i'v got an
error while performing full test on win xp:

test test_warnings failed -- Traceback (most recent
call last):
  File "s:\binw\py24\lib\test\test_warnings.py", line
57, in test_warn_specific_category
    warnings.warn(text, category)
  File "s:\binw\py24\lib\warnings.py", line 57, in warn
    warn_explicit(message, category, filename, lineno,
module, registry)
  File "s:\binw\py24\lib\warnings.py", line 92, in
warn_explicit
    raise message
RuntimeWarning: unfiltered RuntimeWarning

on other side - coll, only one failing test as compared
to previous version:
254 tests OK.
1 test failed:
    test_warnings
35 tests skipped:
    test__locale test_aepack test_al test_applesingle
test_cd test_cl
    test_commands test_curses test_dbm test_dl
test_fcntl test_fork1
    test_gdbm test_gl test_grp test_imgfile test_ioctl
    test_linuxaudiodev test_macfs test_macostools
test_mhlib test_nis
    test_openpty test_ossaudiodev test_plistlib
test_poll test_posix
    test_pty test_pwd test_resource test_scriptpackages
test_signal
    test_sunaudiodev test_threadsignals test_timing
Those skips are all expected on win32.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157665&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 19:47:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 19:47:33 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1D80mn-0003NE-C0@sc8-sf-web4.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 21:55
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Armin Rigo (arigo)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-06 18:47

Message:
Logged In: YES 
user_id=6656

I think the attached fixes all this.

What it does: check the return value of PySequence_Tuple (duh).  Check 
that the returned sequence contains only types or old-style classes.  
Checks that the solid_base of each type in the returned sequence is a 
supertype of the solid_base of type being built.  Adds a few tests.

The error messages are a bit inscrutable.  I find it hard to care.

Assigning to Armin for the first look.  Might want to get Guido to look at it 
too.

When Armin and I talked about this on IRC we found a few oddities in the 
general area, but I don't know if it's worth opening a new bug report for 
them...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-03 09:50

Message:
Logged In: YES 
user_id=6656

Certainly some more checking of what the user-defined MRO contains 
would be good -- check the attached, which dumps core at class definition 
time...

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-03 09:34

Message:
Logged In: YES 
user_id=4771

The PyXxx_Check() macros are #defined with
PyObject_TypeCheck().  Should we change all these #defines to
use a new PyObject_LayoutCheck() or something, and document
to C extension writers that they should also switch to the
new function?  More generally, should we review *all* usages
of PyObject_TypeCheck() and decide if they really meant that
or PyObject_LayoutCheck()?  Do we care about types that are
solid subclasses of 'int' but don't have it in their MRO? 
Should we just forget the whole idea and sanity-check the
user-defined mro, which after all would just add another
strange undocumented condition to typeobject.c? :-)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-02 20:11

Message:
Logged In: YES 
user_id=6656

Hmm, yeah, that works.  It wasn't totally clear to me that the user couldn't 
maliciously influence tp_base, but I don't think they can...

A helper function is presumably in order, unless PyType_IsSubtype should 
be changed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-02 17:03

Message:
Logged In: YES 
user_id=4771

To solve the problem, as hinted in the title of this tracker, I 
think that PyXxx_Check() should simply not trust any mro.  
What PyInt_Check() really means at the C level is to check if 
an object memory layout is compatible with PyIntObject.  This 
is easy to figure out by walking the "solid base" chain, 
tp_base.

As a side note, PyPy gives the same error as Python 2.2.  
However, both in PyPy and in Python 2.2, you can still build 
an instance of the strange class X as follows:

>>> x = object.__new__(X)

Still, all the methods of x are resolved via the dict type.  In 
PyPy we get a clean TypeError because the methods thus 
found don't apply to non-dict objects.  In Python 2.2 you can 
crash the interpreter just as in more recent Python releases, 
e.g. with x[5]=6.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-01 20:18

Message:
Logged In: YES 
user_id=6656

I wonder if Guido owes Armin a beer (read typeobject.c around line 5230).  
Well, not really, but it's that code that is making the difference.

However, reversing the order of dict and object is sufficient to make 2.2 
crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting 
code chopped out which gives the error jelper observes on the original).

I wonder what to do about this.  Removing the ability to customize the mro 
from user code is one obvious approach -- I don't know how much code 
uses this feature though.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 22:17:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 22:17:10 2005
Subject: [ python-Bugs-1157901 ] xml.dom.minidom.Node.removeChild() doesn't
	remove
Message-ID: <E1D837c-0008Oe-Jf@sc8-sf-web4.sourceforge.net>

Bugs item #1157901, was opened at 2005-03-06 22:17
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=1157901&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Kempka (mkempka)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom.Node.removeChild() doesn't remove

Initial Comment:
There seems to be a constellation where
xml.dom.minidom.Node.removeChild() doesn't remove
childs properly.

I found this bug in 2.3.4 and it is still in:

Python 2.3.5 (#2, Feb  9 2005, 00:38:15)
[GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2


I attached 3 files, the dombug.py demonstrates the
problem: 

First, I iterate over all children of a specific
element, check their tag name and remove them using
removeChild() and then child.unlink().
After the elements are removed I iterate again, do the
same check for a tag and find there are still elements
in there. That is, there are still elements in there
when I parse the file errorintroducer.xml. When I parse
the file errorfree.xml the elements are all removed. 

The difference between the xml files is the carriage
return after each closing tag. 

Since to my knowledge both xml files are well-formed I
would expect in both cases that all elements are removed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 22:24:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 22:24:17 2005
Subject: [ python-Bugs-1157901 ] xml.dom.minidom.Node.removeChild() doesn't
	remove
Message-ID: <E1D83ET-0000A0-9d@sc8-sf-web4.sourceforge.net>

Bugs item #1157901, was opened at 2005-03-06 22:17
Message generated for change (Comment added) made by mkempka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Kempka (mkempka)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom.Node.removeChild() doesn't remove

Initial Comment:
There seems to be a constellation where
xml.dom.minidom.Node.removeChild() doesn't remove
childs properly.

I found this bug in 2.3.4 and it is still in:

Python 2.3.5 (#2, Feb  9 2005, 00:38:15)
[GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2


I attached 3 files, the dombug.py demonstrates the
problem: 

First, I iterate over all children of a specific
element, check their tag name and remove them using
removeChild() and then child.unlink().
After the elements are removed I iterate again, do the
same check for a tag and find there are still elements
in there. That is, there are still elements in there
when I parse the file errorintroducer.xml. When I parse
the file errorfree.xml the elements are all removed. 

The difference between the xml files is the carriage
return after each closing tag. 

Since to my knowledge both xml files are well-formed I
would expect in both cases that all elements are removed.

----------------------------------------------------------------------

>Comment By: Matthias Kempka (mkempka)
Date: 2005-03-06 22:24

Message:
Logged In: YES 
user_id=736381

so.. this form posts the error report with uploading
files...interesting...

Anyway, the output I get when running the program with
errorintroducer.xml is:

> python dombug.py
found element 1
 .. removed
found element 3
 .. removed
found element 5
 .. removed
-----------everything removed from timerList[0]---------------
found Element    2
found Element    4
found Element    6


imho it should be, as it is with errorfree.xml:

found element 1
 .. removed
found element 2
 .. removed
found element 3
 .. removed
found element 4
 .. removed
found element 5
 .. removed
found element 6
 .. removed
-----------everything removed from timerList[0]---------------


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 22:36:25 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 22:36:28 2005
Subject: [ python-Bugs-1121416 ] zip incorrectly and incompletely documented
Message-ID: <E1D83QH-0000Lu-8R@sc8-sf-web3.sourceforge.net>

Bugs item #1121416, was opened at 2005-02-12 12:18
Message generated for change (Comment added) made by aisaac0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Alan (aisaac0)
Assigned to: Raymond Hettinger (rhettinger)
Summary: zip incorrectly and incompletely documented

Initial Comment:
See the zip documentation:
http://www.python.org/dev/doc/devel/lib/built-in-funcs.html

i. documentation refers to sequences not to iterables

ii. The other problem is easier to explain by example.
Let it=iter([1,2,3,4]).
What is the result of zip(*[it]*2)?
The current answer is: [(1,2),(3,4)],
but it is impossible to determine this from the docs,
which would allow [(1,3),(2,4)] instead (or indeed
other possibilities).

The example expresses the solution to an actual need,
so the behavior should be documented or warned against,
I believe.

----------------------------------------------------------------------

>Comment By: Alan (aisaac0)
Date: 2005-03-06 16:36

Message:
Logged In: YES 
user_id=1025672

>   The OP's problem should be left as a code smell
indicating a misuse of functionals.

Left how?  I did not propose any change in behavior
or intent.  I only asked that the behavior shd either
i. be determinate and documented, or
ii. be acknowledged in the docs as indeterminate
as a caution not to rely on current behavior
which seems natural but I take it not guaranteed.
(Ideally the docs would link to a helpful explanation
of why it is appropriate not to guarantee the
behavior.)

The fact that this question came up is evidence,
IMO, that the docs are incomplete.  (I'm not the
only one who was puzzled.)


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-16 20:10

Message:
Logged In: YES 
user_id=80475

The first sentence becomes even less clear with the "in the
same order" wording.  

The note about truncating to the shortest sequence length is
essential and should not have been dropped.  

The py2.4 change note is in a standard form
(\versionchanged{} following the explanation of current
behavior) and should not have been altered.

The part that addresses the OP's concern is too specific to
the his one example and is unclear unless you know about
that example.  The wording is discomforting, doesn't add new
information, and is somewhat not obvious in its meaning.

I suggest simply changing "sequence" to "iterable".

There is no sense in stating that the order of combination
is undefined.  It doesn't help with the OP's original desire
to be able to predict the outcome of the example.  However,
it does have the negative effect of making a person question
whether they've understood the preceding description of what
actually zip() does do.

zip() is about lockstep iteration and the docs should serve
those users as straight-forwardly as possible.  The OP's
issue on the other hand only comes up when trying funky
iterator magic -- adding a sentence about undefined ordering
doesn't help one bit.

There is a lesson in all this.  These tools were borrowed
from the world of functional programming which is all about
programming that is free of side-effects.  The OP's problem
should be left as a code smell indicating a misuse of
functionals.



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-02-16 19:03

Message:
Logged In: YES 
user_id=593130

I agree that the zip doc needs improvement.  Confusion will 
continue until it is.  Here is my suggested rewrite:
-------------------------------------------------------------------
zip([iterable1, ...]) 

Return a list of tuples, where the i-th tuple contains the i-th 
element from each input in the same order as the inputs.  
With no arguments, return an empty list (before 2.4, a 
TypeError was raised instead.)  With a single input, return a 
list of 1-tuples.  With multiple inputs, the output length is 
that of the shorted input.  When multiple input lengths are 
equal, zip(i1, ...) is similar to map(None, i1, ...), but there is 
no padding when otherwise.  The result of zipping a volatile 
iterable with itself is undefined.  New in 2.0. 
-------------------------------------------------------------------

There you have it.  More information is about 15% fewer 
words.  The reduction came from greatly condensing the  
overwordy sentence about obsolete behavior into a 
parenthetical comment.  For comparison, here is the current 
version.
-------------------------------------------------------------------
zip( [seq1, ...]) 

This function returns a list of tuples, where the i-th tuple 
contains the i-th element from each of the argument 
sequences. The returned list is truncated in length to the 
length of the shortest argument sequence. When there are 
multiple argument sequences which are all of the same 
length, zip() is similar to map() with an initial argument of 
None. With a single sequence argument, it returns a list of 1-
tuples. With no arguments, it returns an empty list. New in 
version 2.0. 
Changed in version 2.4: Formerly, zip() required at least one 
argument and zip() raised a TypeError instead of returning 
an empty list.. 






----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-02-12 21:25

Message:
Logged In: YES 
user_id=1038590

The generator in the previous comment was incorrect (tuple
swallows the StopIteration, so it never terminates). Try
this instead:

def partition(iterable, part_len):
    itr = iter(iterable)
    while 1:
        item = tuple(islice(itr, part_len))
        if len(item) < part_len:
            raise StopIteration
        yield item 


----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-02-12 20:30

Message:
Logged In: YES 
user_id=1038590

Raymond's point about opaqueness is well-taken, since the
given partitioning behaviour in the example was actually
what was intended (I was part of the relevant c.l.p discussion).

For future reference, the reliable approach is to use a
generator function instead:

from itertools import islice
def partition(iterable, part_len):
    itr = iter(iterable)
    while 1:
        yield tuple(islice(itr, part_len))


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-12 14:50

Message:
Logged In: YES 
user_id=80475

The problem with your example does not lie with zip(). 
Instead, there is a misunderstanding of iter() and how
iterators are consumed.  Instead of iter(), the correct
function is itertools.tee():
>>> zip(*tee([1,2,3,4]))
[(1, 1), (2, 2), (3, 3), (4, 4)]

Also, stylistically, the zip(*func) approach is too opaque.
 It is almost always better (at least for other readers and
possibly for yourself) to write something more obvious in
its intent and operation.  List comprehensions and generator
expressions are often more clear and easier to write correctly:
>>> [(x,x) for x in [1,2,3,4]]
[(1, 1), (2, 2), (3, 3), (4, 4)]

I do agree that the word sequence should be dropped because
it implies that non-sequence iterables are not acceptable as
arguments.  That's too bad because the word "sequence" seems
to help people understand what zip is doing.

You're correct that the zip docs do not describe its
implementation in such detail as to be able to predict the
[(1,2),(3,4)] result.  However, that would be an
over-specification.  That particular result is an
implementation specific detail that is subject to change. 
It probably won't change, but we don't want to encourage
people to write code that relies on the specific order of
operations within zip().  If someone wants to do something
tricky, such as [(1,2),(3,4)], then they are better off
writing an explicit loop so that the order of operation is
clear both to themselves and to code reviewers.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470
From noreply at sourceforge.net  Sun Mar  6 23:28:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  6 23:28:55 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D84F2-0002PX-0E@sc8-sf-web3.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-03 22:00
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
>Assigned to: Greg Ward (gward)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-05 15:30

Message:
Logged In: YES 
user_id=945502

Looks pretty good to me.  Only one change:
    "super(currentclass, cls).__new__([...])"
should look like:
    "super(currentclass, cls).__new__(cls[, ...])"
Sorry I didn't catch this earlier.  But, since it's a
staticmethod, of course you need to pass 'cls' manually.


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-05 11:34

Message:
Logged In: YES 
user_id=14422

Here's an alternative text -- a bit tighter, hopefully a tad
more accurate and clearer:

__new__(cls[, ...])

Called to create a new instance of class 'cls'.  __new__()
is a static method (special-cased so you need not declare it
as such) that takes the class to create an instance of as
the first argument.  The remaining arguments are those
passed to the object constructor expression.  The return
value of __new__() should be the new object instance.

Typical usage is to create a new instance of the class by
invoking the superclass's __new__() method using
"super(currentclass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if necessary, and
then returning it.  If the returned value is an instance of
'cls', its __init__() will be invoked like
"__init__(self[, ...])", where the extra arguments are the
same as were passed to __new__().

You do need not to return an instance of 'cls', but if you
do not, the new instance's __init__() method will not be
invoked.

__new__() is intended mainly to allow subclasses of
immutable types (like int, str, or tuple) to customize
instance creation.


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-05 11:11

Message:
Logged In: YES 
user_id=14422

I think that last paragraph can be written even more concisely:

"The __new__ staticmethod is intended mainly to allow
subclasses of immutable types (like int, str, or tuple) to
customize instance creation."

Also, the usual convention when talking about methods and
functions is to write "__new__()", not "__new__".  At least
that's how the 2.3.3 language ref which I have on my PC looks.

Finally, this bug is in the "Python 2.5" group -- surely
there's no harm in checking this in to the 2.4 docs and
merging forward?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 23:02

Message:
Logged In: YES 
user_id=1038590

Close, but the phrasing's a bit awkward. Getting rid of the
commas seems to fix that:

"The __new__ staticmethod is intended mainly to allow you to
customize instance creation in a subclass of an immutable
type (like int, long, float, complex, str, unicode, or tuple)."

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 15:19

Message:
Logged In: YES 
user_id=945502

Good point.  How about:

"The __new__ staticmethod is intended mainly to allow you,
in a subclass of an immutable type (like int, long, float,
complex, str, unicode, or tuple), to customize instance
creation."

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2005-03-04 13:05

Message:
Logged In: YES 
user_id=562624

"The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple."

You might like to rephrase that. It gives the impression
that __new__ somehow makes it possible to modify the value
of an immutable object. In fact, it only allows customized
creation of new instances.


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 11:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 10:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 01:42:09 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 01:42:12 2005
Subject: [ python-Bugs-1158005 ] unixccompiler.py should deal with env in
	linker
Message-ID: <E1D86K1-0007Gs-QK@sc8-sf-web4.sourceforge.net>

Bugs item #1158005, was opened at 2005-03-06 16: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=1158005&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Moy (edwardmoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: unixccompiler.py should deal with env in linker

Initial Comment:
When the linker command begins with env, plus some environment 
settings, and when the target is c++, the modified linker command 
should place the c++ command in the proper place, which is not the 
first element of the linker array.

The following seems to be fix the problem:

--- unixccompiler.py.orig       2004-08-29 09:45:13.000000000 -0700
+++ unixccompiler.py    2005-03-06 16:36:05.000000000 -0800
@@ -172,7 +172,12 @@
                 else:
                     linker = self.linker_so[:]
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
+                    i = 0
+                    if os.path.basename(linker[0]) == "env":
+                        i = 1
+                        while '=' in linker[i]:
+                            i = i + 1
+                    linker[i] = self.compiler_cxx[0]
                 self.spawn(linker + ld_args)
             except DistutilsExecError, msg:
                 raise LinkError, msg


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 02:27:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 02:27:29 2005
Subject: [ python-Bugs-818006 ] ossaudiodev object does not support common
	readonly attrs
Message-ID: <E1D871q-0000I1-5C@sc8-sf-web4.sourceforge.net>

Bugs item #818006, was opened at 2003-10-05 02:30
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Greg Ward (gward)
>Summary: ossaudiodev object does not support common readonly attrs

Initial Comment:
fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-05 15:48

Message:
Logged In: YES 
user_id=593130

I am not sure who your last comment is aimed at.  As near as I 
can tell, Greg merely updated the group to Py2.4, implying that 
this issue is still relevant.

In Pythonese, should is advisory; only must is mandatory.  So I 
see this as a request for a pre-approved enhancement.  Since 
ossaudiodevice directly wraps an OS open file descripter, rather 
than a Python file object, the patch is more than a triviality.

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-05 13:08

Message:
Logged In: YES 
user_id=314434

That was the point of the bug report. It has no closed 
or other file-like attributes. According the python docs 
then and current: 
'File objects also offer a number of other interesting 
attributes. These are not required for file-like objects, 
but should be implemented if they make sense for 
the particular object. ' 
 
I take that to mean these attributes are mandatory, 
unless it does not make sense to implement them. 
 
In the case of file-like Audio Device Objects, they 
make sense, and thus should be there.  
 
Either this statement of file-like object policy is a bug, 
or the lack of such attributes in Audio Device Objects 
is a bug.  
 

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2003-10-05 16:32

Message:
Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
&quot;&quot;&quot; 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
&quot;&quot; 
 
&quot;Should be&quot; when they &quot;make sense&quot;  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO &quot;should&quot; 
have worked.  : P 
 
Other attributes that &quot;should be&quot; implemented  (mode and 
name) because they &quot;make sense&quot; may also be missing...I 
haven't checked.  
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-10-05 16:16

Message:
Logged In: YES 
user_id=593130

>From Lib Ref 14.11 ossaudiodev &quot;open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
&quot;
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 02:41:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 02:41:42 2005
Subject: [ python-Feature Requests-818006 ] ossaudiodev object does not
	support common readonly attrs
Message-ID: <E1D87Fc-0000SQ-Lo@sc8-sf-web3.sourceforge.net>

Feature Requests item #818006, was opened at 2003-10-05 02:30
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470

>Category: Extension Modules
>Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Greg Ward (gward)
Summary: ossaudiodev object does not support common readonly attrs

Initial Comment:
fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-06 20:41

Message:
Logged In: YES 
user_id=14422

For the record, I consider this an enhancement, not a bug
fix.  As the previous commenter pointed out, "should" is not
mandatory.  But it's a useful feature, and I have no
objection to adding it on a stable branch.  So I've checked
it in on 2.4:

Modules/ossaudiodev.c             rev 1.35.4.1
Lib/test/test_ossaudiodev.py      rev 1.8.10.1
Doc/lib/libossaudiodev.tex        rev 1.12.4.2
Lib/test/output/test_ossaudiodev  rev 1.2.12.1

and merged to the trunk:

Modules/ossaudiodev.c             rev 1.36
Lib/test/test_ossaudiodev.py      rev 1.9
Doc/lib/libossaudiodev.tex        rev 1.14
Lib/test/output/test_ossaudiodev  rev 1.3


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-05 15:48

Message:
Logged In: YES 
user_id=593130

I am not sure who your last comment is aimed at.  As near as I 
can tell, Greg merely updated the group to Py2.4, implying that 
this issue is still relevant.

In Pythonese, should is advisory; only must is mandatory.  So I 
see this as a request for a pre-approved enhancement.  Since 
ossaudiodevice directly wraps an OS open file descripter, rather 
than a Python file object, the patch is more than a triviality.

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-05 13:08

Message:
Logged In: YES 
user_id=314434

That was the point of the bug report. It has no closed 
or other file-like attributes. According the python docs 
then and current: 
'File objects also offer a number of other interesting 
attributes. These are not required for file-like objects, 
but should be implemented if they make sense for 
the particular object. ' 
 
I take that to mean these attributes are mandatory, 
unless it does not make sense to implement them. 
 
In the case of file-like Audio Device Objects, they 
make sense, and thus should be there.  
 
Either this statement of file-like object policy is a bug, 
or the lack of such attributes in Audio Device Objects 
is a bug.  
 

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2003-10-05 16:32

Message:
Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
&quot;&quot;&quot; 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
&quot;&quot; 
 
&quot;Should be&quot; when they &quot;make sense&quot;  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO &quot;should&quot; 
have worked.  : P 
 
Other attributes that &quot;should be&quot; implemented  (mode and 
name) because they &quot;make sense&quot; may also be missing...I 
haven't checked.  
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-10-05 16:16

Message:
Logged In: YES 
user_id=593130

>From Lib Ref 14.11 ossaudiodev &quot;open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
&quot;
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 03:36:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 03:37:02 2005
Subject: [ python-Feature Requests-818006 ] ossaudiodev object does not
	support common readonly attrs
Message-ID: <E1D8877-00026T-Hj@sc8-sf-web3.sourceforge.net>

Feature Requests item #818006, was opened at 2003-10-05 02:30
Message generated for change (Comment added) made by dcinege
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470

Category: Extension Modules
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Greg Ward (gward)
Summary: ossaudiodev object does not support common readonly attrs

Initial Comment:
fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

----------------------------------------------------------------------

>Comment By: Dave Cinege (dcinege)
Date: 2005-03-06 21:36

Message:
Logged In: YES 
user_id=314434

'As the previous commenter pointed out, "should" is 
not mandatory. ' 
 
Don't want to nit-pick...but in common usage and 
especially legalese (which the world is unfortuntaly 
infected with, that being laws) 'shall' is interperted to 
mean an absolute. Should, the past tense of 'shall' , 
therefor inherits the definition of shall...which is: 
1 archaic a : will have to : MUST b : will be able to : 
CAN 
2 a -- used to express a command or exhortation 
<you shall go> b -- used in laws, regulations, or 
directives to express what is mandatory 
 
Thus, I think it's a poor idea that the use of 'should', or 
'shall', should not imply what is mandatory. After all 
they are a synonym for 'must'! 
 
If the language 'may be' was used instead of 'should 
be' I would not have reported this as a bug.  
 
I think as an issue of documentation policy, this 
should be...uhmmm...I mean...must  be changed.  : )  
I don't know where I would raise this issue.  
 

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-06 20:41

Message:
Logged In: YES 
user_id=14422

For the record, I consider this an enhancement, not a bug
fix.  As the previous commenter pointed out, "should" is not
mandatory.  But it's a useful feature, and I have no
objection to adding it on a stable branch.  So I've checked
it in on 2.4:

Modules/ossaudiodev.c             rev 1.35.4.1
Lib/test/test_ossaudiodev.py      rev 1.8.10.1
Doc/lib/libossaudiodev.tex        rev 1.12.4.2
Lib/test/output/test_ossaudiodev  rev 1.2.12.1

and merged to the trunk:

Modules/ossaudiodev.c             rev 1.36
Lib/test/test_ossaudiodev.py      rev 1.9
Doc/lib/libossaudiodev.tex        rev 1.14
Lib/test/output/test_ossaudiodev  rev 1.3


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-05 15:48

Message:
Logged In: YES 
user_id=593130

I am not sure who your last comment is aimed at.  As near as I 
can tell, Greg merely updated the group to Py2.4, implying that 
this issue is still relevant.

In Pythonese, should is advisory; only must is mandatory.  So I 
see this as a request for a pre-approved enhancement.  Since 
ossaudiodevice directly wraps an OS open file descripter, rather 
than a Python file object, the patch is more than a triviality.

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-05 13:08

Message:
Logged In: YES 
user_id=314434

That was the point of the bug report. It has no closed 
or other file-like attributes. According the python docs 
then and current: 
'File objects also offer a number of other interesting 
attributes. These are not required for file-like objects, 
but should be implemented if they make sense for 
the particular object. ' 
 
I take that to mean these attributes are mandatory, 
unless it does not make sense to implement them. 
 
In the case of file-like Audio Device Objects, they 
make sense, and thus should be there.  
 
Either this statement of file-like object policy is a bug, 
or the lack of such attributes in Audio Device Objects 
is a bug.  
 

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2003-10-05 16:32

Message:
Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
&quot;&quot;&quot; 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
&quot;&quot; 
 
&quot;Should be&quot; when they &quot;make sense&quot;  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO &quot;should&quot; 
have worked.  : P 
 
Other attributes that &quot;should be&quot; implemented  (mode and 
name) because they &quot;make sense&quot; may also be missing...I 
haven't checked.  
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-10-05 16:16

Message:
Logged In: YES 
user_id=593130

>From Lib Ref 14.11 ossaudiodev &quot;open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
&quot;
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 06:24:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 06:24:40 2005
Subject: [ python-Bugs-1157665 ] RuntimeWarning: unfiltered RuntimeWarning
Message-ID: <E1D8AjN-0007km-8d@sc8-sf-web2.sourceforge.net>

Bugs item #1157665, was opened at 2005-03-06 06:11
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157665&group_id=5470

Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Grzegorz Makarewicz (makaron)
Assigned to: Nobody/Anonymous (nobody)
Summary: RuntimeWarning: unfiltered RuntimeWarning

Initial Comment:
after updating to latest cvs version for 2.4 i'v got an
error while performing full test on win xp:

test test_warnings failed -- Traceback (most recent
call last):
  File "s:\binw\py24\lib\test\test_warnings.py", line
57, in test_warn_specific_category
    warnings.warn(text, category)
  File "s:\binw\py24\lib\warnings.py", line 57, in warn
    warn_explicit(message, category, filename, lineno,
module, registry)
  File "s:\binw\py24\lib\warnings.py", line 92, in
warn_explicit
    raise message
RuntimeWarning: unfiltered RuntimeWarning

on other side - coll, only one failing test as compared
to previous version:
254 tests OK.
1 test failed:
    test_warnings
35 tests skipped:
    test__locale test_aepack test_al test_applesingle
test_cd test_cl
    test_commands test_curses test_dbm test_dl
test_fcntl test_fork1
    test_gdbm test_gl test_grp test_imgfile test_ioctl
    test_linuxaudiodev test_macfs test_macostools
test_mhlib test_nis
    test_openpty test_ossaudiodev test_plistlib
test_poll test_posix
    test_pty test_pwd test_resource test_scriptpackages
test_signal
    test_sunaudiodev test_threadsignals test_timing
Those skips are all expected on win32.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157665&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 12:50:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 12:50:59 2005
Subject: [ python-Bugs-1158231 ] string.Template does not allow step-by-step
	replacements
Message-ID: <E1D8GlE-0005pk-7T@sc8-sf-web4.sourceforge.net>

Bugs item #1158231, was opened at 2005-03-07 12:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158231&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: string.Template does not allow step-by-step replacements

Initial Comment:
A common use case for templates is partially replacing
placeholders in loops or method cascades. The
safe_substitute method of the Template class provides
rudimentary support for this as long as Templates do
not contain the "$$" escape. In cases where multiple
replacements are necessary, a new Template must be
created. This messes up the "$$" replacement.

An example:

.>>> from string import Template
.>>> a = Template('$a + $$ != $b')
.>>> b = Template(a.safe_substitute(a=1))
.>>> [ b.substitute(b=i) for i in range(3) ]
Traceback [...]
ValueError: Invalid placeholder in string: line 1, col 5

In the current implementation, there is no way of
getting around this problem.

I suggest adding a new class-method as constructor to
the Template class: "Template.from_template", that
takes a template, applies a safe_substitute with the
provided (kw)arguments and returns a *valid* Template
(not a string). However, this method *must not* replace
occurrences of "$$" in the original template.

The above example would then look like this:
.>>> from string import Template
.>>> a = Template('$va + $$ != $vb')
.>>> b = Template.from_template(a, va=1)
.>>> [ b.substitute(vb=i) for i in range(3) ]
[ '1 + $ != 0', '1 + $ != 1', '1 + $ != 2' ]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158231&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 15:15:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 15:15:08 2005
Subject: [ python-Bugs-1158313 ] heapq should provide iterators:
	itersmallest, iterlargest
Message-ID: <E1D8J0g-0004H2-Bt@sc8-sf-web4.sourceforge.net>

Bugs item #1158313, was opened at 2005-03-07 15:15
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=1158313&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: heapq should provide iterators: itersmallest, iterlargest

Initial Comment:
The current C-based heapq implementation provides
implementations of min-heaps and max-heaps for the
"nsmallest" and "nlargest" functions. I would like to
see them used to provide iterators over the
smallest/largest items of a heap: "itersmallest(heap)"
and "iterlargest(heap)".

Why:

The functions nsmallest() and nlargest() are efficient
(and sufficient) if n is known. However, if n is *not*
known in advance, it would still be more efficient than
sorting to run heapify() over a list and then have an
iterator run heappop on each iteration. While this is
easily implemented for min-heaps using heappop,
max-heaps are not part of the Python-Implementation.
Currently, they are only implemented in C.

Possible counter-arguments:

The straight-forward iterator implementation will
manipulate the heap. This could be seen as a
side-effect. It should, however, be enough to document
that. Similar problems are documented for mutating
sequences during iteration.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158313&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 17:22:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 17:22:36 2005
Subject: [ python-Bugs-1158313 ] heapq should provide iterators:
	itersmallest, iterlargest
Message-ID: <E1D8L04-0002iH-Bp@sc8-sf-web1.sourceforge.net>

Bugs item #1158313, was opened at 2005-03-07 09:15
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158313&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: heapq should provide iterators: itersmallest, iterlargest

Initial Comment:
The current C-based heapq implementation provides
implementations of min-heaps and max-heaps for the
"nsmallest" and "nlargest" functions. I would like to
see them used to provide iterators over the
smallest/largest items of a heap: "itersmallest(heap)"
and "iterlargest(heap)".

Why:

The functions nsmallest() and nlargest() are efficient
(and sufficient) if n is known. However, if n is *not*
known in advance, it would still be more efficient than
sorting to run heapify() over a list and then have an
iterator run heappop on each iteration. While this is
easily implemented for min-heaps using heappop,
max-heaps are not part of the Python-Implementation.
Currently, they are only implemented in C.

Possible counter-arguments:

The straight-forward iterator implementation will
manipulate the heap. This could be seen as a
side-effect. It should, however, be enough to document
that. Similar problems are documented for mutating
sequences during iteration.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-07 11:22

Message:
Logged In: YES 
user_id=80475

The idea for introducing heapiter() function was
unsuccessfully proposed on python-dev:

 
http://mail.python.org/pipermail/python-dev/2004-June/045348.html

The use cases were rare and the pure python solution was
both easy and fast.

If you need C coded max-heaps, that could be a separate
feature request.  There would need to be sufficient use
cases to warrant building out the module's API.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158313&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 17:31:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 17:31:24 2005
Subject: [ python-Feature Requests-1158231 ] string.Template does not allow
	step-by-step replacements
Message-ID: <E1D8L8a-0003Bu-UI@sc8-sf-web1.sourceforge.net>

Feature Requests item #1158231, was opened at 2005-03-07 06:50
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1158231&group_id=5470

>Category: Python Library
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: string.Template does not allow step-by-step replacements

Initial Comment:
A common use case for templates is partially replacing
placeholders in loops or method cascades. The
safe_substitute method of the Template class provides
rudimentary support for this as long as Templates do
not contain the "$$" escape. In cases where multiple
replacements are necessary, a new Template must be
created. This messes up the "$$" replacement.

An example:

.>>> from string import Template
.>>> a = Template('$a + $$ != $b')
.>>> b = Template(a.safe_substitute(a=1))
.>>> [ b.substitute(b=i) for i in range(3) ]
Traceback [...]
ValueError: Invalid placeholder in string: line 1, col 5

In the current implementation, there is no way of
getting around this problem.

I suggest adding a new class-method as constructor to
the Template class: "Template.from_template", that
takes a template, applies a safe_substitute with the
provided (kw)arguments and returns a *valid* Template
(not a string). However, this method *must not* replace
occurrences of "$$" in the original template.

The above example would then look like this:
.>>> from string import Template
.>>> a = Template('$va + $$ != $vb')
.>>> b = Template.from_template(a, va=1)
.>>> [ b.substitute(vb=i) for i in range(3) ]
[ '1 + $ != 0', '1 + $ != 1', '1 + $ != 2' ]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1158231&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 20:11:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 20:11:09 2005
Subject: [ python-Bugs-1158490 ] locale fails if LANGUAGE has multiple
	locales
Message-ID: <E1D8NdB-000897-A9@sc8-sf-web4.sourceforge.net>

Bugs item #1158490, was opened at 2005-03-07 11:11
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=1158490&group_id=5470

Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: mixedpuppy (mixedpuppy)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale fails if LANGUAGE has multiple locales

Initial Comment:
The locale module does not correctly handle the
LANGUAGE environment variable if it contains multiple
settings.  Example:

LANGUAGE="en_DK:en_GB:en_US:en"

Note, en_DK does not exist in locale_alias

In normalize, the colons are replaced with dots, which
is incorrect.  getdefaultlocal should seperate these
first, then try each one until it finds one that works,
or fails on all.  

GLIBC documentation:
http://www.delorie.com/gnu/docs/glibc/libc_138.html

"While for the LC_xxx variables the value should
consist of exactly one specification of a locale the
LANGUAGE variable's value can consist of a colon
separated list of locale names."


Testing this is simple, just set your LANGUAGE
environment var to the above example, and use
locale.getdefaultlocal()

> export LANGUAGE="en_DK:en_GB:en_US:en"
> python
ActivePython 2.4 Build 244 (ActiveState Corp.) based on
Python 2.4 (#1, Feb  9 2005, 19:33:15)
[GCC 3.3.1 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> locale.getdefaultlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/ActivePython-2.4/lib/python2.4/locale.py",
line 344, in getdefaultlocale
    return _parse_localename(localename)
  File "/opt/ActivePython-2.4/lib/python2.4/locale.py",
line 278, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_DK:en_GB:en_US:en
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 22:45:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 22:45:09 2005
Subject: [ python-Bugs-1158607 ] --disable-unicode fails when linking
Message-ID: <E1D8Q2F-000741-VR@sc8-sf-web4.sourceforge.net>

Bugs item #1158607, was opened at 2005-03-07 21:45
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=1158607&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Baumgart (fbaumgart)
Assigned to: Nobody/Anonymous (nobody)
Summary: --disable-unicode fails when linking

Initial Comment:
Linux, SuSE 9.2, Pentium 4
gcc 3.3.4 (pre 3.3.5 20040809)

./configure --prefix=/opt/python --disable-unicode

...
ranlib libpython2.4.a
c++ -pthread  -Xlinker -export-dynamic -o python                 Modules/python.o                 libpython2.4.a -lpthread -ldl  -lutil   -lm
libpython2.4.a(posixmodule.o)(.text+0x829): In function
`posix_tmpnam':
Modules/posixmodule.c:6158: warning: the use of
`tmpnam_r' is dangerous, better use `mkstemp'
libpython2.4.a(posixmodule.o)(.text+0x8cb): In function
`posix_tempnam':
Modules/posixmodule.c:6113: warning: the use of
`tempnam' is dangerous, better use `mkstemp'
libpython2.4.a(_codecsmodule.o)(.text+0x2c1): In
function `codec_decode':
Modules/_codecsmodule.c:141: undefined reference to
`PyUnicode_GetDefaultEncoding'
libpython2.4.a(_codecsmodule.o)(.text+0x331): In
function `codec_encode':
Modules/_codecsmodule.c:108: undefined reference to
`PyUnicode_GetDefaultEncoding'
collect2: ld returned 1 exit status
make: *** [python] Error 1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158607&group_id=5470
From noreply at sourceforge.net  Mon Mar  7 22:58:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  7 22:58:39 2005
Subject: [ python-Bugs-1158607 ] --disable-unicode fails when linking
Message-ID: <E1D8QFJ-0000w6-1b@sc8-sf-web1.sourceforge.net>

Bugs item #1158607, was opened at 2005-03-07 21:45
Message generated for change (Comment added) made by fbaumgart
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158607&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Baumgart (fbaumgart)
Assigned to: Nobody/Anonymous (nobody)
Summary: --disable-unicode fails when linking

Initial Comment:
Linux, SuSE 9.2, Pentium 4
gcc 3.3.4 (pre 3.3.5 20040809)

./configure --prefix=/opt/python --disable-unicode

...
ranlib libpython2.4.a
c++ -pthread  -Xlinker -export-dynamic -o python                 Modules/python.o                 libpython2.4.a -lpthread -ldl  -lutil   -lm
libpython2.4.a(posixmodule.o)(.text+0x829): In function
`posix_tmpnam':
Modules/posixmodule.c:6158: warning: the use of
`tmpnam_r' is dangerous, better use `mkstemp'
libpython2.4.a(posixmodule.o)(.text+0x8cb): In function
`posix_tempnam':
Modules/posixmodule.c:6113: warning: the use of
`tempnam' is dangerous, better use `mkstemp'
libpython2.4.a(_codecsmodule.o)(.text+0x2c1): In
function `codec_decode':
Modules/_codecsmodule.c:141: undefined reference to
`PyUnicode_GetDefaultEncoding'
libpython2.4.a(_codecsmodule.o)(.text+0x331): In
function `codec_encode':
Modules/_codecsmodule.c:108: undefined reference to
`PyUnicode_GetDefaultEncoding'
collect2: ld returned 1 exit status
make: *** [python] Error 1


----------------------------------------------------------------------

>Comment By: Frank Baumgart (fbaumgart)
Date: 2005-03-07 21:58

Message:
Logged In: YES 
user_id=599418

the same bug exists in the (currently latest):

python_2005-03-07_160000.tar.gz


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158607&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 02:11:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 02:11:27 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D8TFr-0007La-0G@sc8-sf-web4.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-03 22:00
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Greg Ward (gward)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-07 20:11

Message:
Logged In: YES 
user_id=14422

OK, done.  Doc change checked in on release24-maint branch:
  Doc/ref/ref3.tex rev 1.121.2.2
and on trunk
  Doc/ref/ref3.tex rev 1.123


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-05 15:30

Message:
Logged In: YES 
user_id=945502

Looks pretty good to me.  Only one change:
    "super(currentclass, cls).__new__([...])"
should look like:
    "super(currentclass, cls).__new__(cls[, ...])"
Sorry I didn't catch this earlier.  But, since it's a
staticmethod, of course you need to pass 'cls' manually.


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-05 11:34

Message:
Logged In: YES 
user_id=14422

Here's an alternative text -- a bit tighter, hopefully a tad
more accurate and clearer:

__new__(cls[, ...])

Called to create a new instance of class 'cls'.  __new__()
is a static method (special-cased so you need not declare it
as such) that takes the class to create an instance of as
the first argument.  The remaining arguments are those
passed to the object constructor expression.  The return
value of __new__() should be the new object instance.

Typical usage is to create a new instance of the class by
invoking the superclass's __new__() method using
"super(currentclass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if necessary, and
then returning it.  If the returned value is an instance of
'cls', its __init__() will be invoked like
"__init__(self[, ...])", where the extra arguments are the
same as were passed to __new__().

You do need not to return an instance of 'cls', but if you
do not, the new instance's __init__() method will not be
invoked.

__new__() is intended mainly to allow subclasses of
immutable types (like int, str, or tuple) to customize
instance creation.


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-05 11:11

Message:
Logged In: YES 
user_id=14422

I think that last paragraph can be written even more concisely:

"The __new__ staticmethod is intended mainly to allow
subclasses of immutable types (like int, str, or tuple) to
customize instance creation."

Also, the usual convention when talking about methods and
functions is to write "__new__()", not "__new__".  At least
that's how the 2.3.3 language ref which I have on my PC looks.

Finally, this bug is in the "Python 2.5" group -- surely
there's no harm in checking this in to the 2.4 docs and
merging forward?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 23:02

Message:
Logged In: YES 
user_id=1038590

Close, but the phrasing's a bit awkward. Getting rid of the
commas seems to fix that:

"The __new__ staticmethod is intended mainly to allow you to
customize instance creation in a subclass of an immutable
type (like int, long, float, complex, str, unicode, or tuple)."

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 15:19

Message:
Logged In: YES 
user_id=945502

Good point.  How about:

"The __new__ staticmethod is intended mainly to allow you,
in a subclass of an immutable type (like int, long, float,
complex, str, unicode, or tuple), to customize instance
creation."

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2005-03-04 13:05

Message:
Logged In: YES 
user_id=562624

"The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple."

You might like to rephrase that. It gives the impression
that __new__ somehow makes it possible to modify the value
of an immutable object. In fact, it only allows customized
creation of new instances.


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 11:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 10:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 02:11:35 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 02:11:37 2005
Subject: [ python-Bugs-1156412 ] add documentation for __new__
Message-ID: <E1D8TG3-0001L6-Mg@sc8-sf-web2.sourceforge.net>

Bugs item #1156412, was opened at 2005-03-03 22:00
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470

Category: Documentation
>Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Greg Ward (gward)
Summary: add documentation for __new__

Initial Comment:
3.3.1 Basic customization does not document __new__. 
Proposed addition:

__new__(cls[, ...])

Called to create a new instance of the class.  __new__
is a staticmethod (special-cased so you need not
declare it as such) that takes the class to be created
as the first argument.  The remaining arguments are
those passed to the class constructor expression. The
return value of __new__ should be the new object instance.

Typical usage is to create a new instance of the class
by invoking the superclass's __new__ method using
"super(BaseClass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if
necessary, and then returning it.  If the returned
value is an instance of "cls" (the first argument to
__new__), its __init__ will be invoked.

Note that you need not return an instance of "cls", but
if you don't, the new instance's __init__ method will
not be invoked.

The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple.

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-07 20:11

Message:
Logged In: YES 
user_id=14422

OK, done.  Doc change checked in on release24-maint branch:
  Doc/ref/ref3.tex rev 1.121.2.2
and on trunk
  Doc/ref/ref3.tex rev 1.123


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-05 15:30

Message:
Logged In: YES 
user_id=945502

Looks pretty good to me.  Only one change:
    "super(currentclass, cls).__new__([...])"
should look like:
    "super(currentclass, cls).__new__(cls[, ...])"
Sorry I didn't catch this earlier.  But, since it's a
staticmethod, of course you need to pass 'cls' manually.


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-05 11:34

Message:
Logged In: YES 
user_id=14422

Here's an alternative text -- a bit tighter, hopefully a tad
more accurate and clearer:

__new__(cls[, ...])

Called to create a new instance of class 'cls'.  __new__()
is a static method (special-cased so you need not declare it
as such) that takes the class to create an instance of as
the first argument.  The remaining arguments are those
passed to the object constructor expression.  The return
value of __new__() should be the new object instance.

Typical usage is to create a new instance of the class by
invoking the superclass's __new__() method using
"super(currentclass, cls).__new__([...])" with appropriate
arguments, modifying the returned instance if necessary, and
then returning it.  If the returned value is an instance of
'cls', its __init__() will be invoked like
"__init__(self[, ...])", where the extra arguments are the
same as were passed to __new__().

You do need not to return an instance of 'cls', but if you
do not, the new instance's __init__() method will not be
invoked.

__new__() is intended mainly to allow subclasses of
immutable types (like int, str, or tuple) to customize
instance creation.


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-05 11:11

Message:
Logged In: YES 
user_id=14422

I think that last paragraph can be written even more concisely:

"The __new__ staticmethod is intended mainly to allow
subclasses of immutable types (like int, str, or tuple) to
customize instance creation."

Also, the usual convention when talking about methods and
functions is to write "__new__()", not "__new__".  At least
that's how the 2.3.3 language ref which I have on my PC looks.

Finally, this bug is in the "Python 2.5" group -- surely
there's no harm in checking this in to the 2.4 docs and
merging forward?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 23:02

Message:
Logged In: YES 
user_id=1038590

Close, but the phrasing's a bit awkward. Getting rid of the
commas seems to fix that:

"The __new__ staticmethod is intended mainly to allow you to
customize instance creation in a subclass of an immutable
type (like int, long, float, complex, str, unicode, or tuple)."

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 15:19

Message:
Logged In: YES 
user_id=945502

Good point.  How about:

"The __new__ staticmethod is intended mainly to allow you,
in a subclass of an immutable type (like int, long, float,
complex, str, unicode, or tuple), to customize instance
creation."

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2005-03-04 13:05

Message:
Logged In: YES 
user_id=562624

"The __new__ staticmethod is intended mainly to allow
modification of immutable types like int, long, float,
str and tuple."

You might like to rephrase that. It gives the impression
that __new__ somehow makes it possible to modify the value
of an immutable object. In fact, it only allows customized
creation of new instances.


----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-03-04 11:11

Message:
Logged In: YES 
user_id=945502

Yup, type_call in typeobject.c special-cases this behavior.
 See also
http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-04 10:53

Message:
Logged In: YES 
user_id=1038590

Looks reasonable to me - but does CPython actually currently
follow those rules regarding when __init__ is and isn't invoked?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 03:46:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 03:46:03 2005
Subject: [ python-Feature Requests-818006 ] ossaudiodev object does not
	support common readonly attrs
Message-ID: <E1D8UjR-0003p9-NR@sc8-sf-web1.sourceforge.net>

Feature Requests item #818006, was opened at 2003-10-05 02:30
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470

Category: Extension Modules
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Greg Ward (gward)
Summary: ossaudiodev object does not support common readonly attrs

Initial Comment:
fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-07 21:46

Message:
Logged In: YES 
user_id=14422

If you wish to dispute the meaning of "should", I can only
refer you to RFC 2119.  I'm no grammarian, but this RFC is
quite explicit that "should" != "shall", which certainly
agrees with my understanding of English.

If you think this should be formally addressed by Python
documentation standards, you should probably post to
doc-sig@python.org.  I suspect you'll be met with a wall of
indifference, but you never know.


----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-06 21:36

Message:
Logged In: YES 
user_id=314434

'As the previous commenter pointed out, "should" is 
not mandatory. ' 
 
Don't want to nit-pick...but in common usage and 
especially legalese (which the world is unfortuntaly 
infected with, that being laws) 'shall' is interperted to 
mean an absolute. Should, the past tense of 'shall' , 
therefor inherits the definition of shall...which is: 
1 archaic a : will have to : MUST b : will be able to : 
CAN 
2 a -- used to express a command or exhortation 
<you shall go> b -- used in laws, regulations, or 
directives to express what is mandatory 
 
Thus, I think it's a poor idea that the use of 'should', or 
'shall', should not imply what is mandatory. After all 
they are a synonym for 'must'! 
 
If the language 'may be' was used instead of 'should 
be' I would not have reported this as a bug.  
 
I think as an issue of documentation policy, this 
should be...uhmmm...I mean...must  be changed.  : )  
I don't know where I would raise this issue.  
 

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-06 20:41

Message:
Logged In: YES 
user_id=14422

For the record, I consider this an enhancement, not a bug
fix.  As the previous commenter pointed out, "should" is not
mandatory.  But it's a useful feature, and I have no
objection to adding it on a stable branch.  So I've checked
it in on 2.4:

Modules/ossaudiodev.c             rev 1.35.4.1
Lib/test/test_ossaudiodev.py      rev 1.8.10.1
Doc/lib/libossaudiodev.tex        rev 1.12.4.2
Lib/test/output/test_ossaudiodev  rev 1.2.12.1

and merged to the trunk:

Modules/ossaudiodev.c             rev 1.36
Lib/test/test_ossaudiodev.py      rev 1.9
Doc/lib/libossaudiodev.tex        rev 1.14
Lib/test/output/test_ossaudiodev  rev 1.3


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-05 15:48

Message:
Logged In: YES 
user_id=593130

I am not sure who your last comment is aimed at.  As near as I 
can tell, Greg merely updated the group to Py2.4, implying that 
this issue is still relevant.

In Pythonese, should is advisory; only must is mandatory.  So I 
see this as a request for a pre-approved enhancement.  Since 
ossaudiodevice directly wraps an OS open file descripter, rather 
than a Python file object, the patch is more than a triviality.

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-05 13:08

Message:
Logged In: YES 
user_id=314434

That was the point of the bug report. It has no closed 
or other file-like attributes. According the python docs 
then and current: 
'File objects also offer a number of other interesting 
attributes. These are not required for file-like objects, 
but should be implemented if they make sense for 
the particular object. ' 
 
I take that to mean these attributes are mandatory, 
unless it does not make sense to implement them. 
 
In the case of file-like Audio Device Objects, they 
make sense, and thus should be there.  
 
Either this statement of file-like object policy is a bug, 
or the lack of such attributes in Audio Device Objects 
is a bug.  
 

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2003-10-05 16:32

Message:
Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
&quot;&quot;&quot; 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
&quot;&quot; 
 
&quot;Should be&quot; when they &quot;make sense&quot;  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO &quot;should&quot; 
have worked.  : P 
 
Other attributes that &quot;should be&quot; implemented  (mode and 
name) because they &quot;make sense&quot; may also be missing...I 
haven't checked.  
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-10-05 16:16

Message:
Logged In: YES 
user_id=593130

>From Lib Ref 14.11 ossaudiodev &quot;open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
&quot;
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 04:55:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 04:55:15 2005
Subject: [ python-Feature Requests-818006 ] ossaudiodev object does not
	support common readonly attrs
Message-ID: <E1D8VoK-0004uW-I4@sc8-sf-web3.sourceforge.net>

Feature Requests item #818006, was opened at 2003-10-05 02:30
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470

Category: Extension Modules
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Greg Ward (gward)
Summary: ossaudiodev object does not support common readonly attrs

Initial Comment:
fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-07 22:55

Message:
Logged In: YES 
user_id=593130

According to my dictionary, while should can be the past tense 
of shall, it is also a helper (auxiliary) word, as in 'should be' that 
can have various shades of meaning: obligation, propriety, 
expectation, likelihood, and others similar to would.  I personally 
understand it as desired and proper, in between may and must. I 
also believe that the standard for acceptance of library 
submissions has risen in the years since this module went in.

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-07 21:46

Message:
Logged In: YES 
user_id=14422

If you wish to dispute the meaning of "should", I can only
refer you to RFC 2119.  I'm no grammarian, but this RFC is
quite explicit that "should" != "shall", which certainly
agrees with my understanding of English.

If you think this should be formally addressed by Python
documentation standards, you should probably post to
doc-sig@python.org.  I suspect you'll be met with a wall of
indifference, but you never know.


----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-06 21:36

Message:
Logged In: YES 
user_id=314434

'As the previous commenter pointed out, "should" is 
not mandatory. ' 
 
Don't want to nit-pick...but in common usage and 
especially legalese (which the world is unfortuntaly 
infected with, that being laws) 'shall' is interperted to 
mean an absolute. Should, the past tense of 'shall' , 
therefor inherits the definition of shall...which is: 
1 archaic a : will have to : MUST b : will be able to : 
CAN 
2 a -- used to express a command or exhortation 
<you shall go> b -- used in laws, regulations, or 
directives to express what is mandatory 
 
Thus, I think it's a poor idea that the use of 'should', or 
'shall', should not imply what is mandatory. After all 
they are a synonym for 'must'! 
 
If the language 'may be' was used instead of 'should 
be' I would not have reported this as a bug.  
 
I think as an issue of documentation policy, this 
should be...uhmmm...I mean...must  be changed.  : )  
I don't know where I would raise this issue.  
 

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-06 20:41

Message:
Logged In: YES 
user_id=14422

For the record, I consider this an enhancement, not a bug
fix.  As the previous commenter pointed out, "should" is not
mandatory.  But it's a useful feature, and I have no
objection to adding it on a stable branch.  So I've checked
it in on 2.4:

Modules/ossaudiodev.c             rev 1.35.4.1
Lib/test/test_ossaudiodev.py      rev 1.8.10.1
Doc/lib/libossaudiodev.tex        rev 1.12.4.2
Lib/test/output/test_ossaudiodev  rev 1.2.12.1

and merged to the trunk:

Modules/ossaudiodev.c             rev 1.36
Lib/test/test_ossaudiodev.py      rev 1.9
Doc/lib/libossaudiodev.tex        rev 1.14
Lib/test/output/test_ossaudiodev  rev 1.3


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-05 15:48

Message:
Logged In: YES 
user_id=593130

I am not sure who your last comment is aimed at.  As near as I 
can tell, Greg merely updated the group to Py2.4, implying that 
this issue is still relevant.

In Pythonese, should is advisory; only must is mandatory.  So I 
see this as a request for a pre-approved enhancement.  Since 
ossaudiodevice directly wraps an OS open file descripter, rather 
than a Python file object, the patch is more than a triviality.

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-05 13:08

Message:
Logged In: YES 
user_id=314434

That was the point of the bug report. It has no closed 
or other file-like attributes. According the python docs 
then and current: 
'File objects also offer a number of other interesting 
attributes. These are not required for file-like objects, 
but should be implemented if they make sense for 
the particular object. ' 
 
I take that to mean these attributes are mandatory, 
unless it does not make sense to implement them. 
 
In the case of file-like Audio Device Objects, they 
make sense, and thus should be there.  
 
Either this statement of file-like object policy is a bug, 
or the lack of such attributes in Audio Device Objects 
is a bug.  
 

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2003-10-05 16:32

Message:
Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
&quot;&quot;&quot; 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
&quot;&quot; 
 
&quot;Should be&quot; when they &quot;make sense&quot;  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO &quot;should&quot; 
have worked.  : P 
 
Other attributes that &quot;should be&quot; implemented  (mode and 
name) because they &quot;make sense&quot; may also be missing...I 
haven't checked.  
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-10-05 16:16

Message:
Logged In: YES 
user_id=593130

>From Lib Ref 14.11 ossaudiodev &quot;open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
&quot;
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 10:20:28 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 10:20:31 2005
Subject: [ python-Bugs-1158313 ] heapq should provide iterators:
	itersmallest, iterlargest
Message-ID: <E1D8atA-000896-GQ@sc8-sf-web3.sourceforge.net>

Bugs item #1158313, was opened at 2005-03-07 15:15
Message generated for change (Comment added) made by scoder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158313&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: heapq should provide iterators: itersmallest, iterlargest

Initial Comment:
The current C-based heapq implementation provides
implementations of min-heaps and max-heaps for the
"nsmallest" and "nlargest" functions. I would like to
see them used to provide iterators over the
smallest/largest items of a heap: "itersmallest(heap)"
and "iterlargest(heap)".

Why:

The functions nsmallest() and nlargest() are efficient
(and sufficient) if n is known. However, if n is *not*
known in advance, it would still be more efficient than
sorting to run heapify() over a list and then have an
iterator run heappop on each iteration. While this is
easily implemented for min-heaps using heappop,
max-heaps are not part of the Python-Implementation.
Currently, they are only implemented in C.

Possible counter-arguments:

The straight-forward iterator implementation will
manipulate the heap. This could be seen as a
side-effect. It should, however, be enough to document
that. Similar problems are documented for mutating
sequences during iteration.


----------------------------------------------------------------------

>Comment By: Stefan Behnel (scoder)
Date: 2005-03-08 10:20

Message:
Logged In: YES 
user_id=313935

"easy and fast" was the python solution for min-heaps, you
mean. Their API is sufficient for a few-line iterator
implementation. The possible solutions for max-heaps are
comparatively ugly and generally less efficient, the best
ways being either a custom per-case solution
(decorate-useheap-undecorate) or a generic indirection
through an item wrapper class that mirrors the __le__
operator with the additional overhead of python's method
call infrastructure.

I don't think max-heaps are less common than min-heaps in
any way. It just doesn't show that well since custom
solutions are easy to write most of the time (each and every
time).

The major issue with the current heapq implementation is the
design choice of not making it a class. I agree that it is a
major advantage to have it operate on generic lists, but it
come at the price of preventing easy integration of keyword
arguments as in sort() and sorted(). A usage like

h = heap(myIterator, reverse=true)
for item in h: print item

would be so handy...

For the use-cases: As I said before, nsmallest/nlargest are
enough in many cases, but they actually handle a very
special case where n is known. On the other hand, iterators
have become a major first-level construct for Python and I
consider iteration over the ordered elements of a heap a
very comon use case. The step towards an augmented API that
provides efficient iterators both for min-heaps and
max-heaps would both underline Python's paradigm shift and
considerably simplify code that currently suffers from
custom solutions.

And again: most of the code is already there.

Another possible solution: what about a module function
heapified(seq_or_iter, key=..., cmp=..., reverse=...)
in the style of sorted() but returning an iterator?
Advantage over sorted() being the higher efficiency if the
iterator is thrown away after a small number of calls.

Just an idea...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-07 17:22

Message:
Logged In: YES 
user_id=80475

The idea for introducing heapiter() function was
unsuccessfully proposed on python-dev:

 
http://mail.python.org/pipermail/python-dev/2004-June/045348.html

The use cases were rare and the pure python solution was
both easy and fast.

If you need C coded max-heaps, that could be a separate
feature request.  There would need to be sufficient use
cases to warrant building out the module's API.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158313&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 14:20:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 14:20:10 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1D8ed2-0001Qt-Dr@sc8-sf-web3.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by smurf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Martin v. L?wis (loewis)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2005-03-08 14:20

Message:
Logged In: YES 
user_id=10327

Ahem -- seek(0,*whatever*) should still be allowed, whatever
else you do, please.

Reading UTF-16 from an odd position in a file isn't always
an error -- sometimes text is embedded in weird on-disk data
structures. As long as tell() returns something you can
seek() back to, nobody's got a right to complain -- file
position arithmetic in general is nonportable.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-04 12:44

Message:
Logged In: YES 
user_id=89016

How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56

Message:
Logged In: YES 
user_id=38388

This is obviously related to the buffer logic that Walter added
to support .readline().

In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 15:00:09 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 15:00:22 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1D8fFp-0002v7-0u@sc8-sf-web4.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Martin v. L?wis (loewis)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-08 15:00

Message:
Logged In: YES 
user_id=38388

Walter: the patch looks good. Please also add a doc-string
mentioning the resetting of the codec in case .seek() is used.

Whether .seek() causes a mess or not is not within the
responsibility of the codec - it's an application space
decision to make, otherwise we would have to introduce the
notion of seeking code points (rather than bytes) which I'd
rather not like to do since this can break existing
applications in many ways.


----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2005-03-08 14:20

Message:
Logged In: YES 
user_id=10327

Ahem -- seek(0,*whatever*) should still be allowed, whatever
else you do, please.

Reading UTF-16 from an odd position in a file isn't always
an error -- sometimes text is embedded in weird on-disk data
structures. As long as tell() returns something you can
seek() back to, nobody's got a right to complain -- file
position arithmetic in general is nonportable.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-04 12:44

Message:
Logged In: YES 
user_id=89016

How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56

Message:
Logged In: YES 
user_id=38388

This is obviously related to the buffer logic that Walter added
to support .readline().

In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 15:26:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 15:26:51 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1D8ffb-000410-RL@sc8-sf-web4.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
>Assigned to: Walter D?rwald (doerwalter)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-08 15:00

Message:
Logged In: YES 
user_id=38388

Walter: the patch looks good. Please also add a doc-string
mentioning the resetting of the codec in case .seek() is used.

Whether .seek() causes a mess or not is not within the
responsibility of the codec - it's an application space
decision to make, otherwise we would have to introduce the
notion of seeking code points (rather than bytes) which I'd
rather not like to do since this can break existing
applications in many ways.


----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2005-03-08 14:20

Message:
Logged In: YES 
user_id=10327

Ahem -- seek(0,*whatever*) should still be allowed, whatever
else you do, please.

Reading UTF-16 from an odd position in a file isn't always
an error -- sometimes text is embedded in weird on-disk data
structures. As long as tell() returns something you can
seek() back to, nobody's got a right to complain -- file
position arithmetic in general is nonportable.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-04 12:44

Message:
Logged In: YES 
user_id=89016

How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56

Message:
Logged In: YES 
user_id=38388

This is obviously related to the buffer logic that Walter added
to support .readline().

In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 15:40:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 15:40:54 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1D8ftC-0006l1-Fb@sc8-sf-web1.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Walter D?rwald (doerwalter)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-08 15:40

Message:
Logged In: YES 
user_id=89016

OK, I'll check in the patch at the beginning of next week
(I'm currently away from CVS).

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-08 15:00

Message:
Logged In: YES 
user_id=38388

Walter: the patch looks good. Please also add a doc-string
mentioning the resetting of the codec in case .seek() is used.

Whether .seek() causes a mess or not is not within the
responsibility of the codec - it's an application space
decision to make, otherwise we would have to introduce the
notion of seeking code points (rather than bytes) which I'd
rather not like to do since this can break existing
applications in many ways.


----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2005-03-08 14:20

Message:
Logged In: YES 
user_id=10327

Ahem -- seek(0,*whatever*) should still be allowed, whatever
else you do, please.

Reading UTF-16 from an odd position in a file isn't always
an error -- sometimes text is embedded in weird on-disk data
structures. As long as tell() returns something you can
seek() back to, nobody's got a right to complain -- file
position arithmetic in general is nonportable.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-04 12:44

Message:
Logged In: YES 
user_id=89016

How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56

Message:
Logged In: YES 
user_id=38388

This is obviously related to the buffer logic that Walter added
to support .readline().

In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 16:06:09 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 16:06:12 2005
Subject: [ python-Bugs-1158607 ] --disable-unicode fails when linking
Message-ID: <E1D8gHh-0007sM-HB@sc8-sf-web1.sourceforge.net>

Bugs item #1158607, was opened at 2005-03-07 22:45
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158607&group_id=5470

Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Frank Baumgart (fbaumgart)
Assigned to: Nobody/Anonymous (nobody)
Summary: --disable-unicode fails when linking

Initial Comment:
Linux, SuSE 9.2, Pentium 4
gcc 3.3.4 (pre 3.3.5 20040809)

./configure --prefix=/opt/python --disable-unicode

...
ranlib libpython2.4.a
c++ -pthread  -Xlinker -export-dynamic -o python                 Modules/python.o                 libpython2.4.a -lpthread -ldl  -lutil   -lm
libpython2.4.a(posixmodule.o)(.text+0x829): In function
`posix_tmpnam':
Modules/posixmodule.c:6158: warning: the use of
`tmpnam_r' is dangerous, better use `mkstemp'
libpython2.4.a(posixmodule.o)(.text+0x8cb): In function
`posix_tempnam':
Modules/posixmodule.c:6113: warning: the use of
`tempnam' is dangerous, better use `mkstemp'
libpython2.4.a(_codecsmodule.o)(.text+0x2c1): In
function `codec_decode':
Modules/_codecsmodule.c:141: undefined reference to
`PyUnicode_GetDefaultEncoding'
libpython2.4.a(_codecsmodule.o)(.text+0x331): In
function `codec_encode':
Modules/_codecsmodule.c:108: undefined reference to
`PyUnicode_GetDefaultEncoding'
collect2: ld returned 1 exit status
make: *** [python] Error 1


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-08 16:06

Message:
Logged In: YES 
user_id=21627

Thanks for the report. This is now fixed in

setup.py 1.215
codecs.py 1.38
copy.py 1.45
test_support.py 1.63
NEWS 1.1270
_codecsmodule.c 2.21
_tkinter.c 1.169

setup.py 1.204.2.2
codecs.py 1.35.2.3
test_support.py 1.62.4.1
NEWS 1.1193.2.33
_codecsmodule.c 2.20.2.1
_tkinter.c 1.168.2.1


----------------------------------------------------------------------

Comment By: Frank Baumgart (fbaumgart)
Date: 2005-03-07 22:58

Message:
Logged In: YES 
user_id=599418

the same bug exists in the (currently latest):

python_2005-03-07_160000.tar.gz


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158607&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 16:08:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 16:08:09 2005
Subject: [ python-Bugs-1158005 ] unixccompiler.py should deal with env in
	linker
Message-ID: <E1D8gJb-0007yT-F1@sc8-sf-web1.sourceforge.net>

Bugs item #1158005, was opened at 2005-03-07 01:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Moy (edwardmoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: unixccompiler.py should deal with env in linker

Initial Comment:
When the linker command begins with env, plus some environment 
settings, and when the target is c++, the modified linker command 
should place the c++ command in the proper place, which is not the 
first element of the linker array.

The following seems to be fix the problem:

--- unixccompiler.py.orig       2004-08-29 09:45:13.000000000 -0700
+++ unixccompiler.py    2005-03-06 16:36:05.000000000 -0800
@@ -172,7 +172,12 @@
                 else:
                     linker = self.linker_so[:]
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
+                    i = 0
+                    if os.path.basename(linker[0]) == "env":
+                        i = 1
+                        while '=' in linker[i]:
+                            i = i + 1
+                    linker[i] = self.compiler_cxx[0]
                 self.spawn(linker + ld_args)
             except DistutilsExecError, msg:
                 raise LinkError, msg


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-08 16:08

Message:
Logged In: YES 
user_id=21627

Can you please give a specific example of what you did, what
you expected to happen, and what happened instead (precise
error messages, etc)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 16:39:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 16:39:21 2005
Subject: [ python-Bugs-1156179 ] Calls from VBScript clobber passed args
Message-ID: <E1D8gnl-0007Nl-LY@sc8-sf-web4.sourceforge.net>

Bugs item #1156179, was opened at 2005-03-03 15:42
Message generated for change (Comment added) made by grincheroo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Rose (grincheroo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calls from VBScript clobber passed args

Initial Comment:
I'm using Python 2.4.0 and VBScript under ASP on IIS 5. If I call a 
Python function from VBScript AND pass a local var as the first 
parameter AND don't use the return value, then the local var I 
passed in is, upon the function's return, set to Null.

If I store the return value (even if there isn't one) OR pass the return 
value to another function, this doesn't happen. I'm attaching some 
snippets that demonstrate and work around the bug.



----------------------------------------------------------------------

>Comment By: Erik Rose (grincheroo)
Date: 2005-03-08 10:39

Message:
Logged In: YES 
user_id=888812

Let me refine the description a bit: the bug doesn't clobber only a local var 
passed as the *first* param; it clobbers the first local var passed, whether 
it's the first param or not. For example,

call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 16:39:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 16:39:54 2005
Subject: [ python-Bugs-1156179 ] Calls from VBScript clobber passed args
Message-ID: <E1D8goJ-0001Jg-Vy@sc8-sf-web1.sourceforge.net>

Bugs item #1156179, was opened at 2005-03-03 15:42
Message generated for change (Comment added) made by grincheroo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Rose (grincheroo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calls from VBScript clobber passed args

Initial Comment:
I'm using Python 2.4.0 and VBScript under ASP on IIS 5. If I call a 
Python function from VBScript AND pass a local var as the first 
parameter AND don't use the return value, then the local var I 
passed in is, upon the function's return, set to Null.

If I store the return value (even if there isn't one) OR pass the return 
value to another function, this doesn't happen. I'm attaching some 
snippets that demonstrate and work around the bug.



----------------------------------------------------------------------

>Comment By: Erik Rose (grincheroo)
Date: 2005-03-08 10:39

Message:
Logged In: YES 
user_id=888812

Let me refine the description a bit: the bug doesn't clobber only a local var 
passed as the *first* param; it clobbers the first local var passed, whether 
it's the first param or not. For example,

call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

----------------------------------------------------------------------

Comment By: Erik Rose (grincheroo)
Date: 2005-03-08 10:39

Message:
Logged In: YES 
user_id=888812

Let me refine the description a bit: the bug doesn't clobber only a local var 
passed as the *first* param; it clobbers the first local var passed, whether 
it's the first param or not. For example,

call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 16:41:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 16:41:09 2005
Subject: [ python-Bugs-1156179 ] Calls from VBScript clobber passed args
Message-ID: <E1D8gpW-0001P2-Dw@sc8-sf-web1.sourceforge.net>

Bugs item #1156179, was opened at 2005-03-03 15:42
Message generated for change (Comment added) made by grincheroo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Rose (grincheroo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calls from VBScript clobber passed args

Initial Comment:
I'm using Python 2.4.0 and VBScript under ASP on IIS 5. If I call a 
Python function from VBScript AND pass a local var as the first 
parameter AND don't use the return value, then the local var I 
passed in is, upon the function's return, set to Null.

If I store the return value (even if there isn't one) OR pass the return 
value to another function, this doesn't happen. I'm attaching some 
snippets that demonstrate and work around the bug.



----------------------------------------------------------------------

>Comment By: Erik Rose (grincheroo)
Date: 2005-03-08 10:41

Message:
Logged In: YES 
user_id=888812

Let me refine the description a bit: the bug doesn't clobber only a local var 
passed as the *first* param; it clobbers the first local var passed, whether 
it's the first param or not. For example,

call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

----------------------------------------------------------------------

Comment By: Erik Rose (grincheroo)
Date: 2005-03-08 10:39

Message:
Logged In: YES 
user_id=888812

Let me refine the description a bit: the bug doesn't clobber only a local var 
passed as the *first* param; it clobbers the first local var passed, whether 
it's the first param or not. For example,

call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

----------------------------------------------------------------------

Comment By: Erik Rose (grincheroo)
Date: 2005-03-08 10:39

Message:
Logged In: YES 
user_id=888812

Let me refine the description a bit: the bug doesn't clobber only a local var 
passed as the *first* param; it clobbers the first local var passed, whether 
it's the first param or not. For example,

call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 17:15:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 17:15:40 2005
Subject: [ python-Feature Requests-1158313 ] heapq should provide iterators:
	itersmallest, iterlargest
Message-ID: <E1D8hMu-0000fp-Om@sc8-sf-web4.sourceforge.net>

Feature Requests item #1158313, was opened at 2005-03-07 09:15
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1158313&group_id=5470

>Category: Python Library
>Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: heapq should provide iterators: itersmallest, iterlargest

Initial Comment:
The current C-based heapq implementation provides
implementations of min-heaps and max-heaps for the
"nsmallest" and "nlargest" functions. I would like to
see them used to provide iterators over the
smallest/largest items of a heap: "itersmallest(heap)"
and "iterlargest(heap)".

Why:

The functions nsmallest() and nlargest() are efficient
(and sufficient) if n is known. However, if n is *not*
known in advance, it would still be more efficient than
sorting to run heapify() over a list and then have an
iterator run heappop on each iteration. While this is
easily implemented for min-heaps using heappop,
max-heaps are not part of the Python-Implementation.
Currently, they are only implemented in C.

Possible counter-arguments:

The straight-forward iterator implementation will
manipulate the heap. This could be seen as a
side-effect. It should, however, be enough to document
that. Similar problems are documented for mutating
sequences during iteration.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-08 11:15

Message:
Logged In: YES 
user_id=80475

I am -1 on this feature request. The design of the module
(as functions on lists rather than as a class with
encapsulation) does not mesh well these proposals.

Building out the API for maxheap functions makes the module
harder to learn and it introduces a risk of a user
mismatching functions (i.e. heappop with maxheapify). 
Maxheap functionality can already be obtained by decorating
with class which redefines __cmp__.

The case for an iterator wrapper is not strong.  It was not
well received when proposed on python-dev. The risks of
mutating the heap during iteration are greater than the
equivalent situation for lists because there is no simple
way to verify that the heap condition has remained intact
between iteration steps. If truly needs, a iterator around
the existing minheap is trivial to write,

Most user needs are met by sort(), nlargest(), nsmallest(),
the existing minheap functions, or the existing minheap
functions applied to decorated data.

IMO, introducing iterators and maxheaps do not add enough
value to warrant complicating the module and introducing new
risks of misuse (altering the heapcondition during iteration
or mismatching minheap and maxheap functions).

The story would be somewhat different if the heaps had
originally been encapsulated in a class.  If they had,
iterators could be added and given protection from mutation.
Also, if there were a heap class, the API would easily
support key= and reversed= options.  But in the absence of a
heap class, it would be a mistake to force these buildouts.

The OP's corner use case presented on comp.lang.python was
met with solutions using the existing toolset.  The corner
case was wanting a maxheap to read all data into memory,
heapify it, and extract n largest elements AND n is not
known in advance AND n is small enough that sort(data) was
deemed to have too many comparisons.  Not knowing n in
advance arose because the data contained duplicate records
which the OP was unwilling to filter-out in advance with a
single pass O(n) step using a dictionary to condense
equivalence groups to a single element.

----------------------------------------------------------------------

Comment By: Stefan Behnel (scoder)
Date: 2005-03-08 04:20

Message:
Logged In: YES 
user_id=313935

"easy and fast" was the python solution for min-heaps, you
mean. Their API is sufficient for a few-line iterator
implementation. The possible solutions for max-heaps are
comparatively ugly and generally less efficient, the best
ways being either a custom per-case solution
(decorate-useheap-undecorate) or a generic indirection
through an item wrapper class that mirrors the __le__
operator with the additional overhead of python's method
call infrastructure.

I don't think max-heaps are less common than min-heaps in
any way. It just doesn't show that well since custom
solutions are easy to write most of the time (each and every
time).

The major issue with the current heapq implementation is the
design choice of not making it a class. I agree that it is a
major advantage to have it operate on generic lists, but it
come at the price of preventing easy integration of keyword
arguments as in sort() and sorted(). A usage like

h = heap(myIterator, reverse=true)
for item in h: print item

would be so handy...

For the use-cases: As I said before, nsmallest/nlargest are
enough in many cases, but they actually handle a very
special case where n is known. On the other hand, iterators
have become a major first-level construct for Python and I
consider iteration over the ordered elements of a heap a
very comon use case. The step towards an augmented API that
provides efficient iterators both for min-heaps and
max-heaps would both underline Python's paradigm shift and
considerably simplify code that currently suffers from
custom solutions.

And again: most of the code is already there.

Another possible solution: what about a module function
heapified(seq_or_iter, key=..., cmp=..., reverse=...)
in the style of sorted() but returning an iterator?
Advantage over sorted() being the higher efficiency if the
iterator is thrown away after a small number of calls.

Just an idea...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-07 11:22

Message:
Logged In: YES 
user_id=80475

The idea for introducing heapiter() function was
unsuccessfully proposed on python-dev:

 
http://mail.python.org/pipermail/python-dev/2004-June/045348.html

The use cases were rare and the pure python solution was
both easy and fast.

If you need C coded max-heaps, that could be a separate
feature request.  There would need to be sufficient use
cases to warrant building out the module's API.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1158313&group_id=5470
From noreply at sourceforge.net  Tue Mar  8 21:59:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  8 21:59:59 2005
Subject: [ python-Bugs-1144263 ] reload() is broken for C extension objects
Message-ID: <E1D8lo1-0007Hn-Ud@sc8-sf-web3.sourceforge.net>

Bugs item #1144263, was opened at 2005-02-19 03:20
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144263&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew G. Knepley (knepley)
Assigned to: Nobody/Anonymous (nobody)
Summary: reload() is broken for C extension objects

Initial Comment:
1) A C extension module (foo.so) is imported

      import foo

2) The library foo.so is rebuilt with changes

3) We reload the module

      foo = reload(foo)

The reload() method calls imp.load_dynamic() which
eventually gets down to _PyImport_GetDynLoadFunc().
This just calls dlopen(), which returns the old filehandle.

This problem can be fixed by augmenting imp with
unload_dynamic(), which could easily be implemented in
a _PyImport_GetDynUnloadFunc(), which would just
consult its handles[] array, and call dlclose() on the
appropriate handle. This will work if Python was the
only program to dlopen() foo.so.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2005-03-08 14:59

Message:
Logged In: YES 
user_id=699438

I don't know if this is a viable general-purpose fix.  Keep in 
mind that python tracks everything by references, and 
reloading doesn't correct existing bindings.  If you recompile it 
is going to screw up existing function pointers in 
PyCFunction objects.  In the example below calling a() will 
probably end up executing random code or generting a 
memory fault.

>>> import select
>>> a = select.select

... imaginary recompile ...

>>> reload(select)
<module 'select' from 'C:\Python24\DLLs\select.pyd'>
>>> b = select.select
>>> id(a)
18165472
>>> id(b)
18165476
>>> a() #BOOM!

----------------------------------------------------------------------

Comment By: Matthew G. Knepley (knepley)
Date: 2005-02-19 22:34

Message:
Logged In: YES 
user_id=58554

I have coded the proposed solution (changed import.c,
importdl.c, and dynload_shlib.c). I will assemble a test
case for it next week.

----------------------------------------------------------------------

Comment By: Matthew G. Knepley (knepley)
Date: 2005-02-19 15:37

Message:
Logged In: YES 
user_id=58554

I am only interested in fixing it for the dlopen() case,
which I thnk subsumes every architecture likely to have this
problem appear. I have no problem fixing it myself, but I
need to get all the CVS stuff setup. And I am not sure how
to easily generate the patch to send (I'm used to BK).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-19 15:27

Message:
Logged In: YES 
user_id=6656

I don't believe this is quite as easy as you make out.  It might be 
possible to make something that works for platforms that use dlopen 
though...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144263&group_id=5470
From noreply at sourceforge.net  Wed Mar  9 00:14:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  9 00:14:59 2005
Subject: [ python-Bugs-1159425 ] 2.4 crashes when try to exit app and
	mulitple threads active
Message-ID: <E1D8nui-0008To-6J@sc8-sf-web2.sourceforge.net>

Bugs item #1159425, was opened at 2005-03-08 18:14
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=1159425&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: hugendian (hugendian)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4 crashes when try to exit app and mulitple threads active

Initial Comment:
I am attaching the traceback of a python 2.4 crash.

The application I am developing executes many threads
and then has a "monitor" part that monitors certain
events. One event causes the application to shutdown.
On shutdown it notifies threads of a shutdown, and the
threads must cleanup and exit.

The traceback below occured on a shutdown. At the time
there was only one thread running.

I do not know how to investigate further. However given
pointers to do this I would be more than happy to
investigate and provide all information that could help
with this.

Some things I've observed:
1 - my application seems to be able to complete
successfully.
2 - it appears to be only after the app exits.
3 - it is not consistent. (too easy if it was!).
4 - more likely to occur the longer a
thread/application has run.
5 - does occur frequently enough to be a problem.

Once again let me know what other info I can provide,
or anything I can do to help.

Below is the traceback and some system/environment info.

Thanks.
---------------------------------------------------------------------------------
Error traceback:
-----------------
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python2.4/atexit.py", line 22, in
_run_exitfuncs
    func(*targs, **kargs)
  File "/usr/lib/python2.4/threading.py", line 636, in
__exitfunc
    self._Thread__delete()
  File "/usr/lib/python2.4/threading.py", line 522, in
__delete
    del _active[_get_ident()]
KeyError: 16384
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/lib/python2.4/atexit.py", line 22, in
_run_exitfuncs
    func(*targs, **kargs)
  File "/usr/lib/python2.4/threading.py", line 636, in
__exitfunc
    self._Thread__delete()
  File "/usr/lib/python2.4/threading.py", line 522, in
__delete
    del _active[_get_ident()]
KeyError: 16384

Software environment:
-----------------------
*********************************************
***         SYSTEM INFORMATION            ***
***     (Tue Mar  8 17:38:34 EST 2005)    ***
*********************************************
   Machine type       : i686
   Operating system   : Linux
   Kernel version     : 2.4.29
   Linux Distribution : Slackware 10.1.0
*********************************************
Python   2.4 (#1, Jan  1 2005, 21:33:55) [GCC 3.3.4] on
linux2
Gnu make   3.80
util-linux   2.12p
modutils   2.4.27
e2fsprogs   tune2fs
Linux C Library   2.3.4
Dynamic linker (ldd)   2.3.4
Linux C++ Library   5.0.6
Procps   3.2.3
Net-tools  1.60
Kbd   1.12
Sh-utils 5.2.1
*********************************************
Modules Loaded:
	nfs
	lockd
	sunrpc
	ppp_deflate
	zlib_inflate
	zlib_deflate
	bsd_comp
	ppp_async
	ppp_generic
	slhc
	emu10k1
	ac97_codec
	soundcore
	xfs
	ne2k-pci
	8390
	crc32
*********************************************
gcc version 3.3.4
Reading specs from
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs
Configured with: ../gcc-3.3.4/configure --prefix=/usr
--enable-shared --enable-threads=posix
--enable-__cxa_atexit --disable-checking --with-gnu-ld
--verbose --target=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
*********************************************

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1159425&group_id=5470
From noreply at sourceforge.net  Wed Mar  9 01:51:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  9 01:51:08 2005
Subject: [ python-Bugs-1144533 ] htmllib quote parse error within a <script>
Message-ID: <E1D8pPk-0006vC-I3@sc8-sf-web4.sourceforge.net>

Bugs item #1144533, was opened at 2005-02-19 21:02
Message generated for change (Comment added) made by leogah
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144533&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Hoeltje (ahoeltje)
Assigned to: Nobody/Anonymous (nobody)
Summary: htmllib quote parse error within a <script>

Initial Comment:
I am using the htmllib to parse web pages for plain text content.  I 
came across a web page that contained a script construct similar 
to the example below.  Note that the script is itself writing a script.  
The htmllib appears to be confused by the use of single and double 
quotes used within the real <script> and </script> tags.

I am using "Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 
3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin" on a 
PowerBook G4 running OSX 10.3.8.


<html>
  <body>
    <h1> This is a test </h1>
    <br>
    <blockquote>
      <script language="JavaScript">
        rnum = Math.round( Math.random() * 100000 );
        document.write( '<scr' + 'ipt src="http://www.a.org/' + 
rnum + '/"></scr' + 'ipt>' );
      </script>
    </blockquote>
  </body>
</html>

Here is the Python trace:

Traceback (most recent call last):
  File "cleanFeed.py", line 26, in ?
    clean = stripHtml.strip( feed )
  File "/Users/allan/Desktop/Mood for Today/stripHtml.py", line 
144, in strip
    parser.feed(s)
  File "/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/HTMLParser.py", line 108, in feed
    self.goahead(0)
  File "/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/HTMLParser.py", line 150, in goahead
    k = self.parse_endtag(i)
  File "/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/HTMLParser.py", line 327, in parse_endtag
    self.error("bad end tag: %s" % `rawdata[i:j]`)
  File "/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/HTMLParser.py", line 115, in error
    raise HTMLParseError(message, self.getpos())
HTMLParser.HTMLParseError: bad end tag: "</scr' + 'ipt>", at line 
1, column 309




----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2005-03-09 00:51

Message:
Logged In: YES 
user_id=356893

Generally speaking, you are better off conditioning random
junk pulled off the web (with uTidylib or similar) before
feeding it to HTMLParser, which tends to report errors when
it finds them.

See: http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.2.1
for an explanation of why the error message is strictly correct.

Someone may step in with a patch to make HTMLParser more
tolerant in this case; there will always be something else
though.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144533&group_id=5470
From noreply at sourceforge.net  Wed Mar  9 01:56:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  9 01:56:28 2005
Subject: [ python-Feature Requests-818006 ] ossaudiodev object does not
	support common readonly attrs
Message-ID: <E1D8pUt-00076T-D5@sc8-sf-web4.sourceforge.net>

Feature Requests item #818006, was opened at 2003-10-05 02:30
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470

Category: Extension Modules
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Greg Ward (gward)
Summary: ossaudiodev object does not support common readonly attrs

Initial Comment:
fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-08 19:56

Message:
Logged In: YES 
user_id=14422

Oops: since this is a new feature, I should not have added
it on the 2.4 branch.  This will only be in Python 2.5, not
2.4.1.  Reverted changes in:
Modules/ossaudiodev.c rev 1.35.4.2
Lib/test/test_ossaudiodev.py rev 1.8.10.2
Doc/lib/libossaudiodev.tex rev 1.12.4.3

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-07 22:55

Message:
Logged In: YES 
user_id=593130

According to my dictionary, while should can be the past tense 
of shall, it is also a helper (auxiliary) word, as in 'should be' that 
can have various shades of meaning: obligation, propriety, 
expectation, likelihood, and others similar to would.  I personally 
understand it as desired and proper, in between may and must. I 
also believe that the standard for acceptance of library 
submissions has risen in the years since this module went in.

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-07 21:46

Message:
Logged In: YES 
user_id=14422

If you wish to dispute the meaning of "should", I can only
refer you to RFC 2119.  I'm no grammarian, but this RFC is
quite explicit that "should" != "shall", which certainly
agrees with my understanding of English.

If you think this should be formally addressed by Python
documentation standards, you should probably post to
doc-sig@python.org.  I suspect you'll be met with a wall of
indifference, but you never know.


----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-06 21:36

Message:
Logged In: YES 
user_id=314434

'As the previous commenter pointed out, "should" is 
not mandatory. ' 
 
Don't want to nit-pick...but in common usage and 
especially legalese (which the world is unfortuntaly 
infected with, that being laws) 'shall' is interperted to 
mean an absolute. Should, the past tense of 'shall' , 
therefor inherits the definition of shall...which is: 
1 archaic a : will have to : MUST b : will be able to : 
CAN 
2 a -- used to express a command or exhortation 
<you shall go> b -- used in laws, regulations, or 
directives to express what is mandatory 
 
Thus, I think it's a poor idea that the use of 'should', or 
'shall', should not imply what is mandatory. After all 
they are a synonym for 'must'! 
 
If the language 'may be' was used instead of 'should 
be' I would not have reported this as a bug.  
 
I think as an issue of documentation policy, this 
should be...uhmmm...I mean...must  be changed.  : )  
I don't know where I would raise this issue.  
 

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-06 20:41

Message:
Logged In: YES 
user_id=14422

For the record, I consider this an enhancement, not a bug
fix.  As the previous commenter pointed out, "should" is not
mandatory.  But it's a useful feature, and I have no
objection to adding it on a stable branch.  So I've checked
it in on 2.4:

Modules/ossaudiodev.c             rev 1.35.4.1
Lib/test/test_ossaudiodev.py      rev 1.8.10.1
Doc/lib/libossaudiodev.tex        rev 1.12.4.2
Lib/test/output/test_ossaudiodev  rev 1.2.12.1

and merged to the trunk:

Modules/ossaudiodev.c             rev 1.36
Lib/test/test_ossaudiodev.py      rev 1.9
Doc/lib/libossaudiodev.tex        rev 1.14
Lib/test/output/test_ossaudiodev  rev 1.3


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-05 15:48

Message:
Logged In: YES 
user_id=593130

I am not sure who your last comment is aimed at.  As near as I 
can tell, Greg merely updated the group to Py2.4, implying that 
this issue is still relevant.

In Pythonese, should is advisory; only must is mandatory.  So I 
see this as a request for a pre-approved enhancement.  Since 
ossaudiodevice directly wraps an OS open file descripter, rather 
than a Python file object, the patch is more than a triviality.

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2005-03-05 13:08

Message:
Logged In: YES 
user_id=314434

That was the point of the bug report. It has no closed 
or other file-like attributes. According the python docs 
then and current: 
'File objects also offer a number of other interesting 
attributes. These are not required for file-like objects, 
but should be implemented if they make sense for 
the particular object. ' 
 
I take that to mean these attributes are mandatory, 
unless it does not make sense to implement them. 
 
In the case of file-like Audio Device Objects, they 
make sense, and thus should be there.  
 
Either this statement of file-like object policy is a bug, 
or the lack of such attributes in Audio Device Objects 
is a bug.  
 

----------------------------------------------------------------------

Comment By: Dave Cinege (dcinege)
Date: 2003-10-05 16:32

Message:
Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
&quot;&quot;&quot; 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
&quot;&quot; 
 
&quot;Should be&quot; when they &quot;make sense&quot;  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO &quot;should&quot; 
have worked.  : P 
 
Other attributes that &quot;should be&quot; implemented  (mode and 
name) because they &quot;make sense&quot; may also be missing...I 
haven't checked.  
 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-10-05 16:16

Message:
Logged In: YES 
user_id=593130

>From Lib Ref 14.11 ossaudiodev &quot;open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
&quot;
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470
From noreply at sourceforge.net  Wed Mar  9 04:35:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  9 04:35:27 2005
Subject: [ python-Bugs-1117670 ] profiler: Bad return and Bad call errors
	with exceptions
Message-ID: <E1D8rym-0003ol-MY@sc8-sf-web4.sourceforge.net>

Bugs item #1117670, was opened at 2005-02-06 23:50
Message generated for change (Comment added) made by garyoberbrunner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: profiler: Bad return and Bad call errors with exceptions

Initial Comment:
I ran into a weird error when trying to profile a test
script of mine:
AssertionError: ('Bad call', ('', 0, 'encode'))

I managed to whittle it down to some minimal test
cases, which are attached (although the errors they
generate are slightly different.)  

$ python-cvs -m profile profile_badcall.py
Traceback (most recent call last):
[snipped ...]
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "profile_badcall.py", line 10, in ?
    os.path.join("C",'b')
  File
"/home/donut/usr64/python/lib/python2.5/posixpath.py",
line 56, in join
    def join(a, *p):
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
    if self.dispatch[event](self, frame, t):
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 285, in trace_dispatch_call
    assert (self.cur is None or AssertionError: ('Bad call', ('profile_badcall.py', 2,
'trier'))

$ python-cvs -m profile profile_badreturn.py
Traceback (most recent call last):
[snipped...]
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
    if self.dispatch[event](self, frame, t):
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 312, in trace_dispatch_return
    assert frame is self.cur[-2].f_back, ("Bad return",
self.cur[-3])
AssertionError: ('Bad return', ('profile_badreturn.py',
1, 'trier'))


The errors occur in python CVS as of 20050206 and
python 2.4, but not in python 2.3.4.  
OS: debian sid (3.1)
Arch: amd64


----------------------------------------------------------------------

Comment By: Gary Oberbrunner (garyoberbrunner)
Date: 2005-03-08 22:35

Message:
Logged In: YES 
user_id=417980

Is there any news on this bug?  It is possibly preventing
scons (http://scons.org) from being profiled on python 2.4
-- we get the same errors as above.  Test case is too large
to include here, but please email me with any news if
possible!  Would be glad to test a fix.
-- Gary

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&group_id=5470
From noreply at sourceforge.net  Wed Mar  9 12:26:22 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  9 12:26:25 2005
Subject: [ python-Bugs-1143895 ] inspect.getsource() breakage in 2.4
Message-ID: <E1D8zKY-00063R-Jv@sc8-sf-web4.sourceforge.net>

Bugs item #1143895, was opened at 2005-02-18 17:26
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
>Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getsource() breakage in 2.4

Initial Comment:
In a real-life case, inspect.getsource() used to
produce the correct result on 2.3 but no longer does on
2.4:

def somefunc(x, y):  # comments
     ...body...

With 2.4 (and 2.5 CVS) the body is completely skipped
because the first line doesn't end with a colon.  In my
opinion that's a critical problem for any code relying
on getsource(), even though such code can be considered
as relying on a large pile of fragile hacks in the
first place...

Attached is a patch for test_inspect.py, showing the
problem (also includes a different, much more
convoluted bug example).  It seems that looking for and
around ':' in the first line isn't such a good idea;
relying more fully on the tokenizer would probably be a
better solution.

Assigned to jlgijsbers, as the author of the changes
that broke this (Dec 12th, 2004).  (No blame intended,
the change was meant to fix a different bug, and it did
so.)

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-03-09 12:26

Message:
Logged In: YES 
user_id=469548

Well, I'm sorry, but I can't make the time after all. I've
asked the author of the original patch to take a look at
this patch. Note that this code isn't yet in a 2.4 release,
so we could also back this out before 2.4.1.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-02-18 20:11

Message:
Logged In: YES 
user_id=469548

Right now I don't have time to look into this bug deeply,
but I will do so this week. I'll note that the convoluted
example doesn't seem to be working under 2.3, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470
From noreply at sourceforge.net  Wed Mar  9 16:40:00 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  9 16:40:03 2005
Subject: [ python-Bugs-1143895 ] inspect.getsource() breakage in 2.4
Message-ID: <E1D93I0-0008JE-LB@sc8-sf-web1.sourceforge.net>

Bugs item #1143895, was opened at 2005-02-18 17:26
Message generated for change (Comment added) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getsource() breakage in 2.4

Initial Comment:
In a real-life case, inspect.getsource() used to
produce the correct result on 2.3 but no longer does on
2.4:

def somefunc(x, y):  # comments
     ...body...

With 2.4 (and 2.5 CVS) the body is completely skipped
because the first line doesn't end with a colon.  In my
opinion that's a critical problem for any code relying
on getsource(), even though such code can be considered
as relying on a large pile of fragile hacks in the
first place...

Attached is a patch for test_inspect.py, showing the
problem (also includes a different, much more
convoluted bug example).  It seems that looking for and
around ':' in the first line isn't such a good idea;
relying more fully on the tokenizer would probably be a
better solution.

Assigned to jlgijsbers, as the author of the changes
that broke this (Dec 12th, 2004).  (No blame intended,
the change was meant to fix a different bug, and it did
so.)

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2005-03-09 16:40

Message:
Logged In: YES 
user_id=329382

Patch http://www.python.org/sf/1159931 fixes this problem.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-03-09 12:26

Message:
Logged In: YES 
user_id=469548

Well, I'm sorry, but I can't make the time after all. I've
asked the author of the original patch to take a look at
this patch. Note that this code isn't yet in a 2.4 release,
so we could also back this out before 2.4.1.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-02-18 20:11

Message:
Logged In: YES 
user_id=469548

Right now I don't have time to look into this bug deeply,
but I will do so this week. I'll note that the convoluted
example doesn't seem to be working under 2.3, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470
From noreply at sourceforge.net  Wed Mar  9 20:56:46 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  9 20:56:50 2005
Subject: [ python-Bugs-834452 ] python and lithuanian locales
Message-ID: <E1D97IU-00067D-G9@sc8-sf-web4.sourceforge.net>

Bugs item #834452, was opened at 2003-11-02 08:41
Message generated for change (Comment added) made by sorlov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834452&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mantas (mantaz)
Assigned to: Nobody/Anonymous (nobody)
Summary: python and lithuanian locales

Initial Comment:
python's locale.py file contains only one lithuanian
locale Iso 8859-4 which is obsolete. Now almost all
uses iso 8859-13. 
Lithuanian locale is called lt, and i think it must be
named lt_lt.



----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-09 19:56

Message:
Logged In: YES 
user_id=1235914

The fix is in Python 2.5. For 2.4 and 2.3 it is discussed in
patch 1118341

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834452&group_id=5470
From noreply at sourceforge.net  Wed Mar  9 21:37:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  9 21:37:07 2005
Subject: [ python-Bugs-1160187 ] Setup file needs entries for collections,
	itertools, strop 
Message-ID: <E1D97vV-0007uV-66@sc8-sf-web4.sourceforge.net>

Bugs item #1160187, was opened at 2005-03-09 15:37
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=1160187&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Niraj Bajpai (nbajpai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setup file needs entries for collections, itertools, strop 

Initial Comment:
For static builds in python2.4, Setup file under Modules 
directory needs entries for collections, itertools, strop and 
_random modules.

I have made following entries in my Setup file for static 
python build (which can work in self served / isolated 
environments)

_random _randommodule.c
collections collectionsmodule.c
itertools itertoolsmodule.c
strop stropmodule.c

Thanks,
Niraj


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470
From noreply at sourceforge.net  Wed Mar  9 22:42:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  9 22:42:59 2005
Subject: [ python-Bugs-1158005 ] unixccompiler.py should deal with env in
	linker
Message-ID: <E1D98xF-0001YN-Co@sc8-sf-web1.sourceforge.net>

Bugs item #1158005, was opened at 2005-03-06 16:42
Message generated for change (Comment added) made by edwardmoy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Moy (edwardmoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: unixccompiler.py should deal with env in linker

Initial Comment:
When the linker command begins with env, plus some environment 
settings, and when the target is c++, the modified linker command 
should place the c++ command in the proper place, which is not the 
first element of the linker array.

The following seems to be fix the problem:

--- unixccompiler.py.orig       2004-08-29 09:45:13.000000000 -0700
+++ unixccompiler.py    2005-03-06 16:36:05.000000000 -0800
@@ -172,7 +172,12 @@
                 else:
                     linker = self.linker_so[:]
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
+                    i = 0
+                    if os.path.basename(linker[0]) == "env":
+                        i = 1
+                        while '=' in linker[i]:
+                            i = i + 1
+                    linker[i] = self.compiler_cxx[0]
                 self.spawn(linker + ld_args)
             except DistutilsExecError, msg:
                 raise LinkError, msg


----------------------------------------------------------------------

>Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 13:42

Message:
Logged In: YES 
user_id=1233904

I was trying to build wxPython on Mac OS X.  Without the change, it would 
compile all .c files, then when it tried to link, it would execute a command that 
looked like:

g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ...

and fail.  This is because it overwrote "env" with "g++".  It needs to skip the 
env and its arguments, and replace (in this case) the c++.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-08 07:08

Message:
Logged In: YES 
user_id=21627

Can you please give a specific example of what you did, what
you expected to happen, and what happened instead (precise
error messages, etc)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 00:03:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 00:03:55 2005
Subject: [ python-Bugs-1158005 ] unixccompiler.py should deal with env in
	linker
Message-ID: <E1D9ADY-0005JE-S1@sc8-sf-web2.sourceforge.net>

Bugs item #1158005, was opened at 2005-03-07 01:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Moy (edwardmoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: unixccompiler.py should deal with env in linker

Initial Comment:
When the linker command begins with env, plus some environment 
settings, and when the target is c++, the modified linker command 
should place the c++ command in the proper place, which is not the 
first element of the linker array.

The following seems to be fix the problem:

--- unixccompiler.py.orig       2004-08-29 09:45:13.000000000 -0700
+++ unixccompiler.py    2005-03-06 16:36:05.000000000 -0800
@@ -172,7 +172,12 @@
                 else:
                     linker = self.linker_so[:]
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
+                    i = 0
+                    if os.path.basename(linker[0]) == "env":
+                        i = 1
+                        while '=' in linker[i]:
+                            i = i + 1
+                    linker[i] = self.compiler_cxx[0]
                 self.spawn(linker + ld_args)
             except DistutilsExecError, msg:
                 raise LinkError, msg


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-10 00:03

Message:
Logged In: YES 
user_id=21627

Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come
from? I cannot find it in the Python build process or
distutils. So if it is in the wxPython setup.py, it sure
must be a bug in that setup.py, no?

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 22:42

Message:
Logged In: YES 
user_id=1233904

I was trying to build wxPython on Mac OS X.  Without the change, it would 
compile all .c files, then when it tried to link, it would execute a command that 
looked like:

g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ...

and fail.  This is because it overwrote "env" with "g++".  It needs to skip the 
env and its arguments, and replace (in this case) the c++.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-08 16:08

Message:
Logged In: YES 
user_id=21627

Can you please give a specific example of what you did, what
you expected to happen, and what happened instead (precise
error messages, etc)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 00:22:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 00:22:14 2005
Subject: [ python-Bugs-1158005 ] unixccompiler.py should deal with env in
	linker
Message-ID: <E1D9AVH-0006Ss-KZ@sc8-sf-web4.sourceforge.net>

Bugs item #1158005, was opened at 2005-03-06 16:42
Message generated for change (Comment added) made by edwardmoy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Moy (edwardmoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: unixccompiler.py should deal with env in linker

Initial Comment:
When the linker command begins with env, plus some environment 
settings, and when the target is c++, the modified linker command 
should place the c++ command in the proper place, which is not the 
first element of the linker array.

The following seems to be fix the problem:

--- unixccompiler.py.orig       2004-08-29 09:45:13.000000000 -0700
+++ unixccompiler.py    2005-03-06 16:36:05.000000000 -0800
@@ -172,7 +172,12 @@
                 else:
                     linker = self.linker_so[:]
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
+                    i = 0
+                    if os.path.basename(linker[0]) == "env":
+                        i = 1
+                        while '=' in linker[i]:
+                            i = i + 1
+                    linker[i] = self.compiler_cxx[0]
                 self.spawn(linker + ld_args)
             except DistutilsExecError, msg:
                 raise LinkError, msg


----------------------------------------------------------------------

>Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 15:22

Message:
Logged In: YES 
user_id=1233904

I don't know the internal of python all that well, but I know that python (and 
perl as well) use "env MACOSX_DEPLOYMENT_TARGET=10.3 cc" as the 
link command, because this environment variable is required to enable the 
dynamic lookup symbol resolution feature in the linker (used with two-level 
namespaces).  This is all rather Mac OS X specific, but I'm assuming since 
the python distributed with Mac OS X does this, that wxWidgets is picking 
that up and doing the same thing, as it should.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-09 15:03

Message:
Logged In: YES 
user_id=21627

Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come
from? I cannot find it in the Python build process or
distutils. So if it is in the wxPython setup.py, it sure
must be a bug in that setup.py, no?

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 13:42

Message:
Logged In: YES 
user_id=1233904

I was trying to build wxPython on Mac OS X.  Without the change, it would 
compile all .c files, then when it tried to link, it would execute a command that 
looked like:

g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ...

and fail.  This is because it overwrote "env" with "g++".  It needs to skip the 
env and its arguments, and replace (in this case) the c++.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-08 07:08

Message:
Logged In: YES 
user_id=21627

Can you please give a specific example of what you did, what
you expected to happen, and what happened instead (precise
error messages, etc)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 00:48:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 00:48:19 2005
Subject: [ python-Bugs-1160187 ] Setup file needs entries for collections,
	itertools, strop 
Message-ID: <E1D9AuV-0002Et-J3@sc8-sf-web3.sourceforge.net>

Bugs item #1160187, was opened at 2005-03-09 15:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Niraj Bajpai (nbajpai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setup file needs entries for collections, itertools, strop 

Initial Comment:
For static builds in python2.4, Setup file under Modules 
directory needs entries for collections, itertools, strop and 
_random modules.

I have made following entries in my Setup file for static 
python build (which can work in self served / isolated 
environments)

_random _randommodule.c
collections collectionsmodule.c
itertools itertoolsmodule.c
strop stropmodule.c

Thanks,
Niraj


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-09 18:48

Message:
Logged In: YES 
user_id=80475

Fixed.  See Modules/Setup.dist 1.50 and 1.48.2.1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 00:48:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 00:48:57 2005
Subject: [ python-Bugs-1160187 ] Setup file needs entries for collections,
	itertools, strop 
Message-ID: <E1D9Av9-0002HJ-FC@sc8-sf-web3.sourceforge.net>

Bugs item #1160187, was opened at 2005-03-09 15:37
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470

Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Niraj Bajpai (nbajpai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setup file needs entries for collections, itertools, strop 

Initial Comment:
For static builds in python2.4, Setup file under Modules 
directory needs entries for collections, itertools, strop and 
_random modules.

I have made following entries in my Setup file for static 
python build (which can work in self served / isolated 
environments)

_random _randommodule.c
collections collectionsmodule.c
itertools itertoolsmodule.c
strop stropmodule.c

Thanks,
Niraj


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-09 18:48

Message:
Logged In: YES 
user_id=80475

Fixed.  See Modules/Setup.dist 1.50 and 1.48.2.1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 00:58:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 00:58:58 2005
Subject: [ python-Bugs-1158005 ] unixccompiler.py should deal with env in
	linker
Message-ID: <E1D9B4q-0002eO-6A@sc8-sf-web3.sourceforge.net>

Bugs item #1158005, was opened at 2005-03-07 01:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Moy (edwardmoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: unixccompiler.py should deal with env in linker

Initial Comment:
When the linker command begins with env, plus some environment 
settings, and when the target is c++, the modified linker command 
should place the c++ command in the proper place, which is not the 
first element of the linker array.

The following seems to be fix the problem:

--- unixccompiler.py.orig       2004-08-29 09:45:13.000000000 -0700
+++ unixccompiler.py    2005-03-06 16:36:05.000000000 -0800
@@ -172,7 +172,12 @@
                 else:
                     linker = self.linker_so[:]
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
+                    i = 0
+                    if os.path.basename(linker[0]) == "env":
+                        i = 1
+                        while '=' in linker[i]:
+                            i = i + 1
+                    linker[i] = self.compiler_cxx[0]
                 self.spawn(linker + ld_args)
             except DistutilsExecError, msg:
                 raise LinkError, msg


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-10 00:58

Message:
Logged In: YES 
user_id=21627

Can you find out where it does pick it up *from*, please?
Search the distutils and config directories of Python, and
the wxWindows directories for clues; also print your env.

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-10 00:22

Message:
Logged In: YES 
user_id=1233904

I don't know the internal of python all that well, but I know that python (and 
perl as well) use "env MACOSX_DEPLOYMENT_TARGET=10.3 cc" as the 
link command, because this environment variable is required to enable the 
dynamic lookup symbol resolution feature in the linker (used with two-level 
namespaces).  This is all rather Mac OS X specific, but I'm assuming since 
the python distributed with Mac OS X does this, that wxWidgets is picking 
that up and doing the same thing, as it should.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-10 00:03

Message:
Logged In: YES 
user_id=21627

Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come
from? I cannot find it in the Python build process or
distutils. So if it is in the wxPython setup.py, it sure
must be a bug in that setup.py, no?

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 22:42

Message:
Logged In: YES 
user_id=1233904

I was trying to build wxPython on Mac OS X.  Without the change, it would 
compile all .c files, then when it tried to link, it would execute a command that 
looked like:

g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ...

and fail.  This is because it overwrote "env" with "g++".  It needs to skip the 
env and its arguments, and replace (in this case) the c++.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-08 16:08

Message:
Logged In: YES 
user_id=21627

Can you please give a specific example of what you did, what
you expected to happen, and what happened instead (precise
error messages, etc)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 02:37:14 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 02:37:16 2005
Subject: [ python-Bugs-1160328 ] urllib2 post error when using httpproxy
Message-ID: <E1D9Cby-0001or-26@sc8-sf-web1.sourceforge.net>

Bugs item #1160328, was opened at 2005-03-10 01:37
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=1160328&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: small tiger (xhchen111)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 post error when using httpproxy

Initial Comment:
==============
program
==============
# -*- coding: gbk -*-
import httplib, urllib, urllib2#, cookielib

proxy = urllib2.ProxyHandler
({'http':'http://pic:iLusalt@proxy.pconline.com.cn:8080'})
opener = urllib2.build_opener(proxy)
urllib2.install_opener(opener)

f = urllib2.urlopen
("http://192.168.10.177:8080/price/login.do?
method=list")
print f.read()

postdata = urllib.urlencode
({'userId':'admin', 'password':'admin'})
request = urllib2.Request
('http://192.168.10.177:8080/price/login.do?
method=login')
response = urllib2.urlopen(request, postdata)
print response.read()

====================
out put
====================
E:\jt>c:\python24\python t.py
Traceback (most recent call last):
  File "t.py", line 13, in ?
    response = urllib2.urlopen(request, postdata)
  File "c:\python24\lib\urllib2.py", line 130, in urlopen
    return _opener.open(url, data)
  File "c:\python24\lib\urllib2.py", line 358, in open
    response = self._open(req, data)
  File "c:\python24\lib\urllib2.py", line 376, in _open
    '_open', req)
  File "c:\python24\lib\urllib2.py", line 337, in _call_chain
    result = func(*args)
  File "c:\python24\lib\urllib2.py", line 1021, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "c:\python24\lib\urllib2.py", line 996, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error (10053, 'Software 
caused connection abort')>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160328&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 05:32:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 05:32:18 2005
Subject: [ python-Bugs-1160383 ] digit-only tag values are mishandled in
	Tkinter
Message-ID: <E1D9FLL-0006RW-2j@sc8-sf-web4.sourceforge.net>

Bugs item #1160383, was opened at 2005-03-09 20:32
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=1160383&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. L?wis (loewis)
Summary: digit-only tag values are mishandled in Tkinter

Initial Comment:
It  appears that  most Tkinter tag operations fail on
digit-only tag values

>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()       
>>> c.find_withtag("123")
()

tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm

only say this about tag values:
  "Tags are ordinary strings, and they can contain
anything except whitespace."

So this behaviour seems like a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 05:32:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 05:33:05 2005
Subject: [ python-Bugs-1160383 ] digit-only tag values are mishandled in
	Tkinter
Message-ID: <E1D9FM3-0006SI-TD@sc8-sf-web4.sourceforge.net>

Bugs item #1160383, was opened at 2005-03-09 20:32
Message generated for change (Settings changed) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470

Category: Tkinter
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. L?wis (loewis)
Summary: digit-only tag values are mishandled in Tkinter

Initial Comment:
It  appears that  most Tkinter tag operations fail on
digit-only tag values

>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()       
>>> c.find_withtag("123")
()

tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm

only say this about tag values:
  "Tags are ordinary strings, and they can contain
anything except whitespace."

So this behaviour seems like a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 08:34:22 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 08:34:24 2005
Subject: [ python-Bugs-1158005 ] unixccompiler.py should deal with env in
	linker
Message-ID: <E1D9IBa-0003D1-1J@sc8-sf-web4.sourceforge.net>

Bugs item #1158005, was opened at 2005-03-06 16:42
Message generated for change (Comment added) made by edwardmoy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Moy (edwardmoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: unixccompiler.py should deal with env in linker

Initial Comment:
When the linker command begins with env, plus some environment 
settings, and when the target is c++, the modified linker command 
should place the c++ command in the proper place, which is not the 
first element of the linker array.

The following seems to be fix the problem:

--- unixccompiler.py.orig       2004-08-29 09:45:13.000000000 -0700
+++ unixccompiler.py    2005-03-06 16:36:05.000000000 -0800
@@ -172,7 +172,12 @@
                 else:
                     linker = self.linker_so[:]
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
+                    i = 0
+                    if os.path.basename(linker[0]) == "env":
+                        i = 1
+                        while '=' in linker[i]:
+                            i = i + 1
+                    linker[i] = self.compiler_cxx[0]
                 self.spawn(linker + ld_args)
             except DistutilsExecError, msg:
                 raise LinkError, msg


----------------------------------------------------------------------

>Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 23:34

Message:
Logged In: YES 
user_id=1233904

OK, looks like my problem was with 2.3.4, so I made that patch.  Now that 
2.3.5 is out, I didn't notice that this patch doesn't seem to be necessary 
anymore.  Sorry for wasting your time.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-09 15:58

Message:
Logged In: YES 
user_id=21627

Can you find out where it does pick it up *from*, please?
Search the distutils and config directories of Python, and
the wxWindows directories for clues; also print your env.

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 15:22

Message:
Logged In: YES 
user_id=1233904

I don't know the internal of python all that well, but I know that python (and 
perl as well) use "env MACOSX_DEPLOYMENT_TARGET=10.3 cc" as the 
link command, because this environment variable is required to enable the 
dynamic lookup symbol resolution feature in the linker (used with two-level 
namespaces).  This is all rather Mac OS X specific, but I'm assuming since 
the python distributed with Mac OS X does this, that wxWidgets is picking 
that up and doing the same thing, as it should.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-09 15:03

Message:
Logged In: YES 
user_id=21627

Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come
from? I cannot find it in the Python build process or
distutils. So if it is in the wxPython setup.py, it sure
must be a bug in that setup.py, no?

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 13:42

Message:
Logged In: YES 
user_id=1233904

I was trying to build wxPython on Mac OS X.  Without the change, it would 
compile all .c files, then when it tried to link, it would execute a command that 
looked like:

g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ...

and fail.  This is because it overwrote "env" with "g++".  It needs to skip the 
env and its arguments, and replace (in this case) the c++.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-08 07:08

Message:
Logged In: YES 
user_id=21627

Can you please give a specific example of what you did, what
you expected to happen, and what happened instead (precise
error messages, etc)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 11:19:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 11:19:19 2005
Subject: [ python-Bugs-1160534 ] Autoconf failure on FreeBSD 5.3,
	and AC_INIT set incorrectly
Message-ID: <E1D9KlA-0001ek-Ib@sc8-sf-web1.sourceforge.net>

Bugs item #1160534, was opened at 2005-03-10 10:19
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=1160534&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Brooksby (rptb1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly

Initial Comment:
Begin forwarded message:

Date: 8 March 2005 18:20:48 GMT
To: bug-autoconf@gnu.org
Subject: Autoconf asked me to tell you about this bug

On a clean FreeBSD 5.3 machine, do:

  cd /usr/local/lang/python
  make install

and you will see, amongst other things:

checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h: check for missing prerequisite 
headers?
configure: WARNING: ncurses.h: proceeding with the 
preprocessor's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to bug-autoconf@gnu.org. 
##
configure: WARNING:     ## ------------------------------------ ##
checking for ncurses.h... yes
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes

---

Begin forwarded message:

Date: 9 March 2005 11:47:03 GMT
To: Richard Brooksby <rb@ravenbrook.com>
Cc: bug-autoconf@gnu.org
Subject: Re: Autoconf asked me to tell you about this bug

Hello,

On Tue, Mar 08, 2005 at 06:20:48PM +0000, Richard Brooksby 
wrote:
On a clean FreeBSD 5.3 machine, do:
  cd /usr/local/lang/python

you should report this bug to the bug report address of the 
"python"
project.  Tell them to read the section "Present But Cannot Be 
Compiled"
of the manual to autoconf-2.59.

They have misconfigured the bug report address in AC_INIT, so 
also tell
them to change it to *their* bug report address.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 16:43:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 16:43:35 2005
Subject: [ python-Bugs-1158490 ] locale fails if LANGUAGE has multiple
	locales
Message-ID: <E1D9Pow-0006fP-S2@sc8-sf-web1.sourceforge.net>

Bugs item #1158490, was opened at 2005-03-07 20:11
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470

>Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: mixedpuppy (mixedpuppy)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: locale fails if LANGUAGE has multiple locales

Initial Comment:
The locale module does not correctly handle the
LANGUAGE environment variable if it contains multiple
settings.  Example:

LANGUAGE="en_DK:en_GB:en_US:en"

Note, en_DK does not exist in locale_alias

In normalize, the colons are replaced with dots, which
is incorrect.  getdefaultlocal should seperate these
first, then try each one until it finds one that works,
or fails on all.  

GLIBC documentation:
http://www.delorie.com/gnu/docs/glibc/libc_138.html

"While for the LC_xxx variables the value should
consist of exactly one specification of a locale the
LANGUAGE variable's value can consist of a colon
separated list of locale names."


Testing this is simple, just set your LANGUAGE
environment var to the above example, and use
locale.getdefaultlocal()

> export LANGUAGE="en_DK:en_GB:en_US:en"
> python
ActivePython 2.4 Build 244 (ActiveState Corp.) based on
Python 2.4 (#1, Feb  9 2005, 19:33:15)
[GCC 3.3.1 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> locale.getdefaultlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/ActivePython-2.4/lib/python2.4/locale.py",
line 344, in getdefaultlocale
    return _parse_localename(localename)
  File "/opt/ActivePython-2.4/lib/python2.4/locale.py",
line 278, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_DK:en_GB:en_US:en
>>>


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-10 16:43

Message:
Logged In: YES 
user_id=38388

The URL you gave does state that LANGUAGE can take mulitple
entries separated by colons. However, I fail to see how to
choose the locale from the list of possibilities. Any ideas ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 18:21:10 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 18:21:14 2005
Subject: [ python-Bugs-1158909 ] unpack error in getdefaultlocale() on
	certain locales
Message-ID: <E1D9RLS-0005zn-GT@sc8-sf-web3.sourceforge.net>

Bugs item #1158909, was opened at 2005-03-08 10:40
Message generated for change (Settings changed) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158909&group_id=5470

>Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unpack error in getdefaultlocale() on certain locales

Initial Comment:
Patch fixes the locale breakage mentioned in the bug by
using the normalized locale var. Patch is against
current CVS.

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2005-03-10 17:06

Message:
Logged In: YES 
user_id=9205

Oops, I misread the bug report #1158490. I thought it is the
same problem as described here. This is a separate issue,
and I edited the summary accordingly. The bug can be
reproduced with:
$ env -i LANG=de_DE@euro python2.5 -c "import locale; print
locale.getdefaultlocale()"

Sorry for the misunderstanding.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-10 16:43

Message:
Logged In: YES 
user_id=38388

Sorry, but this patch doesn't fix the bug. See bug #1158490
for discussion.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-10 15:01

Message:
Logged In: YES 
user_id=1235914

Sorry, I mean England hasn't accepted euro as default
currency, not that England hasn't joined EU. Sometimes I
write not what I think :)

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-10 14:58

Message:
Logged In: YES 
user_id=1235914

There is no en_EN@euro because England hasn't joined EU :)
If the code that tries to guess encoding is removed it will
raise an exception:
ValueError: unknown locale: en_EN@euro
Like locale command line tool prints warning:
LANG=en_EN@euro locale charmap
locale: Cannot set LC_CTYPE to default locale: No such file
or directory
locale: Cannot set LC_MESSAGES to default locale: No such
file or directory
locale: Cannot set LC_ALL to default locale: No such file or
directory
ANSI_X3.4-1968



----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2005-03-09 22:35

Message:
Logged In: YES 
user_id=9205

Wouldn't removing the if '@' stuff break other cases? For
example locale.normalize('en_EN@euro') still returns
'en_EN@euro'. In this case the @euro part would not get
split off and will be returned. When I understand the
documentation of getdefaultlocale() correctly, it is not
supposed to return the @euro part.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-09 21:31

Message:
Logged In: YES 
user_id=1235914

I think the correct fix is to remove the whole if '@' in
code:. There is also a comment that the code under if is
bogus. The reason for the breakage is that
locale.normalize('de_DE@euro') started to return
de_DE.ISO8859-15

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2005-03-09 20:59

Message:
Logged In: YES 
user_id=9205

I forgot an example. this fails for me on current CVS:
$ env LANG=de_DE@euro python2.5 -c "import locale; print
locale.getdefaultlocale()"
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/usr/local/lib/python2.5/locale.py", line 357, in
getdefaultlocale
    return _parse_localename(localename)
  File "/usr/local/lib/python2.5/locale.py", line 280, in
_parse_localename
    code, modifier = code.split('@')
ValueError: need more than 1 value to unpack

The error is that the @ char is searched in the original
locale, but the split is done on the normalized locale.
Hence the unpack error.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-09 20:26

Message:
Logged In: YES 
user_id=1235914

I don't get what this patch fixes. It actually changes
handling of locales with @ sign, but there is no mentioning
of that in bug 1158490. What do I miss?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158909&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 18:22:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 18:22:19 2005
Subject: [ python-Bugs-1158909 ] unpack error in getdefaultlocale() on
	certain locales
Message-ID: <E1D9RMV-00062g-VQ@sc8-sf-web3.sourceforge.net>

Bugs item #1158909, was opened at 2005-03-08 10:40
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158909&group_id=5470

>Category: Python Library
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unpack error in getdefaultlocale() on certain locales

Initial Comment:
Patch fixes the locale breakage mentioned in the bug by
using the normalized locale var. Patch is against
current CVS.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-10 18:22

Message:
Logged In: YES 
user_id=38388

Change ticket type to bug.

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2005-03-10 17:06

Message:
Logged In: YES 
user_id=9205

Oops, I misread the bug report #1158490. I thought it is the
same problem as described here. This is a separate issue,
and I edited the summary accordingly. The bug can be
reproduced with:
$ env -i LANG=de_DE@euro python2.5 -c "import locale; print
locale.getdefaultlocale()"

Sorry for the misunderstanding.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-10 16:43

Message:
Logged In: YES 
user_id=38388

Sorry, but this patch doesn't fix the bug. See bug #1158490
for discussion.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-10 15:01

Message:
Logged In: YES 
user_id=1235914

Sorry, I mean England hasn't accepted euro as default
currency, not that England hasn't joined EU. Sometimes I
write not what I think :)

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-10 14:58

Message:
Logged In: YES 
user_id=1235914

There is no en_EN@euro because England hasn't joined EU :)
If the code that tries to guess encoding is removed it will
raise an exception:
ValueError: unknown locale: en_EN@euro
Like locale command line tool prints warning:
LANG=en_EN@euro locale charmap
locale: Cannot set LC_CTYPE to default locale: No such file
or directory
locale: Cannot set LC_MESSAGES to default locale: No such
file or directory
locale: Cannot set LC_ALL to default locale: No such file or
directory
ANSI_X3.4-1968



----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2005-03-09 22:35

Message:
Logged In: YES 
user_id=9205

Wouldn't removing the if '@' stuff break other cases? For
example locale.normalize('en_EN@euro') still returns
'en_EN@euro'. In this case the @euro part would not get
split off and will be returned. When I understand the
documentation of getdefaultlocale() correctly, it is not
supposed to return the @euro part.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-09 21:31

Message:
Logged In: YES 
user_id=1235914

I think the correct fix is to remove the whole if '@' in
code:. There is also a comment that the code under if is
bogus. The reason for the breakage is that
locale.normalize('de_DE@euro') started to return
de_DE.ISO8859-15

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2005-03-09 20:59

Message:
Logged In: YES 
user_id=9205

I forgot an example. this fails for me on current CVS:
$ env LANG=de_DE@euro python2.5 -c "import locale; print
locale.getdefaultlocale()"
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/usr/local/lib/python2.5/locale.py", line 357, in
getdefaultlocale
    return _parse_localename(localename)
  File "/usr/local/lib/python2.5/locale.py", line 280, in
_parse_localename
    code, modifier = code.split('@')
ValueError: need more than 1 value to unpack

The error is that the @ char is searched in the original
locale, but the split is done on the normalized locale.
Hence the unpack error.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-09 20:26

Message:
Logged In: YES 
user_id=1235914

I don't get what this patch fixes. It actually changes
handling of locales with @ sign, but there is no mentioning
of that in bug 1158490. What do I miss?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158909&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 18:38:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 18:38:56 2005
Subject: [ python-Bugs-1158909 ] unpack error in getdefaultlocale() on
	certain locales
Message-ID: <E1D9Rcb-0002rA-Qy@sc8-sf-web4.sourceforge.net>

Bugs item #1158909, was opened at 2005-03-08 10:40
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158909&group_id=5470

Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unpack error in getdefaultlocale() on certain locales

Initial Comment:
Patch fixes the locale breakage mentioned in the bug by
using the normalized locale var. Patch is against
current CVS.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-10 18:38

Message:
Logged In: YES 
user_id=38388

Reference:
http://www.delorie.com/gnu/docs/glibc/libc_138.html

Just as note to myself: 

Need to change the code in _parse_localename() - the special
casing of the euro modifier is wrong and should be removed
(the locale database now contains all valid references to
iso-8859-15). Looking at the locale database, it seems safe
to just strip off the modifier: if the database doesn't have
an entry for the modifier, there's nothing much we can do
with it anyway.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-10 18:22

Message:
Logged In: YES 
user_id=38388

Change ticket type to bug.

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2005-03-10 17:06

Message:
Logged In: YES 
user_id=9205

Oops, I misread the bug report #1158490. I thought it is the
same problem as described here. This is a separate issue,
and I edited the summary accordingly. The bug can be
reproduced with:
$ env -i LANG=de_DE@euro python2.5 -c "import locale; print
locale.getdefaultlocale()"

Sorry for the misunderstanding.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-10 16:43

Message:
Logged In: YES 
user_id=38388

Sorry, but this patch doesn't fix the bug. See bug #1158490
for discussion.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-10 15:01

Message:
Logged In: YES 
user_id=1235914

Sorry, I mean England hasn't accepted euro as default
currency, not that England hasn't joined EU. Sometimes I
write not what I think :)

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-10 14:58

Message:
Logged In: YES 
user_id=1235914

There is no en_EN@euro because England hasn't joined EU :)
If the code that tries to guess encoding is removed it will
raise an exception:
ValueError: unknown locale: en_EN@euro
Like locale command line tool prints warning:
LANG=en_EN@euro locale charmap
locale: Cannot set LC_CTYPE to default locale: No such file
or directory
locale: Cannot set LC_MESSAGES to default locale: No such
file or directory
locale: Cannot set LC_ALL to default locale: No such file or
directory
ANSI_X3.4-1968



----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2005-03-09 22:35

Message:
Logged In: YES 
user_id=9205

Wouldn't removing the if '@' stuff break other cases? For
example locale.normalize('en_EN@euro') still returns
'en_EN@euro'. In this case the @euro part would not get
split off and will be returned. When I understand the
documentation of getdefaultlocale() correctly, it is not
supposed to return the @euro part.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-09 21:31

Message:
Logged In: YES 
user_id=1235914

I think the correct fix is to remove the whole if '@' in
code:. There is also a comment that the code under if is
bogus. The reason for the breakage is that
locale.normalize('de_DE@euro') started to return
de_DE.ISO8859-15

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2005-03-09 20:59

Message:
Logged In: YES 
user_id=9205

I forgot an example. this fails for me on current CVS:
$ env LANG=de_DE@euro python2.5 -c "import locale; print
locale.getdefaultlocale()"
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/usr/local/lib/python2.5/locale.py", line 357, in
getdefaultlocale
    return _parse_localename(localename)
  File "/usr/local/lib/python2.5/locale.py", line 280, in
_parse_localename
    code, modifier = code.split('@')
ValueError: need more than 1 value to unpack

The error is that the @ char is searched in the original
locale, but the split is done on the normalized locale.
Hence the unpack error.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-09 20:26

Message:
Logged In: YES 
user_id=1235914

I don't get what this patch fixes. It actually changes
handling of locales with @ sign, but there is no mentioning
of that in bug 1158490. What do I miss?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158909&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 19:09:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 19:09:39 2005
Subject: [ python-Bugs-1160802 ] Can't build Zope on Windows w/ 2.4.1c1
Message-ID: <E1D9S6K-0004Dz-KD@sc8-sf-web4.sourceforge.net>

Bugs item #1160802, was opened at 2005-03-10 13:09
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=1160802&group_id=5470

Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't build Zope on Windows w/ 2.4.1c1

Initial Comment:
See the python-dev thread with the same name, at

<http://mail.python.org/pipermail/python-dev/2005-
March/051995.html>

The PATH we build, when compiling C extensions, 
keeps getting bigger until putenv() blows up.  Zope 
builds a lot of C extensions.

A simple but sane hack is adding a new:

.                if p not in self.__paths:

guard inside the:

.            for p in string.split(os.environ['path'], ';'):
.                self.__paths.append(p)

loop in 2.4.1c1's msvccompiler.py's initialize() function.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160802&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 19:48:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 19:48:10 2005
Subject: [ python-Bugs-1158490 ] locale fails if LANGUAGE has multiple
	locales
Message-ID: <E1D9ShZ-0006iV-MR@sc8-sf-web2.sourceforge.net>

Bugs item #1158490, was opened at 2005-03-07 19:11
Message generated for change (Comment added) made by sorlov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: mixedpuppy (mixedpuppy)
Assigned to: M.-A. Lemburg (lemburg)
Summary: locale fails if LANGUAGE has multiple locales

Initial Comment:
The locale module does not correctly handle the
LANGUAGE environment variable if it contains multiple
settings.  Example:

LANGUAGE="en_DK:en_GB:en_US:en"

Note, en_DK does not exist in locale_alias

In normalize, the colons are replaced with dots, which
is incorrect.  getdefaultlocal should seperate these
first, then try each one until it finds one that works,
or fails on all.  

GLIBC documentation:
http://www.delorie.com/gnu/docs/glibc/libc_138.html

"While for the LC_xxx variables the value should
consist of exactly one specification of a locale the
LANGUAGE variable's value can consist of a colon
separated list of locale names."


Testing this is simple, just set your LANGUAGE
environment var to the above example, and use
locale.getdefaultlocal()

> export LANGUAGE="en_DK:en_GB:en_US:en"
> python
ActivePython 2.4 Build 244 (ActiveState Corp.) based on
Python 2.4 (#1, Feb  9 2005, 19:33:15)
[GCC 3.3.1 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> locale.getdefaultlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/ActivePython-2.4/lib/python2.4/locale.py",
line 344, in getdefaultlocale
    return _parse_localename(localename)
  File "/opt/ActivePython-2.4/lib/python2.4/locale.py",
line 278, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_DK:en_GB:en_US:en
>>>


----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-10 18:48

Message:
Logged In: YES 
user_id=1235914

The docs for getdefaultlocale state that it follows the GNU
gettext search path. OTOH gettext can return result from any
of catalogs en_DK:en_GB:en_US:en, it depends on the content
of the message. So maybe getdefaultlocale should just pick
up the first value from LANGUAGE ?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-10 15:43

Message:
Logged In: YES 
user_id=38388

The URL you gave does state that LANGUAGE can take mulitple
entries separated by colons. However, I fail to see how to
choose the locale from the list of possibilities. Any ideas ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470
From noreply at sourceforge.net  Thu Mar 10 22:50:14 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 10 22:50:18 2005
Subject: [ python-Bugs-1158490 ] locale fails if LANGUAGE has multiple
	locales
Message-ID: <E1D9VXq-0008IA-0n@sc8-sf-web1.sourceforge.net>

Bugs item #1158490, was opened at 2005-03-07 11:11
Message generated for change (Comment added) made by mixedpuppy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: mixedpuppy (mixedpuppy)
Assigned to: M.-A. Lemburg (lemburg)
Summary: locale fails if LANGUAGE has multiple locales

Initial Comment:
The locale module does not correctly handle the
LANGUAGE environment variable if it contains multiple
settings.  Example:

LANGUAGE="en_DK:en_GB:en_US:en"

Note, en_DK does not exist in locale_alias

In normalize, the colons are replaced with dots, which
is incorrect.  getdefaultlocal should seperate these
first, then try each one until it finds one that works,
or fails on all.  

GLIBC documentation:
http://www.delorie.com/gnu/docs/glibc/libc_138.html

"While for the LC_xxx variables the value should
consist of exactly one specification of a locale the
LANGUAGE variable's value can consist of a colon
separated list of locale names."


Testing this is simple, just set your LANGUAGE
environment var to the above example, and use
locale.getdefaultlocal()

> export LANGUAGE="en_DK:en_GB:en_US:en"
> python
ActivePython 2.4 Build 244 (ActiveState Corp.) based on
Python 2.4 (#1, Feb  9 2005, 19:33:15)
[GCC 3.3.1 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> locale.getdefaultlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/ActivePython-2.4/lib/python2.4/locale.py",
line 344, in getdefaultlocale
    return _parse_localename(localename)
  File "/opt/ActivePython-2.4/lib/python2.4/locale.py",
line 278, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_DK:en_GB:en_US:en
>>>


----------------------------------------------------------------------

>Comment By: mixedpuppy (mixedpuppy)
Date: 2005-03-10 13:50

Message:
Logged In: YES 
user_id=1234417

IMHO the proper behaviour is to split on the colon, then try
each one from start to finish until there is a success, or
all fail.  For example, if you just try en_DK, you will get
a failure since that is not in locale.locale_alias, but
en_GB or en_US would succeed.

----------------------------------------------------------------------

Comment By: Serge Orlov (sorlov)
Date: 2005-03-10 10:48

Message:
Logged In: YES 
user_id=1235914

The docs for getdefaultlocale state that it follows the GNU
gettext search path. OTOH gettext can return result from any
of catalogs en_DK:en_GB:en_US:en, it depends on the content
of the message. So maybe getdefaultlocale should just pick
up the first value from LANGUAGE ?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-10 07:43

Message:
Logged In: YES 
user_id=38388

The URL you gave does state that LANGUAGE can take mulitple
entries separated by colons. However, I fail to see how to
choose the locale from the list of possibilities. Any ideas ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 00:13:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 00:13:43 2005
Subject: [ python-Bugs-1160802 ] Can't build Zope on Windows w/ 2.4.1c1
Message-ID: <E1D9Wqa-0001GR-EW@sc8-sf-web4.sourceforge.net>

Bugs item #1160802, was opened at 2005-03-10 13:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160802&group_id=5470

Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't build Zope on Windows w/ 2.4.1c1

Initial Comment:
See the python-dev thread with the same name, at

<http://mail.python.org/pipermail/python-dev/2005-
March/051995.html>

The PATH we build, when compiling C extensions, 
keeps getting bigger until putenv() blows up.  Zope 
builds a lot of C extensions.

A simple but sane hack is adding a new:

.                if p not in self.__paths:

guard inside the:

.            for p in string.split(os.environ['path'], ';'):
.                self.__paths.append(p)

loop in 2.4.1c1's msvccompiler.py's initialize() function.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-10 18:13

Message:
Logged In: YES 
user_id=31435

On python-dev, AMK said:

"""
In distutils.msvccompiler:

   def __init__ (self, verbose=0, dry_run=0, force=0):
       ...
       self.initialized = False

   def compile(self, sources,
               output_dir=None, macros=None, 
include_dirs=None, debug=0,
               extra_preargs=None, extra_postargs=None, 
depends=None):

       if not self.initialized: self.initialize()
       ...

   def initialize(self):
       ... does not seem to set self.initialized to True!

I think the fix is to add 'self.initialized = True' to the
initialize() method, but can't test it (no Windows).  This fix 
should also go into 2.4.1-final, I expect.
"""

Adding that to the end of initialize() worked for me (and 
ripping out my hack).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160802&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 01:27:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 01:27:33 2005
Subject: [ python-Bugs-706450 ] test_socket fails when not connected
Message-ID: <E1D9Y03-0004fN-Uh@sc8-sf-web2.sourceforge.net>

Bugs item #706450, was opened at 2003-03-19 11:12
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706450&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Stone (mbrierst)
>Assigned to: Brett Cannon (bcannon)
Summary: test_socket fails when not connected

Initial Comment:

Should test_socket require the network resource
be enabled?  It only works for me when I'm
connected (Running an old slackware linux).
This is true of both CVS and 2.2 python

When not connected testHostnameRes fails because
getfqdn() returns my hostname, 'zazz', but
gethostbyaddr(ip) returns the hostname 'localhost'.
When I am connected getfqdn() also returns
'localhost' so there's no problem.  It could be
fixed for me by either requiring the network
resource or changing line 234 of test_socket from:
all_host_names = [hname] + aliases
to:
all_host_names = [hname, hostname] + aliases

Or maybe my machine's setup is just messed
up in which case I trust you'll close the bug.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-10 16:27

Message:
Logged In: YES 
user_id=357491

This can either be considered invalid because of my previous comment 
explaining why the 'network' resource is not appropriate for test_socket, or 
it can be considered fix since I just coincidentally fixed test_socket in the 
exact same way Michael suggested.

Either way it is now closed.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 15:38

Message:
Logged In: YES 
user_id=357491

The purpose of the network resource if for when you need to 
connect to the Internet, not to use sockets so the test is correct 
in that regard.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706450&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 01:34:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 01:34:51 2005
Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore
Message-ID: <E1D9Y75-0004Ax-Kz@sc8-sf-web4.sourceforge.net>

Bugs item #1161031, was opened at 2005-03-11 13:34
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=1161031&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Neverending warnings from asyncore

Initial Comment:
Changes in asyncore from 2.3 to 2.4 mean that
asyncore.poll() now passes all the sockets in the map
to select.select() to be checked for errors, which is
probably a good thing.  If an error occurs, then
handle_expt() is called, which by default logs the error.

asyncore.dispatcher creates nonblocking sockets.  When
connect_ex() is called on a nonblocking socket, it will
probably return EWOULDBLOCK (connecting takes time),
which may mean the connection is successful, or may not
(asyncore dispatcher keeps going assuming all is well).

If the connection is not successful, and then
asyncore.loop() is called, then select.select() will
indicate that there is an error with the socket (can't
connect) and the error will be logged.

The trouble is that asyncore.loop then keeps going, and
will log this error again.  My not-that-fast system
here gets about 10,000 logged messages per second with
a single socket in the asyncore map.

There are ways to avoid this:

  (1) if the socket is blocking when connect()ing (and
then nonblocking afterwards) an error is raised if the
connect fails.

  (2) Before calling asyncore.loop(), the caller can
run through all the sockets, checking that they are ok.

  (3) handle_expt() can be overridden with a function
that repairs or removes the socket from the map (etc)

However, I'm not convinced that this is good behavior
for asyncore to have, by default.  On Windows,
select.select() will only indicate an error when trying
to connect (nonblocking) or if SO_OOBINLINE is
disabled, but this may not be the case (i.e. errors can
occur at other times) with other platforms, right? 
Unless the error is temporary, asyncore will by default
start streaming (extremely fast) a lot of "warning:
unhandled exception" (not very helpful an error
message, either) messages.  Even if the error only
lasts a minute, that could easily result in 10,000
warnings being logged.

Do any of the python developers agree that this is a
flaw?  I'm happy to work up a patch for whatever the
desired solution is, if so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 05:24:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 05:24:51 2005
Subject: [ python-Bugs-1160802 ] Can't build Zope on Windows w/ 2.4.1c1
Message-ID: <E1D9bhg-0002Y2-6U@sc8-sf-web4.sourceforge.net>

Bugs item #1160802, was opened at 2005-03-10 13:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160802&group_id=5470

Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 8
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Can't build Zope on Windows w/ 2.4.1c1

Initial Comment:
See the python-dev thread with the same name, at

<http://mail.python.org/pipermail/python-dev/2005-
March/051995.html>

The PATH we build, when compiling C extensions, 
keeps getting bigger until putenv() blows up.  Zope 
builds a lot of C extensions.

A simple but sane hack is adding a new:

.                if p not in self.__paths:

guard inside the:

.            for p in string.split(os.environ['path'], ';'):
.                self.__paths.append(p)

loop in 2.4.1c1's msvccompiler.py's initialize() function.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-10 23:24

Message:
Logged In: YES 
user_id=31435

Assigned to me.  I'll check in Andrew's fix Friday, pending 
more testing.  (Anthony approved this plan, BTW.)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-10 18:13

Message:
Logged In: YES 
user_id=31435

On python-dev, AMK said:

"""
In distutils.msvccompiler:

   def __init__ (self, verbose=0, dry_run=0, force=0):
       ...
       self.initialized = False

   def compile(self, sources,
               output_dir=None, macros=None, 
include_dirs=None, debug=0,
               extra_preargs=None, extra_postargs=None, 
depends=None):

       if not self.initialized: self.initialize()
       ...

   def initialize(self):
       ... does not seem to set self.initialized to True!

I think the fix is to add 'self.initialized = True' to the
initialize() method, but can't test it (no Windows).  This fix 
should also go into 2.4.1-final, I expect.
"""

Adding that to the end of initialize() worked for me (and 
ripping out my hack).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160802&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 09:25:14 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 09:25:18 2005
Subject: [ python-Bugs-1157901 ] xml.dom.minidom.Node.removeChild() doesn't
	remove
Message-ID: <E1D9fSM-0003iy-8E@sc8-sf-web2.sourceforge.net>

Bugs item #1157901, was opened at 2005-03-06 21:17
Message generated for change (Comment added) made by bobince
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Kempka (mkempka)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom.Node.removeChild() doesn't remove

Initial Comment:
There seems to be a constellation where
xml.dom.minidom.Node.removeChild() doesn't remove
childs properly.

I found this bug in 2.3.4 and it is still in:

Python 2.3.5 (#2, Feb  9 2005, 00:38:15)
[GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2


I attached 3 files, the dombug.py demonstrates the
problem: 

First, I iterate over all children of a specific
element, check their tag name and remove them using
removeChild() and then child.unlink().
After the elements are removed I iterate again, do the
same check for a tag and find there are still elements
in there. That is, there are still elements in there
when I parse the file errorintroducer.xml. When I parse
the file errorfree.xml the elements are all removed. 

The difference between the xml files is the carriage
return after each closing tag. 

Since to my knowledge both xml files are well-formed I
would expect in both cases that all elements are removed.

----------------------------------------------------------------------

Comment By: Andrew Clover (bobince)
Date: 2005-03-11 08:25

Message:
Logged In: YES 
user_id=311085

Bug should be marked INVALID.

childNodes lists are 'live'. You are iterating over a list
you are destroying at the same time. The code is equivalent
to the more obviously broken:

  foo= [1, 2, 3, 4]
  i= 0
  while i<len(foo):
    del foo[i]
    i+= 1
  foo
  >>> [2, 4]

The 'working' example only works because it has extra
whitespace nodes in, so when you delete child number i, the
child i+1 that is skipped over is a Text node containing
only whitespace.

BTW, there's a separate bug tracker for the PyXML project
from which minidom is taken. You may get better results by
submitting there (and discussing on the XML-SIG list).


----------------------------------------------------------------------

Comment By: Matthias Kempka (mkempka)
Date: 2005-03-06 21:24

Message:
Logged In: YES 
user_id=736381

so.. this form posts the error report with uploading
files...interesting...

Anyway, the output I get when running the program with
errorintroducer.xml is:

> python dombug.py
found element 1
 .. removed
found element 3
 .. removed
found element 5
 .. removed
-----------everything removed from timerList[0]---------------
found Element    2
found Element    4
found Element    6


imho it should be, as it is with errorfree.xml:

found element 1
 .. removed
found element 2
 .. removed
found element 3
 .. removed
found element 4
 .. removed
found element 5
 .. removed
found element 6
 .. removed
-----------everything removed from timerList[0]---------------


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 09:56:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 09:56:05 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1D9fwB-0000ZM-5f@sc8-sf-web3.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 08:56
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=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 16:42:34 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 16:42:39 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1D9mHa-0002o0-Fj@sc8-sf-web3.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 03:56
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
>Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-11 10:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 17:28:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 17:28:47 2005
Subject: [ python-Bugs-1161476 ] Incorrect return value in gc docs
Message-ID: <E1D9n0G-0004YK-V5@sc8-sf-web1.sourceforge.net>

Bugs item #1161476, was opened at 2005-03-11 08:28
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=1161476&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Aravind (iamfenris)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect return value in gc docs

Initial Comment:
The document

http://www.python.org/doc/current/lib/module-gc.html

notes that gc.isenabled() returns true, while it
actually returns 1. 

The description reads:
isenabled(  	)
    Returns true if automatic collection is enabled.

Suggested correction:
isenabled(  	)
    Returns 1 if automatic collection is enabled.

HTH,
-Aravind

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161476&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 18:23:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 18:24:02 2005
Subject: [ python-Bugs-1160802 ] Can't build Zope on Windows w/ 2.4.1c1
Message-ID: <E1D9nrj-0007Ow-RS@sc8-sf-web1.sourceforge.net>

Bugs item #1160802, was opened at 2005-03-10 13:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160802&group_id=5470

Category: Distutils
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Can't build Zope on Windows w/ 2.4.1c1

Initial Comment:
See the python-dev thread with the same name, at

<http://mail.python.org/pipermail/python-dev/2005-
March/051995.html>

The PATH we build, when compiling C extensions, 
keeps getting bigger until putenv() blows up.  Zope 
builds a lot of C extensions.

A simple but sane hack is adding a new:

.                if p not in self.__paths:

guard inside the:

.            for p in string.split(os.environ['path'], ';'):
.                self.__paths.append(p)

loop in 2.4.1c1's msvccompiler.py's initialize() function.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-11 12:23

Message:
Logged In: YES 
user_id=31435

Fixed, via AMK's suggestion:

Lib/distutils/msvccompiler.py 1.64.2.3
Misc/NEWS 1.1193.2.35

Not an issue for 2.5 (MSVCCompiler initialization is already 
OK there).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-10 23:24

Message:
Logged In: YES 
user_id=31435

Assigned to me.  I'll check in Andrew's fix Friday, pending 
more testing.  (Anthony approved this plan, BTW.)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-10 18:13

Message:
Logged In: YES 
user_id=31435

On python-dev, AMK said:

"""
In distutils.msvccompiler:

   def __init__ (self, verbose=0, dry_run=0, force=0):
       ...
       self.initialized = False

   def compile(self, sources,
               output_dir=None, macros=None, 
include_dirs=None, debug=0,
               extra_preargs=None, extra_postargs=None, 
depends=None):

       if not self.initialized: self.initialize()
       ...

   def initialize(self):
       ... does not seem to set self.initialized to True!

I think the fix is to add 'self.initialized = True' to the
initialize() method, but can't test it (no Windows).  This fix 
should also go into 2.4.1-final, I expect.
"""

Adding that to the end of initialize() worked for me (and 
ripping out my hack).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160802&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 20:29:28 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 20:29:30 2005
Subject: [ python-Bugs-1161595 ] Minor error in section 3.2
Message-ID: <E1D9ppA-0001Qu-TF@sc8-sf-web2.sourceforge.net>

Bugs item #1161595, was opened at 2005-03-11 19:29
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=1161595&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Barbay (jyby)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor error in section 3.2

Initial Comment:
In the section "3.2 First Steps Towards Programming " of 
the Python tutorial (http://docs.python.org/tut/node5.html), 
the output of both implementations of the Fibonacci 
sequence computation is incorrect. 
 
As written, only one 1 should be output.  
You should either remove one 1 from the input,  
or replace the lines "print b" and "print b,"  
by "print a" and "print a,". 
 
This is minor but might confuse unnecessarily  beginners. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161595&group_id=5470
From noreply at sourceforge.net  Fri Mar 11 20:40:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 11 20:40:59 2005
Subject: [ python-Bugs-1161595 ] Minor error in section 3.2
Message-ID: <E1D9q0G-0005nJ-II@sc8-sf-web3.sourceforge.net>

Bugs item #1161595, was opened at 2005-03-11 19:29
Message generated for change (Comment added) made by jyby
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161595&group_id=5470

Category: Documentation
Group: None
Status: Open
>Resolution: Invalid
>Priority: 1
Submitted By: Jeremy Barbay (jyby)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor error in section 3.2

Initial Comment:
In the section "3.2 First Steps Towards Programming " of 
the Python tutorial (http://docs.python.org/tut/node5.html), 
the output of both implementations of the Fibonacci 
sequence computation is incorrect. 
 
As written, only one 1 should be output.  
You should either remove one 1 from the input,  
or replace the lines "print b" and "print b,"  
by "print a" and "print a,". 
 
This is minor but might confuse unnecessarily  beginners. 

----------------------------------------------------------------------

>Comment By: Jeremy Barbay (jyby)
Date: 2005-03-11 19:40

Message:
Logged In: YES 
user_id=149696

All my apologies: I didn't check my code correctly: 
as the algorithm is initializing a with  0  instead of 1, the output is 
correct. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161595&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 08:46:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 08:46:56 2005
Subject: [ python-Bugs-1161476 ] Incorrect return value in gc docs
Message-ID: <E1DA1Ko-0007Rl-AC@sc8-sf-web1.sourceforge.net>

Bugs item #1161476, was opened at 2005-03-12 01:28
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161476&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Aravind (iamfenris)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect return value in gc docs

Initial Comment:
The document

http://www.python.org/doc/current/lib/module-gc.html

notes that gc.isenabled() returns true, while it
actually returns 1. 

The description reads:
isenabled(  	)
    Returns true if automatic collection is enabled.

Suggested correction:
isenabled(  	)
    Returns 1 if automatic collection is enabled.

HTH,
-Aravind

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2005-03-12 16:46

Message:
Logged In: YES 
user_id=671362

This document is for Python 2.4.
  http://www.python.org/doc/current/lib/

Are you sure your Python has the same version number as 
this?
I guess you're using Python(say, 2.2) that doesn't have a built-
in bool type.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161476&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 11:59:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 11:59:46 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DA4LO-0000Sn-V5@sc8-sf-web2.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 16:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 12:14:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 12:14:07 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DA4ZJ-0006K6-DO@sc8-sf-web4.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 16:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 12:16:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 12:16:14 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DA4bL-0006Nu-Jg@sc8-sf-web4.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 16:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 12:59:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 12:59:51 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DA5HV-00052L-Pl@sc8-sf-web3.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 08:56
Message generated for change (Comment added) made by m_webber_sydney
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 10:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 15:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 13:13:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 13:13:51 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DA5V6-0005RZ-EL@sc8-sf-web3.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 13:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 12:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 16:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 14:05:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 14:05:19 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DA6It-0007El-Gr@sc8-sf-web1.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 08:56
Message generated for change (Comment added) made by m_webber_sydney
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 13:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 10:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 15:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 15:07:28 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 15:07:30 2005
Subject: [ python-Bugs-1161476 ] Incorrect return value in gc docs
Message-ID: <E1DA7H6-00038d-So@sc8-sf-web4.sourceforge.net>

Bugs item #1161476, was opened at 2005-03-11 08:28
Message generated for change (Comment added) made by iamfenris
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161476&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Aravind (iamfenris)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect return value in gc docs

Initial Comment:
The document

http://www.python.org/doc/current/lib/module-gc.html

notes that gc.isenabled() returns true, while it
actually returns 1. 

The description reads:
isenabled(  	)
    Returns true if automatic collection is enabled.

Suggested correction:
isenabled(  	)
    Returns 1 if automatic collection is enabled.

HTH,
-Aravind

----------------------------------------------------------------------

>Comment By: Aravind (iamfenris)
Date: 2005-03-12 06:07

Message:
Logged In: YES 
user_id=1237322

Oops! I apologise -- I have both 2.3.4 and 2.4 running on my
machine, and the return value was 1 with 2.3.4 but the
correct True with 2.4. 
This is not a bug.

-Aravind

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2005-03-11 23:46

Message:
Logged In: YES 
user_id=671362

This document is for Python 2.4.
  http://www.python.org/doc/current/lib/

Are you sure your Python has the same version number as 
this?
I guess you're using Python(say, 2.2) that doesn't have a built-
in bool type.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161476&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 15:51:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 15:51:24 2005
Subject: [ python-Bugs-1161476 ] Incorrect return value in gc docs
Message-ID: <E1DA7xZ-0001sZ-NG@sc8-sf-web3.sourceforge.net>

Bugs item #1161476, was opened at 2005-03-12 01:28
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161476&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: None
Priority: 5
Submitted By: Aravind (iamfenris)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect return value in gc docs

Initial Comment:
The document

http://www.python.org/doc/current/lib/module-gc.html

notes that gc.isenabled() returns true, while it
actually returns 1. 

The description reads:
isenabled(  	)
    Returns true if automatic collection is enabled.

Suggested correction:
isenabled(  	)
    Returns 1 if automatic collection is enabled.

HTH,
-Aravind

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2005-03-12 23:51

Message:
Logged In: YES 
user_id=671362

Looks like so.
CVS log of gcmodule.c shows that isenabled function has 
changed to return True/False instead of 1/0 since 2.4.

http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/M
odules/gcmodule.c?r1=2.75&r2=2.76



----------------------------------------------------------------------

Comment By: Aravind (iamfenris)
Date: 2005-03-12 23:07

Message:
Logged In: YES 
user_id=1237322

Oops! I apologise -- I have both 2.3.4 and 2.4 running on my
machine, and the return value was 1 with 2.3.4 but the
correct True with 2.4. 
This is not a bug.

-Aravind

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2005-03-12 16:46

Message:
Logged In: YES 
user_id=671362

This document is for Python 2.4.
  http://www.python.org/doc/current/lib/

Are you sure your Python has the same version number as 
this?
I guess you're using Python(say, 2.2) that doesn't have a built-
in bool type.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161476&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 15:54:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 15:54:55 2005
Subject: [ python-Bugs-1162001 ] configure incorrectly adds -OPT:Olimit=0
	for icc
Message-ID: <E1DA80y-0007av-7U@sc8-sf-web2.sourceforge.net>

Bugs item #1162001, was opened at 2005-03-12 14:54
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=1162001&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure incorrectly adds -OPT:Olimit=0 for icc

Initial Comment:
When using Python 2.4 and the Intel C Compiler,
configure adds -OPT:Olimit=0 to BASECFLAGS. This is
because using icc -OPT:Olimit=0 does not produce an
error, but instead an irritating warning for every
source file compiled.

$ icc -OPT:Olimit=0 test1.c; echo $?
icc: Command line warning: ignoring option '-O'; no
argument required
0

$ gcc -OPT:Olimit=0 test1.c; echo $?
cc1: error: invalid option argument `-OPT:Olimit=0'
1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 16:58:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 16:58:33 2005
Subject: [ python-Bugs-1162001 ] configure incorrectly adds -OPT:Olimit=0
	for icc
Message-ID: <E1DA90Y-0004Nc-Ey@sc8-sf-web3.sourceforge.net>

Bugs item #1162001, was opened at 2005-03-12 14:54
Message generated for change (Comment added) made by hoffmanm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure incorrectly adds -OPT:Olimit=0 for icc

Initial Comment:
When using Python 2.4 and the Intel C Compiler,
configure adds -OPT:Olimit=0 to BASECFLAGS. This is
because using icc -OPT:Olimit=0 does not produce an
error, but instead an irritating warning for every
source file compiled.

$ icc -OPT:Olimit=0 test1.c; echo $?
icc: Command line warning: ignoring option '-O'; no
argument required
0

$ gcc -OPT:Olimit=0 test1.c; echo $?
cc1: error: invalid option argument `-OPT:Olimit=0'
1


----------------------------------------------------------------------

>Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-12 15:58

Message:
Logged In: YES 
user_id=987664

Patch submitted:

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 17:39:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 17:39:15 2005
Subject: [ python-Bugs-1143895 ] inspect.getsource() breakage in 2.4
Message-ID: <E1DA9dx-0006S5-HN@sc8-sf-web1.sourceforge.net>

Bugs item #1143895, was opened at 2005-02-18 17:26
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getsource() breakage in 2.4

Initial Comment:
In a real-life case, inspect.getsource() used to
produce the correct result on 2.3 but no longer does on
2.4:

def somefunc(x, y):  # comments
     ...body...

With 2.4 (and 2.5 CVS) the body is completely skipped
because the first line doesn't end with a colon.  In my
opinion that's a critical problem for any code relying
on getsource(), even though such code can be considered
as relying on a large pile of fragile hacks in the
first place...

Attached is a patch for test_inspect.py, showing the
problem (also includes a different, much more
convoluted bug example).  It seems that looking for and
around ':' in the first line isn't such a good idea;
relying more fully on the tokenizer would probably be a
better solution.

Assigned to jlgijsbers, as the author of the changes
that broke this (Dec 12th, 2004).  (No blame intended,
the change was meant to fix a different bug, and it did
so.)

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-03-12 17:39

Message:
Logged In: YES 
user_id=469548

Simons patch has now been checked in on maint24 and HEAD.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2005-03-09 16:40

Message:
Logged In: YES 
user_id=329382

Patch http://www.python.org/sf/1159931 fixes this problem.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-03-09 12:26

Message:
Logged In: YES 
user_id=469548

Well, I'm sorry, but I can't make the time after all. I've
asked the author of the original patch to take a look at
this patch. Note that this code isn't yet in a 2.4 release,
so we could also back this out before 2.4.1.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-02-18 20:11

Message:
Logged In: YES 
user_id=469548

Right now I don't have time to look into this bug deeply,
but I will do so this week. I'll note that the convoluted
example doesn't seem to be working under 2.3, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 19:16:34 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 19:16:39 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DABAA-00017X-Ug@sc8-sf-web1.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 03:56
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-12 13:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 08:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 07:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 06:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 06:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 06:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 05:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 10:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 22:18:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 22:18:23 2005
Subject: [ python-Bugs-1162154 ] inspect.getmembers() breaks sometimes
Message-ID: <E1DAE04-0006Zp-Aj@sc8-sf-web1.sourceforge.net>

Bugs item #1162154, was opened at 2005-03-12 21:18
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=1162154&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Quale (quale)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getmembers() breaks sometimes

Initial Comment:
The inspect library module getmembers() method breaks
sometimes when it makes a getattr() call that fails. A
simple example is a slot that doesn't have a value:

 >>> class X(object): __slots__ = 'foo'
 >>> import inspect
 >>> inspect.getmembers(x())
Traceback (most recent call last):
   File "<pyshell#4>", line 1, in -toplevel-
     inspect.getmembers(X())
   File "C:\PYTHON23\lib\inspect.py", line 171, in
getmembers
     value = getattr(object, key)
AttributeError: foo
 >>>

On the PEAK mailing list Phillip Eby suggested wrapping
the gettattr() call in try/except. This seems to work fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162154&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 23:25:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 23:25:11 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DAF2h-0000EB-R0@sc8-sf-web1.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 23:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 19:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 14:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 13:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 12:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 16:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Sat Mar 12 23:36:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 12 23:36:27 2005
Subject: [ python-Bugs-1160534 ] Autoconf failure on FreeBSD 5.3,
	and AC_INIT set incorrectly
Message-ID: <E1DAFDc-0001rK-Fp@sc8-sf-web4.sourceforge.net>

Bugs item #1160534, was opened at 2005-03-10 11:19
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Brooksby (rptb1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly

Initial Comment:
Begin forwarded message:

Date: 8 March 2005 18:20:48 GMT
To: bug-autoconf@gnu.org
Subject: Autoconf asked me to tell you about this bug

On a clean FreeBSD 5.3 machine, do:

  cd /usr/local/lang/python
  make install

and you will see, amongst other things:

checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h: check for missing prerequisite 
headers?
configure: WARNING: ncurses.h: proceeding with the 
preprocessor's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to bug-autoconf@gnu.org. 
##
configure: WARNING:     ## ------------------------------------ ##
checking for ncurses.h... yes
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes

---

Begin forwarded message:

Date: 9 March 2005 11:47:03 GMT
To: Richard Brooksby <rb@ravenbrook.com>
Cc: bug-autoconf@gnu.org
Subject: Re: Autoconf asked me to tell you about this bug

Hello,

On Tue, Mar 08, 2005 at 06:20:48PM +0000, Richard Brooksby 
wrote:
On a clean FreeBSD 5.3 machine, do:
  cd /usr/local/lang/python

you should report this bug to the bug report address of the 
"python"
project.  Tell them to read the section "Present But Cannot Be 
Compiled"
of the manual to autoconf-2.59.

They have misconfigured the bug report address in AC_INIT, so 
also tell
them to change it to *their* bug report address.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 23:36

Message:
Logged In: YES 
user_id=21627

That information does not help to resolve the problem, and
it is not clear that it is a problem in Python's configure -
it could be a bug in your operating system installation also.

Please attach the config.log.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470
From noreply at sourceforge.net  Sun Mar 13 14:35:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 13 14:35:29 2005
Subject: [ python-Bugs-1162428 ] subprocess.Popen with copious output hangs
Message-ID: <E1DATFe-0000EM-JX@sc8-sf-web2.sourceforge.net>

Bugs item #1162428, was opened at 2005-03-13 14:35
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=1162428&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: neuhauser (neuhauser)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.Popen with copious output hangs

Initial Comment:
the following script works fine with modest amount of
output from the subprocess, but hangs with 23 kB of output:

import subprocess

c = subprocess.Popen (['svnlook', 'diff',
'/home/svn/repos', '-r', '57'],
                      stdin  = subprocess.PIPE,
                      stdout = subprocess.PIPE,
                      stderr = subprocess.STDOUT)
rc = c.wait ()
lines = [line.rstrip () for line in c.stdout.readlines ()]
if rc:
    raise Exception (lines)
print lines

r57 in the above subversion repository produces a diff
of just under 23 kB, and the code hangs in:

^CTraceback (most recent call last):
  File "/home/roman/tmp/scratch15", line 9, in ?
    rc = c.wait ()
  File "/usr/local/lib/python2.4/subprocess.py", line
1018, in wait
    pid, sts = os.waitpid(self.pid, 0)
KeyboardInterrupt

this is with 2.4 built from the ports on
FreeBSD isis.sigpipe.cz 4.10-STABLE FreeBSD 4.10-STABLE
#3: Sat Aug  7 16:06:48 CEST 2004 i386


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162428&group_id=5470
From noreply at sourceforge.net  Sun Mar 13 17:11:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 13 17:11:49 2005
Subject: [ python-Bugs-1162477 ] Parsing failures in parsedate_tz
Message-ID: <E1DAVgx-0001De-2R@sc8-sf-web1.sourceforge.net>

Bugs item #1162477, was opened at 2005-03-13 16:11
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=1162477&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parsing failures in parsedate_tz

Initial Comment:
Some email clients send bad-formed datetimes, not
parsed by parsedate_tz (both rfc822.py and
email._parseaddr.py). 

The format not recognized is "HH.MM.SS".

I don't know if it's worth taking in account but in
doubt I give a small patch for email._parseaddr :

----------------------------------------------------------------
@@ -90,6 +100,14 @@ def parsedate_tz(data):
         tss = '0'
     elif len(tm) == 3:
         [thh, tmm, tss] = tm
+    elif len(tm) == 1:
+        # Small hack to get HH.MM.ss
+        tm = tm[0].split(".")
+        if len(tm) == 2:
+            [thh, tmm] = tm
+            tss = '0'
+        elif len(tm) == 3:
+            [thh, tmm, tss] = tm
     else:
         return None
----------------------------------------------------------------

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162477&group_id=5470
From noreply at sourceforge.net  Sun Mar 13 23:39:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 13 23:39:08 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DAbjk-0003GP-TU@sc8-sf-web3.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 23:39

Message:
Logged In: YES 
user_id=21627

Somebody suggested in the newsgroup to request a log file; I
should have thought of this earlier.

So please reinstall the MSI file, using

msiexec /i python-2.4.1c1.msi /l*v python.log

and attach the resulting python.log to this report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 23:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 19:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 14:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 13:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 12:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 16:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Sun Mar 13 23:53:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 13 23:53:03 2005
Subject: [ python-Feature Requests-1155485 ] file() on a file
Message-ID: <E1DAbxF-0003q5-G0@sc8-sf-web3.sourceforge.net>

Feature Requests item #1155485, was opened at 2005-03-03 00:48
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Felix Lee (felixlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: file() on a file

Initial Comment:
it would be nice if file(f) worked when f is already a
file, either by returning f or by constructing a new
file that refers to the same thing.  that would make it
easy to write functions that can take either a file or
a filename as an argument, like so:
    def p(f): print list(file(f))
which is kind of like using int() as a cast operation.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 23:53

Message:
Logged In: YES 
user_id=21627

It's not at all obvious what this should do. Three
alternatives come to mind:
1. return f
2. return a wrapper object which delegates all calls
3. return a new file object, which is dup(2)'ed from the
original one.

Either of them might be meaningful in some context, and they
are mutually incompatible. In the face of ambiguity, refuse
the temptation to guess, so I'm -1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 00:00:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 00:00:52 2005
Subject: [ python-Feature Requests-1154351 ] add get_current_dir_name() to
	os module
Message-ID: <E1DAc4n-0007GT-8e@sc8-sf-web1.sourceforge.net>

Feature Requests item #1154351, was opened at 2005-03-01 17:26
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: add get_current_dir_name() to os module

Initial Comment:
os.getcwd() does not use the contents of the PWD
environment variable, much as the glibc getcwd() does
not. This means that if a user sets the path using a
symbolic link, it will be dereferenced before being
passed by os.getcwd().

I propose that get_current_dir_name() be added, either
as a call to the glibc get_current_dir_name(), which
uses the PWD environment variable and therefore will
not dereference symbolic links in the path, or as a
fallback to this Pure Python function:

def get_current_dir_name():
    cwd = os.getcwd()
    
    try:
        pwd = os.environ["PWD"]
    except KeyError:
        return cwd

    cwd_stat, pwd_stat = map(os.stat, [cwd, pwd])

    if cwd_stat.st_dev == pwd_stat.st_dev and
cwd_stat.st_ino == pwd_stat.st_ino:
        return pwd
    else:
        return cwd


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 00:00

Message:
Logged In: YES 
user_id=21627

I was going to say "what is the advantage of using the PWD
variable?", but, thinking about it three times, I found that
it gives you what the user typed in the last cd(1),
independent of symbolic links. So even though you wrote what
it does, and how it differs from getcwd, its not at all
obvious that this is a good thing (even though I now agree
it is a good thing)

Would you like to work on a patch? A pure Python
implementation sounds reasonable, if your code is what glibc
does as well. It seems to me that the documentation patch is
really crucial here, or else users will wonder "what the
heck...".

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-01 17:27

Message:
Logged In: YES 
user_id=987664

Hmmm... my indentation seems to have gone by the wayside.
Still you can probably figure out what the code is supposed
to do <wink>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 01:32:35 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 01:32:37 2005
Subject: [ python-Bugs-1162677 ] Unable to Install Python 2.4.1rc1 on
	windows XP SP2
Message-ID: <E1DAdVb-0007De-H1@sc8-sf-web3.sourceforge.net>

Bugs item #1162677, was opened at 2005-03-13 19:32
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=1162677&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sergio Correia (sergiocorreia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to Install  Python 2.4.1rc1 on windows XP SP2

Initial Comment:
First of all, YES i had everything i needed to install,
and yes i read the info on the site.

When i tried to install python-2.4.1c1.msi (or even
ActivePython-2.4.0-244-win32-ix86.msi), install "ended
prematurely because of an error".

I tried everything but, after a while i found a way to
avoid the bug.

I was installing from "F:\Docs\Varios\Sandbox".. i
moved the msi file to C:\ and then the install (both,
python and activepython) worked out perfectly.

Folders were not shared, restricted, compressed or on a
network (it was a normal local hard disk).

Any ideas on why that happened?

Thanks


PS: Sorry about the sp. mistakes. I am not very fluent
on technical english.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 09:37:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 09:37:56 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DAl5E-00075T-7F@sc8-sf-web4.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 08:56
Message generated for change (Comment added) made by m_webber_sydney
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:37

Message:
Logged In: YES 
user_id=1237039

Uninstalled, rebooted and reinstalled using

c:\windows\system\msiexec /i python-2.4.1c1.msi /l*v python.log

The log file (1.1MB) is available, probably too big to
cut/paste into here. I can email it to you if you like.
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 22:39

Message:
Logged In: YES 
user_id=21627

Somebody suggested in the newsgroup to request a log file; I
should have thought of this earlier.

So please reinstall the MSI file, using

msiexec /i python-2.4.1c1.msi /l*v python.log

and attach the resulting python.log to this report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 22:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 18:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 13:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 10:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 15:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 09:50:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 09:50:06 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DAlH0-0005Hm-QN@sc8-sf-web2.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 08:56
Message generated for change (Comment added) made by m_webber_sydney
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:50

Message:
Logged In: YES 
user_id=1237039

I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.

Let me know if you still want the full log.

<snip>
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,,,,,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python.File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: , Value:
Python.File
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: Content Type,
Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyw,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.NoConFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: , Value:
Python.NoConFile
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: Content
Type, Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyc,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyc, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyo,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyo, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\open\command,
Name: , Value: "C:\Python24\pythonw.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\pyc.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\DefaultIcon,
Name: , Value: C:\Python24\pyc.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File, Name: ,
Value: Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python
File (no console),)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile, Name:
, Value: Python File (no console)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Compiled
Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile,
Name: , Value: Compiled Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=C:\Python24\,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath,
Name: , Value: C:\Python24MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath\InstallGroup,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python 2.4,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath\InstallGroup,
Name: , Value: Python 2.4
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\PythonPath,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\PythonPath,
Name: , Value:
C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Help\Main
Python Documentation,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Doc\Python24.chm,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Help\Main
Python Documentation, Name: , Value:
C:\Python24\Doc\Python24.chm
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Modules,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegCreateKey()
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Modules,
Name: , Value: 
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Python.exe,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe, Name: , Value: C:\Python24\Python.exe
MSI (c) (63:E3): Executing op:
ActionStart(Name=RegisterProduct,Description=Registering
product,Template=)
Action 08:30:42: RegisterProduct. Registering product
MSI (c) (63:E3): Executing op:
ChangeMedia(,MediaPrompt=Please insert the disk:
,MediaCabinet=python,BytesPerTick=0,CopierType=2,ModuleFileName=C:\WINDOWS\TEMP\147044.msi,,,,,IsFirstPhysicalMedia=1)
MSI (c) (63:E3): Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\TEMP\147044.msi,ProductCode={BE027411-8E6B-4440-A29B-B07DF0690230},CabinetStreams=python,,)
MSI (c) (63:E3): Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{BE027411-8E6B-4440-A29B-B07DF0690230}
3: 2 
MSI (c) (63:E3): Executing op:
ProductRegister(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F},VersionString=2.4.1121,,,,InstallSource=C:\Temp\,Publisher=Martin
v. L?wis,,,,,,,,,,,,EstimatedSize=147397)
RegisterProduct: {BE027411-8E6B-4440-A29B-B07DF0690230}
MSI (c) (63:E3): Executing op: ProductCPDisplayInfoRegister()
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing
Product Features,Template=Feature: )
Action 08:30:43: PublishFeatures. Publishing Product Features
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=DefaultFeature,,Absent=2,Component=j??OUe4X`@i$uC&6A2qKuw,UtgLSt9m.od.692RZ14m~@6pq]8rhPoS&X)D7,bSm,eXa{8$(h.$owxyck=FB1Y)f$9U{ur.`[,ZJ^vr!dfOU`?Ze`ysEk=JLr[E3WgU-x?t?D)z]I=*_dA7ec=)+g=.76?]FKIu1bHFqL5
t([A(1Km9_s+_'MX_[35rw5@g7u+ac`x.,%1%br~*0!9vfmt%=Y!B^1u`AX_!9d=QApJYFnOvfrlI!(GokO?JveVYQYi8f2h%NxT.ig?]b-vBu+r,'ILhl6E^-OA_^v?e$_5IhpTh,w`g.N?qf)G`5^4s@8ASKoHt8MAM`oqO+Ln^S}fQKl6}?d=Tih{Ky=Zf7'JU80OwSF?TJ(O4,B_~91aJSG40wt@5N6cU5hBP94V7`LyWD79f{p{rqL'wg%
-PF16tLs=5)f}`W9QR(r{Gc20~$^@,_d]6k9Gn?e(^7ur&kL9a'1v8~0UWrbAoRjqcwy9wcVYhIk_cjsxfZz1_]MA'bedCP7nB+)
PublishFeatures: Feature: DefaultFeature
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Extensions,Parent=DefaultFeature,Absent=2,Component=&9(xBhb)k@mF)9P]=(i!)
PublishFeatures: Feature: Extensions
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=TclTk,Parent=DefaultFeature,Absent=2,Component=,bSm,eXa{8$(h.$owxycJ=q7zM[@j9hagbp9Xn{co}9nlGPd??^awQ@CGf&0-.'yhr,K&=_3ltzeM.Qc7h^.8-d3T9)EPfCo,d-cyu_m6l_Gp8iMuR,lW[RaQ0A+uDN@U@{L}6cbw?f]i8b7_eX9o@Iy1S
X(&PF?sQlcW}I[(=ZW{-%ivt=M9q7C*M1R.=^Y)J6v,TcMap(-Gk+@a?KT*p2xdCh7XAW'KA95m89]E~`3eN^^V'z(N7]CZA^_7iztK`7eJ^xBgfwjB@Kak6MPA?DO0+@DO3n_AA*K3`@ZtQe?JI6uO%l2W@HN9(W}M~%Cv*,VbO.G[A$XLioN){*Yf.dR$)o(-A+-DXZ!lt&oGrAwx)$J(?6NoDW`@(cYdtWtQ%}-k9Xp1X(yzF}LhTMu7w[79
?OXFqcAk4XyMFpxsxPXJ9m0`},7bv575{8hzkK1!=dJ}y@IG9}`$P8eiaoR`A-VfxP}t9D6)
PublishFeatures: Feature: TclTk
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Documentation,Parent=DefaultFeature,Absent=2,Component=$iX{^*~A'@=`^v0gCm5X)
PublishFeatures: Feature: Documentation
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Tools,Parent=DefaultFeature,Absent=2,Component=GJ+9CR,Tg?JmdBV'[kOW}SK*mRvEv?G8?t0.GQYLZ]11hQx9R?w+A+ac(}(ag~YSM,m2}8,3oy-cjePH&LNCwsJs=A)aA*4Us@6vupTcf8q@f?{n?.&u+hH9)
PublishFeatures: Feature: Tools
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Testsuite,Parent=DefaultFeature,Absent=2,Component=i_BtQR~?6AGCn$H2OkjM8b9z7R7n&95PE+0LABr`iKX^Iz4rs8^Z,]haLA$!9Lg3..?M,9fQ8{GaTQ^.kJFgv&A1D?xHAqGH%u8BS1VasQ)be@`Az3s,j_3[)
PublishFeatures: Feature: Testsuite
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishProduct,Description=Publishing
product information,)
Action 08:30:43: PublishProduct. Publishing product information
MSI (c) (63:E3): Executing op:
IconCreate(Icon=python_icon.exe,Data=BinaryData)
1: python_icon.exe 
MSI (c) (63:E3): Executing op:
ProductPublish(PackageKey={1D61CFC0-C34A-4E8E-804C-CE8F6A7CE163})
1: {BE027411-8E6B-4440-A29B-B07DF0690230} 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Executing op:
UpgradeCodePublish(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F})
MSI (c) (63:E3): Executing op:
SourceListPublish(,,,,NumberOfDisks=1)
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003\SourceList
3: 2 
MSI (c) (63:E3): Executing op: ProductPublishClient(,,)
MSI (c) (63:E3): Executing op:
SourceListRegisterLastUsed(SourceProduct={BE027411-8E6B-4440-A29B-B07DF0690230},LastUsedSource=C:\Temp\)
MSI (c) (63:E3): Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (63:E3): Specifed source is already in a list.
MSI (c) (63:E3): User policy value 'SearchOrder' is 'nmu'
MSI (c) (63:E3): Machine policy value 'DisableBrowse' is 0
MSI (c) (63:E3): Machine policy value 'AllowLockdownBrowse' is 0
MSI (c) (63:E3): Adding new sources is allowed.
MSI (c) (63:E3): Set LastUsedSource to: C:\Temp\.
MSI (c) (63:E3): Set LastUsedType to: n.
MSI (c) (63:E3): Set LastUsedIndex to: 1.
MSI (c) (63:E3): Executing op:
End(Checksum=0,ProgressTotal=28708301)
MSI (c) (63:E3): FEATURECACHE: Entering Invalidate
MSI (c) (63:E3): User policy value 'DisableRollback' is 0
MSI (c) (63:E3): Machine policy value 'DisableRollback' is 0
Action 08:30:43: RollbackCleanup. Removing backup files
MSI (c) (63:E3): Unlocking Server
Action ended 08:30:43: InstallFinalize. Return value 1.
MSI (c) (63:E3): Skipping action: CompilePyc (condition is
false)
MSI (c) (63:E3): Skipping action: CompilePyo (condition is
false)
Action ended 08:30:43: INSTALL. Return value 1.
MSI (c) (63:E3): Decrementing counter to disable shutdown.
If counter >= 0, shutdown will be denied.  Counter after
decrement: -1
Action ended 08:30:43: ExecuteAction. Return value 1.
MSI (c) (63:E3): Doing action: ExitDialog
Action start 08:30:43: ExitDialog.
Action 08:30:43: ExitDialog. Dialog created
Action ended 08:30:45: ExitDialog. Return value 1.
Action ended 08:30:45: INSTALL. Return value 1.

</snip>

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:37

Message:
Logged In: YES 
user_id=1237039

Uninstalled, rebooted and reinstalled using

c:\windows\system\msiexec /i python-2.4.1c1.msi /l*v python.log

The log file (1.1MB) is available, probably too big to
cut/paste into here. I can email it to you if you like.
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 22:39

Message:
Logged In: YES 
user_id=21627

Somebody suggested in the newsgroup to request a log file; I
should have thought of this earlier.

So please reinstall the MSI file, using

msiexec /i python-2.4.1c1.msi /l*v python.log

and attach the resulting python.log to this report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 22:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 18:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 13:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 10:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 15:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 10:03:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 10:03:51 2005
Subject: [ python-Feature Requests-1154351 ] add get_current_dir_name() to
	os module
Message-ID: <E1DAlUK-0005kO-8B@sc8-sf-web2.sourceforge.net>

Feature Requests item #1154351, was opened at 2005-03-01 16:26
Message generated for change (Comment added) made by hoffmanm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: add get_current_dir_name() to os module

Initial Comment:
os.getcwd() does not use the contents of the PWD
environment variable, much as the glibc getcwd() does
not. This means that if a user sets the path using a
symbolic link, it will be dereferenced before being
passed by os.getcwd().

I propose that get_current_dir_name() be added, either
as a call to the glibc get_current_dir_name(), which
uses the PWD environment variable and therefore will
not dereference symbolic links in the path, or as a
fallback to this Pure Python function:

def get_current_dir_name():
    cwd = os.getcwd()
    
    try:
        pwd = os.environ["PWD"]
    except KeyError:
        return cwd

    cwd_stat, pwd_stat = map(os.stat, [cwd, pwd])

    if cwd_stat.st_dev == pwd_stat.st_dev and
cwd_stat.st_ino == pwd_stat.st_ino:
        return pwd
    else:
        return cwd


----------------------------------------------------------------------

>Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-14 09:03

Message:
Logged In: YES 
user_id=987664

Thanks for your comments. I agree that a better description
of the difference here is necessary.

I just checked the glibc source and this is almost exactly
what it does. It actually does an os.stat on "." and only
calls __getcwd() if necessary. It's in
glibc-2.3.4/io/getdirname.c if you're curious.

I'll make that change and add the patch to my list of things
to do...

Since st_dev and st_ino don't work outside Posix, should I
just return os.getcwd() on other platforms?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 23:00

Message:
Logged In: YES 
user_id=21627

I was going to say "what is the advantage of using the PWD
variable?", but, thinking about it three times, I found that
it gives you what the user typed in the last cd(1),
independent of symbolic links. So even though you wrote what
it does, and how it differs from getcwd, its not at all
obvious that this is a good thing (even though I now agree
it is a good thing)

Would you like to work on a patch? A pure Python
implementation sounds reasonable, if your code is what glibc
does as well. It seems to me that the documentation patch is
really crucial here, or else users will wonder "what the
heck...".

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-01 16:27

Message:
Logged In: YES 
user_id=987664

Hmmm... my indentation seems to have gone by the wayside.
Still you can probably figure out what the code is supposed
to do <wink>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 11:41:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 11:41:19 2005
Subject: [ python-Bugs-1160534 ] Autoconf failure on FreeBSD 5.3,
	and AC_INIT set incorrectly
Message-ID: <E1DAn0e-0006Q4-My@sc8-sf-web1.sourceforge.net>

Bugs item #1160534, was opened at 2005-03-10 10:19
Message generated for change (Comment added) made by rptb1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Brooksby (rptb1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly

Initial Comment:
Begin forwarded message:

Date: 8 March 2005 18:20:48 GMT
To: bug-autoconf@gnu.org
Subject: Autoconf asked me to tell you about this bug

On a clean FreeBSD 5.3 machine, do:

  cd /usr/local/lang/python
  make install

and you will see, amongst other things:

checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h: check for missing prerequisite 
headers?
configure: WARNING: ncurses.h: proceeding with the 
preprocessor's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to bug-autoconf@gnu.org. 
##
configure: WARNING:     ## ------------------------------------ ##
checking for ncurses.h... yes
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes

---

Begin forwarded message:

Date: 9 March 2005 11:47:03 GMT
To: Richard Brooksby <rb@ravenbrook.com>
Cc: bug-autoconf@gnu.org
Subject: Re: Autoconf asked me to tell you about this bug

Hello,

On Tue, Mar 08, 2005 at 06:20:48PM +0000, Richard Brooksby 
wrote:
On a clean FreeBSD 5.3 machine, do:
  cd /usr/local/lang/python

you should report this bug to the bug report address of the 
"python"
project.  Tell them to read the section "Present But Cannot Be 
Compiled"
of the manual to autoconf-2.59.

They have misconfigured the bug report address in AC_INIT, so 
also tell
them to change it to *their* bug report address.



----------------------------------------------------------------------

>Comment By: Richard Brooksby (rptb1)
Date: 2005-03-14 10:41

Message:
Logged In: YES 
user_id=927536

Sorry if the text isn't helpful -- I'm just following instructions.  Please find 
config.log attached.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 22:36

Message:
Logged In: YES 
user_id=21627

That information does not help to resolve the problem, and
it is not clear that it is a problem in Python's configure -
it could be a bug in your operating system installation also.

Please attach the config.log.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 12:02:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 12:02:36 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1DAnLD-0007T7-HG@sc8-sf-web1.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Walter D?rwald (doerwalter)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2005-03-14 12:02

Message:
Logged In: YES 
user_id=60903

added doc string

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-08 15:40

Message:
Logged In: YES 
user_id=89016

OK, I'll check in the patch at the beginning of next week
(I'm currently away from CVS).

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-08 15:00

Message:
Logged In: YES 
user_id=38388

Walter: the patch looks good. Please also add a doc-string
mentioning the resetting of the codec in case .seek() is used.

Whether .seek() causes a mess or not is not within the
responsibility of the codec - it's an application space
decision to make, otherwise we would have to introduce the
notion of seeking code points (rather than bytes) which I'd
rather not like to do since this can break existing
applications in many ways.


----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2005-03-08 14:20

Message:
Logged In: YES 
user_id=10327

Ahem -- seek(0,*whatever*) should still be allowed, whatever
else you do, please.

Reading UTF-16 from an odd position in a file isn't always
an error -- sometimes text is embedded in weird on-disk data
structures. As long as tell() returns something you can
seek() back to, nobody's got a right to complain -- file
position arithmetic in general is nonportable.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-04 12:44

Message:
Logged In: YES 
user_id=89016

How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56

Message:
Logged In: YES 
user_id=38388

This is obviously related to the buffer logic that Walter added
to support .readline().

In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 12:20:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 12:20:09 2005
Subject: [ python-Bugs-1162912 ] typesseq-mutable lacks note on combined
	key/cmp usage
Message-ID: <E1DAncE-0008C7-Qr@sc8-sf-web1.sourceforge.net>

Bugs item #1162912, was opened at 2005-03-14 12: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=1162912&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: typesseq-mutable lacks note on combined key/cmp usage

Initial Comment:
The documentation about list.sort() and sorted() does
not state how the keyword arguments cmp and key
interact. Aparently, if key is supplied, cmp works on
the result of the key function and no longer on the
item itself. This should be documented.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 12:25:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 12:25:09 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1DAnh4-0003l7-6O@sc8-sf-web2.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 21:55
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2005-03-14 11:25

Message:
Logged In: YES 
user_id=4771

I tried to convince myself that this check always accepts the 
default mro, but there are more implicit assumptions around 
than I can handle in a quick review...

Instead, I modified the patch so that a debug build of Python 
always does the check in mro_internal().  This results in a 
shallow problem: the basestring type has tp_basicsize==0, 
which makes the computation of its solid_base trigger an 
assertion in extra_ivars().  If I hack around this problem, then 
I cannot quickly find an example of built-in mro that triggers a 
TypeError, but it doesn't mean there isn't one...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-06 18:47

Message:
Logged In: YES 
user_id=6656

I think the attached fixes all this.

What it does: check the return value of PySequence_Tuple (duh).  Check 
that the returned sequence contains only types or old-style classes.  
Checks that the solid_base of each type in the returned sequence is a 
supertype of the solid_base of type being built.  Adds a few tests.

The error messages are a bit inscrutable.  I find it hard to care.

Assigning to Armin for the first look.  Might want to get Guido to look at it 
too.

When Armin and I talked about this on IRC we found a few oddities in the 
general area, but I don't know if it's worth opening a new bug report for 
them...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-03 09:50

Message:
Logged In: YES 
user_id=6656

Certainly some more checking of what the user-defined MRO contains 
would be good -- check the attached, which dumps core at class definition 
time...

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-03 09:34

Message:
Logged In: YES 
user_id=4771

The PyXxx_Check() macros are #defined with
PyObject_TypeCheck().  Should we change all these #defines to
use a new PyObject_LayoutCheck() or something, and document
to C extension writers that they should also switch to the
new function?  More generally, should we review *all* usages
of PyObject_TypeCheck() and decide if they really meant that
or PyObject_LayoutCheck()?  Do we care about types that are
solid subclasses of 'int' but don't have it in their MRO? 
Should we just forget the whole idea and sanity-check the
user-defined mro, which after all would just add another
strange undocumented condition to typeobject.c? :-)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-02 20:11

Message:
Logged In: YES 
user_id=6656

Hmm, yeah, that works.  It wasn't totally clear to me that the user couldn't 
maliciously influence tp_base, but I don't think they can...

A helper function is presumably in order, unless PyType_IsSubtype should 
be changed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-02 17:03

Message:
Logged In: YES 
user_id=4771

To solve the problem, as hinted in the title of this tracker, I 
think that PyXxx_Check() should simply not trust any mro.  
What PyInt_Check() really means at the C level is to check if 
an object memory layout is compatible with PyIntObject.  This 
is easy to figure out by walking the "solid base" chain, 
tp_base.

As a side note, PyPy gives the same error as Python 2.2.  
However, both in PyPy and in Python 2.2, you can still build 
an instance of the strange class X as follows:

>>> x = object.__new__(X)

Still, all the methods of x are resolved via the dict type.  In 
PyPy we get a clean TypeError because the methods thus 
found don't apply to non-dict objects.  In Python 2.2 you can 
crash the interpreter just as in more recent Python releases, 
e.g. with x[5]=6.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-01 20:18

Message:
Logged In: YES 
user_id=6656

I wonder if Guido owes Armin a beer (read typeobject.c around line 5230).  
Well, not really, but it's that code that is making the difference.

However, reversing the order of dict and object is sufficient to make 2.2 
crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting 
code chopped out which gives the error jelper observes on the original).

I wonder what to do about this.  Removing the ability to customize the mro 
from user code is one obvious approach -- I don't know how much code 
uses this feature though.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 12:41:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 12:42:01 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1DAnxO-0005h0-7F@sc8-sf-web3.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 21:55
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-14 11:41

Message:
Logged In: YES 
user_id=6656

Well, emprically that can't happen because the patch passes test_descr, 
and far sillier things happen in that file than in real life.

More theoretically... I'll think about it :)

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-14 11:25

Message:
Logged In: YES 
user_id=4771

I tried to convince myself that this check always accepts the 
default mro, but there are more implicit assumptions around 
than I can handle in a quick review...

Instead, I modified the patch so that a debug build of Python 
always does the check in mro_internal().  This results in a 
shallow problem: the basestring type has tp_basicsize==0, 
which makes the computation of its solid_base trigger an 
assertion in extra_ivars().  If I hack around this problem, then 
I cannot quickly find an example of built-in mro that triggers a 
TypeError, but it doesn't mean there isn't one...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-06 18:47

Message:
Logged In: YES 
user_id=6656

I think the attached fixes all this.

What it does: check the return value of PySequence_Tuple (duh).  Check 
that the returned sequence contains only types or old-style classes.  
Checks that the solid_base of each type in the returned sequence is a 
supertype of the solid_base of type being built.  Adds a few tests.

The error messages are a bit inscrutable.  I find it hard to care.

Assigning to Armin for the first look.  Might want to get Guido to look at it 
too.

When Armin and I talked about this on IRC we found a few oddities in the 
general area, but I don't know if it's worth opening a new bug report for 
them...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-03 09:50

Message:
Logged In: YES 
user_id=6656

Certainly some more checking of what the user-defined MRO contains 
would be good -- check the attached, which dumps core at class definition 
time...

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-03 09:34

Message:
Logged In: YES 
user_id=4771

The PyXxx_Check() macros are #defined with
PyObject_TypeCheck().  Should we change all these #defines to
use a new PyObject_LayoutCheck() or something, and document
to C extension writers that they should also switch to the
new function?  More generally, should we review *all* usages
of PyObject_TypeCheck() and decide if they really meant that
or PyObject_LayoutCheck()?  Do we care about types that are
solid subclasses of 'int' but don't have it in their MRO? 
Should we just forget the whole idea and sanity-check the
user-defined mro, which after all would just add another
strange undocumented condition to typeobject.c? :-)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-02 20:11

Message:
Logged In: YES 
user_id=6656

Hmm, yeah, that works.  It wasn't totally clear to me that the user couldn't 
maliciously influence tp_base, but I don't think they can...

A helper function is presumably in order, unless PyType_IsSubtype should 
be changed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-02 17:03

Message:
Logged In: YES 
user_id=4771

To solve the problem, as hinted in the title of this tracker, I 
think that PyXxx_Check() should simply not trust any mro.  
What PyInt_Check() really means at the C level is to check if 
an object memory layout is compatible with PyIntObject.  This 
is easy to figure out by walking the "solid base" chain, 
tp_base.

As a side note, PyPy gives the same error as Python 2.2.  
However, both in PyPy and in Python 2.2, you can still build 
an instance of the strange class X as follows:

>>> x = object.__new__(X)

Still, all the methods of x are resolved via the dict type.  In 
PyPy we get a clean TypeError because the methods thus 
found don't apply to non-dict objects.  In Python 2.2 you can 
crash the interpreter just as in more recent Python releases, 
e.g. with x[5]=6.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-01 20:18

Message:
Logged In: YES 
user_id=6656

I wonder if Guido owes Armin a beer (read typeobject.c around line 5230).  
Well, not really, but it's that code that is making the difference.

However, reversing the order of dict and object is sufficient to make 2.2 
crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting 
code chopped out which gives the error jelper observes on the original).

I wonder what to do about this.  Removing the ability to customize the mro 
from user code is one obvious approach -- I don't know how much code 
uses this feature though.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 15:41:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 15:41:42 2005
Subject: [ python-Bugs-1158005 ] unixccompiler.py should deal with env in
	linker
Message-ID: <E1DAqlE-0006Qg-Bk@sc8-sf-web3.sourceforge.net>

Bugs item #1158005, was opened at 2005-03-07 01:42
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470

Category: Distutils
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Edward Moy (edwardmoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: unixccompiler.py should deal with env in linker

Initial Comment:
When the linker command begins with env, plus some environment 
settings, and when the target is c++, the modified linker command 
should place the c++ command in the proper place, which is not the 
first element of the linker array.

The following seems to be fix the problem:

--- unixccompiler.py.orig       2004-08-29 09:45:13.000000000 -0700
+++ unixccompiler.py    2005-03-06 16:36:05.000000000 -0800
@@ -172,7 +172,12 @@
                 else:
                     linker = self.linker_so[:]
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
+                    i = 0
+                    if os.path.basename(linker[0]) == "env":
+                        i = 1
+                        while '=' in linker[i]:
+                            i = i + 1
+                    linker[i] = self.compiler_cxx[0]
                 self.spawn(linker + ld_args)
             except DistutilsExecError, msg:
                 raise LinkError, msg


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2005-03-14 15:41

Message:
Logged In: YES 
user_id=45365

Indeed, 2.3.5 (and 2.4.1) were patched wrt. the 
MACOSX_DEPLOYMENT_TARGET environment specifically to address 
this problem.

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-10 08:34

Message:
Logged In: YES 
user_id=1233904

OK, looks like my problem was with 2.3.4, so I made that patch.  Now that 
2.3.5 is out, I didn't notice that this patch doesn't seem to be necessary 
anymore.  Sorry for wasting your time.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-10 00:58

Message:
Logged In: YES 
user_id=21627

Can you find out where it does pick it up *from*, please?
Search the distutils and config directories of Python, and
the wxWindows directories for clues; also print your env.

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-10 00:22

Message:
Logged In: YES 
user_id=1233904

I don't know the internal of python all that well, but I know that python (and 
perl as well) use "env MACOSX_DEPLOYMENT_TARGET=10.3 cc" as the 
link command, because this environment variable is required to enable the 
dynamic lookup symbol resolution feature in the linker (used with two-level 
namespaces).  This is all rather Mac OS X specific, but I'm assuming since 
the python distributed with Mac OS X does this, that wxWidgets is picking 
that up and doing the same thing, as it should.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-10 00:03

Message:
Logged In: YES 
user_id=21627

Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come
from? I cannot find it in the Python build process or
distutils. So if it is in the wxPython setup.py, it sure
must be a bug in that setup.py, no?

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 22:42

Message:
Logged In: YES 
user_id=1233904

I was trying to build wxPython on Mac OS X.  Without the change, it would 
compile all .c files, then when it tried to link, it would execute a command that 
looked like:

g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ...

and fail.  This is because it overwrote "env" with "g++".  It needs to skip the 
env and its arguments, and replace (in this case) the c++.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-08 16:08

Message:
Logged In: YES 
user_id=21627

Can you please give a specific example of what you did, what
you expected to happen, and what happened instead (precise
error messages, etc)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 18:24:46 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 18:24:49 2005
Subject: [ python-Feature Requests-1163139 ] expm1 and log1p
Message-ID: <E1DAtJ8-0006vL-RY@sc8-sf-web4.sourceforge.net>

Feature Requests item #1163139, was opened at 2005-03-14 17:24
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=1163139&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: expm1 and log1p

Initial Comment:
Could we please have expm1 and log1p interfaced in the 
math module (where these exist in libm)?   These are 
essential for any serious mathematical applications.
lgamma would be nice too.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 18:39:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 18:39:52 2005
Subject: [ python-Feature Requests-1163139 ] expm1 and log1p
Message-ID: <E1DAtXj-0007jx-2g@sc8-sf-web4.sourceforge.net>

Feature Requests item #1163139, was opened at 2005-03-14 12:24
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: expm1 and log1p

Initial Comment:
Could we please have expm1 and log1p interfaced in the 
math module (where these exist in libm)?   These are 
essential for any serious mathematical applications.
lgamma would be nice too.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-14 12:39

Message:
Logged In: YES 
user_id=31435

Hard one, since none of those functions are required by the 
C89 standard, Python doesn't require more than C89, and the 
math module overwhelmingly consists of thin wrappers 
around the platform C's implementations.  When C99 is 
universally available, then it will be easy.  Before then, 
someone would have to volunteer non-trivial work (for 
example, Microsoft's C runtime doesn't supply any of these -- 
it's a x-platform mess).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 18:59:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 18:59:55 2005
Subject: [ python-Feature Requests-1163139 ] expm1 and log1p
Message-ID: <E1DAtr6-0000Pg-SS@sc8-sf-web3.sourceforge.net>

Feature Requests item #1163139, was opened at 2005-03-14 17:24
Message generated for change (Comment added) made by kbriggs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: expm1 and log1p

Initial Comment:
Could we please have expm1 and log1p interfaced in the 
math module (where these exist in libm)?   These are 
essential for any serious mathematical applications.
lgamma would be nice too.


----------------------------------------------------------------------

>Comment By: Keith Briggs (kbriggs)
Date: 2005-03-14 17:59

Message:
Logged In: YES 
user_id=888261

Is there an objection in principle to including something in the 
math module only if it is found in the system's libm?

If so, a solution would be to use a C implementation of expm1 
when it is not already supplied, for example from fdlibm:
http://www.netlib.org/fdlibm/

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-14 17:39

Message:
Logged In: YES 
user_id=31435

Hard one, since none of those functions are required by the 
C89 standard, Python doesn't require more than C89, and the 
math module overwhelmingly consists of thin wrappers 
around the platform C's implementations.  When C99 is 
universally available, then it will be easy.  Before then, 
someone would have to volunteer non-trivial work (for 
example, Microsoft's C runtime doesn't supply any of these -- 
it's a x-platform mess).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 19:20:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 19:20:24 2005
Subject: [ python-Feature Requests-1163139 ] expm1 and log1p
Message-ID: <E1DAuAu-0001Nf-HM@sc8-sf-web3.sourceforge.net>

Feature Requests item #1163139, was opened at 2005-03-14 12:24
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: expm1 and log1p

Initial Comment:
Could we please have expm1 and log1p interfaced in the 
math module (where these exist in libm)?   These are 
essential for any serious mathematical applications.
lgamma would be nice too.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-14 13:20

Message:
Logged In: YES 
user_id=31435

Python code intends to be portable, and the math module 
hasn't yet included any platform-specific functions.

I used to write math libraries for a living, so I know about 
netlib <wink>.  If that's the intended approach to portability , 
it still needs someone to volunteer to do all the non-trivial 
coding, testing, doc, license-hassling, and x-platform config 
work.  Won't be me because I can't make time for it.

Note that you could easily write an extension module 
exposing these functions on _your_ platform (assuming your 
platform C supplies them).

----------------------------------------------------------------------

Comment By: Keith Briggs (kbriggs)
Date: 2005-03-14 12:59

Message:
Logged In: YES 
user_id=888261

Is there an objection in principle to including something in the 
math module only if it is found in the system's libm?

If so, a solution would be to use a C implementation of expm1 
when it is not already supplied, for example from fdlibm:
http://www.netlib.org/fdlibm/

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-14 12:39

Message:
Logged In: YES 
user_id=31435

Hard one, since none of those functions are required by the 
C89 standard, Python doesn't require more than C89, and the 
math module overwhelmingly consists of thin wrappers 
around the platform C's implementations.  When C99 is 
universally available, then it will be easy.  Before then, 
someone would have to volunteer non-trivial work (for 
example, Microsoft's C runtime doesn't supply any of these -- 
it's a x-platform mess).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 19:38:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 19:38:43 2005
Subject: [ python-Bugs-1163178 ] IDNA StreamReader broken
Message-ID: <E1DAuSe-000567-NZ@sc8-sf-web1.sourceforge.net>

Bugs item #1163178, was opened at 2005-03-14 19:38
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=1163178&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Martin v. L?wis (loewis)
Summary: IDNA StreamReader broken

Initial Comment:
It seems that the IDNA StreamReader is broken (this
problem occurs both in Python 2.3.4 and Python 2.4):

>>> import codecs, cStringIO
>>> r =
codecs.getreader("idna")(cStringIO.StringIO("abc"))   
          
>>> r.read(1)
u'a'
>>> r.read(1)
u'b'
>>> r.read(1)
u'c'
>>> r.read(1)
u'.'
>>> r.read(1)
u'.'

I would have expected that read(1) returns u"" after
the third call.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163178&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 20:17:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 20:17:15 2005
Subject: [ python-Feature Requests-1154351 ] add get_current_dir_name() to
	os module
Message-ID: <E1DAv3x-000736-05@sc8-sf-web1.sourceforge.net>

Feature Requests item #1154351, was opened at 2005-03-01 17:26
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: add get_current_dir_name() to os module

Initial Comment:
os.getcwd() does not use the contents of the PWD
environment variable, much as the glibc getcwd() does
not. This means that if a user sets the path using a
symbolic link, it will be dereferenced before being
passed by os.getcwd().

I propose that get_current_dir_name() be added, either
as a call to the glibc get_current_dir_name(), which
uses the PWD environment variable and therefore will
not dereference symbolic links in the path, or as a
fallback to this Pure Python function:

def get_current_dir_name():
    cwd = os.getcwd()
    
    try:
        pwd = os.environ["PWD"]
    except KeyError:
        return cwd

    cwd_stat, pwd_stat = map(os.stat, [cwd, pwd])

    if cwd_stat.st_dev == pwd_stat.st_dev and
cwd_stat.st_ino == pwd_stat.st_ino:
        return pwd
    else:
        return cwd


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 20:17

Message:
Logged In: YES 
user_id=21627

Equalling get_current_dir_name and getcwd for non-POSIX
systems seems like a conservative approach, so I'm for it.
Alternatively, one might think that PWD won't be set on
non-POSIX systems.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-14 10:03

Message:
Logged In: YES 
user_id=987664

Thanks for your comments. I agree that a better description
of the difference here is necessary.

I just checked the glibc source and this is almost exactly
what it does. It actually does an os.stat on "." and only
calls __getcwd() if necessary. It's in
glibc-2.3.4/io/getdirname.c if you're curious.

I'll make that change and add the patch to my list of things
to do...

Since st_dev and st_ino don't work outside Posix, should I
just return os.getcwd() on other platforms?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 00:00

Message:
Logged In: YES 
user_id=21627

I was going to say "what is the advantage of using the PWD
variable?", but, thinking about it three times, I found that
it gives you what the user typed in the last cd(1),
independent of symbolic links. So even though you wrote what
it does, and how it differs from getcwd, its not at all
obvious that this is a good thing (even though I now agree
it is a good thing)

Would you like to work on a patch? A pure Python
implementation sounds reasonable, if your code is what glibc
does as well. It seems to me that the documentation patch is
really crucial here, or else users will wonder "what the
heck...".

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-01 17:27

Message:
Logged In: YES 
user_id=987664

Hmmm... my indentation seems to have gone by the wayside.
Still you can probably figure out what the code is supposed
to do <wink>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 20:22:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 20:22:06 2005
Subject: [ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader
	broken
Message-ID: <E1DAv8e-0007FV-3r@sc8-sf-web1.sourceforge.net>

Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470

Category: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Walter D?rwald (doerwalter)
Summary: [2.4 regression] seeking in codecs.reader broken

Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]

This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.

Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5

import sys
import codecs
from random import random

data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
    #XXX data.seek(0,1)
    #XXX data.read()
    data.seek(0,0)
    dn=""
    for l in data:
        dn += l
        if random() < 0.1: break
    if not df.startswith(dn):
        print "OUCH",t
        print "BAD:", dn[0:100]
        print "GOOD:", df[0:100]
        sys.exit(1)

print "OK",len(df)
sys.exit(0)

----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-14 20:22

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/codecs.py 1.39
Lib/encodings/utf_16.py 1.6
Lib/test/test_codecs.py 1.21
I've also added a reset() method to the UTF-16 reader that
resets the decode method as well as a test in test_codecs.py.

Backported to release24-maint as:
Lib/codecs.py 1.35.2.4
Lib/encodings/utf_16.py 1.5.2.1
Lib/test/test_codecs.py 1.15.2.3

(Here the test is implemented differently, because the 2.4
branch doesn't have a BasicUnicodeTest test case in
test_codecs.py)


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2005-03-14 12:02

Message:
Logged In: YES 
user_id=60903

added doc string

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-08 15:40

Message:
Logged In: YES 
user_id=89016

OK, I'll check in the patch at the beginning of next week
(I'm currently away from CVS).

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-08 15:00

Message:
Logged In: YES 
user_id=38388

Walter: the patch looks good. Please also add a doc-string
mentioning the resetting of the codec in case .seek() is used.

Whether .seek() causes a mess or not is not within the
responsibility of the codec - it's an application space
decision to make, otherwise we would have to introduce the
notion of seeking code points (rather than bytes) which I'd
rather not like to do since this can break existing
applications in many ways.


----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2005-03-08 14:20

Message:
Logged In: YES 
user_id=10327

Ahem -- seek(0,*whatever*) should still be allowed, whatever
else you do, please.

Reading UTF-16 from an odd position in a file isn't always
an error -- sometimes text is embedded in weird on-disk data
structures. As long as tell() returns something you can
seek() back to, nobody's got a right to complain -- file
position arithmetic in general is nonportable.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-04 12:44

Message:
Logged In: YES 
user_id=89016

How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56

Message:
Logged In: YES 
user_id=38388

This is obviously related to the buffer logic that Walter added
to support .readline().

In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 20:45:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 20:45:34 2005
Subject: [ python-Feature Requests-1154351 ] add get_current_dir_name() to
	os module
Message-ID: <E1DAvVL-0003IS-3S@sc8-sf-web2.sourceforge.net>

Feature Requests item #1154351, was opened at 2005-03-01 16:26
Message generated for change (Comment added) made by hoffmanm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: add get_current_dir_name() to os module

Initial Comment:
os.getcwd() does not use the contents of the PWD
environment variable, much as the glibc getcwd() does
not. This means that if a user sets the path using a
symbolic link, it will be dereferenced before being
passed by os.getcwd().

I propose that get_current_dir_name() be added, either
as a call to the glibc get_current_dir_name(), which
uses the PWD environment variable and therefore will
not dereference symbolic links in the path, or as a
fallback to this Pure Python function:

def get_current_dir_name():
    cwd = os.getcwd()
    
    try:
        pwd = os.environ["PWD"]
    except KeyError:
        return cwd

    cwd_stat, pwd_stat = map(os.stat, [cwd, pwd])

    if cwd_stat.st_dev == pwd_stat.st_dev and
cwd_stat.st_ino == pwd_stat.st_ino:
        return pwd
    else:
        return cwd


----------------------------------------------------------------------

>Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-14 19:45

Message:
Logged In: YES 
user_id=987664

It might if they were using a ported UNIX shell. But I think
trusting PWD without checking it is a Bad Thing.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 19:17

Message:
Logged In: YES 
user_id=21627

Equalling get_current_dir_name and getcwd for non-POSIX
systems seems like a conservative approach, so I'm for it.
Alternatively, one might think that PWD won't be set on
non-POSIX systems.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-14 09:03

Message:
Logged In: YES 
user_id=987664

Thanks for your comments. I agree that a better description
of the difference here is necessary.

I just checked the glibc source and this is almost exactly
what it does. It actually does an os.stat on "." and only
calls __getcwd() if necessary. It's in
glibc-2.3.4/io/getdirname.c if you're curious.

I'll make that change and add the patch to my list of things
to do...

Since st_dev and st_ino don't work outside Posix, should I
just return os.getcwd() on other platforms?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 23:00

Message:
Logged In: YES 
user_id=21627

I was going to say "what is the advantage of using the PWD
variable?", but, thinking about it three times, I found that
it gives you what the user typed in the last cd(1),
independent of symbolic links. So even though you wrote what
it does, and how it differs from getcwd, its not at all
obvious that this is a good thing (even though I now agree
it is a good thing)

Would you like to work on a patch? A pure Python
implementation sounds reasonable, if your code is what glibc
does as well. It seems to me that the documentation patch is
really crucial here, or else users will wonder "what the
heck...".

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-01 16:27

Message:
Logged In: YES 
user_id=987664

Hmmm... my indentation seems to have gone by the wayside.
Still you can probably figure out what the code is supposed
to do <wink>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 21:20:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 21:20:18 2005
Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS
	encoding
Message-ID: <E1DAw2l-0001zU-I9@sc8-sf-web1.sourceforge.net>

Bugs item #1163244, was opened at 2005-03-14 21: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=1163244&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim N. van der Leeuw (tnleeuw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax error on large file with MBCS encoding

Initial Comment:
Large files generated by make-py.py from the win32all
extensions cannot be compiled by Python2.4.1rc1 - they
give a syntax error.

This is a regression from 2.3.5

(With Python2.4, the interpreter crashes. That is fixed
now.)

Removing the mbcs encoding line from the top of the
file, compilation succeeds.

File should be attached, as zip-file. Probably requires
win32all extensions to be installed to be compiled /
imported (generated using build 203 of the win32all
extensions).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 21:47:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 21:47:54 2005
Subject: [ python-Feature Requests-1155485 ] file() on a file
Message-ID: <E1DAwTe-0007Mb-Sb@sc8-sf-web4.sourceforge.net>

Feature Requests item #1155485, was opened at 2005-03-02 23:48
Message generated for change (Comment added) made by felixlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Felix Lee (felixlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: file() on a file

Initial Comment:
it would be nice if file(f) worked when f is already a
file, either by returning f or by constructing a new
file that refers to the same thing.  that would make it
easy to write functions that can take either a file or
a filename as an argument, like so:
    def p(f): print list(file(f))
which is kind of like using int() as a cast operation.

----------------------------------------------------------------------

>Comment By: Felix Lee (felixlee)
Date: 2005-03-14 20:47

Message:
Logged In: YES 
user_id=77867

that argument also works against str() and list().  it's not
obvious whether str(s) and list(v) should return itself, a
proxy, or a copy, and they're all useful in different
situations.  I don't think anyone would argue that the
ambiguity means those should be undefined.

I think file(f) is similar.  it has a few more issues
because files are special, but I think picking a reasonable
behavior for file(f) would simplify some programming. 
returning a dup is probably the least surprising in most
situations, because of f.close().

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 22:53

Message:
Logged In: YES 
user_id=21627

It's not at all obvious what this should do. Three
alternatives come to mind:
1. return f
2. return a wrapper object which delegates all calls
3. return a new file object, which is dup(2)'ed from the
original one.

Either of them might be meaningful in some context, and they
are mutually incompatible. In the face of ambiguity, refuse
the temptation to guess, so I'm -1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 21:54:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 21:54:27 2005
Subject: [ python-Bugs-978632 ] configure and gmake fail in openbsd 3.5 i386
Message-ID: <E1DAwZx-0006Tv-V3@sc8-sf-web2.sourceforge.net>

Bugs item #978632, was opened at 2004-06-24 02:16
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978632&group_id=5470

Category: Installation
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: - (panterrap)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure and gmake fail in openbsd 3.5 i386

Initial Comment:

Problem with compiler of python-2.3.4 in
OpenBSD 3.5 i386


# ./configure --prefix=/usr/local/python-2.3.4
--with-cxx=/usr/bin/gcc

4 warnings sections in configure
 
------------
configure: WARNING: ncurses.h: present but cannot be
compiled
configure: WARNING: ncurses.h: check for missing
prerequisite headers?
configure: WARNING: ncurses.h: proceeding with the
preprocessor's result
configure: WARNING:     ##
------------------------------------ ##
configure: WARNING:     ## Report this to
bug-autoconf@gnu.org. ##
configure: WARNING:     ##
------------------------------------ ##
-------------
configure: WARNING: sys/audioio.h: present but cannot
be compiled
configure: WARNING: sys/audioio.h: check for missing
prerequisite headers?
configure: WARNING: sys/audioio.h: proceeding with the
preprocessor's result
configure: WARNING:     ##
------------------------------------ ##
configure: WARNING:     ## Report this to
bug-autoconf@gnu.org. ##
configure: WARNING:     ##
------------------------------------ ##
--------------
configure: WARNING: sys/lock.h: present but cannot be
compiled
configure: WARNING: sys/lock.h: check for missing
prerequisite headers?
configure: WARNING: sys/lock.h: proceeding with the
preprocessor's result
configure: WARNING:     ##
------------------------------------ ##
configure: WARNING:     ## Report this to
bug-autoconf@gnu.org. ##
configure: WARNING:     ##
------------------------------------ ##
--------------
configure: WARNING: sys/select.h: present but cannot be
compiled
configure: WARNING: sys/select.h: check for missing
prerequisite headers?
configure: WARNING: sys/select.h: proceeding with the
preprocessor's result
configure: WARNING:     ##
------------------------------------ ##
configure: WARNING:     ## Report this to
bug-autoconf@gnu.org. ##
configure: WARNING:     ##
------------------------------------ ##
---------------

my compilation in this platform

# gmake
/usr/bin/gcc -pthread -c -fno-strict-aliasing -DNDEBUG
-g -O3 -Wall -Wstrict-prototypes -I. -I./Include 
-DPy_BUILD_CORE -o Modules/ccpython.o ./Modules/ccpython.cc
In file included from /usr/include/sys/select.h:38,
                 from Include/pyport.h:118,
                 from Include/Python.h:48,
                 from ./Modules/ccpython.cc:3:
/usr/include/sys/event.h:53: syntax error before `;'
/usr/include/sys/event.h:55: syntax error before `;'
gmake: *** [Modules/ccpython.o] Error 1

-------------

P.D.: Python-2.2.3 in this platform  ok



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 21:54

Message:
Logged In: YES 
user_id=21627

Closed because of lack of activity.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-06-27 23:03

Message:
Logged In: YES 
user_id=21627

Can you please analyse the problem in more detail, and
suggest a patch?

If not, can you please attach the config.log that you got
when running configure?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978632&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 22:20:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 22:20:54 2005
Subject: [ python-Feature Requests-1155485 ] file() on a file
Message-ID: <E1DAwzb-0001L1-IZ@sc8-sf-web4.sourceforge.net>

Feature Requests item #1155485, was opened at 2005-03-03 00:48
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Felix Lee (felixlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: file() on a file

Initial Comment:
it would be nice if file(f) worked when f is already a
file, either by returning f or by constructing a new
file that refers to the same thing.  that would make it
easy to write functions that can take either a file or
a filename as an argument, like so:
    def p(f): print list(file(f))
which is kind of like using int() as a cast operation.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 22:20

Message:
Logged In: YES 
user_id=21627

The same argument can *not* be made for strings, since
strings are immutable, so it does not matter whether you get
the original thing or a copy. Also, str(x) invokes x's
__str__ conversion. For lists, the argument is also
different: list(x) requires an iterable object and creates a
list out of it. The notion of an iterable object is
well-defined, and if you pass something that is not
iterable, you get a TypeError.

For files, this is entirely different. file() does not take
one argument, but three (and two of them are optional). The
first (mandatory) argument is a "filename". It might be
debatable what precisely a file name is, and indeed you can
pass both byte strings and unicode strings. A file, most
certainly, is *not* a filename, and there is no notion of
"converting to a file" in Python (e.g. by means of
__file__). This just isn't a useful generalization.

----------------------------------------------------------------------

Comment By: Felix Lee (felixlee)
Date: 2005-03-14 21:47

Message:
Logged In: YES 
user_id=77867

that argument also works against str() and list().  it's not
obvious whether str(s) and list(v) should return itself, a
proxy, or a copy, and they're all useful in different
situations.  I don't think anyone would argue that the
ambiguity means those should be undefined.

I think file(f) is similar.  it has a few more issues
because files are special, but I think picking a reasonable
behavior for file(f) would simplify some programming. 
returning a dup is probably the least surprising in most
situations, because of f.close().

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 23:53

Message:
Logged In: YES 
user_id=21627

It's not at all obvious what this should do. Three
alternatives come to mind:
1. return f
2. return a wrapper object which delegates all calls
3. return a new file object, which is dup(2)'ed from the
original one.

Either of them might be meaningful in some context, and they
are mutually incompatible. In the face of ambiguity, refuse
the temptation to guess, so I'm -1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 22:34:46 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 22:34:49 2005
Subject: [ python-Bugs-1160534 ] Autoconf failure on FreeBSD 5.3,
	and AC_INIT set incorrectly
Message-ID: <E1DAxD4-0001w6-Sw@sc8-sf-web4.sourceforge.net>

Bugs item #1160534, was opened at 2005-03-10 11:19
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470

Category: Build
>Group: 3rd Party
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard Brooksby (rptb1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly

Initial Comment:
Begin forwarded message:

Date: 8 March 2005 18:20:48 GMT
To: bug-autoconf@gnu.org
Subject: Autoconf asked me to tell you about this bug

On a clean FreeBSD 5.3 machine, do:

  cd /usr/local/lang/python
  make install

and you will see, amongst other things:

checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h: check for missing prerequisite 
headers?
configure: WARNING: ncurses.h: proceeding with the 
preprocessor's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to bug-autoconf@gnu.org. 
##
configure: WARNING:     ## ------------------------------------ ##
checking for ncurses.h... yes
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes

---

Begin forwarded message:

Date: 9 March 2005 11:47:03 GMT
To: Richard Brooksby <rb@ravenbrook.com>
Cc: bug-autoconf@gnu.org
Subject: Re: Autoconf asked me to tell you about this bug

Hello,

On Tue, Mar 08, 2005 at 06:20:48PM +0000, Richard Brooksby 
wrote:
On a clean FreeBSD 5.3 machine, do:
  cd /usr/local/lang/python

you should report this bug to the bug report address of the 
"python"
project.  Tell them to read the section "Present But Cannot Be 
Compiled"
of the manual to autoconf-2.59.

They have misconfigured the bug report address in AC_INIT, so 
also tell
them to change it to *their* bug report address.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 22:34

Message:
Logged In: YES 
user_id=21627

Thanks for the report! Looking at the file, I see

In file included from configure:4766:
/usr/include/ncurses.h:289: error: conflicting types for
'wchar_t'
/usr/include/stdlib.h:58: error: previous declaration of
'wchar_t' was here

So it looks like your system has conflicting definitions of
wchar_t, one in ncurses.h, and one in stdlib.h. I thought I
had seen this before, but I cannot find a resolution. You
might want to report this to the FreeBSD people.

As for the autoconf manual hint: they propose to perform
further includes to make the header compilable. However,
since the header is truly broken, this is no solution.

As for the hint to change the bug reporting address: I have
now done this, and committed this change as

configure.in 1.475.2.7
configure 1.462.2.7
configure.in 1.483
configure 1.470

Closing the report as fixed, 3rd party.

----------------------------------------------------------------------

Comment By: Richard Brooksby (rptb1)
Date: 2005-03-14 11:41

Message:
Logged In: YES 
user_id=927536

Sorry if the text isn't helpful -- I'm just following instructions.  Please find 
config.log attached.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 23:36

Message:
Logged In: YES 
user_id=21627

That information does not help to resolve the problem, and
it is not clear that it is a problem in Python's configure -
it could be a bug in your operating system installation also.

Please attach the config.log.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 22:36:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 22:36:52 2005
Subject: [ python-Bugs-1162677 ] Unable to Install Python 2.4.1rc1 on
	windows XP SP2
Message-ID: <E1DAxF3-000216-Gp@sc8-sf-web4.sourceforge.net>

Bugs item #1162677, was opened at 2005-03-14 01:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sergio Correia (sergiocorreia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to Install  Python 2.4.1rc1 on windows XP SP2

Initial Comment:
First of all, YES i had everything i needed to install,
and yes i read the info on the site.

When i tried to install python-2.4.1c1.msi (or even
ActivePython-2.4.0-244-win32-ix86.msi), install "ended
prematurely because of an error".

I tried everything but, after a while i found a way to
avoid the bug.

I was installing from "F:\Docs\Varios\Sandbox".. i
moved the msi file to C:\ and then the install (both,
python and activepython) worked out perfectly.

Folders were not shared, restricted, compressed or on a
network (it was a normal local hard disk).

Any ideas on why that happened?

Thanks


PS: Sorry about the sp. mistakes. I am not very fluent
on technical english.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 22:36

Message:
Logged In: YES 
user_id=21627

No, but I know how to find out. Please run, in a cmd.exe window,

msiexec /i python-2.4.1c1.msi /l*v python.log

Compress python.log with Winzip, and attach the resulting
file to this report.

As a wild guess: could it be that F: is SUBSTed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 23:17:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 23:17:11 2005
Subject: [ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron)
Message-ID: <E1DAxs4-0003WB-9f@sc8-sf-web4.sourceforge.net>

Bugs item #1066546, was opened at 2004-11-15 10:34
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pwd fails on 64bit system (Opteron)

Initial Comment:
test test_pwd failed -- Traceback (most recent call last):
  File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py",
line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum


$ cat /proc/version 
Linux version 2.4.21-20.ELsmp
(bhcompile@dolly.build.redhat.com) (gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18
20:34:58 EDT 2004

Processor is AMD Opteron 2.4MHz

----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-14 23:17

Message:
Logged In: YES 
user_id=89016

On a 32bit system adding the line
nobody:x:4294967294:65534:nobody:/:/bin/false
to /etc/passwd pwd.getpwall() gives me an entry:
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
and
pwd.getpwuid(-2)
gives me
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')

Maybe for 64bit systems the SETI macro should use
PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can
you try the following patch?

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-11-17 09:43

Message:
Logged In: YES 
user_id=358087

1. How do I find the largest user id?
2. It's 4294967294
3. Can't attach etc/password since it's a company machine
(IT will kill me :-)
    However there is a similar line for nobody with 65534

The hardware is 4 CPU with 16GB of memory.
OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-11-17 02:58

Message:
Logged In: YES 
user_id=33168

I just tested this on an opteron and it ran ok, so this
problem isn't necessarily opteron/64-bit specific.  What is
the largest user id on the system?  What is the value of
pw_uid that is causing a problem?  Can you attach your
/etc/passwd file?  If so, you may want to change any user info.

I have:
  nobody:x:65534:65534:nobody:/:/bin/false

I tried adding another nobody with a larger uid, but did not
have any problems with the test.  This is on a gentoo system.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-11-15 10:36

Message:
Logged In: YES 
user_id=358087

Ran with -v:
$ ./python Lib/test/test_pwd.py -v
test_errors (__main__.PwdTest) ... ok
test_values (__main__.PwdTest) ... ERROR

======================================================================
ERROR: test_values (__main__.PwdTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_pwd.py", line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum

----------------------------------------------------------------------
Ran 2 tests in 0.480s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_pwd.py", line 92, in ?
    test_main()
  File "Lib/test/test_pwd.py", line 89, in test_main
    test_support.run_unittest(PwdTest)
  File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 290, in run_unitt                                     
       est
    run_suite(suite, testclass)
  File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 275, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_pwd.py", line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 23:37:14 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 23:37:17 2005
Subject: [ python-Bugs-1163325 ] "special" decimals aren't hashable
Message-ID: <E1DAyBW-0004Ff-Sv@sc8-sf-web4.sourceforge.net>

Bugs item #1163325, was opened at 2005-03-14 22:37
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=1163325&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: "special" decimals aren't hashable

Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34) 
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
    i = int(self)
  File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
    return context._raise_error(InvalidContext)
  File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
    raise error, explanation
decimal.InvalidOperation

This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)

Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 23:42:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 23:42:14 2005
Subject: [ python-Bugs-1163325 ] "special" decimals aren't hashable
Message-ID: <E1DAyGJ-0002kb-CS@sc8-sf-web2.sourceforge.net>

Bugs item #1163325, was opened at 2005-03-14 17:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
>Assigned to: Tim Peters (tim_one)
Summary: "special" decimals aren't hashable

Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34) 
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
    i = int(self)
  File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
    return context._raise_error(InvalidContext)
  File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
    raise error, explanation
decimal.InvalidOperation

This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)

Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-14 17:42

Message:
Logged In: YES 
user_id=80475

Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them.  Tim, do you have
another thoughts on the subject?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
From noreply at sourceforge.net  Mon Mar 14 23:52:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 14 23:52:50 2005
Subject: [ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Message-ID: <E1DAyQZ-0004rq-0B@sc8-sf-web4.sourceforge.net>

Bugs item #1105699, was opened at 2005-01-19 19:52
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470

Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Warnings in Python.h with gcc 4.0.0

Initial Comment:
(this happens for every file that includes Python.h)

In file included from ../Include/Python.h:55,
                 from ../Objects/intobject.c:4:
../Include/pyport.h:396: warning: 'struct winsize' declared inside 
parameter list
../Include/pyport.h:397: warning: 'struct winsize' declared inside 
parameter list

The source lines look like this:
extern int openpty(int *, int *, char *, struct termios *, struct 
winsize *);
extern int forkpty(int *, char *, struct termios *, struct winsize *);

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2005-03-14 17:52

Message:
Logged In: YES 
user_id=139309

Turns out that this is a GCC4 bug (not sure which, though).  The OS 
headers are fine.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-04 15:15

Message:
Logged In: YES 
user_id=21627

What operating system is this on? struct winsize should have
been included through <termios.h>. Then, the mentioning of
it in the propotypes is not a declaration, just a reference.

So if you get this warning, it probably indicates a problem
with your system headers.

----------------------------------------------------------------------

Comment By: Richard Kettlewell (rjk1002)
Date: 2005-01-31 10:43

Message:
Logged In: YES 
user_id=217390

C does guarantee that all struct pointers share the same
*representation* (section 6.2.5 of C99).  That's not what
the compiler is complaining about here.
Rather, a struct declared inside a parameter list is
restricted in scope to that parameter list, and so is not
the same structure as one declared outside it, even if the
tag is the same.
The solution is to forward-declare the struct (as an
incomplete type, i.e. just "struct winsize;") before any of
the declarations that use it.  Then the struct tag will mean
the same thing in every scope.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-01-20 18:13

Message:
Logged In: YES 
user_id=31435

The warning almost certainly means that there's no 
declaration of struct winsize in scope when these externs are 
declared.  That's bad, because C doesn't guarantee that all 
pointers are the same size (although they are on all Python 
platforms I'm aware of).

Some quality time with Google suggested that other projects 
wormed around this by #include'ing <termio.h> instead of 
<termios.h>, because the former but not the latter #include's 
<sys/ioctl.h> where the winsize struct was defined.  Beats 
me -- ain't a Windows problem <wink>.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-01-20 17:49

Message:
Logged In: YES 
user_id=139309

Beats me, it's probably just "bad style".

It's a problem because it shows up a lot in the output, so we should at 
least figure out how to disable this warning so that it doesn't become 
annoying.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-01-20 10:18

Message:
Logged In: YES 
user_id=6656

Why is this a problem?  Is it not valid C or something?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 00:39:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 00:39:41 2005
Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super
Message-ID: <E1DAz9v-0004p8-10@sc8-sf-web2.sourceforge.net>

Bugs item #1163367, was opened at 2005-03-14 16:39
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=1163367&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
    def meth(self, arg):
        super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 01:00:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 01:00:09 2005
Subject: [ python-Feature Requests-1155485 ] file() on a file
Message-ID: <E1DAzTf-0005LK-Tu@sc8-sf-web2.sourceforge.net>

Feature Requests item #1155485, was opened at 2005-03-02 18:48
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Felix Lee (felixlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: file() on a file

Initial Comment:
it would be nice if file(f) worked when f is already a
file, either by returning f or by constructing a new
file that refers to the same thing.  that would make it
easy to write functions that can take either a file or
a filename as an argument, like so:
    def p(f): print list(file(f))
which is kind of like using int() as a cast operation.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-14 19:00

Message:
Logged In: YES 
user_id=31435

I'm also -1 on this -- I have no idea what would make sense 
when applying file() to a file object, or to a file-like object.  
Therefore anything it did in response would be surprising to 
me, except for raising an exception.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 16:20

Message:
Logged In: YES 
user_id=21627

The same argument can *not* be made for strings, since
strings are immutable, so it does not matter whether you get
the original thing or a copy. Also, str(x) invokes x's
__str__ conversion. For lists, the argument is also
different: list(x) requires an iterable object and creates a
list out of it. The notion of an iterable object is
well-defined, and if you pass something that is not
iterable, you get a TypeError.

For files, this is entirely different. file() does not take
one argument, but three (and two of them are optional). The
first (mandatory) argument is a "filename". It might be
debatable what precisely a file name is, and indeed you can
pass both byte strings and unicode strings. A file, most
certainly, is *not* a filename, and there is no notion of
"converting to a file" in Python (e.g. by means of
__file__). This just isn't a useful generalization.

----------------------------------------------------------------------

Comment By: Felix Lee (felixlee)
Date: 2005-03-14 15:47

Message:
Logged In: YES 
user_id=77867

that argument also works against str() and list().  it's not
obvious whether str(s) and list(v) should return itself, a
proxy, or a copy, and they're all useful in different
situations.  I don't think anyone would argue that the
ambiguity means those should be undefined.

I think file(f) is similar.  it has a few more issues
because files are special, but I think picking a reasonable
behavior for file(f) would simplify some programming. 
returning a dup is probably the least surprising in most
situations, because of f.close().

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 17:53

Message:
Logged In: YES 
user_id=21627

It's not at all obvious what this should do. Three
alternatives come to mind:
1. return f
2. return a wrapper object which delegates all calls
3. return a new file object, which is dup(2)'ed from the
original one.

Either of them might be meaningful in some context, and they
are mutually incompatible. In the face of ambiguity, refuse
the temptation to guess, so I'm -1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 01:04:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 01:04:39 2005
Subject: [ python-Bugs-1163325 ] "special" decimals aren't hashable
Message-ID: <E1DAzY4-0005ZL-Mj@sc8-sf-web2.sourceforge.net>

Bugs item #1163325, was opened at 2005-03-14 17:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: "special" decimals aren't hashable

Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34) 
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
    i = int(self)
  File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
    return context._raise_error(InvalidContext)
  File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
    raise error, explanation
decimal.InvalidOperation

This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)

Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-14 19:04

Message:
Logged In: YES 
user_id=31435

Well, I'm not really a fan of Python's tying hashability 
to "usable as a dict key", but given that's what Python 
_does_, ya, hashing a NaN doesn't make sense.

marienz, by "special" decimals did you mean only NaNs, or 
do you have other cases in mind too?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-14 17:42

Message:
Logged In: YES 
user_id=80475

Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them.  Tim, do you have
another thoughts on the subject?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 01:39:18 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 01:39:21 2005
Subject: [ python-Bugs-1163401 ] uncaught AttributeError deep in urllib
Message-ID: <E1DB05e-0004vP-F3@sc8-sf-web1.sourceforge.net>

Bugs item #1163401, was opened at 2005-03-14 16:39
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=1163401&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: K Lars Lohn (lohnk)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncaught AttributeError deep in urllib

Initial Comment:
Python 2.4 and Python 2.3.4 running under Suse 9.2

We're getting an AttributeError exception "AttributeError: 'NoneType' object has no attribute 'read'" within a very simple call to urllib.urlopen.

This was discovered while working on Sentry 2, the new mirror integrity checker for the Mozilla project.  We try to touch hundreds of URLs to make sure that the files are present on each of the mirrors.  One particular URL kills the call to urllib.urlopen: http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe
This file probably does not exist on the mirror, however, in other cases of bad URLs, we get much more graceful failures when we try to read from the object returned by urllib.urlopen.

>>> import urllib
>>> urlReader = urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.4/urllib.py", line 180, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__
    addbase.__init__(self, fp)
  File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__
    self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'

The  attached file is a three line scipt that demos the problem.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 03:20:43 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 03:20:47 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DB1fn-0007fc-UY@sc8-sf-web1.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 03:56
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-14 21:20

Message:
Logged In: YES 
user_id=31435

Martin, re "resiliency":  Cool -- that works!  Microsoft has too 
much spare cash <wink>.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 03:50

Message:
Logged In: YES 
user_id=1237039

I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.

Let me know if you still want the full log.

<snip>
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,,,,,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python.File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: , Value:
Python.File
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: Content Type,
Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyw,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.NoConFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: , Value:
Python.NoConFile
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: Content
Type, Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyc,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyc, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyo,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyo, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\open\command,
Name: , Value: "C:\Python24\pythonw.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\pyc.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\DefaultIcon,
Name: , Value: C:\Python24\pyc.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File, Name: ,
Value: Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python
File (no console),)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile, Name:
, Value: Python File (no console)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Compiled
Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile,
Name: , Value: Compiled Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=C:\Python24\,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath,
Name: , Value: C:\Python24MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath\InstallGroup,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python 2.4,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath\InstallGroup,
Name: , Value: Python 2.4
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\PythonPath,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\PythonPath,
Name: , Value:
C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Help\Main
Python Documentation,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Doc\Python24.chm,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Help\Main
Python Documentation, Name: , Value:
C:\Python24\Doc\Python24.chm
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Modules,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegCreateKey()
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Modules,
Name: , Value: 
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Python.exe,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe, Name: , Value: C:\Python24\Python.exe
MSI (c) (63:E3): Executing op:
ActionStart(Name=RegisterProduct,Description=Registering
product,Template=)
Action 08:30:42: RegisterProduct. Registering product
MSI (c) (63:E3): Executing op:
ChangeMedia(,MediaPrompt=Please insert the disk:
,MediaCabinet=python,BytesPerTick=0,CopierType=2,ModuleFileName=C:\WINDOWS\TEMP\147044.msi,,,,,IsFirstPhysicalMedia=1)
MSI (c) (63:E3): Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\TEMP\147044.msi,ProductCode={BE027411-8E6B-4440-A29B-B07DF0690230},CabinetStreams=python,,)
MSI (c) (63:E3): Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{BE027411-8E6B-4440-A29B-B07DF0690230}
3: 2 
MSI (c) (63:E3): Executing op:
ProductRegister(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F},VersionString=2.4.1121,,,,InstallSource=C:\Temp\,Publisher=Martin
v. L?wis,,,,,,,,,,,,EstimatedSize=147397)
RegisterProduct: {BE027411-8E6B-4440-A29B-B07DF0690230}
MSI (c) (63:E3): Executing op: ProductCPDisplayInfoRegister()
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing
Product Features,Template=Feature: )
Action 08:30:43: PublishFeatures. Publishing Product Features
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=DefaultFeature,,Absent=2,Component=j??OUe4X`@i$uC&6A2qKuw,UtgLSt9m.od.692RZ14m~@6pq]8rhPoS&X)D7,bSm,eXa{8$(h.$owxyck=FB1Y)f$9U{ur.`[,ZJ^vr!dfOU`?Ze`ysEk=JLr[E3WgU-x?t?D)z]I=*_dA7ec=)+g=.76?]FKIu1bHFqL5
t([A(1Km9_s+_'MX_[35rw5@g7u+ac`x.,%1%br~*0!9vfmt%=Y!B^1u`AX_!9d=QApJYFnOvfrlI!(GokO?JveVYQYi8f2h%NxT.ig?]b-vBu+r,'ILhl6E^-OA_^v?e$_5IhpTh,w`g.N?qf)G`5^4s@8ASKoHt8MAM`oqO+Ln^S}fQKl6}?d=Tih{Ky=Zf7'JU80OwSF?TJ(O4,B_~91aJSG40wt@5N6cU5hBP94V7`LyWD79f{p{rqL'wg%
-PF16tLs=5)f}`W9QR(r{Gc20~$^@,_d]6k9Gn?e(^7ur&kL9a'1v8~0UWrbAoRjqcwy9wcVYhIk_cjsxfZz1_]MA'bedCP7nB+)
PublishFeatures: Feature: DefaultFeature
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Extensions,Parent=DefaultFeature,Absent=2,Component=&9(xBhb)k@mF)9P]=(i!)
PublishFeatures: Feature: Extensions
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=TclTk,Parent=DefaultFeature,Absent=2,Component=,bSm,eXa{8$(h.$owxycJ=q7zM[@j9hagbp9Xn{co}9nlGPd??^awQ@CGf&0-.'yhr,K&=_3ltzeM.Qc7h^.8-d3T9)EPfCo,d-cyu_m6l_Gp8iMuR,lW[RaQ0A+uDN@U@{L}6cbw?f]i8b7_eX9o@Iy1S
X(&PF?sQlcW}I[(=ZW{-%ivt=M9q7C*M1R.=^Y)J6v,TcMap(-Gk+@a?KT*p2xdCh7XAW'KA95m89]E~`3eN^^V'z(N7]CZA^_7iztK`7eJ^xBgfwjB@Kak6MPA?DO0+@DO3n_AA*K3`@ZtQe?JI6uO%l2W@HN9(W}M~%Cv*,VbO.G[A$XLioN){*Yf.dR$)o(-A+-DXZ!lt&oGrAwx)$J(?6NoDW`@(cYdtWtQ%}-k9Xp1X(yzF}LhTMu7w[79
?OXFqcAk4XyMFpxsxPXJ9m0`},7bv575{8hzkK1!=dJ}y@IG9}`$P8eiaoR`A-VfxP}t9D6)
PublishFeatures: Feature: TclTk
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Documentation,Parent=DefaultFeature,Absent=2,Component=$iX{^*~A'@=`^v0gCm5X)
PublishFeatures: Feature: Documentation
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Tools,Parent=DefaultFeature,Absent=2,Component=GJ+9CR,Tg?JmdBV'[kOW}SK*mRvEv?G8?t0.GQYLZ]11hQx9R?w+A+ac(}(ag~YSM,m2}8,3oy-cjePH&LNCwsJs=A)aA*4Us@6vupTcf8q@f?{n?.&u+hH9)
PublishFeatures: Feature: Tools
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Testsuite,Parent=DefaultFeature,Absent=2,Component=i_BtQR~?6AGCn$H2OkjM8b9z7R7n&95PE+0LABr`iKX^Iz4rs8^Z,]haLA$!9Lg3..?M,9fQ8{GaTQ^.kJFgv&A1D?xHAqGH%u8BS1VasQ)be@`Az3s,j_3[)
PublishFeatures: Feature: Testsuite
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishProduct,Description=Publishing
product information,)
Action 08:30:43: PublishProduct. Publishing product information
MSI (c) (63:E3): Executing op:
IconCreate(Icon=python_icon.exe,Data=BinaryData)
1: python_icon.exe 
MSI (c) (63:E3): Executing op:
ProductPublish(PackageKey={1D61CFC0-C34A-4E8E-804C-CE8F6A7CE163})
1: {BE027411-8E6B-4440-A29B-B07DF0690230} 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Executing op:
UpgradeCodePublish(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F})
MSI (c) (63:E3): Executing op:
SourceListPublish(,,,,NumberOfDisks=1)
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003\SourceList
3: 2 
MSI (c) (63:E3): Executing op: ProductPublishClient(,,)
MSI (c) (63:E3): Executing op:
SourceListRegisterLastUsed(SourceProduct={BE027411-8E6B-4440-A29B-B07DF0690230},LastUsedSource=C:\Temp\)
MSI (c) (63:E3): Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (63:E3): Specifed source is already in a list.
MSI (c) (63:E3): User policy value 'SearchOrder' is 'nmu'
MSI (c) (63:E3): Machine policy value 'DisableBrowse' is 0
MSI (c) (63:E3): Machine policy value 'AllowLockdownBrowse' is 0
MSI (c) (63:E3): Adding new sources is allowed.
MSI (c) (63:E3): Set LastUsedSource to: C:\Temp\.
MSI (c) (63:E3): Set LastUsedType to: n.
MSI (c) (63:E3): Set LastUsedIndex to: 1.
MSI (c) (63:E3): Executing op:
End(Checksum=0,ProgressTotal=28708301)
MSI (c) (63:E3): FEATURECACHE: Entering Invalidate
MSI (c) (63:E3): User policy value 'DisableRollback' is 0
MSI (c) (63:E3): Machine policy value 'DisableRollback' is 0
Action 08:30:43: RollbackCleanup. Removing backup files
MSI (c) (63:E3): Unlocking Server
Action ended 08:30:43: InstallFinalize. Return value 1.
MSI (c) (63:E3): Skipping action: CompilePyc (condition is
false)
MSI (c) (63:E3): Skipping action: CompilePyo (condition is
false)
Action ended 08:30:43: INSTALL. Return value 1.
MSI (c) (63:E3): Decrementing counter to disable shutdown.
If counter >= 0, shutdown will be denied.  Counter after
decrement: -1
Action ended 08:30:43: ExecuteAction. Return value 1.
MSI (c) (63:E3): Doing action: ExitDialog
Action start 08:30:43: ExitDialog.
Action 08:30:43: ExitDialog. Dialog created
Action ended 08:30:45: ExitDialog. Return value 1.
Action ended 08:30:45: INSTALL. Return value 1.

</snip>

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 03:37

Message:
Logged In: YES 
user_id=1237039

Uninstalled, rebooted and reinstalled using

c:\windows\system\msiexec /i python-2.4.1c1.msi /l*v python.log

The log file (1.1MB) is available, probably too big to
cut/paste into here. I can email it to you if you like.
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 17:39

Message:
Logged In: YES 
user_id=21627

Somebody suggested in the newsgroup to request a log file; I
should have thought of this earlier.

So please reinstall the MSI file, using

msiexec /i python-2.4.1c1.msi /l*v python.log

and attach the resulting python.log to this report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 17:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 13:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 08:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 07:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 06:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 06:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 06:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 05:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 10:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 05:15:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 05:15:48 2005
Subject: [ python-Bugs-1163325 ] "special" decimals aren't hashable
Message-ID: <E1DB3T7-0004DL-NV@sc8-sf-web2.sourceforge.net>

Bugs item #1163325, was opened at 2005-03-14 17:37
Message generated for change (Comment added) made by foom
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: "special" decimals aren't hashable

Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34) 
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
    i = int(self)
  File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
    return context._raise_error(InvalidContext)
  File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
    raise error, explanation
decimal.InvalidOperation

This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)

Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?


----------------------------------------------------------------------

Comment By: James Y Knight (foom)
Date: 2005-03-14 23:15

Message:
Logged In: YES 
user_id=1104715

NaN, Inf, and negInf all fail to hash. 

Inf and negInf are equal to themselves, so they don't have any problem 
being used as a dict key. 

As for NaN, I don't see any harm in allowing it to return a hashcode 
anyways, but perhaps you're right. 

However, in that case, it would be nice to have the exception raised be 
somewhat more regular and expected-looking than a InvalidOperation 
from int(). Perhaps it should raise TypeError('Decimal("NaN") is 
unhashable').


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-14 19:04

Message:
Logged In: YES 
user_id=31435

Well, I'm not really a fan of Python's tying hashability 
to "usable as a dict key", but given that's what Python 
_does_, ya, hashing a NaN doesn't make sense.

marienz, by "special" decimals did you mean only NaNs, or 
do you have other cases in mind too?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-14 17:42

Message:
Logged In: YES 
user_id=80475

Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them.  Tim, do you have
another thoughts on the subject?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 06:00:43 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 06:00:47 2005
Subject: [ python-Bugs-1163325 ] "special" decimals aren't hashable
Message-ID: <E1DB4Ad-00089Q-T6@sc8-sf-web3.sourceforge.net>

Bugs item #1163325, was opened at 2005-03-14 17:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Marien Zwart (marienz)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: "special" decimals aren't hashable

Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34) 
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
    i = int(self)
  File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
    return context._raise_error(InvalidContext)
  File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
    raise error, explanation
decimal.InvalidOperation

This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)

Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-15 00:00

Message:
Logged In: YES 
user_id=80475

Fixed.  See Lib/decimal.py 1.35.

Anthony, can this be backported to 2.4.1 or does it need to
wait for 2.4.2?

----------------------------------------------------------------------

Comment By: James Y Knight (foom)
Date: 2005-03-14 23:15

Message:
Logged In: YES 
user_id=1104715

NaN, Inf, and negInf all fail to hash. 

Inf and negInf are equal to themselves, so they don't have any problem 
being used as a dict key. 

As for NaN, I don't see any harm in allowing it to return a hashcode 
anyways, but perhaps you're right. 

However, in that case, it would be nice to have the exception raised be 
somewhat more regular and expected-looking than a InvalidOperation 
from int(). Perhaps it should raise TypeError('Decimal("NaN") is 
unhashable').


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-14 19:04

Message:
Logged In: YES 
user_id=31435

Well, I'm not really a fan of Python's tying hashability 
to "usable as a dict key", but given that's what Python 
_does_, ya, hashing a NaN doesn't make sense.

marienz, by "special" decimals did you mean only NaNs, or 
do you have other cases in mind too?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-14 17:42

Message:
Logged In: YES 
user_id=80475

Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them.  Tim, do you have
another thoughts on the subject?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 07:00:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 07:00:56 2005
Subject: [ python-Bugs-1162677 ] Unable to Install Python 2.4.1rc1 on
	windows XP SP2
Message-ID: <E1DB56q-000556-74@sc8-sf-web1.sourceforge.net>

Bugs item #1162677, was opened at 2005-03-13 19:32
Message generated for change (Comment added) made by sergiocorreia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sergio Correia (sergiocorreia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to Install  Python 2.4.1rc1 on windows XP SP2

Initial Comment:
First of all, YES i had everything i needed to install,
and yes i read the info on the site.

When i tried to install python-2.4.1c1.msi (or even
ActivePython-2.4.0-244-win32-ix86.msi), install "ended
prematurely because of an error".

I tried everything but, after a while i found a way to
avoid the bug.

I was installing from "F:\Docs\Varios\Sandbox".. i
moved the msi file to C:\ and then the install (both,
python and activepython) worked out perfectly.

Folders were not shared, restricted, compressed or on a
network (it was a normal local hard disk).

Any ideas on why that happened?

Thanks


PS: Sorry about the sp. mistakes. I am not very fluent
on technical english.

----------------------------------------------------------------------

>Comment By: Sergio Correia (sergiocorreia)
Date: 2005-03-15 01:00

Message:
Logged In: YES 
user_id=1238520

Thanks for the reply.

So i uninstalled it, tried again from 
the "F:\Docs\Varios\Sandbox" folder, got the same error, and 
attached the log.

Btw,  F: is a physical drive, and its not SUBSTed.

=)

Oh, the last lines of the log were:
=== Logging stopped: 15/03/2005  00:54:23 ===
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 1708 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Product: Python 2.4.1c1 -- 
Installation failed.

MSI (c) (24:A0) [00:54:23:163]: Grabbed execution mutex.
MSI (c) (24:A0) [00:54:23:163]: Cleaning up uninstalled install 
packages, if any exist
MSI (c) (24:A0) [00:54:23:173]: MainEngineThread is 
returning 1603
=== Verbose logging stopped: 15/03/2005  00:54:23 ===


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 16:36

Message:
Logged In: YES 
user_id=21627

No, but I know how to find out. Please run, in a cmd.exe window,

msiexec /i python-2.4.1c1.msi /l*v python.log

Compress python.log with Winzip, and attach the resulting
file to this report.

As a wild guess: could it be that F: is SUBSTed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 09:06:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 09:06:35 2005
Subject: [ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Message-ID: <E1DB74Q-00006d-Im@sc8-sf-web1.sourceforge.net>

Bugs item #1105699, was opened at 2005-01-20 01:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470

Category: Build
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Warnings in Python.h with gcc 4.0.0

Initial Comment:
(this happens for every file that includes Python.h)

In file included from ../Include/Python.h:55,
                 from ../Objects/intobject.c:4:
../Include/pyport.h:396: warning: 'struct winsize' declared inside 
parameter list
../Include/pyport.h:397: warning: 'struct winsize' declared inside 
parameter list

The source lines look like this:
extern int openpty(int *, int *, char *, struct termios *, struct 
winsize *);
extern int forkpty(int *, char *, struct termios *, struct winsize *);

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-15 09:06

Message:
Logged In: YES 
user_id=21627

Still, for the record: what operating system is this on?

I don't believe the analysis that this is a GCC bug, but I'm
willing to accept it <wink>. Closing this as third-party.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-03-14 23:52

Message:
Logged In: YES 
user_id=139309

Turns out that this is a GCC4 bug (not sure which, though).  The OS 
headers are fine.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-04 21:15

Message:
Logged In: YES 
user_id=21627

What operating system is this on? struct winsize should have
been included through <termios.h>. Then, the mentioning of
it in the propotypes is not a declaration, just a reference.

So if you get this warning, it probably indicates a problem
with your system headers.

----------------------------------------------------------------------

Comment By: Richard Kettlewell (rjk1002)
Date: 2005-01-31 16:43

Message:
Logged In: YES 
user_id=217390

C does guarantee that all struct pointers share the same
*representation* (section 6.2.5 of C99).  That's not what
the compiler is complaining about here.
Rather, a struct declared inside a parameter list is
restricted in scope to that parameter list, and so is not
the same structure as one declared outside it, even if the
tag is the same.
The solution is to forward-declare the struct (as an
incomplete type, i.e. just "struct winsize;") before any of
the declarations that use it.  Then the struct tag will mean
the same thing in every scope.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-01-21 00:13

Message:
Logged In: YES 
user_id=31435

The warning almost certainly means that there's no 
declaration of struct winsize in scope when these externs are 
declared.  That's bad, because C doesn't guarantee that all 
pointers are the same size (although they are on all Python 
platforms I'm aware of).

Some quality time with Google suggested that other projects 
wormed around this by #include'ing <termio.h> instead of 
<termios.h>, because the former but not the latter #include's 
<sys/ioctl.h> where the winsize struct was defined.  Beats 
me -- ain't a Windows problem <wink>.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-01-20 23:49

Message:
Logged In: YES 
user_id=139309

Beats me, it's probably just "bad style".

It's a problem because it shows up a lot in the output, so we should at 
least figure out how to disable this warning so that it doesn't become 
annoying.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-01-20 16:18

Message:
Logged In: YES 
user_id=6656

Why is this a problem?  Is it not valid C or something?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 09:42:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 09:42:03 2005
Subject: [ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Message-ID: <E1DB7cn-0005QZ-2J@sc8-sf-web4.sourceforge.net>

Bugs item #1105699, was opened at 2005-01-19 19:52
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470

Category: Build
Group: 3rd Party
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Warnings in Python.h with gcc 4.0.0

Initial Comment:
(this happens for every file that includes Python.h)

In file included from ../Include/Python.h:55,
                 from ../Objects/intobject.c:4:
../Include/pyport.h:396: warning: 'struct winsize' declared inside 
parameter list
../Include/pyport.h:397: warning: 'struct winsize' declared inside 
parameter list

The source lines look like this:
extern int openpty(int *, int *, char *, struct termios *, struct 
winsize *);
extern int forkpty(int *, char *, struct termios *, struct winsize *);

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2005-03-15 03:42

Message:
Logged In: YES 
user_id=139309

It is most certainly a GCC bug (remember, this is GCC 4).

I'm not sure I can say which OS it is, due to NDA, but it shouldn't be hard 
to guess.  The release I'm using is not public.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-15 03:06

Message:
Logged In: YES 
user_id=21627

Still, for the record: what operating system is this on?

I don't believe the analysis that this is a GCC bug, but I'm
willing to accept it <wink>. Closing this as third-party.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-03-14 17:52

Message:
Logged In: YES 
user_id=139309

Turns out that this is a GCC4 bug (not sure which, though).  The OS 
headers are fine.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-04 15:15

Message:
Logged In: YES 
user_id=21627

What operating system is this on? struct winsize should have
been included through <termios.h>. Then, the mentioning of
it in the propotypes is not a declaration, just a reference.

So if you get this warning, it probably indicates a problem
with your system headers.

----------------------------------------------------------------------

Comment By: Richard Kettlewell (rjk1002)
Date: 2005-01-31 10:43

Message:
Logged In: YES 
user_id=217390

C does guarantee that all struct pointers share the same
*representation* (section 6.2.5 of C99).  That's not what
the compiler is complaining about here.
Rather, a struct declared inside a parameter list is
restricted in scope to that parameter list, and so is not
the same structure as one declared outside it, even if the
tag is the same.
The solution is to forward-declare the struct (as an
incomplete type, i.e. just "struct winsize;") before any of
the declarations that use it.  Then the struct tag will mean
the same thing in every scope.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-01-20 18:13

Message:
Logged In: YES 
user_id=31435

The warning almost certainly means that there's no 
declaration of struct winsize in scope when these externs are 
declared.  That's bad, because C doesn't guarantee that all 
pointers are the same size (although they are on all Python 
platforms I'm aware of).

Some quality time with Google suggested that other projects 
wormed around this by #include'ing <termio.h> instead of 
<termios.h>, because the former but not the latter #include's 
<sys/ioctl.h> where the winsize struct was defined.  Beats 
me -- ain't a Windows problem <wink>.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-01-20 17:49

Message:
Logged In: YES 
user_id=139309

Beats me, it's probably just "bad style".

It's a problem because it shows up a lot in the output, so we should at 
least figure out how to disable this warning so that it doesn't become 
annoying.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-01-20 10:18

Message:
Logged In: YES 
user_id=6656

Why is this a problem?  Is it not valid C or something?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 09:56:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 09:56:28 2005
Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode
Message-ID: <E1DB7qk-00060T-TY@sc8-sf-web4.sourceforge.net>

Bugs item #1163563, was opened at 2005-03-15 09:56
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=1163563&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: anothermax (yetanothermax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sub threads execute in restricted mode

Initial Comment:
I'm using the JEP product which allows integration
of Java with Python (see http://jepp.sourceforge.net) via
starting a Python interpreter in the same process as the 
JVM.
This integrates with python via the C interface, allowing 
the user to 'eval' python code (amongst other features).

It seems that since Python 2.3.5 any threads (using the 
threading module) created via code that has been 
evaluated through the jep.eval() interface (i.e.Python C 
interface )are executed in restricted mode and cannot, 
for example, create files. Code that is just evaled (i.e not 
in a subthread) thread has no restrictions.

The error reported is:
IOError: file() constructor not accessible in restricted 
mode

(see http://sourceforge.net/forum/forum.php?
thread_id=1247793&forum_id=376782) - I've given a JEP 
specific example here.

There seems to be a similar problem with mod_python
(see 
http://www.modpython.org/pipermail/mod_python/2005-
January/017129.html)

Reading through the release notes for Python 2.3.5
I see:
 Bug #754449: threading.Thread will no longer mask 
exceptions raised during interpreter shutdown with 
another exception caused by attempting to output the 
initial exception. This fix also includes a backport of rev. 
1.41 from HEAD. 

This might be the problem as it seems to involve the 
porting of 2.4 threading code back to the 2.3 tree.

I've attached a Java file which shows the problem when 
using JEP.
The error output is:
Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\Lib\threading.py", line 442, in 
__bootstrap
  File "<string>", line 5, in run
IOError: file() constructor not accessible in restricted 
mode

2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 
bit (Intel)]
Creating file from main thread...
Done
Creating file from sub thread...
Done


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 09:59:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 10:00:01 2005
Subject: [ python-Bugs-1054943 ] Python may contain NFC/NFKC bug per Unicode
	PRI #29
Message-ID: <E1DB7uB-0006D1-LU@sc8-sf-web4.sourceforge.net>

Bugs item #1054943, was opened at 2004-10-27 01:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054943&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rick McGowan (rick_mcgowan)
Assigned to: Martin v. L?wis (loewis)
Summary: Python may contain NFC/NFKC bug per Unicode PRI #29

Initial Comment:
The Unicode Technical Committee posted Public Review
Issue #29, describing a bug in the documentation of NFC
and NFKC in the text of UAX #15 Unicode Normalization
Forms. I have examined unicodedata.c in the Python
implementation (2.3.4) and it appears the
implementation of normalization in Python 2.3.4 may
have the bug therein described. Please see the
description of the bug and the textual fix that is
being made to UAX #15, at the URL:
http://www.unicode.org/review/pr-29.html
The bug is in the definition of rule D2, affecting the
characters "blocked" during re-composition.

You may contact me by e-mail, or fill out the
Unicode.org error reporting form if you have any
questions or concerns.

Since Python uses Unicode internally, it may also be
wise to have someone from the Python development
community on the Unicode Consortium's notification list
to receive immediate notifications of public review
issues, bugs, and other announcements affecting
implementation of the standard.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-15 09:59

Message:
Logged In: YES 
user_id=21627

Is it true that the most recent interpretation of this PR
suggests that the correction should only apply to Unicode
4.1? If so, I think Python should abstain from adopting the
change right now, and should defer that to the point when
the Unicode 4.1 database is incorporated.

----------------------------------------------------------------------

Comment By: Rick McGowan (rick_mcgowan)
Date: 2004-10-27 22:11

Message:
Logged In: YES 
user_id=1146994

Thanks all for quick reply. My initial thoughts regarding a
fix were as below. The relevant piece of code seems to be in
function "nfc_nfkc()" in the file unicodedata.c

>           if (comb1 && comb == comb1) { 
>               /* Character is blocked. */ 
>               i1++; 
>               continue; 
>           } 

That should possibly be changed to: 

>           if (comb1 && (comb <= comb1)) { 
>               /* Character is blocked. */ 
>               i1++; 
>               continue; 
>           } 

because the new spec says "either B is a starter or it has
the same or higher combining class as C".


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-10-27 20:11

Message:
Logged In: YES 
user_id=38388

Thanks for submitting a bug report. The problem does indeed
occur in the Python normalization code:

>>> unicodedata.normalize('NFC', u'\u0B47\u0300\u0B3E')
u'\u0b4b\u0300'

I think the following line in unicodedata.c needs to be changed:

          if (comb1 && comb == comb1) {
              /* Character is blocked. */
              i1++;
              continue;
          }

to

          if (comb && (comb1 == 0 || comb == comb1)) {
              /* Character is blocked. */
              i1++;
              continue;
          }

Martin, what do you think ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054943&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 10:52:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 10:52:57 2005
Subject: [ python-Bugs-1163401 ] uncaught AttributeError deep in urllib
Message-ID: <E1DB8jO-0008Vm-NI@sc8-sf-web4.sourceforge.net>

Bugs item #1163401, was opened at 2005-03-15 01:39
Message generated for change (Comment added) made by zgoda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: K Lars Lohn (lohnk)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncaught AttributeError deep in urllib

Initial Comment:
Python 2.4 and Python 2.3.4 running under Suse 9.2

We're getting an AttributeError exception "AttributeError: 'NoneType' object has no attribute 'read'" within a very simple call to urllib.urlopen.

This was discovered while working on Sentry 2, the new mirror integrity checker for the Mozilla project.  We try to touch hundreds of URLs to make sure that the files are present on each of the mirrors.  One particular URL kills the call to urllib.urlopen: http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe
This file probably does not exist on the mirror, however, in other cases of bad URLs, we get much more graceful failures when we try to read from the object returned by urllib.urlopen.

>>> import urllib
>>> urlReader = urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.4/urllib.py", line 180, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__
    addbase.__init__(self, fp)
  File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__
    self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'

The  attached file is a three line scipt that demos the problem.



----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-15 10:52

Message:
Logged In: YES 
user_id=92222

No such error on Windows:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 14:22:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 14:22:45 2005
Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Message-ID: <E1DBC0P-0002T6-Vv@sc8-sf-web3.sourceforge.net>

Bugs item #1153075, was opened at 2005-02-27 21:55
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro

Initial Comment:
The functions PyInt_Check(), PyString_Check(),
PyList_Check() etc. are used all over the core to check
which typecasts are safe, from PyObject* to the various
PyXxxObject*.

But the macros themselves are implemented by
inspecting the "tp_mro" tuple of the incoming object's
type.  As the latter can be completely controlled by the
user, an object can pretend to inherit from anything and
pass the PyXxx_Check() checks of its choice, even if
its memory layout is actually completely wrong.

See attached example.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-15 13:22

Message:
Logged In: YES 
user_id=6656

Please see the attached PDF for a proof of ... well, something in the area.

I think this is what typeobject.c should be doing and what it's *trying* to 
do.  I'm less confident that this is what it's actually doing (particularly wrt 
the subclassing two subclasses of str thing).



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-14 11:41

Message:
Logged In: YES 
user_id=6656

Well, emprically that can't happen because the patch passes test_descr, 
and far sillier things happen in that file than in real life.

More theoretically... I'll think about it :)

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-14 11:25

Message:
Logged In: YES 
user_id=4771

I tried to convince myself that this check always accepts the 
default mro, but there are more implicit assumptions around 
than I can handle in a quick review...

Instead, I modified the patch so that a debug build of Python 
always does the check in mro_internal().  This results in a 
shallow problem: the basestring type has tp_basicsize==0, 
which makes the computation of its solid_base trigger an 
assertion in extra_ivars().  If I hack around this problem, then 
I cannot quickly find an example of built-in mro that triggers a 
TypeError, but it doesn't mean there isn't one...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-06 18:47

Message:
Logged In: YES 
user_id=6656

I think the attached fixes all this.

What it does: check the return value of PySequence_Tuple (duh).  Check 
that the returned sequence contains only types or old-style classes.  
Checks that the solid_base of each type in the returned sequence is a 
supertype of the solid_base of type being built.  Adds a few tests.

The error messages are a bit inscrutable.  I find it hard to care.

Assigning to Armin for the first look.  Might want to get Guido to look at it 
too.

When Armin and I talked about this on IRC we found a few oddities in the 
general area, but I don't know if it's worth opening a new bug report for 
them...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-03 09:50

Message:
Logged In: YES 
user_id=6656

Certainly some more checking of what the user-defined MRO contains 
would be good -- check the attached, which dumps core at class definition 
time...

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-03 09:34

Message:
Logged In: YES 
user_id=4771

The PyXxx_Check() macros are #defined with
PyObject_TypeCheck().  Should we change all these #defines to
use a new PyObject_LayoutCheck() or something, and document
to C extension writers that they should also switch to the
new function?  More generally, should we review *all* usages
of PyObject_TypeCheck() and decide if they really meant that
or PyObject_LayoutCheck()?  Do we care about types that are
solid subclasses of 'int' but don't have it in their MRO? 
Should we just forget the whole idea and sanity-check the
user-defined mro, which after all would just add another
strange undocumented condition to typeobject.c? :-)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-02 20:11

Message:
Logged In: YES 
user_id=6656

Hmm, yeah, that works.  It wasn't totally clear to me that the user couldn't 
maliciously influence tp_base, but I don't think they can...

A helper function is presumably in order, unless PyType_IsSubtype should 
be changed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-02 17:03

Message:
Logged In: YES 
user_id=4771

To solve the problem, as hinted in the title of this tracker, I 
think that PyXxx_Check() should simply not trust any mro.  
What PyInt_Check() really means at the C level is to check if 
an object memory layout is compatible with PyIntObject.  This 
is easy to figure out by walking the "solid base" chain, 
tp_base.

As a side note, PyPy gives the same error as Python 2.2.  
However, both in PyPy and in Python 2.2, you can still build 
an instance of the strange class X as follows:

>>> x = object.__new__(X)

Still, all the methods of x are resolved via the dict type.  In 
PyPy we get a clean TypeError because the methods thus 
found don't apply to non-dict objects.  In Python 2.2 you can 
crash the interpreter just as in more recent Python releases, 
e.g. with x[5]=6.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-01 20:18

Message:
Logged In: YES 
user_id=6656

I wonder if Guido owes Armin a beer (read typeobject.c around line 5230).  
Well, not really, but it's that code that is making the difference.

However, reversing the order of dict and object is sufficient to make 2.2 
crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting 
code chopped out which gives the error jelper observes on the original).

I wonder what to do about this.  Removing the ability to customize the mro 
from user code is one obvious approach -- I don't know how much code 
uses this feature though.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-01 19:15

Message:
Logged In: YES 
user_id=2772

Not sure if this is relevant, but the example given didn't
crash 2.2:
$ python2.2 bug.py
Traceback (most recent call last):
  File "bug.py", line 9, in ?
    x = X()
TypeError: dict.__new__(X) is not safe, use object.__new__()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 15:10:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 15:10:17 2005
Subject: [ python-Bugs-1163325 ] "special" decimals aren't hashable
Message-ID: <E1DBCkP-0004rb-Ii@sc8-sf-web3.sourceforge.net>

Bugs item #1163325, was opened at 2005-03-15 09:37
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: "special" decimals aren't hashable

Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34) 
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
    i = int(self)
  File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
    return context._raise_error(InvalidContext)
  File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
    raise error, explanation
decimal.InvalidOperation

This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)

Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-16 01:10

Message:
Logged In: YES 
user_id=29957

If you can check it in in the next 24 hours, yes.
otherwise, it can wait til 2.4.2


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-15 16:00

Message:
Logged In: YES 
user_id=80475

Fixed.  See Lib/decimal.py 1.35.

Anthony, can this be backported to 2.4.1 or does it need to
wait for 2.4.2?

----------------------------------------------------------------------

Comment By: James Y Knight (foom)
Date: 2005-03-15 15:15

Message:
Logged In: YES 
user_id=1104715

NaN, Inf, and negInf all fail to hash. 

Inf and negInf are equal to themselves, so they don't have any problem 
being used as a dict key. 

As for NaN, I don't see any harm in allowing it to return a hashcode 
anyways, but perhaps you're right. 

However, in that case, it would be nice to have the exception raised be 
somewhat more regular and expected-looking than a InvalidOperation 
from int(). Perhaps it should raise TypeError('Decimal("NaN") is 
unhashable').


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-15 11:04

Message:
Logged In: YES 
user_id=31435

Well, I'm not really a fan of Python's tying hashability 
to "usable as a dict key", but given that's what Python 
_does_, ya, hashing a NaN doesn't make sense.

marienz, by "special" decimals did you mean only NaNs, or 
do you have other cases in mind too?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-15 09:42

Message:
Logged In: YES 
user_id=80475

Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them.  Tim, do you have
another thoughts on the subject?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 15:49:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 15:49:58 2005
Subject: [ python-Bugs-1163759 ] subprocess pipe fails under Emacs
Message-ID: <E1DBDMp-00030s-Pv@sc8-sf-web1.sourceforge.net>

Bugs item #1163759, was opened at 2005-03-15 15:49
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=1163759&group_id=5470

Category: XML
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders J. Munch (andersjm)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess pipe fails under Emacs

Initial Comment:
Creating a pipe with subprocess.Popen fails if Python
is running in a non-interactive subshell under XEmacs
on MSWin.

This program
  import subprocess
  pipe = subprocess.Popen(['cmd', '/c', r'echo', 'Hi
there!'],
                        stdout=subprocess.PIPE)
  print pipe.stdout.read()

produces the expected "Hi there!" when run from a
console. But when run from an XEmacs non-interactive
subshell, I get this traceback:

Traceback (most recent call last):
  File "C:\temp\subprocessbug.py", line 3, in ?
    stdout=subprocess.PIPE)
  File "c:\App\Dev\Python24\lib\subprocess.py", line
545, in __init__
    (p2cread, p2cwrite,
  File "c:\App\Dev\Python24\lib\subprocess.py", line
605, in _get_handles
    p2cread = self._make_inheritable(p2cread)
  File "c:\App\Dev\Python24\lib\subprocess.py", line
646, in _make_inheritable
    DUPLICATE_SAME_ACCESS)
TypeError: an integer is required

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)]
W2K, XEmacs 21.4p13


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163759&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 16:09:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 16:09:55 2005
Subject: [ python-Bugs-1163759 ] subprocess pipe fails under Emacs
Message-ID: <E1DBDg9-000452-FR@sc8-sf-web1.sourceforge.net>

Bugs item #1163759, was opened at 2005-03-15 15:49
Message generated for change (Settings changed) made by andersjm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163759&group_id=5470

>Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders J. Munch (andersjm)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess pipe fails under Emacs

Initial Comment:
Creating a pipe with subprocess.Popen fails if Python
is running in a non-interactive subshell under XEmacs
on MSWin.

This program
  import subprocess
  pipe = subprocess.Popen(['cmd', '/c', r'echo', 'Hi
there!'],
                        stdout=subprocess.PIPE)
  print pipe.stdout.read()

produces the expected "Hi there!" when run from a
console. But when run from an XEmacs non-interactive
subshell, I get this traceback:

Traceback (most recent call last):
  File "C:\temp\subprocessbug.py", line 3, in ?
    stdout=subprocess.PIPE)
  File "c:\App\Dev\Python24\lib\subprocess.py", line
545, in __init__
    (p2cread, p2cwrite,
  File "c:\App\Dev\Python24\lib\subprocess.py", line
605, in _get_handles
    p2cread = self._make_inheritable(p2cread)
  File "c:\App\Dev\Python24\lib\subprocess.py", line
646, in _make_inheritable
    DUPLICATE_SAME_ACCESS)
TypeError: an integer is required

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)]
W2K, XEmacs 21.4p13


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163759&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 17:45:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 17:45:52 2005
Subject: [ python-Bugs-1054943 ] Python may contain NFC/NFKC bug per Unicode
	PRI #29
Message-ID: <E1DBFAr-0001u8-Rk@sc8-sf-web2.sourceforge.net>

Bugs item #1054943, was opened at 2004-10-26 23:58
Message generated for change (Comment added) made by rick_mcgowan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054943&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rick McGowan (rick_mcgowan)
Assigned to: Martin v. L?wis (loewis)
Summary: Python may contain NFC/NFKC bug per Unicode PRI #29

Initial Comment:
The Unicode Technical Committee posted Public Review
Issue #29, describing a bug in the documentation of NFC
and NFKC in the text of UAX #15 Unicode Normalization
Forms. I have examined unicodedata.c in the Python
implementation (2.3.4) and it appears the
implementation of normalization in Python 2.3.4 may
have the bug therein described. Please see the
description of the bug and the textual fix that is
being made to UAX #15, at the URL:
http://www.unicode.org/review/pr-29.html
The bug is in the definition of rule D2, affecting the
characters "blocked" during re-composition.

You may contact me by e-mail, or fill out the
Unicode.org error reporting form if you have any
questions or concerns.

Since Python uses Unicode internally, it may also be
wise to have someone from the Python development
community on the Unicode Consortium's notification list
to receive immediate notifications of public review
issues, bugs, and other announcements affecting
implementation of the standard.


----------------------------------------------------------------------

>Comment By: Rick McGowan (rick_mcgowan)
Date: 2005-03-15 16:45

Message:
Logged In: YES 
user_id=1146994

Yes. The "current" version of UAX #15 is an annex to Unicode
4.1, which will be coming out very soon. No previous
versions of Unicode have been changed. Previous versions of
UAX #15 apply to previous versions of the standard. The UTC
plans to issue a "corrigendum" for this problem, and the
corrigendum is something that *can* be applied to
implementations of earlier versions of Unicode. In that
case, one would cite the implementation of "Unicode Version
X with Corrigendum Y" as shown on the "Enumerated Versions"
page of the Unicode web site. To follow corrigenda, you may
want to keep tabs on the "Updates and Errata" page on the
Unicode web site. This is likely to be Corrigendum #5. You
could fix the bug when you update Python to Unicode 4.1, or
fix it when the corrigendum comes out. Of course, I would
recommend fixing bugs sooner rather than later, but your
release plans may be such that one path is easier. If it's
going to be a long time before you update to 4.1, you may
want to fix the bug and cite the corrigendum when it comes
out. If you plan to update to 4.1 soon after it comes out,
perhaps fixing the bug with that update is fine.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-15 08:59

Message:
Logged In: YES 
user_id=21627

Is it true that the most recent interpretation of this PR
suggests that the correction should only apply to Unicode
4.1? If so, I think Python should abstain from adopting the
change right now, and should defer that to the point when
the Unicode 4.1 database is incorporated.

----------------------------------------------------------------------

Comment By: Rick McGowan (rick_mcgowan)
Date: 2004-10-27 20:11

Message:
Logged In: YES 
user_id=1146994

Thanks all for quick reply. My initial thoughts regarding a
fix were as below. The relevant piece of code seems to be in
function "nfc_nfkc()" in the file unicodedata.c

>           if (comb1 && comb == comb1) { 
>               /* Character is blocked. */ 
>               i1++; 
>               continue; 
>           } 

That should possibly be changed to: 

>           if (comb1 && (comb <= comb1)) { 
>               /* Character is blocked. */ 
>               i1++; 
>               continue; 
>           } 

because the new spec says "either B is a starter or it has
the same or higher combining class as C".


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-10-27 18:11

Message:
Logged In: YES 
user_id=38388

Thanks for submitting a bug report. The problem does indeed
occur in the Python normalization code:

>>> unicodedata.normalize('NFC', u'\u0B47\u0300\u0B3E')
u'\u0b4b\u0300'

I think the following line in unicodedata.c needs to be changed:

          if (comb1 && comb == comb1) {
              /* Character is blocked. */
              i1++;
              continue;
          }

to

          if (comb && (comb1 == 0 || comb == comb1)) {
              /* Character is blocked. */
              i1++;
              continue;
          }

Martin, what do you think ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054943&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 17:50:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 17:50:43 2005
Subject: [ python-Bugs-1163401 ] uncaught AttributeError deep in urllib
Message-ID: <E1DBFFg-0003P5-KQ@sc8-sf-web4.sourceforge.net>

Bugs item #1163401, was opened at 2005-03-14 16:39
Message generated for change (Comment added) made by lohnk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: K Lars Lohn (lohnk)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncaught AttributeError deep in urllib

Initial Comment:
Python 2.4 and Python 2.3.4 running under Suse 9.2

We're getting an AttributeError exception "AttributeError: 'NoneType' object has no attribute 'read'" within a very simple call to urllib.urlopen.

This was discovered while working on Sentry 2, the new mirror integrity checker for the Mozilla project.  We try to touch hundreds of URLs to make sure that the files are present on each of the mirrors.  One particular URL kills the call to urllib.urlopen: http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe
This file probably does not exist on the mirror, however, in other cases of bad URLs, we get much more graceful failures when we try to read from the object returned by urllib.urlopen.

>>> import urllib
>>> urlReader = urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.4/urllib.py", line 180, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__
    addbase.__init__(self, fp)
  File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__
    self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'

The  attached file is a three line scipt that demos the problem.



----------------------------------------------------------------------

>Comment By: K Lars Lohn (lohnk)
Date: 2005-03-15 08:50

Message:
Logged In: YES 
user_id=1239273

This problem is apparently transient depending on network conditions or, perhaps, the configuration of the server end.  On 3/14 the problem has mysteriously vanished....

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-15 01:52

Message:
Logged In: YES 
user_id=92222

No such error on Windows:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
From noreply at sourceforge.net  Tue Mar 15 20:09:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 15 20:09:56 2005
Subject: [ python-Bugs-1163401 ] uncaught AttributeError deep in urllib
Message-ID: <E1DBHQO-0003Vt-GX@sc8-sf-web3.sourceforge.net>

Bugs item #1163401, was opened at 2005-03-14 18:39
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: K Lars Lohn (lohnk)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncaught AttributeError deep in urllib

Initial Comment:
Python 2.4 and Python 2.3.4 running under Suse 9.2

We're getting an AttributeError exception "AttributeError: 'NoneType' object has no attribute 'read'" within a very simple call to urllib.urlopen.

This was discovered while working on Sentry 2, the new mirror integrity checker for the Mozilla project.  We try to touch hundreds of URLs to make sure that the files are present on each of the mirrors.  One particular URL kills the call to urllib.urlopen: http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe
This file probably does not exist on the mirror, however, in other cases of bad URLs, we get much more graceful failures when we try to read from the object returned by urllib.urlopen.

>>> import urllib
>>> urlReader = urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.4/urllib.py", line 180, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__
    addbase.__init__(self, fp)
  File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__
    self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'

The  attached file is a three line scipt that demos the problem.



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2005-03-15 13:09

Message:
Logged In: YES 
user_id=44345


Looking through the code I believe I traced the problem back
to httplib.HTTP which sets self.fp to None when it's closed.
It seems that urllib is trying to access this object after
the connection's been closed.

I realize the problem has passed for the moment, but have you 
considered using urllib2?  The urllib library still uses
httplib.HTTP
which is really only there for backward compatibility.  From
this end it would be nice to leave urllib and httplib.HTTP
alone.
New apps should probably use urllib2 which uses the newer
httplib.HTTPConnection class.


----------------------------------------------------------------------

Comment By: K Lars Lohn (lohnk)
Date: 2005-03-15 10:50

Message:
Logged In: YES 
user_id=1239273

This problem is apparently transient depending on network conditions or, perhaps, the configuration of the server end.  On 3/14 the problem has mysteriously vanished....

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-15 03:52

Message:
Logged In: YES 
user_id=92222

No such error on Windows:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 08:05:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 08:05:44 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DBSb6-0000Li-0H@sc8-sf-web1.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-16 08:05

Message:
Logged In: YES 
user_id=21627

Can you please try

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.msi

and confirm that it "works"? This has the CHM shortcut
non-advertised.

As for the log file: the link creation is correct IMO; it is
no problem that the argument is missing (as the CHM file is
the target of the link, and needs no arguments). I was
curious whether an error is logged, but that appears not to
be the case.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-15 03:20

Message:
Logged In: YES 
user_id=31435

Martin, re "resiliency":  Cool -- that works!  Microsoft has too 
much spare cash <wink>.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 09:50

Message:
Logged In: YES 
user_id=1237039

I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.

Let me know if you still want the full log.

<snip>
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,,,,,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python.File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: , Value:
Python.File
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: Content Type,
Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyw,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.NoConFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: , Value:
Python.NoConFile
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: Content
Type, Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyc,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyc, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyo,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyo, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\open\command,
Name: , Value: "C:\Python24\pythonw.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\pyc.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\DefaultIcon,
Name: , Value: C:\Python24\pyc.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File, Name: ,
Value: Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python
File (no console),)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile, Name:
, Value: Python File (no console)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Compiled
Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile,
Name: , Value: Compiled Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=C:\Python24\,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath,
Name: , Value: C:\Python24MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath\InstallGroup,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python 2.4,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath\InstallGroup,
Name: , Value: Python 2.4
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\PythonPath,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\PythonPath,
Name: , Value:
C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Help\Main
Python Documentation,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Doc\Python24.chm,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Help\Main
Python Documentation, Name: , Value:
C:\Python24\Doc\Python24.chm
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Modules,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegCreateKey()
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Modules,
Name: , Value: 
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Python.exe,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe, Name: , Value: C:\Python24\Python.exe
MSI (c) (63:E3): Executing op:
ActionStart(Name=RegisterProduct,Description=Registering
product,Template=)
Action 08:30:42: RegisterProduct. Registering product
MSI (c) (63:E3): Executing op:
ChangeMedia(,MediaPrompt=Please insert the disk:
,MediaCabinet=python,BytesPerTick=0,CopierType=2,ModuleFileName=C:\WINDOWS\TEMP\147044.msi,,,,,IsFirstPhysicalMedia=1)
MSI (c) (63:E3): Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\TEMP\147044.msi,ProductCode={BE027411-8E6B-4440-A29B-B07DF0690230},CabinetStreams=python,,)
MSI (c) (63:E3): Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{BE027411-8E6B-4440-A29B-B07DF0690230}
3: 2 
MSI (c) (63:E3): Executing op:
ProductRegister(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F},VersionString=2.4.1121,,,,InstallSource=C:\Temp\,Publisher=Martin
v. L?wis,,,,,,,,,,,,EstimatedSize=147397)
RegisterProduct: {BE027411-8E6B-4440-A29B-B07DF0690230}
MSI (c) (63:E3): Executing op: ProductCPDisplayInfoRegister()
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing
Product Features,Template=Feature: )
Action 08:30:43: PublishFeatures. Publishing Product Features
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=DefaultFeature,,Absent=2,Component=j??OUe4X`@i$uC&6A2qKuw,UtgLSt9m.od.692RZ14m~@6pq]8rhPoS&X)D7,bSm,eXa{8$(h.$owxyck=FB1Y)f$9U{ur.`[,ZJ^vr!dfOU`?Ze`ysEk=JLr[E3WgU-x?t?D)z]I=*_dA7ec=)+g=.76?]FKIu1bHFqL5
t([A(1Km9_s+_'MX_[35rw5@g7u+ac`x.,%1%br~*0!9vfmt%=Y!B^1u`AX_!9d=QApJYFnOvfrlI!(GokO?JveVYQYi8f2h%NxT.ig?]b-vBu+r,'ILhl6E^-OA_^v?e$_5IhpTh,w`g.N?qf)G`5^4s@8ASKoHt8MAM`oqO+Ln^S}fQKl6}?d=Tih{Ky=Zf7'JU80OwSF?TJ(O4,B_~91aJSG40wt@5N6cU5hBP94V7`LyWD79f{p{rqL'wg%
-PF16tLs=5)f}`W9QR(r{Gc20~$^@,_d]6k9Gn?e(^7ur&kL9a'1v8~0UWrbAoRjqcwy9wcVYhIk_cjsxfZz1_]MA'bedCP7nB+)
PublishFeatures: Feature: DefaultFeature
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Extensions,Parent=DefaultFeature,Absent=2,Component=&9(xBhb)k@mF)9P]=(i!)
PublishFeatures: Feature: Extensions
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=TclTk,Parent=DefaultFeature,Absent=2,Component=,bSm,eXa{8$(h.$owxycJ=q7zM[@j9hagbp9Xn{co}9nlGPd??^awQ@CGf&0-.'yhr,K&=_3ltzeM.Qc7h^.8-d3T9)EPfCo,d-cyu_m6l_Gp8iMuR,lW[RaQ0A+uDN@U@{L}6cbw?f]i8b7_eX9o@Iy1S
X(&PF?sQlcW}I[(=ZW{-%ivt=M9q7C*M1R.=^Y)J6v,TcMap(-Gk+@a?KT*p2xdCh7XAW'KA95m89]E~`3eN^^V'z(N7]CZA^_7iztK`7eJ^xBgfwjB@Kak6MPA?DO0+@DO3n_AA*K3`@ZtQe?JI6uO%l2W@HN9(W}M~%Cv*,VbO.G[A$XLioN){*Yf.dR$)o(-A+-DXZ!lt&oGrAwx)$J(?6NoDW`@(cYdtWtQ%}-k9Xp1X(yzF}LhTMu7w[79
?OXFqcAk4XyMFpxsxPXJ9m0`},7bv575{8hzkK1!=dJ}y@IG9}`$P8eiaoR`A-VfxP}t9D6)
PublishFeatures: Feature: TclTk
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Documentation,Parent=DefaultFeature,Absent=2,Component=$iX{^*~A'@=`^v0gCm5X)
PublishFeatures: Feature: Documentation
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Tools,Parent=DefaultFeature,Absent=2,Component=GJ+9CR,Tg?JmdBV'[kOW}SK*mRvEv?G8?t0.GQYLZ]11hQx9R?w+A+ac(}(ag~YSM,m2}8,3oy-cjePH&LNCwsJs=A)aA*4Us@6vupTcf8q@f?{n?.&u+hH9)
PublishFeatures: Feature: Tools
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Testsuite,Parent=DefaultFeature,Absent=2,Component=i_BtQR~?6AGCn$H2OkjM8b9z7R7n&95PE+0LABr`iKX^Iz4rs8^Z,]haLA$!9Lg3..?M,9fQ8{GaTQ^.kJFgv&A1D?xHAqGH%u8BS1VasQ)be@`Az3s,j_3[)
PublishFeatures: Feature: Testsuite
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishProduct,Description=Publishing
product information,)
Action 08:30:43: PublishProduct. Publishing product information
MSI (c) (63:E3): Executing op:
IconCreate(Icon=python_icon.exe,Data=BinaryData)
1: python_icon.exe 
MSI (c) (63:E3): Executing op:
ProductPublish(PackageKey={1D61CFC0-C34A-4E8E-804C-CE8F6A7CE163})
1: {BE027411-8E6B-4440-A29B-B07DF0690230} 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Executing op:
UpgradeCodePublish(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F})
MSI (c) (63:E3): Executing op:
SourceListPublish(,,,,NumberOfDisks=1)
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003\SourceList
3: 2 
MSI (c) (63:E3): Executing op: ProductPublishClient(,,)
MSI (c) (63:E3): Executing op:
SourceListRegisterLastUsed(SourceProduct={BE027411-8E6B-4440-A29B-B07DF0690230},LastUsedSource=C:\Temp\)
MSI (c) (63:E3): Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (63:E3): Specifed source is already in a list.
MSI (c) (63:E3): User policy value 'SearchOrder' is 'nmu'
MSI (c) (63:E3): Machine policy value 'DisableBrowse' is 0
MSI (c) (63:E3): Machine policy value 'AllowLockdownBrowse' is 0
MSI (c) (63:E3): Adding new sources is allowed.
MSI (c) (63:E3): Set LastUsedSource to: C:\Temp\.
MSI (c) (63:E3): Set LastUsedType to: n.
MSI (c) (63:E3): Set LastUsedIndex to: 1.
MSI (c) (63:E3): Executing op:
End(Checksum=0,ProgressTotal=28708301)
MSI (c) (63:E3): FEATURECACHE: Entering Invalidate
MSI (c) (63:E3): User policy value 'DisableRollback' is 0
MSI (c) (63:E3): Machine policy value 'DisableRollback' is 0
Action 08:30:43: RollbackCleanup. Removing backup files
MSI (c) (63:E3): Unlocking Server
Action ended 08:30:43: InstallFinalize. Return value 1.
MSI (c) (63:E3): Skipping action: CompilePyc (condition is
false)
MSI (c) (63:E3): Skipping action: CompilePyo (condition is
false)
Action ended 08:30:43: INSTALL. Return value 1.
MSI (c) (63:E3): Decrementing counter to disable shutdown.
If counter >= 0, shutdown will be denied.  Counter after
decrement: -1
Action ended 08:30:43: ExecuteAction. Return value 1.
MSI (c) (63:E3): Doing action: ExitDialog
Action start 08:30:43: ExitDialog.
Action 08:30:43: ExitDialog. Dialog created
Action ended 08:30:45: ExitDialog. Return value 1.
Action ended 08:30:45: INSTALL. Return value 1.

</snip>

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 09:37

Message:
Logged In: YES 
user_id=1237039

Uninstalled, rebooted and reinstalled using

c:\windows\system\msiexec /i python-2.4.1c1.msi /l*v python.log

The log file (1.1MB) is available, probably too big to
cut/paste into here. I can email it to you if you like.
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 23:39

Message:
Logged In: YES 
user_id=21627

Somebody suggested in the newsgroup to request a log file; I
should have thought of this earlier.

So please reinstall the MSI file, using

msiexec /i python-2.4.1c1.msi /l*v python.log

and attach the resulting python.log to this report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 23:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 19:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 14:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 13:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 12:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 16:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 12:07:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 12:07:08 2005
Subject: [ python-Bugs-1163325 ] "special" decimals aren't hashable
Message-ID: <E1DBWMj-0007JR-3U@sc8-sf-web3.sourceforge.net>

Bugs item #1163325, was opened at 2005-03-14 17:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Marien Zwart (marienz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: "special" decimals aren't hashable

Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34) 
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
    i = int(self)
  File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
    return context._raise_error(InvalidContext)
  File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
    raise error, explanation
decimal.InvalidOperation

This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)

Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-16 06:07

Message:
Logged In: YES 
user_id=80475

Okay, it's backported.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-15 09:10

Message:
Logged In: YES 
user_id=29957

If you can check it in in the next 24 hours, yes.
otherwise, it can wait til 2.4.2


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-15 00:00

Message:
Logged In: YES 
user_id=80475

Fixed.  See Lib/decimal.py 1.35.

Anthony, can this be backported to 2.4.1 or does it need to
wait for 2.4.2?

----------------------------------------------------------------------

Comment By: James Y Knight (foom)
Date: 2005-03-14 23:15

Message:
Logged In: YES 
user_id=1104715

NaN, Inf, and negInf all fail to hash. 

Inf and negInf are equal to themselves, so they don't have any problem 
being used as a dict key. 

As for NaN, I don't see any harm in allowing it to return a hashcode 
anyways, but perhaps you're right. 

However, in that case, it would be nice to have the exception raised be 
somewhat more regular and expected-looking than a InvalidOperation 
from int(). Perhaps it should raise TypeError('Decimal("NaN") is 
unhashable').


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-14 19:04

Message:
Logged In: YES 
user_id=31435

Well, I'm not really a fan of Python's tying hashability 
to "usable as a dict key", but given that's what Python 
_does_, ya, hashing a NaN doesn't make sense.

marienz, by "special" decimals did you mean only NaNs, or 
do you have other cases in mind too?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-14 17:42

Message:
Logged In: YES 
user_id=80475

Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them.  Tim, do you have
another thoughts on the subject?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 12:32:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 12:32:48 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DBWlY-0000AS-2U@sc8-sf-web3.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 08:56
Message generated for change (Comment added) made by m_webber_sydney
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Spider (m_webber_sydney)
Date: 2005-03-16 11:32

Message:
Logged In: YES 
user_id=1237039

I tried
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.ms
i

(which is only 96K) and got "the installer has encountered
an unexpected error installing this package. This may
indicate a problem with this package. The error code is 2235."

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-16 07:05

Message:
Logged In: YES 
user_id=21627

Can you please try

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.msi

and confirm that it "works"? This has the CHM shortcut
non-advertised.

As for the log file: the link creation is correct IMO; it is
no problem that the argument is missing (as the CHM file is
the target of the link, and needs no arguments). I was
curious whether an error is logged, but that appears not to
be the case.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-15 02:20

Message:
Logged In: YES 
user_id=31435

Martin, re "resiliency":  Cool -- that works!  Microsoft has too 
much spare cash <wink>.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:50

Message:
Logged In: YES 
user_id=1237039

I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.

Let me know if you still want the full log.

<snip>
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,,,,,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python.File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: , Value:
Python.File
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: Content Type,
Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyw,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.NoConFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: , Value:
Python.NoConFile
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: Content
Type, Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyc,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyc, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyo,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyo, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\open\command,
Name: , Value: "C:\Python24\pythonw.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\pyc.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\DefaultIcon,
Name: , Value: C:\Python24\pyc.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File, Name: ,
Value: Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python
File (no console),)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile, Name:
, Value: Python File (no console)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Compiled
Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile,
Name: , Value: Compiled Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=C:\Python24\,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath,
Name: , Value: C:\Python24MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath\InstallGroup,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python 2.4,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath\InstallGroup,
Name: , Value: Python 2.4
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\PythonPath,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\PythonPath,
Name: , Value:
C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Help\Main
Python Documentation,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Doc\Python24.chm,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Help\Main
Python Documentation, Name: , Value:
C:\Python24\Doc\Python24.chm
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Modules,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegCreateKey()
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Modules,
Name: , Value: 
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Python.exe,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe, Name: , Value: C:\Python24\Python.exe
MSI (c) (63:E3): Executing op:
ActionStart(Name=RegisterProduct,Description=Registering
product,Template=)
Action 08:30:42: RegisterProduct. Registering product
MSI (c) (63:E3): Executing op:
ChangeMedia(,MediaPrompt=Please insert the disk:
,MediaCabinet=python,BytesPerTick=0,CopierType=2,ModuleFileName=C:\WINDOWS\TEMP\147044.msi,,,,,IsFirstPhysicalMedia=1)
MSI (c) (63:E3): Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\TEMP\147044.msi,ProductCode={BE027411-8E6B-4440-A29B-B07DF0690230},CabinetStreams=python,,)
MSI (c) (63:E3): Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{BE027411-8E6B-4440-A29B-B07DF0690230}
3: 2 
MSI (c) (63:E3): Executing op:
ProductRegister(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F},VersionString=2.4.1121,,,,InstallSource=C:\Temp\,Publisher=Martin
v. L?wis,,,,,,,,,,,,EstimatedSize=147397)
RegisterProduct: {BE027411-8E6B-4440-A29B-B07DF0690230}
MSI (c) (63:E3): Executing op: ProductCPDisplayInfoRegister()
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing
Product Features,Template=Feature: )
Action 08:30:43: PublishFeatures. Publishing Product Features
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=DefaultFeature,,Absent=2,Component=j??OUe4X`@i$uC&6A2qKuw,UtgLSt9m.od.692RZ14m~@6pq]8rhPoS&X)D7,bSm,eXa{8$(h.$owxyck=FB1Y)f$9U{ur.`[,ZJ^vr!dfOU`?Ze`ysEk=JLr[E3WgU-x?t?D)z]I=*_dA7ec=)+g=.76?]FKIu1bHFqL5
t([A(1Km9_s+_'MX_[35rw5@g7u+ac`x.,%1%br~*0!9vfmt%=Y!B^1u`AX_!9d=QApJYFnOvfrlI!(GokO?JveVYQYi8f2h%NxT.ig?]b-vBu+r,'ILhl6E^-OA_^v?e$_5IhpTh,w`g.N?qf)G`5^4s@8ASKoHt8MAM`oqO+Ln^S}fQKl6}?d=Tih{Ky=Zf7'JU80OwSF?TJ(O4,B_~91aJSG40wt@5N6cU5hBP94V7`LyWD79f{p{rqL'wg%
-PF16tLs=5)f}`W9QR(r{Gc20~$^@,_d]6k9Gn?e(^7ur&kL9a'1v8~0UWrbAoRjqcwy9wcVYhIk_cjsxfZz1_]MA'bedCP7nB+)
PublishFeatures: Feature: DefaultFeature
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Extensions,Parent=DefaultFeature,Absent=2,Component=&9(xBhb)k@mF)9P]=(i!)
PublishFeatures: Feature: Extensions
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=TclTk,Parent=DefaultFeature,Absent=2,Component=,bSm,eXa{8$(h.$owxycJ=q7zM[@j9hagbp9Xn{co}9nlGPd??^awQ@CGf&0-.'yhr,K&=_3ltzeM.Qc7h^.8-d3T9)EPfCo,d-cyu_m6l_Gp8iMuR,lW[RaQ0A+uDN@U@{L}6cbw?f]i8b7_eX9o@Iy1S
X(&PF?sQlcW}I[(=ZW{-%ivt=M9q7C*M1R.=^Y)J6v,TcMap(-Gk+@a?KT*p2xdCh7XAW'KA95m89]E~`3eN^^V'z(N7]CZA^_7iztK`7eJ^xBgfwjB@Kak6MPA?DO0+@DO3n_AA*K3`@ZtQe?JI6uO%l2W@HN9(W}M~%Cv*,VbO.G[A$XLioN){*Yf.dR$)o(-A+-DXZ!lt&oGrAwx)$J(?6NoDW`@(cYdtWtQ%}-k9Xp1X(yzF}LhTMu7w[79
?OXFqcAk4XyMFpxsxPXJ9m0`},7bv575{8hzkK1!=dJ}y@IG9}`$P8eiaoR`A-VfxP}t9D6)
PublishFeatures: Feature: TclTk
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Documentation,Parent=DefaultFeature,Absent=2,Component=$iX{^*~A'@=`^v0gCm5X)
PublishFeatures: Feature: Documentation
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Tools,Parent=DefaultFeature,Absent=2,Component=GJ+9CR,Tg?JmdBV'[kOW}SK*mRvEv?G8?t0.GQYLZ]11hQx9R?w+A+ac(}(ag~YSM,m2}8,3oy-cjePH&LNCwsJs=A)aA*4Us@6vupTcf8q@f?{n?.&u+hH9)
PublishFeatures: Feature: Tools
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Testsuite,Parent=DefaultFeature,Absent=2,Component=i_BtQR~?6AGCn$H2OkjM8b9z7R7n&95PE+0LABr`iKX^Iz4rs8^Z,]haLA$!9Lg3..?M,9fQ8{GaTQ^.kJFgv&A1D?xHAqGH%u8BS1VasQ)be@`Az3s,j_3[)
PublishFeatures: Feature: Testsuite
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishProduct,Description=Publishing
product information,)
Action 08:30:43: PublishProduct. Publishing product information
MSI (c) (63:E3): Executing op:
IconCreate(Icon=python_icon.exe,Data=BinaryData)
1: python_icon.exe 
MSI (c) (63:E3): Executing op:
ProductPublish(PackageKey={1D61CFC0-C34A-4E8E-804C-CE8F6A7CE163})
1: {BE027411-8E6B-4440-A29B-B07DF0690230} 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Executing op:
UpgradeCodePublish(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F})
MSI (c) (63:E3): Executing op:
SourceListPublish(,,,,NumberOfDisks=1)
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003\SourceList
3: 2 
MSI (c) (63:E3): Executing op: ProductPublishClient(,,)
MSI (c) (63:E3): Executing op:
SourceListRegisterLastUsed(SourceProduct={BE027411-8E6B-4440-A29B-B07DF0690230},LastUsedSource=C:\Temp\)
MSI (c) (63:E3): Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (63:E3): Specifed source is already in a list.
MSI (c) (63:E3): User policy value 'SearchOrder' is 'nmu'
MSI (c) (63:E3): Machine policy value 'DisableBrowse' is 0
MSI (c) (63:E3): Machine policy value 'AllowLockdownBrowse' is 0
MSI (c) (63:E3): Adding new sources is allowed.
MSI (c) (63:E3): Set LastUsedSource to: C:\Temp\.
MSI (c) (63:E3): Set LastUsedType to: n.
MSI (c) (63:E3): Set LastUsedIndex to: 1.
MSI (c) (63:E3): Executing op:
End(Checksum=0,ProgressTotal=28708301)
MSI (c) (63:E3): FEATURECACHE: Entering Invalidate
MSI (c) (63:E3): User policy value 'DisableRollback' is 0
MSI (c) (63:E3): Machine policy value 'DisableRollback' is 0
Action 08:30:43: RollbackCleanup. Removing backup files
MSI (c) (63:E3): Unlocking Server
Action ended 08:30:43: InstallFinalize. Return value 1.
MSI (c) (63:E3): Skipping action: CompilePyc (condition is
false)
MSI (c) (63:E3): Skipping action: CompilePyo (condition is
false)
Action ended 08:30:43: INSTALL. Return value 1.
MSI (c) (63:E3): Decrementing counter to disable shutdown.
If counter >= 0, shutdown will be denied.  Counter after
decrement: -1
Action ended 08:30:43: ExecuteAction. Return value 1.
MSI (c) (63:E3): Doing action: ExitDialog
Action start 08:30:43: ExitDialog.
Action 08:30:43: ExitDialog. Dialog created
Action ended 08:30:45: ExitDialog. Return value 1.
Action ended 08:30:45: INSTALL. Return value 1.

</snip>

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:37

Message:
Logged In: YES 
user_id=1237039

Uninstalled, rebooted and reinstalled using

c:\windows\system\msiexec /i python-2.4.1c1.msi /l*v python.log

The log file (1.1MB) is available, probably too big to
cut/paste into here. I can email it to you if you like.
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 22:39

Message:
Logged In: YES 
user_id=21627

Somebody suggested in the newsgroup to request a log file; I
should have thought of this earlier.

So please reinstall the MSI file, using

msiexec /i python-2.4.1c1.msi /l*v python.log

and attach the resulting python.log to this report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 22:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 18:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 13:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 10:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 15:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 14:22:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 14:22:07 2005
Subject: [ python-Bugs-672115 ] Assignment to __bases__ of direct object
	subclasses
Message-ID: <E1DBYTN-0001Pn-DQ@sc8-sf-web4.sourceforge.net>

Bugs item #672115, was opened at 2003-01-21 22:45
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Assignment to __bases__ of direct object subclasses

Initial Comment:
I'm not entirely sure this is a bug, but I think it is 
surprising:

Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC 
v.1200 32 bit (Intel)] on win32
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more 
information.
&gt;&gt;&gt; class A(object):
...     pass
...
&gt;&gt;&gt; class B(object):
...     pass
...
&gt;&gt;&gt; B.__bases__ = (A,)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
TypeError: __bases__ assignment: 'A' deallocator differs 
from 'object'

It seems like you should be able to change the 
__bases__ of a new-style class (implemented in 
Python) which inherits directly from object to another 
new-style class.  (Will the deallocator issue ever come 
into play if the only types involved are HEAPTYPES and 
object as the ultimate base?)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-16 13:22

Message:
Logged In: YES 
user_id=6656

Two years on, I think about this again.  Still here? :)

The motivating thought is that:

class A(object): pass
class B(object): pass
B.__bases__ = (A,)

and 

class A(object): pass
class B(A): pass

should be equivalent.

An issue that hadn't occurred to me before is that in the first example both 
A and B have a __dict__ (and __weakref__) descriptor, and in the second 
B doesn't.  Should B's __dict__ descriptor be removed on the 
__bases__ assignment?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-02-05 14:22

Message:
Logged In: YES 
user_id=6656

Mhmm.  That looks OK to me (after realizing that solid_base
worries about __slots__).

But I don't know how one can be sure :-(

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 02:39

Message:
Logged In: YES 
user_id=86307

Well, I wrote a small patch which I'm attaching.  However, I 
can't say that I'm partcularly confident in it.  It works for the 
simple cases I've  been able to think of (and for 
test_descr.py), but looking at typeobject.c, I get the nagging 
feeling that a lot more tests are required to be sure it's OK.  
The problem is, I'm just not sure what they (the tests) are.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-31 18:09

Message:
Logged In: YES 
user_id=6656

Are you interested in working up a patch for this?  Hacking
this kind of stuff requires motivation I'm not sure I can
drum up in time for 2.3...

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-01-23 17:03

Message:
Logged In: YES 
user_id=86307

Sorry about the parenthetical comment; I think what I was trying 
to say is basically what you have in your last paragraph.

As for use cases, I don't have any myself (I ran into this with 
some test code for a metaclass which &quot;overrides&quot; __bases__).  
However, grepping through the standard library, I note that one 
place where assignment to __bases__ is used is in 
xmlrpclib.SlowParser.  It appears to me that if SlowParser and 
xmllib.XMLParser (neither of which has a base class) were 
converted to new-style classes, the assignment to __bases__ 
would generate this exception.  Of course, that shouldn't be too 
hard to work around if that turns out to be necessary.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-22 11:50

Message:
Logged In: YES 
user_id=6656

I agree this is a bit surprising.  When I was writing this
code I went for the conservative-as-possible approach as I
didn't want to introduce instabilities to Python.

It certainly may be that I've overdone it.  In this case I
probably have; if the tp_dealloc of the class being adjusted
is subtype_dealloc and the tp_dealloc that ultimately gets
invoked is the same we're probably OK.  But I'm not sure and
it's been a while since I thought about this.

It also happens that my motivating use-case for this isn't
troubled by this restriction.

I don't understand your last, parenthetical, comment. 
HEAPTYPES as such doesn't come into it, does it?  

You might be right that we don't need to worry about
tp_dealloc if the ultimate solid_base doesn't change and all
the tp_deallocs on the way there are subtype_dealloc...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 18:07:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 18:07:40 2005
Subject: [ python-Bugs-1163401 ] uncaught AttributeError deep in urllib
Message-ID: <E1DBbzc-00064R-TW@sc8-sf-web2.sourceforge.net>

Bugs item #1163401, was opened at 2005-03-14 16:39
Message generated for change (Comment added) made by lohnk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: K Lars Lohn (lohnk)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncaught AttributeError deep in urllib

Initial Comment:
Python 2.4 and Python 2.3.4 running under Suse 9.2

We're getting an AttributeError exception "AttributeError: 'NoneType' object has no attribute 'read'" within a very simple call to urllib.urlopen.

This was discovered while working on Sentry 2, the new mirror integrity checker for the Mozilla project.  We try to touch hundreds of URLs to make sure that the files are present on each of the mirrors.  One particular URL kills the call to urllib.urlopen: http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe
This file probably does not exist on the mirror, however, in other cases of bad URLs, we get much more graceful failures when we try to read from the object returned by urllib.urlopen.

>>> import urllib
>>> urlReader = urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.4/urllib.py", line 180, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__
    addbase.__init__(self, fp)
  File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__
    self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'

The  attached file is a three line scipt that demos the problem.



----------------------------------------------------------------------

>Comment By: K Lars Lohn (lohnk)
Date: 2005-03-16 09:07

Message:
Logged In: YES 
user_id=1239273

I've changed over to urllib2. The only complication involved the exception handling model: urllib2's HTTPError exceptions cannot be pickled because they contain an open socket._fileobject.  While mildly inconvenient, the workaround was not difficult.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-03-15 11:09

Message:
Logged In: YES 
user_id=44345


Looking through the code I believe I traced the problem back
to httplib.HTTP which sets self.fp to None when it's closed.
It seems that urllib is trying to access this object after
the connection's been closed.

I realize the problem has passed for the moment, but have you 
considered using urllib2?  The urllib library still uses
httplib.HTTP
which is really only there for backward compatibility.  From
this end it would be nice to leave urllib and httplib.HTTP
alone.
New apps should probably use urllib2 which uses the newer
httplib.HTTPConnection class.


----------------------------------------------------------------------

Comment By: K Lars Lohn (lohnk)
Date: 2005-03-15 08:50

Message:
Logged In: YES 
user_id=1239273

This problem is apparently transient depending on network conditions or, perhaps, the configuration of the server end.  On 3/14 the problem has mysteriously vanished....

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-15 01:52

Message:
Logged In: YES 
user_id=92222

No such error on Windows:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit
(Intel)] on win32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 18:07:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 18:07:55 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DBbzr-0003d0-Hg@sc8-sf-web1.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-16 17: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=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 18:11:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 18:12:01 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DBc3o-0003pt-PJ@sc8-sf-web1.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-16 17:07
Message generated for change (Comment added) made by brenck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

>Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-16 17:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 20:34:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 20:34:23 2005
Subject: [ python-Bugs-1164726 ] UserDict is not iterable
Message-ID: <E1DBeHY-00036X-4D@sc8-sf-web4.sourceforge.net>

Bugs item #1164726, was opened at 2005-03-16 19:34
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=1164726&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: UserDict is not iterable

Initial Comment:
UserDict does not directly support iteration:

>>> import UserDict
>>> ud = UserDict.UserDict()
>>> ud['a'] = 1
>>> [k for k in ud]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\lib\UserDict.py", line 17, in
__getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 0

The fix is to define __iter__ = iterkeys:
>>> class UD(UserDict.UserDict):
...   __iter__ = UserDict.UserDict.iterkeys
...
>>> ud = UD()
>>> ud['a'] = 1
>>> [k for k in ud]
['a']

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164726&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 20:55:09 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 20:55:13 2005
Subject: [ python-Bugs-1164742 ] Tkdnd.py crashes due to read-only attributes
Message-ID: <E1DBebl-0003Xk-JU@sc8-sf-web1.sourceforge.net>

Bugs item #1164742, was opened at 2005-03-16 19:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164742&group_id=5470

Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: tynods (tynods)
Assigned to: Martin v. L?wis (loewis)
Summary: Tkdnd.py crashes due to read-only attributes

Initial Comment:
When running Tkdnd.py, it crashes :

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python24\Lib\lib-tk\Tkinter.py", line 1345,
in __call__
    return self.func(*args)
  File "C:\Python24\Lib\lib-tk\Tkdnd.py", line 179, in
on_release
    self.finish(event, 1)
  File "C:\Python24\Lib\lib-tk\Tkdnd.py", line 190, in
finish
    del root.__dnd
  File "C:\Python24\Lib\lib-tk\Tkinter.py", line 1653,
in __delattr__
    return delattr(self.tk, attr)
TypeError: 'tkapp' object has only read-only attributes
(del ._DndHandler__dnd)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164742&group_id=5470
From noreply at sourceforge.net  Wed Mar 16 21:24:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 16 21:24:43 2005
Subject: [ python-Bugs-1164726 ] UserDict is not iterable
Message-ID: <E1DBf4K-0001aN-RR@sc8-sf-web3.sourceforge.net>

Bugs item #1164726, was opened at 2005-03-16 14:34
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164726&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: UserDict is not iterable

Initial Comment:
UserDict does not directly support iteration:

>>> import UserDict
>>> ud = UserDict.UserDict()
>>> ud['a'] = 1
>>> [k for k in ud]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\lib\UserDict.py", line 17, in
__getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 0

The fix is to define __iter__ = iterkeys:
>>> class UD(UserDict.UserDict):
...   __iter__ = UserDict.UserDict.iterkeys
...
>>> ud = UD()
>>> ud['a'] = 1
>>> [k for k in ud]
['a']

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-16 15:24

Message:
Logged In: YES 
user_id=80475

This could not be done for reasons of backwards compatability.

To get what you want, use UserDict.IterableUserDict.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164726&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 01:27:33 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 01:27:35 2005
Subject: [ python-Bugs-1164912 ] xmlrpclib.DateTime.decode() should
	stringify argument
Message-ID: <E1DBirN-0007Rx-Fy@sc8-sf-web4.sourceforge.net>

Bugs item #1164912, was opened at 2005-03-16 16:27
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=1164912&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Saddi (asaddi)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib.DateTime.decode() should stringify argument

Initial Comment:
DateTime.decode() is allowing unicode strings to be assigned to 
self.value.

Python 2.4 (#2, Feb 17 2005, 09:44:14) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> from xmlrpclib import *
>>> s = loads(dumps((DateTime(),), methodresponse=True))
>>> print s
((<DateTime u'20050316T16:10:20' at 81ca38c>,), None)

When this DateTime object with unicode value is subsequently 
passed to dumps(), dumps() will either return the result as a unicode 
string (which I don't believe is the correct behavior), or it will raise a 
UnicodeDecodeError.

>>> dumps(s[0])
u'<params>\n<param>\n<value><dateTime.iso8601>20050316T16:
10:20</dateTime.iso8601></value>\n</param>\n</params>\n'

(UnicodeDecodeError is raised when marshalling other unicode 
strings that do not have a simple ascii representation with the 
resultant DateTime.)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164912&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 03:38:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 03:38:19 2005
Subject: [ python-Bugs-1164953 ] logging.basicConfig creates phantom handler
Message-ID: <E1DBktt-0007UA-IV@sc8-sf-web3.sourceforge.net>

Bugs item #1164953, was opened at 2005-03-16 20:38
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=1164953&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging.basicConfig creates phantom handler

Initial Comment:
calling logging.basicConfig() creates a phantom handler 
that doesn't operate in an intuitive way.  A reproducable 
follows.

My actual use case:  I started off using the logging 
module on a project with the builting logging.info(), 
logging.debug(), logging.error() functions.  As my needs 
got more sophisticated, I started creating some loggers 
via logging.getLogger('a.b.c')  I setup a custom handler 
to do formatting without printing "INFO:a.b.c" headers.  
One of my import statements triggered a call to 
logging.basicConfig.  Halfway through the running 
program, my logging messages started showing up 
twice.  Once without the header and once with.  I 
eventually tracked this down to usage of a logging.info() 
statement.  I tried explicitly calling logging.basicConfig
(level=logging.ERROR) to disable the duplicate errors, 
but that didn't work.

A trivial patch is attached.  It fixes the problem if you 
explicitly call logging.basicConfig.  I don't know if it will 
fix the implicit calls by logging.info(), etc.

C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import logging
>>>
>>> logger = logging.getLogger('foo')
>>> logger.setLevel(logging.INFO)
>>> logger.info('bar') # no output yet
No handlers could be found for logger "foo"
>>>
>>> console = logging.StreamHandler()
>>> console.setLevel(logging.INFO)
>>> console.setFormatter(logging.Formatter("%
(message)s")
... )
>>> logger.addHandler(console)
>>>
>>> logger.info('foo')
foo
>>>
>>> logger.warning('foo')
foo
>>>
>>> logger.debug('foo')
>>>
>>> logger.info('foo')
foo
>>>
>>> logging.basicConfig(level=logging.ERROR)
>>>
>>> logger.info('foo')
foo
INFO:foo:foo
>>> ^Z


C:\Python24>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 03:39:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 03:39:55 2005
Subject: [ python-Bugs-1164953 ] logging.basicConfig creates phantom handler
Message-ID: <E1DBkvP-0002pM-IP@sc8-sf-web4.sourceforge.net>

Bugs item #1164953, was opened at 2005-03-16 20:38
Message generated for change (Settings changed) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging.basicConfig creates phantom handler

Initial Comment:
calling logging.basicConfig() creates a phantom handler 
that doesn't operate in an intuitive way.  A reproducable 
follows.

My actual use case:  I started off using the logging 
module on a project with the builting logging.info(), 
logging.debug(), logging.error() functions.  As my needs 
got more sophisticated, I started creating some loggers 
via logging.getLogger('a.b.c')  I setup a custom handler 
to do formatting without printing "INFO:a.b.c" headers.  
One of my import statements triggered a call to 
logging.basicConfig.  Halfway through the running 
program, my logging messages started showing up 
twice.  Once without the header and once with.  I 
eventually tracked this down to usage of a logging.info() 
statement.  I tried explicitly calling logging.basicConfig
(level=logging.ERROR) to disable the duplicate errors, 
but that didn't work.

A trivial patch is attached.  It fixes the problem if you 
explicitly call logging.basicConfig.  I don't know if it will 
fix the implicit calls by logging.info(), etc.

C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import logging
>>>
>>> logger = logging.getLogger('foo')
>>> logger.setLevel(logging.INFO)
>>> logger.info('bar') # no output yet
No handlers could be found for logger "foo"
>>>
>>> console = logging.StreamHandler()
>>> console.setLevel(logging.INFO)
>>> console.setFormatter(logging.Formatter("%
(message)s")
... )
>>> logger.addHandler(console)
>>>
>>> logger.info('foo')
foo
>>>
>>> logger.warning('foo')
foo
>>>
>>> logger.debug('foo')
>>>
>>> logger.info('foo')
foo
>>>
>>> logging.basicConfig(level=logging.ERROR)
>>>
>>> logger.info('foo')
foo
INFO:foo:foo
>>> ^Z


C:\Python24>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 10:20:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 10:20:11 2005
Subject: [ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron)
Message-ID: <E1DBrAj-0004hQ-2A@sc8-sf-web3.sourceforge.net>

Bugs item #1066546, was opened at 2004-11-15 11:34
Message generated for change (Comment added) made by tebeka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pwd fails on 64bit system (Opteron)

Initial Comment:
test test_pwd failed -- Traceback (most recent call last):
  File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py",
line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum


$ cat /proc/version 
Linux version 2.4.21-20.ELsmp
(bhcompile@dolly.build.redhat.com) (gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18
20:34:58 EDT 2004

Processor is AMD Opteron 2.4MHz

----------------------------------------------------------------------

>Comment By: Miki Tebeka (tebeka)
Date: 2005-03-17 11:20

Message:
Logged In: YES 
user_id=358087

I've tried the patch - no luck :-(

I'm stealing time on these machines since they belong to
another group.
However I see that SF's compile farm
(http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
have an AMD64 host (amd64-linux1)
Maybe you can shorten the loop ...

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-15 00:17

Message:
Logged In: YES 
user_id=89016

On a 32bit system adding the line
nobody:x:4294967294:65534:nobody:/:/bin/false
to /etc/passwd pwd.getpwall() gives me an entry:
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
and
pwd.getpwuid(-2)
gives me
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')

Maybe for 64bit systems the SETI macro should use
PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can
you try the following patch?

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-11-17 10:43

Message:
Logged In: YES 
user_id=358087

1. How do I find the largest user id?
2. It's 4294967294
3. Can't attach etc/password since it's a company machine
(IT will kill me :-)
    However there is a similar line for nobody with 65534

The hardware is 4 CPU with 16GB of memory.
OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-11-17 03:58

Message:
Logged In: YES 
user_id=33168

I just tested this on an opteron and it ran ok, so this
problem isn't necessarily opteron/64-bit specific.  What is
the largest user id on the system?  What is the value of
pw_uid that is causing a problem?  Can you attach your
/etc/passwd file?  If so, you may want to change any user info.

I have:
  nobody:x:65534:65534:nobody:/:/bin/false

I tried adding another nobody with a larger uid, but did not
have any problems with the test.  This is on a gentoo system.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-11-15 11:36

Message:
Logged In: YES 
user_id=358087

Ran with -v:
$ ./python Lib/test/test_pwd.py -v
test_errors (__main__.PwdTest) ... ok
test_values (__main__.PwdTest) ... ERROR

======================================================================
ERROR: test_values (__main__.PwdTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_pwd.py", line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum

----------------------------------------------------------------------
Ran 2 tests in 0.480s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_pwd.py", line 92, in ?
    test_main()
  File "Lib/test/test_pwd.py", line 89, in test_main
    test_support.run_unittest(PwdTest)
  File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 290, in run_unitt                                     
       est
    run_suite(suite, testclass)
  File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 275, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_pwd.py", line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 11:52:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 11:52:26 2005
Subject: [ python-Bugs-1164953 ] logging.basicConfig creates phantom handler
Message-ID: <E1DBsc3-0004cc-T6@sc8-sf-web4.sourceforge.net>

Bugs item #1164953, was opened at 2005-03-17 02:38
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.basicConfig creates phantom handler

Initial Comment:
calling logging.basicConfig() creates a phantom handler 
that doesn't operate in an intuitive way.  A reproducable 
follows.

My actual use case:  I started off using the logging 
module on a project with the builting logging.info(), 
logging.debug(), logging.error() functions.  As my needs 
got more sophisticated, I started creating some loggers 
via logging.getLogger('a.b.c')  I setup a custom handler 
to do formatting without printing "INFO:a.b.c" headers.  
One of my import statements triggered a call to 
logging.basicConfig.  Halfway through the running 
program, my logging messages started showing up 
twice.  Once without the header and once with.  I 
eventually tracked this down to usage of a logging.info() 
statement.  I tried explicitly calling logging.basicConfig
(level=logging.ERROR) to disable the duplicate errors, 
but that didn't work.

A trivial patch is attached.  It fixes the problem if you 
explicitly call logging.basicConfig.  I don't know if it will 
fix the implicit calls by logging.info(), etc.

C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import logging
>>>
>>> logger = logging.getLogger('foo')
>>> logger.setLevel(logging.INFO)
>>> logger.info('bar') # no output yet
No handlers could be found for logger "foo"
>>>
>>> console = logging.StreamHandler()
>>> console.setLevel(logging.INFO)
>>> console.setFormatter(logging.Formatter("%
(message)s")
... )
>>> logger.addHandler(console)
>>>
>>> logger.info('foo')
foo
>>>
>>> logger.warning('foo')
foo
>>>
>>> logger.debug('foo')
>>>
>>> logger.info('foo')
foo
>>>
>>> logging.basicConfig(level=logging.ERROR)
>>>
>>> logger.info('foo')
foo
INFO:foo:foo
>>> ^Z


C:\Python24>

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2005-03-17 10:52

Message:
Logged In: YES 
user_id=308438

Thanks for the feedback, but it's not a bug. Check the 
docstring for basicConfig: "This function does nothing if the 
root logger already has handlers configured. It is a 
convenience method intended for use by simple scripts to do 
one-shot configuration of the logging package. The default 
behaviour is to create a StreamHandler which writes to 
sys.stderr, set a formatter using the BASIC_FORMAT format 
string, and add the handler to the root logger."

The logging.debug(), etc. methods are for simple use of the 
logging package. If you are using named loggers, then don't 
use basicConfig() except to configure a handler at the root 
level - and do this early in your application. Thereafter you 
can log to the root logger (using logging.debug() and its 
brethren) or to a named logger which has no handlers set (the 
root's handlers will be used).

If you add a console handler manually to logger "foo" and 
then add another one to the root handler via basicConfig(), 
then both handlers will be called (correctly). This is what you 
are seeing.

Your fix (add the level to the handler as well) does not fit the 
contract of basicConfig(). Users working in simple mode will 
just use the logger's level. Setting levels in the handler is for 
more sophisticated use of the logging package than implied 
by use of basicConfig() and logging.debug(), etc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 11:53:38 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 11:53:41 2005
Subject: [ python-Bugs-932563 ] logging: need a way to discard Logger objects
Message-ID: <E1DBsdG-0004ex-MQ@sc8-sf-web4.sourceforge.net>

Bugs item #932563, was opened at 2004-04-09 21:51
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=932563&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: logging: need a way to discard Logger objects

Initial Comment:
There needs to be a way to tell the logging package
that an application is done with a particular logger
object.  This is important for long-running processes
that want to use a logger to represent a related set of
activities over a relatively short period of time
(compared to the life of the process).

This is useful to allow creating per-connection loggers
for internet servers, for example.  Using a
connection-specific logger allows the application to
provide an identifier for the session that can be
automatically included in the logs without having the
application encode it into each message (a far more
error prone approach).


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2005-03-17 10:53

Message:
Logged In: YES 
user_id=308438

Hi Fred,

Any update on this? If you haven't the time (which I quite
understand), please post the code which does the Right Thing
(or mail it to me) without an explanation, and I'll try to
understand it.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-09-22 13:43

Message:
Logged In: YES 
user_id=308438

Hi Fred,

Any update on this? If you haven't the time (which I quite
understand), please post the code which does the Right Thing
(or mail it to me) without an explanation, and I'll try to
understand it.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-01 03:53

Message:
Logged In: YES 
user_id=3066

Vinay:  I don't think that will work.  Another issue that
crops up once I start looking into the Logger class is that
findCaller() won't do (what I think is) the Right Thing when
wrappers and subclasses are involved.

After reviewing my application, I think the only thing the
application really needs to control is the creation of the
record objects, but that has to happen on the wrapper, or
there's no way to get the necessary information into the
record (without seriously performing surgery on the
underlying logger).

I think I've come up with a base class that does the Right
Thing, but I need to write up an explanation of why it works
the way it does.  It's not massively mysterious, but does
end up dealing with more than I really like worrying about.
 I don't have any more time for this tonight, but will write
up what I have and post it here in the next few days.

It shouldn't be hard to refactor what's in logging.Logger
and my base class to share most of the code.  Having the
base class in the logging package would avoid having to use
a separate findCaller() implementation.

Boosting the priority to make sure this stays on my radar.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-29 22:10

Message:
Logged In: YES 
user_id=308438

I just had a further thought: is the approach below any good 
to you? Apart from not being able to use the root logger, it 
seems to meet your need.

import logging

class MyLogger(logging.Logger):
  def makeRecord(self, name, level, fn, lno, msg, args, 
exc_info):
    record = logging.Logger.makeRecord(self, name, level, fn, 
lno, msg, args, exc_info)
    record.magicnumber = 0xDECAFBAD    # special number
    return record

logging._loggerClass = MyLogger

h = logging.StreamHandler()
logger = logging.getLogger("mylogger")
h.setFormatter(logging.Formatter("%(asctime)s %(levelname)
s %(magicnumber)X %(message)s"))
logger.addHandler(h)
logger.warn("There's a custom attribute in my message!")


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-24 15:28

Message:
Logged In: YES 
user_id=308438

Suppose I add a callable "recordMaker" to logging, and modify 
makeRecord() to call it with logger + the args passed to 
makeRecord(). If it's necessary to add extra attrs to the 
LogRecord, this can be done by replacing recordMaker with 
your own callable. Seems less icky - what do you think? If 
you think it'll fly, are there any other args you think I need to 
pass into the callable?

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-06-24 14:06

Message:
Logged In: YES 
user_id=3066

I've attached a file showing the class I came up with.  I
don't consider this to be a good wrapper, just what worked.

I think one of the problems is that what I really want to
override is the makeRecord() method, not the logging methods
themselves.  There's too much logic in those dealing with
the disabling and level filtering that I don't want to
duplicate, but as soon as I pass the calls on to the
underlying logger, I can no longer change the makeRecord().

It would be possible to inject a new makeRecord() while my
methods are active (in my definition for log() in the
sample), and restore the original in a finally clause, but
that feels... icky.

The advantage of overriding makeRecord() is that formatter
can deal with with how the additional information is added
to the log because more information is made available on the
record.


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-24 10:58

Message:
Logged In: YES 
user_id=308438

How about if I add a LoggerAdapter class which takes a 
logger in the __init__ and has logging methods debug(), info() 
etc. [and including _log()] which delegate to the underlying 
logger? Then you could subclass the Adapter and just 
override the methods you needed. Would that fit the bill? Of 
course the package can use a Logger-derived class, but this 
would apply to all loggers where the LoggerAdapter could be 
used for just some of the loggers in a system.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-06-24 04:13

Message:
Logged In: YES 
user_id=3066

Looking at this again, after adjusting the application I
have that used the connection-specific loggers, I decided
that a different approach better solves the problem.

What you've shown requires exactly what I wanted to avoid:
having to make a gesture at each logging call (to transform
the message).  Instead of doing this, I ended up writing a
wrapper for the logger objects that implement the methods
log(), debug(), info(), warn(), warning(), error(),
exception(), critical(), and fatal().  These methods each
transform the message before calling the underlying logger.

It would be really nice to have something like this that
isolates the final call to Logger._log() so specific
implementations can simply override _log() (or some other
helper routine that gets all the info) and maybe the
__init__().  I don't think that's completely necessary, but
would probably make it a lot easier to implement this pattern.

There's probably some useful documentation improvements that
could be made to help people avoid the issue of leaking loggers.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-06-10 16:50

Message:
Logged In: YES 
user_id=3066

Sorry for the delay in following up.

I'll re-visit the software where I wanted this to see how
it'll work out in practice.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-09 16:01

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, because Vinay wants his input (in general, 
a bug should be assigned to the next person who needs 
to "do something" about it, and that can change over time).

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-09 09:28

Message:
Logged In: YES 
user_id=308438

Fred, any more thoughts on this? Thanks, Vinay

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-05-08 19:28

Message:
Logged In: YES 
user_id=308438

The problem with disposing of Logger objects 
programmatically is that you don't know who is referencing 
them. How about the following approach? I'm making no 
assumptions about the actual connection classes used; if you 
need to make it even less error prone, you can create 
delegating methods in the server class which do the 
appropriate wrapping.

class ConnectionWrapper:
	def __init__(self, conn):
		self.conn = conn
		
	def message(self, msg):
		return "[connection: %s]: %s" % 
(self.conn, msg)
		
		
and then use this like so...

class Server:

	def get_connection(self, request):
		# return the connection for this request
		
	def handle_request(self, request):
		conn = self.get_connection(request)
		# we use a cache of connection wrappers
		if conn in self.conn_cache:
			cw = self.conn_cache[conn]
		else:
			cw = ConnectionWrapper(conn)
			self.conn_cache[conn] = cw
		#process request, and if events need to 
be logged, you can e.g.
		logger.debug(cw.message("Network packet 
truncated at %d bytes"), n)
		#The logged message will contain the 
connection ID


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=932563&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 13:21:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 13:21:33 2005
Subject: [ python-Bugs-1153226 ] string interpolation breaks with %d and
	large float
Message-ID: <E1DBu0H-0005V5-6t@sc8-sf-web3.sourceforge.net>

Bugs item #1153226, was opened at 2005-02-28 05:10
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: string interpolation breaks with %d and large float

Initial Comment:
We have experienced a problem recently when wanting to
render a large float as a string. Converting the float
to an int/long manuall was required. 

'%d' % f
throws an exception for all floats f, f >= 2**31

Expected output, shown with 'int()' and 'long()':
>>> '%d %d' % (long(float(2**31)), int(float(2**31)))
'2147483648 2147483648'

Non-Working Example.
>>> '%d' % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

Tested on:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40) 
Python 2.4.1a0 (#2, Feb  9 2005, 22:42:24)

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2005-03-17 12:21

Message:
Logged In: YES 
user_id=4771

I am afraid that the same problem occurs all over the place, wherever long integers are accepted by built-in operations or functions.  Most of these places accept (and round) a float argument as well, though this is supposedly deprecated.  For example:

f = open('filename')
f.seek(999999999999)    # ok
f.seek(12.0)            # ok
f.seek(999999999999.0)  # OverflowError

Unless someone is willing to conduct a systematic review I believe it unlikely that it will get fixed, given the deprecation status.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-03-02 00:42

Message:
Logged In: YES 
user_id=44345

Sorry, I got corn-fused and misinterpreted 2**50 as 2e50.


----------------------------------------------------------------------

Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 23:53

Message:
Logged In: YES 
user_id=100823

%ld doesn't help. see the following example:

>>> "%.f" % float(2**31)
'2147483648'
>>> "%ld" % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-03-01 15:38

Message:
Logged In: YES 
user_id=44345

This is probably a corner case that got missed in the
int/long convergence.  Still, is there a reason not to use
%.f when you know you are passing a float and want to
display it with no fractional component?

>>> '%.f' % 2**50 
'1125899906842624'

or %ld if you expect the range to exceed the integer limits of
your hardware?

>>> '%ld' % 2**50
'1125899906842624'

I agree the documentation could probably be improved
in this area.


----------------------------------------------------------------------

Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 13:21

Message:
Logged In: YES 
user_id=100823

My immediate reaction is, yes. This is a bug. 

Either floats should work with %d, or they should not at
all. Having a platform dependant upper bound on the size of
the float allowed is a bug.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-03-01 06:36

Message:
Logged In: YES 
user_id=341410

Note that it will also raise a TypeError when the float f, f
< -2**31

Is this a bug?  I don't know.  I tend to not pass floats
when string interpolation is expecting integers.  Maybe the
documentation should be cleared up.

If you really want a truncated float, perhaps "%.0f" is the
format you are looking for, to save you the effort of using
int() or long().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 15:57:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 15:57:04 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DBwQo-0004S8-JL@sc8-sf-web2.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 15:56
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=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Remy Blank (remyblank)
Assigned to: Nobody/Anonymous (nobody)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 16:17:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 16:17:15 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DBwkL-0002OC-8p@sc8-sf-web4.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 14:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 6
Submitted By: Remy Blank (remyblank)
Assigned to: Nobody/Anonymous (nobody)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-17 15:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 17:44:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 17:44:59 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DBy7F-0004kB-Ed@sc8-sf-web3.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 14:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Remy Blank (remyblank)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-17 16:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test <poke> (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 15:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 17:57:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 17:57:07 2005
Subject: [ python-Feature Requests-1165404 ] ConfigParser alternative
	key-value delimitier
Message-ID: <E1DByIz-0005RP-0K@sc8-sf-web3.sourceforge.net>

Feature Requests item #1165404, was opened at 2005-03-17 19:57
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=1165404&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sergey Dorofeev (fidoman)
Assigned to: Nobody/Anonymous (nobody)
Summary: ConfigParser alternative key-value delimitier

Initial Comment:
ConfigParser is module which parses commonly used 
INI files. It gets sections from file and values from 
sections. By now, it gets from file key and value divided 
by symbol ":" or "=".

For FTN application, a want to use FTN addresses as 
keys. FTN address looks like "2:5020/12000". So if I try 
to use it as key, ConfigParser considers "2" as key 
and "5020/12000 = ..." as value. 

I made patch, which allows to use any set of symbols 
(or '=' and ':' by default for compatibility) as delimitier 
between key and value in INI file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1165404&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 18:03:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 18:03:27 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DByP6-0002t5-5H@sc8-sf-web1.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 09:56
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Remy Blank (remyblank)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 12:03

Message:
Logged In: YES 
user_id=6380

Looks like I wasn't finished with the thought when I checked
it in. I think I was trying to make instancemethod generally
useful as a currying primitive. That should probably be
considered more careful; please roll it back.

(I think it may have been part of the aborted experiment to
get rid of bound methods.)

Is there time to backport this to 2.4.1?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 11:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test <poke> (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 10:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 18:15:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 18:16:00 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DBybE-0003fO-TV@sc8-sf-web1.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 14:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Remy Blank (remyblank)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:15

Message:
Logged In: YES 
user_id=6656

Well, it's a bit more subtle than I thought:

>>> def f(): pass
... 
>>> print f.__get__(1).im_class
None

The problem occurs when *both* im_self and im_class are None; and I'm 
now reasonably convinced that calling the type object is the only way this 
can be acheived.  So a simple check along these lines in 
instancemethod_new would suffice (patch attached), and seems less likely 
to break code.

I suspect this has missed 2.4.1.

remyblank: let me guess your code wasn't doing what you thought it did? :)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 17:03

Message:
Logged In: YES 
user_id=6380

Looks like I wasn't finished with the thought when I checked
it in. I think I was trying to make instancemethod generally
useful as a currying primitive. That should probably be
considered more careful; please roll it back.

(I think it may have been part of the aborted experiment to
get rid of bound methods.)

Is there time to backport this to 2.4.1?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 16:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test <poke> (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 15:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 18:28:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 18:28:39 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DBynV-0005cC-Bb@sc8-sf-web2.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 14:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Remy Blank (remyblank)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:28

Message:
Logged In: YES 
user_id=6656

Let's attach a test case too.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:15

Message:
Logged In: YES 
user_id=6656

Well, it's a bit more subtle than I thought:

>>> def f(): pass
... 
>>> print f.__get__(1).im_class
None

The problem occurs when *both* im_self and im_class are None; and I'm 
now reasonably convinced that calling the type object is the only way this 
can be acheived.  So a simple check along these lines in 
instancemethod_new would suffice (patch attached), and seems less likely 
to break code.

I suspect this has missed 2.4.1.

remyblank: let me guess your code wasn't doing what you thought it did? :)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 17:03

Message:
Logged In: YES 
user_id=6380

Looks like I wasn't finished with the thought when I checked
it in. I think I was trying to make instancemethod generally
useful as a currying primitive. That should probably be
considered more careful; please roll it back.

(I think it may have been part of the aborted experiment to
get rid of bound methods.)

Is there time to backport this to 2.4.1?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 16:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test <poke> (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 15:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 18:46:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 18:46:51 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DBz55-0008Ab-IT@sc8-sf-web3.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-17 18:46

Message:
Logged In: YES 
user_id=21627

I'm sorry about this. Please try

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-
2.4.1c2.msi

(which you can also get from python.org when its released)

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-16 12:32

Message:
Logged In: YES 
user_id=1237039

I tried
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.ms
i

(which is only 96K) and got "the installer has encountered
an unexpected error installing this package. This may
indicate a problem with this package. The error code is 2235."

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-16 08:05

Message:
Logged In: YES 
user_id=21627

Can you please try

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.msi

and confirm that it "works"? This has the CHM shortcut
non-advertised.

As for the log file: the link creation is correct IMO; it is
no problem that the argument is missing (as the CHM file is
the target of the link, and needs no arguments). I was
curious whether an error is logged, but that appears not to
be the case.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-15 03:20

Message:
Logged In: YES 
user_id=31435

Martin, re "resiliency":  Cool -- that works!  Microsoft has too 
much spare cash <wink>.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 09:50

Message:
Logged In: YES 
user_id=1237039

I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.

Let me know if you still want the full log.

<snip>
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,,,,,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python.File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: , Value:
Python.File
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: Content Type,
Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyw,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.NoConFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: , Value:
Python.NoConFile
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: Content
Type, Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyc,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyc, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyo,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyo, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\open\command,
Name: , Value: "C:\Python24\pythonw.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\pyc.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\DefaultIcon,
Name: , Value: C:\Python24\pyc.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File, Name: ,
Value: Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python
File (no console),)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile, Name:
, Value: Python File (no console)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Compiled
Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile,
Name: , Value: Compiled Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=C:\Python24\,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath,
Name: , Value: C:\Python24MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath\InstallGroup,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python 2.4,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath\InstallGroup,
Name: , Value: Python 2.4
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\PythonPath,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\PythonPath,
Name: , Value:
C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Help\Main
Python Documentation,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Doc\Python24.chm,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Help\Main
Python Documentation, Name: , Value:
C:\Python24\Doc\Python24.chm
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Modules,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegCreateKey()
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Modules,
Name: , Value: 
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Python.exe,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe, Name: , Value: C:\Python24\Python.exe
MSI (c) (63:E3): Executing op:
ActionStart(Name=RegisterProduct,Description=Registering
product,Template=)
Action 08:30:42: RegisterProduct. Registering product
MSI (c) (63:E3): Executing op:
ChangeMedia(,MediaPrompt=Please insert the disk:
,MediaCabinet=python,BytesPerTick=0,CopierType=2,ModuleFileName=C:\WINDOWS\TEMP\147044.msi,,,,,IsFirstPhysicalMedia=1)
MSI (c) (63:E3): Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\TEMP\147044.msi,ProductCode={BE027411-8E6B-4440-A29B-B07DF0690230},CabinetStreams=python,,)
MSI (c) (63:E3): Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{BE027411-8E6B-4440-A29B-B07DF0690230}
3: 2 
MSI (c) (63:E3): Executing op:
ProductRegister(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F},VersionString=2.4.1121,,,,InstallSource=C:\Temp\,Publisher=Martin
v. L?wis,,,,,,,,,,,,EstimatedSize=147397)
RegisterProduct: {BE027411-8E6B-4440-A29B-B07DF0690230}
MSI (c) (63:E3): Executing op: ProductCPDisplayInfoRegister()
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing
Product Features,Template=Feature: )
Action 08:30:43: PublishFeatures. Publishing Product Features
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=DefaultFeature,,Absent=2,Component=j??OUe4X`@i$uC&6A2qKuw,UtgLSt9m.od.692RZ14m~@6pq]8rhPoS&X)D7,bSm,eXa{8$(h.$owxyck=FB1Y)f$9U{ur.`[,ZJ^vr!dfOU`?Ze`ysEk=JLr[E3WgU-x?t?D)z]I=*_dA7ec=)+g=.76?]FKIu1bHFqL5
t([A(1Km9_s+_'MX_[35rw5@g7u+ac`x.,%1%br~*0!9vfmt%=Y!B^1u`AX_!9d=QApJYFnOvfrlI!(GokO?JveVYQYi8f2h%NxT.ig?]b-vBu+r,'ILhl6E^-OA_^v?e$_5IhpTh,w`g.N?qf)G`5^4s@8ASKoHt8MAM`oqO+Ln^S}fQKl6}?d=Tih{Ky=Zf7'JU80OwSF?TJ(O4,B_~91aJSG40wt@5N6cU5hBP94V7`LyWD79f{p{rqL'wg%
-PF16tLs=5)f}`W9QR(r{Gc20~$^@,_d]6k9Gn?e(^7ur&kL9a'1v8~0UWrbAoRjqcwy9wcVYhIk_cjsxfZz1_]MA'bedCP7nB+)
PublishFeatures: Feature: DefaultFeature
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Extensions,Parent=DefaultFeature,Absent=2,Component=&9(xBhb)k@mF)9P]=(i!)
PublishFeatures: Feature: Extensions
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=TclTk,Parent=DefaultFeature,Absent=2,Component=,bSm,eXa{8$(h.$owxycJ=q7zM[@j9hagbp9Xn{co}9nlGPd??^awQ@CGf&0-.'yhr,K&=_3ltzeM.Qc7h^.8-d3T9)EPfCo,d-cyu_m6l_Gp8iMuR,lW[RaQ0A+uDN@U@{L}6cbw?f]i8b7_eX9o@Iy1S
X(&PF?sQlcW}I[(=ZW{-%ivt=M9q7C*M1R.=^Y)J6v,TcMap(-Gk+@a?KT*p2xdCh7XAW'KA95m89]E~`3eN^^V'z(N7]CZA^_7iztK`7eJ^xBgfwjB@Kak6MPA?DO0+@DO3n_AA*K3`@ZtQe?JI6uO%l2W@HN9(W}M~%Cv*,VbO.G[A$XLioN){*Yf.dR$)o(-A+-DXZ!lt&oGrAwx)$J(?6NoDW`@(cYdtWtQ%}-k9Xp1X(yzF}LhTMu7w[79
?OXFqcAk4XyMFpxsxPXJ9m0`},7bv575{8hzkK1!=dJ}y@IG9}`$P8eiaoR`A-VfxP}t9D6)
PublishFeatures: Feature: TclTk
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Documentation,Parent=DefaultFeature,Absent=2,Component=$iX{^*~A'@=`^v0gCm5X)
PublishFeatures: Feature: Documentation
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Tools,Parent=DefaultFeature,Absent=2,Component=GJ+9CR,Tg?JmdBV'[kOW}SK*mRvEv?G8?t0.GQYLZ]11hQx9R?w+A+ac(}(ag~YSM,m2}8,3oy-cjePH&LNCwsJs=A)aA*4Us@6vupTcf8q@f?{n?.&u+hH9)
PublishFeatures: Feature: Tools
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Testsuite,Parent=DefaultFeature,Absent=2,Component=i_BtQR~?6AGCn$H2OkjM8b9z7R7n&95PE+0LABr`iKX^Iz4rs8^Z,]haLA$!9Lg3..?M,9fQ8{GaTQ^.kJFgv&A1D?xHAqGH%u8BS1VasQ)be@`Az3s,j_3[)
PublishFeatures: Feature: Testsuite
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishProduct,Description=Publishing
product information,)
Action 08:30:43: PublishProduct. Publishing product information
MSI (c) (63:E3): Executing op:
IconCreate(Icon=python_icon.exe,Data=BinaryData)
1: python_icon.exe 
MSI (c) (63:E3): Executing op:
ProductPublish(PackageKey={1D61CFC0-C34A-4E8E-804C-CE8F6A7CE163})
1: {BE027411-8E6B-4440-A29B-B07DF0690230} 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Executing op:
UpgradeCodePublish(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F})
MSI (c) (63:E3): Executing op:
SourceListPublish(,,,,NumberOfDisks=1)
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003\SourceList
3: 2 
MSI (c) (63:E3): Executing op: ProductPublishClient(,,)
MSI (c) (63:E3): Executing op:
SourceListRegisterLastUsed(SourceProduct={BE027411-8E6B-4440-A29B-B07DF0690230},LastUsedSource=C:\Temp\)
MSI (c) (63:E3): Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (63:E3): Specifed source is already in a list.
MSI (c) (63:E3): User policy value 'SearchOrder' is 'nmu'
MSI (c) (63:E3): Machine policy value 'DisableBrowse' is 0
MSI (c) (63:E3): Machine policy value 'AllowLockdownBrowse' is 0
MSI (c) (63:E3): Adding new sources is allowed.
MSI (c) (63:E3): Set LastUsedSource to: C:\Temp\.
MSI (c) (63:E3): Set LastUsedType to: n.
MSI (c) (63:E3): Set LastUsedIndex to: 1.
MSI (c) (63:E3): Executing op:
End(Checksum=0,ProgressTotal=28708301)
MSI (c) (63:E3): FEATURECACHE: Entering Invalidate
MSI (c) (63:E3): User policy value 'DisableRollback' is 0
MSI (c) (63:E3): Machine policy value 'DisableRollback' is 0
Action 08:30:43: RollbackCleanup. Removing backup files
MSI (c) (63:E3): Unlocking Server
Action ended 08:30:43: InstallFinalize. Return value 1.
MSI (c) (63:E3): Skipping action: CompilePyc (condition is
false)
MSI (c) (63:E3): Skipping action: CompilePyo (condition is
false)
Action ended 08:30:43: INSTALL. Return value 1.
MSI (c) (63:E3): Decrementing counter to disable shutdown.
If counter >= 0, shutdown will be denied.  Counter after
decrement: -1
Action ended 08:30:43: ExecuteAction. Return value 1.
MSI (c) (63:E3): Doing action: ExitDialog
Action start 08:30:43: ExitDialog.
Action 08:30:43: ExitDialog. Dialog created
Action ended 08:30:45: ExitDialog. Return value 1.
Action ended 08:30:45: INSTALL. Return value 1.

</snip>

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 09:37

Message:
Logged In: YES 
user_id=1237039

Uninstalled, rebooted and reinstalled using

c:\windows\system\msiexec /i python-2.4.1c1.msi /l*v python.log

The log file (1.1MB) is available, probably too big to
cut/paste into here. I can email it to you if you like.
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 23:39

Message:
Logged In: YES 
user_id=21627

Somebody suggested in the newsgroup to request a log file; I
should have thought of this earlier.

So please reinstall the MSI file, using

msiexec /i python-2.4.1c1.msi /l*v python.log

and attach the resulting python.log to this report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 23:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 19:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 14:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 13:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 12:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 16:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 18:53:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 18:53:38 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DBzBc-00073f-PI@sc8-sf-web2.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 08:56
Message generated for change (Comment added) made by m_webber_sydney
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Spider (m_webber_sydney)
Date: 2005-03-17 17:53

Message:
Logged In: YES 
user_id=1237039

c2 installed ok on Win98, and the "Manuals" shortcut was
correctly built.  I didn't do any testing beyond that point.

Thanks! I guess this one can be closed.



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-17 17:46

Message:
Logged In: YES 
user_id=21627

I'm sorry about this. Please try

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-
2.4.1c2.msi

(which you can also get from python.org when its released)

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-16 11:32

Message:
Logged In: YES 
user_id=1237039

I tried
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.ms
i

(which is only 96K) and got "the installer has encountered
an unexpected error installing this package. This may
indicate a problem with this package. The error code is 2235."

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-16 07:05

Message:
Logged In: YES 
user_id=21627

Can you please try

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.msi

and confirm that it "works"? This has the CHM shortcut
non-advertised.

As for the log file: the link creation is correct IMO; it is
no problem that the argument is missing (as the CHM file is
the target of the link, and needs no arguments). I was
curious whether an error is logged, but that appears not to
be the case.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-15 02:20

Message:
Logged In: YES 
user_id=31435

Martin, re "resiliency":  Cool -- that works!  Microsoft has too 
much spare cash <wink>.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:50

Message:
Logged In: YES 
user_id=1237039

I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.

Let me know if you still want the full log.

<snip>
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,,,,,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python.File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: , Value:
Python.File
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: Content Type,
Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyw,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.NoConFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: , Value:
Python.NoConFile
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: Content
Type, Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyc,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyc, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyo,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyo, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\open\command,
Name: , Value: "C:\Python24\pythonw.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\pyc.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\DefaultIcon,
Name: , Value: C:\Python24\pyc.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File, Name: ,
Value: Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python
File (no console),)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile, Name:
, Value: Python File (no console)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Compiled
Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile,
Name: , Value: Compiled Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=C:\Python24\,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath,
Name: , Value: C:\Python24MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath\InstallGroup,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python 2.4,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath\InstallGroup,
Name: , Value: Python 2.4
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\PythonPath,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\PythonPath,
Name: , Value:
C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Help\Main
Python Documentation,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Doc\Python24.chm,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Help\Main
Python Documentation, Name: , Value:
C:\Python24\Doc\Python24.chm
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Modules,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegCreateKey()
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Modules,
Name: , Value: 
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Python.exe,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe, Name: , Value: C:\Python24\Python.exe
MSI (c) (63:E3): Executing op:
ActionStart(Name=RegisterProduct,Description=Registering
product,Template=)
Action 08:30:42: RegisterProduct. Registering product
MSI (c) (63:E3): Executing op:
ChangeMedia(,MediaPrompt=Please insert the disk:
,MediaCabinet=python,BytesPerTick=0,CopierType=2,ModuleFileName=C:\WINDOWS\TEMP\147044.msi,,,,,IsFirstPhysicalMedia=1)
MSI (c) (63:E3): Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\TEMP\147044.msi,ProductCode={BE027411-8E6B-4440-A29B-B07DF0690230},CabinetStreams=python,,)
MSI (c) (63:E3): Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{BE027411-8E6B-4440-A29B-B07DF0690230}
3: 2 
MSI (c) (63:E3): Executing op:
ProductRegister(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F},VersionString=2.4.1121,,,,InstallSource=C:\Temp\,Publisher=Martin
v. L?wis,,,,,,,,,,,,EstimatedSize=147397)
RegisterProduct: {BE027411-8E6B-4440-A29B-B07DF0690230}
MSI (c) (63:E3): Executing op: ProductCPDisplayInfoRegister()
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing
Product Features,Template=Feature: )
Action 08:30:43: PublishFeatures. Publishing Product Features
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=DefaultFeature,,Absent=2,Component=j??OUe4X`@i$uC&6A2qKuw,UtgLSt9m.od.692RZ14m~@6pq]8rhPoS&X)D7,bSm,eXa{8$(h.$owxyck=FB1Y)f$9U{ur.`[,ZJ^vr!dfOU`?Ze`ysEk=JLr[E3WgU-x?t?D)z]I=*_dA7ec=)+g=.76?]FKIu1bHFqL5
t([A(1Km9_s+_'MX_[35rw5@g7u+ac`x.,%1%br~*0!9vfmt%=Y!B^1u`AX_!9d=QApJYFnOvfrlI!(GokO?JveVYQYi8f2h%NxT.ig?]b-vBu+r,'ILhl6E^-OA_^v?e$_5IhpTh,w`g.N?qf)G`5^4s@8ASKoHt8MAM`oqO+Ln^S}fQKl6}?d=Tih{Ky=Zf7'JU80OwSF?TJ(O4,B_~91aJSG40wt@5N6cU5hBP94V7`LyWD79f{p{rqL'wg%
-PF16tLs=5)f}`W9QR(r{Gc20~$^@,_d]6k9Gn?e(^7ur&kL9a'1v8~0UWrbAoRjqcwy9wcVYhIk_cjsxfZz1_]MA'bedCP7nB+)
PublishFeatures: Feature: DefaultFeature
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Extensions,Parent=DefaultFeature,Absent=2,Component=&9(xBhb)k@mF)9P]=(i!)
PublishFeatures: Feature: Extensions
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=TclTk,Parent=DefaultFeature,Absent=2,Component=,bSm,eXa{8$(h.$owxycJ=q7zM[@j9hagbp9Xn{co}9nlGPd??^awQ@CGf&0-.'yhr,K&=_3ltzeM.Qc7h^.8-d3T9)EPfCo,d-cyu_m6l_Gp8iMuR,lW[RaQ0A+uDN@U@{L}6cbw?f]i8b7_eX9o@Iy1S
X(&PF?sQlcW}I[(=ZW{-%ivt=M9q7C*M1R.=^Y)J6v,TcMap(-Gk+@a?KT*p2xdCh7XAW'KA95m89]E~`3eN^^V'z(N7]CZA^_7iztK`7eJ^xBgfwjB@Kak6MPA?DO0+@DO3n_AA*K3`@ZtQe?JI6uO%l2W@HN9(W}M~%Cv*,VbO.G[A$XLioN){*Yf.dR$)o(-A+-DXZ!lt&oGrAwx)$J(?6NoDW`@(cYdtWtQ%}-k9Xp1X(yzF}LhTMu7w[79
?OXFqcAk4XyMFpxsxPXJ9m0`},7bv575{8hzkK1!=dJ}y@IG9}`$P8eiaoR`A-VfxP}t9D6)
PublishFeatures: Feature: TclTk
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Documentation,Parent=DefaultFeature,Absent=2,Component=$iX{^*~A'@=`^v0gCm5X)
PublishFeatures: Feature: Documentation
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Tools,Parent=DefaultFeature,Absent=2,Component=GJ+9CR,Tg?JmdBV'[kOW}SK*mRvEv?G8?t0.GQYLZ]11hQx9R?w+A+ac(}(ag~YSM,m2}8,3oy-cjePH&LNCwsJs=A)aA*4Us@6vupTcf8q@f?{n?.&u+hH9)
PublishFeatures: Feature: Tools
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Testsuite,Parent=DefaultFeature,Absent=2,Component=i_BtQR~?6AGCn$H2OkjM8b9z7R7n&95PE+0LABr`iKX^Iz4rs8^Z,]haLA$!9Lg3..?M,9fQ8{GaTQ^.kJFgv&A1D?xHAqGH%u8BS1VasQ)be@`Az3s,j_3[)
PublishFeatures: Feature: Testsuite
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishProduct,Description=Publishing
product information,)
Action 08:30:43: PublishProduct. Publishing product information
MSI (c) (63:E3): Executing op:
IconCreate(Icon=python_icon.exe,Data=BinaryData)
1: python_icon.exe 
MSI (c) (63:E3): Executing op:
ProductPublish(PackageKey={1D61CFC0-C34A-4E8E-804C-CE8F6A7CE163})
1: {BE027411-8E6B-4440-A29B-B07DF0690230} 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Executing op:
UpgradeCodePublish(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F})
MSI (c) (63:E3): Executing op:
SourceListPublish(,,,,NumberOfDisks=1)
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003\SourceList
3: 2 
MSI (c) (63:E3): Executing op: ProductPublishClient(,,)
MSI (c) (63:E3): Executing op:
SourceListRegisterLastUsed(SourceProduct={BE027411-8E6B-4440-A29B-B07DF0690230},LastUsedSource=C:\Temp\)
MSI (c) (63:E3): Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (63:E3): Specifed source is already in a list.
MSI (c) (63:E3): User policy value 'SearchOrder' is 'nmu'
MSI (c) (63:E3): Machine policy value 'DisableBrowse' is 0
MSI (c) (63:E3): Machine policy value 'AllowLockdownBrowse' is 0
MSI (c) (63:E3): Adding new sources is allowed.
MSI (c) (63:E3): Set LastUsedSource to: C:\Temp\.
MSI (c) (63:E3): Set LastUsedType to: n.
MSI (c) (63:E3): Set LastUsedIndex to: 1.
MSI (c) (63:E3): Executing op:
End(Checksum=0,ProgressTotal=28708301)
MSI (c) (63:E3): FEATURECACHE: Entering Invalidate
MSI (c) (63:E3): User policy value 'DisableRollback' is 0
MSI (c) (63:E3): Machine policy value 'DisableRollback' is 0
Action 08:30:43: RollbackCleanup. Removing backup files
MSI (c) (63:E3): Unlocking Server
Action ended 08:30:43: InstallFinalize. Return value 1.
MSI (c) (63:E3): Skipping action: CompilePyc (condition is
false)
MSI (c) (63:E3): Skipping action: CompilePyo (condition is
false)
Action ended 08:30:43: INSTALL. Return value 1.
MSI (c) (63:E3): Decrementing counter to disable shutdown.
If counter >= 0, shutdown will be denied.  Counter after
decrement: -1
Action ended 08:30:43: ExecuteAction. Return value 1.
MSI (c) (63:E3): Doing action: ExitDialog
Action start 08:30:43: ExitDialog.
Action 08:30:43: ExitDialog. Dialog created
Action ended 08:30:45: ExitDialog. Return value 1.
Action ended 08:30:45: INSTALL. Return value 1.

</snip>

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:37

Message:
Logged In: YES 
user_id=1237039

Uninstalled, rebooted and reinstalled using

c:\windows\system\msiexec /i python-2.4.1c1.msi /l*v python.log

The log file (1.1MB) is available, probably too big to
cut/paste into here. I can email it to you if you like.
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 22:39

Message:
Logged In: YES 
user_id=21627

Somebody suggested in the newsgroup to request a log file; I
should have thought of this earlier.

So please reinstall the MSI file, using

msiexec /i python-2.4.1c1.msi /l*v python.log

and attach the resulting python.log to this report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 22:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 18:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 13:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 10:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 15:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 19:43:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 19:43:45 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DBzy7-0005iA-Fb@sc8-sf-web4.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 09:56
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Remy Blank (remyblank)
>Assigned to: Michael Hudson (mwh)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 13:43

Message:
Logged In: YES 
user_id=6380

Looks OK on cursory inspection.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 12:28

Message:
Logged In: YES 
user_id=6656

Let's attach a test case too.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 12:15

Message:
Logged In: YES 
user_id=6656

Well, it's a bit more subtle than I thought:

>>> def f(): pass
... 
>>> print f.__get__(1).im_class
None

The problem occurs when *both* im_self and im_class are None; and I'm 
now reasonably convinced that calling the type object is the only way this 
can be acheived.  So a simple check along these lines in 
instancemethod_new would suffice (patch attached), and seems less likely 
to break code.

I suspect this has missed 2.4.1.

remyblank: let me guess your code wasn't doing what you thought it did? :)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 12:03

Message:
Logged In: YES 
user_id=6380

Looks like I wasn't finished with the thought when I checked
it in. I think I was trying to make instancemethod generally
useful as a currying primitive. That should probably be
considered more careful; please roll it back.

(I think it may have been part of the aborted experiment to
get rid of bound methods.)

Is there time to backport this to 2.4.1?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 11:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test <poke> (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 10:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 21:13:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 21:13:59 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DC1NT-0006tc-Sa@sc8-sf-web2.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 15:56
Message generated for change (Comment added) made by remyblank
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Remy Blank (remyblank)
Assigned to: Michael Hudson (mwh)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

>Comment By: Remy Blank (remyblank)
Date: 2005-03-17 21:13

Message:
Logged In: YES 
user_id=568100

> remyblank: let me guess your code wasn't doing what you
thought it did? :)

Err... Not sure what you mean... What would be the correct
way to do what I thought it did?

The code was largely inspired by a Cookbook entry. These are
still my first steps with decorators, and I have to admit I
don't yet fully understand why I have to create a MethodType
manually.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 19:43

Message:
Logged In: YES 
user_id=6380

Looks OK on cursory inspection.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 18:28

Message:
Logged In: YES 
user_id=6656

Let's attach a test case too.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 18:15

Message:
Logged In: YES 
user_id=6656

Well, it's a bit more subtle than I thought:

>>> def f(): pass
... 
>>> print f.__get__(1).im_class
None

The problem occurs when *both* im_self and im_class are None; and I'm 
now reasonably convinced that calling the type object is the only way this 
can be acheived.  So a simple check along these lines in 
instancemethod_new would suffice (patch attached), and seems less likely 
to break code.

I suspect this has missed 2.4.1.

remyblank: let me guess your code wasn't doing what you thought it did? :)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 18:03

Message:
Logged In: YES 
user_id=6380

Looks like I wasn't finished with the thought when I checked
it in. I think I was trying to make instancemethod generally
useful as a currying primitive. That should probably be
considered more careful; please roll it back.

(I think it may have been part of the aborted experiment to
get rid of bound methods.)

Is there time to backport this to 2.4.1?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test <poke> (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 16:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Thu Mar 17 22:37:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 17 22:37:48 2005
Subject: [ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Message-ID: <E1DC2gb-0005xs-2w@sc8-sf-web2.sourceforge.net>

Bugs item #1161187, was opened at 2005-03-11 09:56
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470

Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. L?wis (loewis)
Summary: Install problem 2.4.1rc1 on Win98

Initial Comment:
Python 2.4.1 Release Candidate 1.

I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.

The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".

This shortcut is inactive  - does not point to anything
valid, and clicking on it does not bring up the manuals.

I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.

I guess the install builds the shortcut wrongly.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-17 22:37

Message:
Logged In: YES 
user_id=21627

Thanks for the confirmation, and for the report! Closing as
fixed.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-17 18:53

Message:
Logged In: YES 
user_id=1237039

c2 installed ok on Win98, and the "Manuals" shortcut was
correctly built.  I didn't do any testing beyond that point.

Thanks! I guess this one can be closed.



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-17 18:46

Message:
Logged In: YES 
user_id=21627

I'm sorry about this. Please try

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-
2.4.1c2.msi

(which you can also get from python.org when its released)

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-16 12:32

Message:
Logged In: YES 
user_id=1237039

I tried
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.ms
i

(which is only 96K) and got "the installer has encountered
an unexpected error installing this package. This may
indicate a problem with this package. The error code is 2235."

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-16 08:05

Message:
Logged In: YES 
user_id=21627

Can you please try

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.msi

and confirm that it "works"? This has the CHM shortcut
non-advertised.

As for the log file: the link creation is correct IMO; it is
no problem that the argument is missing (as the CHM file is
the target of the link, and needs no arguments). I was
curious whether an error is logged, but that appears not to
be the case.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-15 03:20

Message:
Logged In: YES 
user_id=31435

Martin, re "resiliency":  Cool -- that works!  Microsoft has too 
much spare cash <wink>.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 09:50

Message:
Logged In: YES 
user_id=1237039

I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.

Let me know if you still want the full log.

<snip>
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Note: 1: 2360 
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,,,,,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python.File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: , Value:
Python.File
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: Content Type,
Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyw,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.NoConFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: , Value:
Python.NoConFile
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: Content
Type, Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyc,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyc, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyo,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyo, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\open\command,
Name: , Value: "C:\Python24\pythonw.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\shell\open\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\python.exe" "%1" %*,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\shell\open\command,
Name: , Value: "C:\Python24\python.exe" "%1" %*
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value="C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1",)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\shell\Edit
with IDLE\command, Name: , Value: "C:\Python24\pythonw.exe"
"C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1"
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\py.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile\DefaultIcon,
Name: , Value: C:\Python24\py.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile\DefaultIcon,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\pyc.ico,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile\DefaultIcon,
Name: , Value: C:\Python24\pyc.ico
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.File,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.File, Name: ,
Value: Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.NoConFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python
File (no console),)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.NoConFile, Name:
, Value: Python File (no console)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\Python.CompiledFile,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Compiled
Python File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\Python.CompiledFile,
Name: , Value: Compiled Python File
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=C:\Python24\,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath,
Name: , Value: C:\Python24MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\InstallPath\InstallGroup,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python 2.4,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\InstallPath\InstallGroup,
Name: , Value: Python 2.4
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\PythonPath,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\PythonPath,
Name: , Value:
C:\Python24\Lib;C:\Python24\DLLs;C:\Python24\Lib\lib-tk
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Help\Main
Python Documentation,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Doc\Python24.chm,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Help\Main
Python Documentation, Name: , Value:
C:\Python24\Doc\Python24.chm
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Python\PythonCore\2.4\Modules,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegCreateKey()
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.4\Modules,
Name: , Value: 
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=C:\Python24\Python.exe,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe, Name: , Value: C:\Python24\Python.exe
MSI (c) (63:E3): Executing op:
ActionStart(Name=RegisterProduct,Description=Registering
product,Template=)
Action 08:30:42: RegisterProduct. Registering product
MSI (c) (63:E3): Executing op:
ChangeMedia(,MediaPrompt=Please insert the disk:
,MediaCabinet=python,BytesPerTick=0,CopierType=2,ModuleFileName=C:\WINDOWS\TEMP\147044.msi,,,,,IsFirstPhysicalMedia=1)
MSI (c) (63:E3): Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\TEMP\147044.msi,ProductCode={BE027411-8E6B-4440-A29B-B07DF0690230},CabinetStreams=python,,)
MSI (c) (63:E3): Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{BE027411-8E6B-4440-A29B-B07DF0690230}
3: 2 
MSI (c) (63:E3): Executing op:
ProductRegister(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F},VersionString=2.4.1121,,,,InstallSource=C:\Temp\,Publisher=Martin
v. L?wis,,,,,,,,,,,,EstimatedSize=147397)
RegisterProduct: {BE027411-8E6B-4440-A29B-B07DF0690230}
MSI (c) (63:E3): Executing op: ProductCPDisplayInfoRegister()
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing
Product Features,Template=Feature: )
Action 08:30:43: PublishFeatures. Publishing Product Features
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=DefaultFeature,,Absent=2,Component=j??OUe4X`@i$uC&6A2qKuw,UtgLSt9m.od.692RZ14m~@6pq]8rhPoS&X)D7,bSm,eXa{8$(h.$owxyck=FB1Y)f$9U{ur.`[,ZJ^vr!dfOU`?Ze`ysEk=JLr[E3WgU-x?t?D)z]I=*_dA7ec=)+g=.76?]FKIu1bHFqL5
t([A(1Km9_s+_'MX_[35rw5@g7u+ac`x.,%1%br~*0!9vfmt%=Y!B^1u`AX_!9d=QApJYFnOvfrlI!(GokO?JveVYQYi8f2h%NxT.ig?]b-vBu+r,'ILhl6E^-OA_^v?e$_5IhpTh,w`g.N?qf)G`5^4s@8ASKoHt8MAM`oqO+Ln^S}fQKl6}?d=Tih{Ky=Zf7'JU80OwSF?TJ(O4,B_~91aJSG40wt@5N6cU5hBP94V7`LyWD79f{p{rqL'wg%
-PF16tLs=5)f}`W9QR(r{Gc20~$^@,_d]6k9Gn?e(^7ur&kL9a'1v8~0UWrbAoRjqcwy9wcVYhIk_cjsxfZz1_]MA'bedCP7nB+)
PublishFeatures: Feature: DefaultFeature
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Extensions,Parent=DefaultFeature,Absent=2,Component=&9(xBhb)k@mF)9P]=(i!)
PublishFeatures: Feature: Extensions
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=TclTk,Parent=DefaultFeature,Absent=2,Component=,bSm,eXa{8$(h.$owxycJ=q7zM[@j9hagbp9Xn{co}9nlGPd??^awQ@CGf&0-.'yhr,K&=_3ltzeM.Qc7h^.8-d3T9)EPfCo,d-cyu_m6l_Gp8iMuR,lW[RaQ0A+uDN@U@{L}6cbw?f]i8b7_eX9o@Iy1S
X(&PF?sQlcW}I[(=ZW{-%ivt=M9q7C*M1R.=^Y)J6v,TcMap(-Gk+@a?KT*p2xdCh7XAW'KA95m89]E~`3eN^^V'z(N7]CZA^_7iztK`7eJ^xBgfwjB@Kak6MPA?DO0+@DO3n_AA*K3`@ZtQe?JI6uO%l2W@HN9(W}M~%Cv*,VbO.G[A$XLioN){*Yf.dR$)o(-A+-DXZ!lt&oGrAwx)$J(?6NoDW`@(cYdtWtQ%}-k9Xp1X(yzF}LhTMu7w[79
?OXFqcAk4XyMFpxsxPXJ9m0`},7bv575{8hzkK1!=dJ}y@IG9}`$P8eiaoR`A-VfxP}t9D6)
PublishFeatures: Feature: TclTk
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Documentation,Parent=DefaultFeature,Absent=2,Component=$iX{^*~A'@=`^v0gCm5X)
PublishFeatures: Feature: Documentation
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Tools,Parent=DefaultFeature,Absent=2,Component=GJ+9CR,Tg?JmdBV'[kOW}SK*mRvEv?G8?t0.GQYLZ]11hQx9R?w+A+ac(}(ag~YSM,m2}8,3oy-cjePH&LNCwsJs=A)aA*4Us@6vupTcf8q@f?{n?.&u+hH9)
PublishFeatures: Feature: Tools
MSI (c) (63:E3): Executing op:
FeaturePublish(Feature=Testsuite,Parent=DefaultFeature,Absent=2,Component=i_BtQR~?6AGCn$H2OkjM8b9z7R7n&95PE+0LABr`iKX^Iz4rs8^Z,]haLA$!9Lg3..?M,9fQ8{GaTQ^.kJFgv&A1D?xHAqGH%u8BS1VasQ)be@`Az3s,j_3[)
PublishFeatures: Feature: Testsuite
MSI (c) (63:E3): Executing op:
ActionStart(Name=PublishProduct,Description=Publishing
product information,)
Action 08:30:43: PublishProduct. Publishing product information
MSI (c) (63:E3): Executing op:
IconCreate(Icon=python_icon.exe,Data=BinaryData)
1: python_icon.exe 
MSI (c) (63:E3): Executing op:
ProductPublish(PackageKey={1D61CFC0-C34A-4E8E-804C-CE8F6A7CE163})
1: {BE027411-8E6B-4440-A29B-B07DF0690230} 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003
3: 2 
MSI (c) (63:E3): Executing op:
UpgradeCodePublish(UpgradeCode={65E6DE48-A358-434D-AA4F-4AF72DB4718F})
MSI (c) (63:E3): Executing op:
SourceListPublish(,,,,NumberOfDisks=1)
MSI (c) (63:E3): Note: 1: 1402 2:
UNKNOWN\Installer\Products\114720EBB6E804442AB90BD70F962003\SourceList
3: 2 
MSI (c) (63:E3): Executing op: ProductPublishClient(,,)
MSI (c) (63:E3): Executing op:
SourceListRegisterLastUsed(SourceProduct={BE027411-8E6B-4440-A29B-B07DF0690230},LastUsedSource=C:\Temp\)
MSI (c) (63:E3): Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (63:E3): Specifed source is already in a list.
MSI (c) (63:E3): User policy value 'SearchOrder' is 'nmu'
MSI (c) (63:E3): Machine policy value 'DisableBrowse' is 0
MSI (c) (63:E3): Machine policy value 'AllowLockdownBrowse' is 0
MSI (c) (63:E3): Adding new sources is allowed.
MSI (c) (63:E3): Set LastUsedSource to: C:\Temp\.
MSI (c) (63:E3): Set LastUsedType to: n.
MSI (c) (63:E3): Set LastUsedIndex to: 1.
MSI (c) (63:E3): Executing op:
End(Checksum=0,ProgressTotal=28708301)
MSI (c) (63:E3): FEATURECACHE: Entering Invalidate
MSI (c) (63:E3): User policy value 'DisableRollback' is 0
MSI (c) (63:E3): Machine policy value 'DisableRollback' is 0
Action 08:30:43: RollbackCleanup. Removing backup files
MSI (c) (63:E3): Unlocking Server
Action ended 08:30:43: InstallFinalize. Return value 1.
MSI (c) (63:E3): Skipping action: CompilePyc (condition is
false)
MSI (c) (63:E3): Skipping action: CompilePyo (condition is
false)
Action ended 08:30:43: INSTALL. Return value 1.
MSI (c) (63:E3): Decrementing counter to disable shutdown.
If counter >= 0, shutdown will be denied.  Counter after
decrement: -1
Action ended 08:30:43: ExecuteAction. Return value 1.
MSI (c) (63:E3): Doing action: ExitDialog
Action start 08:30:43: ExitDialog.
Action 08:30:43: ExitDialog. Dialog created
Action ended 08:30:45: ExitDialog. Return value 1.
Action ended 08:30:45: INSTALL. Return value 1.

</snip>

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 09:37

Message:
Logged In: YES 
user_id=1237039

Uninstalled, rebooted and reinstalled using

c:\windows\system\msiexec /i python-2.4.1c1.msi /l*v python.log

The log file (1.1MB) is available, probably too big to
cut/paste into here. I can email it to you if you like.
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-13 23:39

Message:
Logged In: YES 
user_id=21627

Somebody suggested in the newsgroup to request a log file; I
should have thought of this earlier.

So please reinstall the MSI file, using

msiexec /i python-2.4.1c1.msi /l*v python.log

and attach the resulting python.log to this report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 23:25

Message:
Logged In: YES 
user_id=21627

Do the other links work fine?

If so, I'm about to give up and make the doc link
non-advertised. Before that, I'd like you to run another
experiment: The documentation has no working directory. It
should be possible to edit the shortcut to change the
working directory (this is possible on XP atleast), please
try setting it to c:\python24\docs (or whereever the chm is
located).

tim_one: right, the Tk links are also advertised (it was the
"Edit with IDLE" context menu that can't be made
advertised). That they are not editable is a magic of
Installer: They don't primarily contain the target file
name, but the package code of the MSI file, plus the key
name in the Shortcut table (or some such). To see that work,
delete python24.chm, then run the start menu item for
documentation. Microsoft calls it "resiliency"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-12 19:16

Message:
Logged In: YES 
user_id=31435

Hmm.  On my box (WinXP, etc), _all_ the shortcut property 
sheets look like this (greyed out target, disabled buttons) 
with the sole exception of "Uninstall Python".  Why they 
don't come up with editable strings and "Find Target ..." 
enabled remains a mystery then.

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 14:05

Message:
Logged In: YES 
user_id=1237039

Installer was already on the machine.
I am testing this under VMWare, by the way.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 13:13

Message:
Logged In: YES 
user_id=21627

Did you install Installer 2.0 as part of the Python
installation, or was it already on your machine? If you did
install it, did you reboot after installing it?

----------------------------------------------------------------------

Comment By: Spider (m_webber_sydney)
Date: 2005-03-12 12:59

Message:
Logged In: YES 
user_id=1237039

As requested, I uninstalled, rebooted and then installed with

C;\windows\system\msiexec.exe /i python-2.4.1c1.msi
DISABLEADVTSHORTCUTS=1

That worked, and the shortcut to the Manuals was correctly
built this time (I did not need to reboot).

Let me know if you want any further tests.

Matthew


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:16

Message:
Logged In: YES 
user_id=21627

Also, did you reboot the machine after installing the
install 2.0? According to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp

advertised shortcuts don't work until the machine is rebooted.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 12:14

Message:
Logged In: YES 
user_id=21627

m_webber_sydney, can you please also try the following
procedure, and report whether it changes anything?

- uninstall your current 2.4.1 installation
- reinstall it, using the following command in a command.com
window

msiexec /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-12 11:59

Message:
Logged In: YES 
user_id=21627

It's an "advertised shortcut" - a special OLE file  that the
shell recognizes and unpacks as a link. However, before
unpacking it, it verifies that the target file is there, and
if it isn't, it invokes invokes installer to provide the file.

According to Microsoft's documentation, installer checks
whether the IShellLink interface supports "installer
description resolution", which should be the case for W2k,
W98, and systems running IE4. If installer determines that
the system does not support advertisement, it creates an
unadvertised shortcut. So it "ought to" work on all systems.

The IDLE shortcut is unadvertised, because it is not
possible to trigger the Tkinter installation correctly.

m_webber_sydney, does the "Python (command line)" link work
correctly? It is built in the same way.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-11 16:42

Message:
Logged In: YES 
user_id=31435

Assigning to Martin.  Martin, what kind of "shortcut" does the 
installer build now -- could it perhaps depend on an NTFS 
feature, like hard links?  Why I ask:

When I right-click on, e.g., "IDLE (Python GUI)" and select 
Properties in a 2.3 installation, I get "the expected" kind of 
window, with a Shortcut tab containing

C:\Python23\pythonw.exe "C:\Python23\Lib\idlelib\idle.pyw"

in the Target box, which is an editable string.  When I do the 
same with 2.4.1c1 (and don't know about 2.4 -- never tried 
this there), the Shortcut tab's Target box contains just

Python 2.4.1c1

and that's greyed out -- can't edit it.  The "Find Target .." 
and "Change Icon .." buttons are greyed out too.

It _works_ for me anyway, but I'm on WinXP + NTFS here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 04:45:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 04:46:00 2005
Subject: [ python-Bugs-853411 ] After fork in subthread, signals are blocked
Message-ID: <E1DC8Qt-0006Ze-1I@sc8-sf-web4.sourceforge.net>

Bugs item #853411, was opened at 2003-12-03 16:55
Message generated for change (Comment added) made by moculus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470

Category: Threads
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: G?ran Uddeborg (goeran)
Assigned to: Nobody/Anonymous (nobody)
Summary: After fork in subthread, signals are blocked

Initial Comment:
When a Python program starts a new thread, and this new
thread forks, the forked process ingores signals.  It
will not terminate, or dump core if that would be
applicable, when it receives a signal.

I attach a test case which illustrates the behaviour. 
In this example, the child process is sent a SEGV
signal from the subthread of the parent process.  This
should cause the child process to die and produce a
core.  But execution of the parent program threads
finishes, there is still a python process around,
continuing to sleep.

Apparently, Python subthreads blocks signals.  On
Linux, /proc/*/status for subthreads includes the line

SigBlk: ffffffff7ffbfeff

The Python documentation says one should only install
signal handlers in the main thread, and only the main
thread will recieve signals.  So this makes sense.  But
when the subthread forks, the new process inherits this
signal mask, which seems to be incorrect behaviour.  I
would assume, if Python sets this signal mask for
threads, it should also reset it again after a fork.

I've seen this on these two platforms:
Python 2.2.3 on Red Hat Linux RHEL 3WS (IA32)
Python 2.2.1 on Sun Solaris 8 (Sparc)

----------------------------------------------------------------------

Comment By: Erik Osheim (moculus)
Date: 2005-03-18 03:45

Message:
Logged In: YES 
user_id=542811

This bug is still around. I have been experiencing it
firsthand: if I write a simple program with one parent and
one child thread and run rsync in the parent thread (via
os.system), all is well. In the child thread it hangs
indefinitely.

After putting a bunch of debugging into rsync, I discovered
that a USR2 signal was getting sent but never received, and
rsyncs parent thread was waiting for the child to exit, and
that the child was sleeping (having not gotten the signal).

Is there any clue as to why this happens? This has been
widely observed on Linux 2.6.* (this particular case affects
Gentoo).


----------------------------------------------------------------------

Comment By: gmanipon (pymonger)
Date: 2004-12-06 21:24

Message:
Logged In: YES 
user_id=1173063

Sorry for the bother.

Was there any resolution to this bug report?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-01-26 10:02

Message:
Logged In: YES 
user_id=45365

I have absolutely no idea where the bug could be, someone better 
versed in the threading ideosyncracies of the various platforms 
needs to look at this, but I do want to point at hairy_flange's 
comment that fink-python 2.2.3 on OSX does *not* exhibit the bug 
(while on other platforms it does). It may be worthwhile to 
download a fink-python in source form, and see whether they do 
any configure magic.

----------------------------------------------------------------------

Comment By: Steve Muir (hairy_flange)
Date: 2004-01-26 04:04

Message:
Logged In: YES 
user_id=960132

I just submitted a bug report that is a duplicate of this bug
(apologies!), I observed the same behaviour with the Python
shipped with Mac OS X (Python 2.3), and Python 2.2.2 on
RedHat/x86, but Fink Python 2.2.3 for OS X does not have
this bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 06:18:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 06:18:08 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DC9s4-0006zQ-Vi@sc8-sf-web2.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-17 21:18
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=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 07:44:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 07:45:02 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCBEB-00032q-KV@sc8-sf-web2.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-17 21:18
Message generated for change (Comment added) made by jeffstearns
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-17 22:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 09:59:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 09:59:38 2005
Subject: [ python-Bugs-853411 ] After fork in subthread, signals are blocked
Message-ID: <E1DCDKN-0000Df-LD@sc8-sf-web4.sourceforge.net>

Bugs item #853411, was opened at 2003-12-03 16:55
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470

Category: Threads
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: G?ran Uddeborg (goeran)
Assigned to: Nobody/Anonymous (nobody)
Summary: After fork in subthread, signals are blocked

Initial Comment:
When a Python program starts a new thread, and this new
thread forks, the forked process ingores signals.  It
will not terminate, or dump core if that would be
applicable, when it receives a signal.

I attach a test case which illustrates the behaviour. 
In this example, the child process is sent a SEGV
signal from the subthread of the parent process.  This
should cause the child process to die and produce a
core.  But execution of the parent program threads
finishes, there is still a python process around,
continuing to sleep.

Apparently, Python subthreads blocks signals.  On
Linux, /proc/*/status for subthreads includes the line

SigBlk: ffffffff7ffbfeff

The Python documentation says one should only install
signal handlers in the main thread, and only the main
thread will recieve signals.  So this makes sense.  But
when the subthread forks, the new process inherits this
signal mask, which seems to be incorrect behaviour.  I
would assume, if Python sets this signal mask for
threads, it should also reset it again after a fork.

I've seen this on these two platforms:
Python 2.2.3 on Red Hat Linux RHEL 3WS (IA32)
Python 2.2.1 on Sun Solaris 8 (Sparc)

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-18 08:59

Message:
Logged In: YES 
user_id=6656

I think this should be fixed in Python 2.4.

----------------------------------------------------------------------

Comment By: Erik Osheim (moculus)
Date: 2005-03-18 03:45

Message:
Logged In: YES 
user_id=542811

This bug is still around. I have been experiencing it
firsthand: if I write a simple program with one parent and
one child thread and run rsync in the parent thread (via
os.system), all is well. In the child thread it hangs
indefinitely.

After putting a bunch of debugging into rsync, I discovered
that a USR2 signal was getting sent but never received, and
rsyncs parent thread was waiting for the child to exit, and
that the child was sleeping (having not gotten the signal).

Is there any clue as to why this happens? This has been
widely observed on Linux 2.6.* (this particular case affects
Gentoo).


----------------------------------------------------------------------

Comment By: gmanipon (pymonger)
Date: 2004-12-06 21:24

Message:
Logged In: YES 
user_id=1173063

Sorry for the bother.

Was there any resolution to this bug report?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-01-26 10:02

Message:
Logged In: YES 
user_id=45365

I have absolutely no idea where the bug could be, someone better 
versed in the threading ideosyncracies of the various platforms 
needs to look at this, but I do want to point at hairy_flange's 
comment that fink-python 2.2.3 on OSX does *not* exhibit the bug 
(while on other platforms it does). It may be worthwhile to 
download a fink-python in source form, and see whether they do 
any configure magic.

----------------------------------------------------------------------

Comment By: Steve Muir (hairy_flange)
Date: 2004-01-26 04:04

Message:
Logged In: YES 
user_id=960132

I just submitted a bug report that is a duplicate of this bug
(apologies!), I observed the same behaviour with the Python
shipped with Mac OS X (Python 2.3), and Python 2.2.2 on
RedHat/x86, but Fink Python 2.2.3 for OS X does not have
this bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 10:00:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 10:00:41 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCDLR-0000IJ-UX@sc8-sf-web4.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 10:53:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 10:53:54 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCEAx-0006Wv-Et@sc8-sf-web1.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 10:56:10 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 10:56:13 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCEDC-0006hg-Bo@sc8-sf-web1.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 11:38:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 11:38:59 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCEsZ-0001ek-Hz@sc8-sf-web2.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-16 17:07
Message generated for change (Comment added) made by brenck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

>Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 10:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-16 17:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 15:13:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 15:13:25 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCIE5-0006Qv-NQ@sc8-sf-web3.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-16 17:07
Message generated for change (Comment added) made by brenck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

>Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 14:13

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 10:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-16 17:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 15:15:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 15:15:55 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCIGV-0006bj-TE@sc8-sf-web3.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 06:18
Message generated for change (Comment added) made by zgoda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 15:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 10:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 10:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 10:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 07:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 15:41:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 15:41:33 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCIfK-0008Rb-8Z@sc8-sf-web2.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-16 17:07
Message generated for change (Comment added) made by brenck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

>Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 14:41

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 14:13

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 10:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-16 17:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 15:52:18 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 15:52:21 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCIpm-0000nJ-OL@sc8-sf-web3.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 14:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 15:53:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 15:53:34 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCIqy-0005ly-Ig@sc8-sf-web4.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 14:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 16:30:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 16:30:59 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCJRA-0003in-CN@sc8-sf-web2.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 14:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 16:43:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 16:43:40 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCJdQ-0000id-Ki@sc8-sf-web4.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 14:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 16:48:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 16:48:57 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCJiY-0004zs-LQ@sc8-sf-web2.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-16 17:07
Message generated for change (Comment added) made by brenck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

>Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 15:48

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 14:41

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 14:13

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 10:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-16 17:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 20:14:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 20:14:09 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCMv7-000499-W2@sc8-sf-web4.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-16 12:07
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-18 14:14

Message:
Logged In: YES 
user_id=764593

Yes, it is intentional.  

class Derived(Base): ...

should mean that you can use an instance of Derived 
anywhere you need an instance of Base.

There are ways to break this, but it isn't a good idea.

Letting Derived ignore part of the metaclass (and creation 
instructions) of Base would make it much easier to create an 
invalid Derived by accident -- and the error could show up as 
memory corruption, instead of something meaningful.


----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 10:48

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 09:41

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 09:13

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 05:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-16 12:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 21:18:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 21:18:44 2005
Subject: [ python-Bugs-1166206 ] SSL_pending is not used
Message-ID: <E1DCNve-0002bm-IV@sc8-sf-web3.sourceforge.net>

Bugs item #1166206, was opened at 2005-03-18 20:18
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=1166206&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: hahahhah (yawl)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL_pending is not used

Initial Comment:
I am not a Python user but use openssl a lot.
Recently I am checking implementations of non-blocking 
usage of SSL and find _ssl.c in Python.
It does a good job but I find there is an error in the code.
The problem is SSL_pending() should be called to check 
if there is data in openssl's internal buffer, otherwise a 
timeout may occur while it shouldn't.

This link explains SSL_Pending in detail:
http://www.linuxjournal.com/article/5487

And you check also check out SSL_Pending man page.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166206&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 22:38:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 22:38:57 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCPBG-00074W-Mf@sc8-sf-web1.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 00:18
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-18 16:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 10:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 10:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 09:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 04:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 04:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 04:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 01:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Fri Mar 18 23:21:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 18 23:21:23 2005
Subject: [ python-Bugs-1166274 ] missing sequence tests - pull from deque
Message-ID: <E1DCPqL-0000nu-2B@sc8-sf-web1.sourceforge.net>

Bugs item #1166274, was opened at 2005-03-18 17:21
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=1166274&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing sequence tests - pull from deque

Initial Comment:
tuples and lists can be initialized from any sequence, 
including an iterator.  This is not tested.  The iterator 
tests in test_deque would do a good job.

list_tests (for list and UserList) test_remove does not 
test that it is the _first_ occurence that gets removed.  
Again, the deque tests that Raymond just checked in 
are up to the job, if "deque" is replaced by "type2test"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166274&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 01:14:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 01:14:56 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCRcD-0004mJ-Hf@sc8-sf-web3.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-17 03:07
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 10:14

Message:
Logged In: YES 
user_id=1038590

Minimal case that should throw an exception on C3, but
doesn't (instead, it silently replaces the explicitly
requested metaclass M1 with its subclass M2):

class M1(type):
  pass

class M2(M1):
  pass

class C1(object):
  __metaclass__ = M1

class C2(C1):
  __metaclass__ = M2

class C3(C2):
  __metaclass__ = M1


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-19 05:14

Message:
Logged In: YES 
user_id=764593

Yes, it is intentional.  

class Derived(Base): ...

should mean that you can use an instance of Derived 
anywhere you need an instance of Base.

There are ways to break this, but it isn't a good idea.

Letting Derived ignore part of the metaclass (and creation 
instructions) of Base would make it much easier to create an 
invalid Derived by accident -- and the error could show up as 
memory corruption, instead of something meaningful.


----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 01:48

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 00:41

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 00:13

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 20:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-17 03:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 01:17:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 01:17:19 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCReW-0004to-GD@sc8-sf-web3.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-17 03:07
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 10:17

Message:
Logged In: YES 
user_id=1038590

To address the documentation side, the following text from
Guido's descrintro essay could be added to the official
documentation:

"""For new-style metaclasses, there is a constraint that the
chosen metaclass is equal to, or a subclass of, each of the
metaclasses of the bases. Consider a class C with two base
classes, B1 and B2. Let's say M = C.__class__, M1 =
B1.__class__, M2 = B2.__class__. Then we require
issubclass(M, M1) and issubclass(M, M2). (This is because a
method of B1 should be able to call a meta-method defined in
M1 on self.__class__, even when self is an instance of a
subclass of B1.)""" 

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 10:14

Message:
Logged In: YES 
user_id=1038590

Minimal case that should throw an exception on C3, but
doesn't (instead, it silently replaces the explicitly
requested metaclass M1 with its subclass M2):

class M1(type):
  pass

class M2(M1):
  pass

class C1(object):
  __metaclass__ = M1

class C2(C1):
  __metaclass__ = M2

class C3(C2):
  __metaclass__ = M1


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-19 05:14

Message:
Logged In: YES 
user_id=764593

Yes, it is intentional.  

class Derived(Base): ...

should mean that you can use an instance of Derived 
anywhere you need an instance of Base.

There are ways to break this, but it isn't a good idea.

Letting Derived ignore part of the metaclass (and creation 
instructions) of Base would make it much easier to create an 
invalid Derived by accident -- and the error could show up as 
memory corruption, instead of something meaningful.


----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 01:48

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 00:41

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 00:13

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 20:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-17 03:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 02:30:25 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 02:30:27 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCSnJ-0000KI-0Y@sc8-sf-web1.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-17 03:07
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 11:30

Message:
Logged In: YES 
user_id=1038590

Additional text from the descrintro essay, indicating that
it is deliberate that C3 does not trigger an exception:

"""However, if one of the base metaclasses satisfies the
constraint (including the explicitly given __metaclass__, if
any), the first base metaclass found satisfying the
constraint will be used as the metaclass."""

So, unless Guido chooses to change the desired behaviour,
these two snippets pretty much cover what needs to be added
to the docs.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 10:17

Message:
Logged In: YES 
user_id=1038590

To address the documentation side, the following text from
Guido's descrintro essay could be added to the official
documentation:

"""For new-style metaclasses, there is a constraint that the
chosen metaclass is equal to, or a subclass of, each of the
metaclasses of the bases. Consider a class C with two base
classes, B1 and B2. Let's say M = C.__class__, M1 =
B1.__class__, M2 = B2.__class__. Then we require
issubclass(M, M1) and issubclass(M, M2). (This is because a
method of B1 should be able to call a meta-method defined in
M1 on self.__class__, even when self is an instance of a
subclass of B1.)""" 

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 10:14

Message:
Logged In: YES 
user_id=1038590

Minimal case that should throw an exception on C3, but
doesn't (instead, it silently replaces the explicitly
requested metaclass M1 with its subclass M2):

class M1(type):
  pass

class M2(M1):
  pass

class C1(object):
  __metaclass__ = M1

class C2(C1):
  __metaclass__ = M2

class C3(C2):
  __metaclass__ = M1


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-19 05:14

Message:
Logged In: YES 
user_id=764593

Yes, it is intentional.  

class Derived(Base): ...

should mean that you can use an instance of Derived 
anywhere you need an instance of Base.

There are ways to break this, but it isn't a good idea.

Letting Derived ignore part of the metaclass (and creation 
instructions) of Base would make it much easier to create an 
invalid Derived by accident -- and the error could show up as 
memory corruption, instead of something meaningful.


----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 01:48

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 00:41

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 00:13

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 20:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-17 03:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 02:46:19 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 02:46:23 2005
Subject: [ python-Bugs-1108992 ] idle freezes when run over ssh
Message-ID: <E1DCT2h-0004ma-J3@sc8-sf-web4.sourceforge.net>

Bugs item #1108992, was opened at 2005-01-25 19:44
Message generated for change (Comment added) made by suzuki_hisao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Poolman (mgpoolman)
Assigned to: Nobody/Anonymous (nobody)
Summary: idle freezes when run over ssh

Initial Comment:
Python 2.3.4 (#2, Aug 13 2004, 00:36:58) 
[GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2
IDLE 1.0.3      

When running idle over an ssh link, idle freezes after
an unpredictable length of time. Over 3 days the
longest it has stayed allive for is ~4hrs, but a few
minutes before freezing is the norm. Niether idle nor
python are consuming cpu time once frozen. I can find
no definete recipie to bring about the freeze, although
(I think) there has always been at least one editor
window open when it happens. There is no output on
stderr, or other diagnostics that I can see.

ssh server(ubuntu warty):
OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL
0.9.7d 17 Mar 2004

ssh client (RH9):
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

/best/*

Mark

----------------------------------------------------------------------

Comment By: SUZUKI Hisao (suzuki_hisao)
Date: 2005-03-19 10:46

Message:
Logged In: YES 
user_id=495142

If
1) your IDLE freezes when you close an editor window 
2) which has been editing a file whose path contains a
   non-ASCII character, and
3) you do not call sys.setdefaultencoding() in your
   sitecustomize.py (so letting the default encoding to be
   'ascii'),
then 
my patch 'idlelib.diff' in Python Patch ID 1162825 
"EditorWindow's title with non-ASCII chars." 
may help you.

More precisely, IDLE freezes when updating the
"Recent Files" menu if an implicit conversion of
unicode to ASCII string occurs.  The patch fixes it.

Sorry if it is irrelevant.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-03-04 09:28

Message:
Logged In: YES 
user_id=149084

There have been recent reports on idle-dev regarding
IDLE freezing on Debian Sid.  Since ubuntu is Debian
derived, I assume there may be a relationship.

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-02-03 03:50

Message:
Logged In: YES 
user_id=993923

>0.8 doesn't have the problem.  Are you sure?

Can't be certain as haven't used it for extended periods on
that box, but I'll look into it. I've used IDLE daily for
about 4 years on various RH and Suse, and never seen a
problem until now. 

> What else is the ubuntu box doing?  Is the load heavy?
Almost nothing, it's there to evaluate ubuntu as a desktop
w/s, and my main activity is getting some in-house python
s/w ported to it.

gdb results to follow. 

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-02-03 02:21

Message:
Logged In: YES 
user_id=149084

To keep things simple, please start IDLE with the
-n switch directly on your ubuntu box for the
purposes of future investigations on this issue.

Can you attach to the frozen IDLE with gdb and then
use 'bt' to get a backtrace and find out what was
going at at the time of the freeze?  If so, is it
repeatable?  

It's occasionally reported that IDLE freezes.  I've never
seen it myself, running IDLE for many days on OpenBSD,
Debian, RH, and Arch Linux, WindowsXP, W2K, and W98,
over a period of many years, so it's hard for me to figure
out what's going on.  But it's peculiar that 0.8 doesn't have
the problem.  Are you sure?

What else is the ubuntu box doing?  Is the load heavy?

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-02-01 22:35

Message:
Logged In: YES 
user_id=993923

> So if I follow correctly,  IDLE -n freezes on your
ubuntu box without using ssh tunneling.

That is correct. The problem appears exactly the same when
run over ssh though, which, I guess rules out any
gnome/metacity/X wierdness.


> I suspect a hardware problem
I' sceptical about that. There's nothing in dmesg or
/var/log to suggest it, and absolutely no other problems
with the machine in question.

 >Are you starting IDLE from the command line
Yes, but no messages are shown.

> How much memory
255MB, IDLE uses about 3.5% of that on startup, grew to 5.7%
at time of last  crash

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-02-01 11:01

Message:
Logged In: YES 
user_id=149084

Right, there is no subprocess when you use the -n
switch.  It causes IDLE to run like IDLE 0.8.

So if I follow correctly,  IDLE -n freezes on your
ubuntu box without using ssh tunneling.  I suspect
a hardware problem with that system.

Are you starting IDLE on the ubuntu box from the
command line?  If so, are there any messages left
in the command line window?

How much memory does the ubuntu box have? 
Does 'top' show increasing memory requirement for
the IDLE -n process?

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-02-01 01:46

Message:
Logged In: YES 
user_id=993923

2 - erm forgive me for sounding stupid, but with the -n
switch I see no sub-process, only the Idle process. It still
freezes though, and killing it just kills it.

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-02-01 01:27

Message:
Logged In: YES 
user_id=993923

1 - OK It's not ssh it's ubuntu.

2 - I'll try this with ububtu.
...And by frozen, I assume ...
All Idle windows are unresponsive to screen and kbd events.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-31 15:26

Message:
Logged In: YES 
user_id=149084

Please try two things:
1. Run IDLE directly on the ubuntu machine long
enough to assure there is no problem standalone.

2. Run IDLE on the xclient but start it with the
-n switch so it runs without the subprocess.

When IDLE freezes, walk over to the server and
kill the subprocess.  It should restart itself.  Is the
system still frozen?  And by frozen, I assume you
mean all screen and keyboard events are
unresponsive.

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-01-31 05:06

Message:
Logged In: YES 
user_id=993923


Yes, I've used Idle on that (although only ~ 1 hour) and not
seen the problem there.  

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-01-31 04:43

Message:
Logged In: YES 
user_id=341410

Do you have physical access to the ubuntu warty machine, and
if so, does Idle run very well locally on that machine, not
X forwarded?

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-01-31 02:02

Message:
Logged In: YES 
user_id=993923

Yes, exactly. I'm pretty sure it's not an X/ssh/network problem,
everything else works fine (including Idle 0.8).


Mark

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-01-30 05:23

Message:
Logged In: YES 
user_id=341410

It has been a while since I ran Idle, but I am curious as to
what you mean by "run over ssh".

Do you mean that you have an SSH tunnel to a remote machine,
which forwards X-Windows sessions, and when running Idle
over this, it locks up?

----------------------------------------------------------------------

Comment By: Mark Poolman (mgpoolman)
Date: 2005-01-26 18:15

Message:
Logged In: YES 
user_id=993923

PS - You don't need an editor window open to get the freeze.

M

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 04:41:27 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 04:41:30 2005
Subject: [ python-Bugs-1166378 ] No os.spawn*p* on Windows
Message-ID: <E1DCUq7-0004m5-3s@sc8-sf-web2.sourceforge.net>

Bugs item #1166378, was opened at 2005-03-19 03:41
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=1166378&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Palmer (chris_palmer)
Assigned to: Nobody/Anonymous (nobody)
Summary: No os.spawn*p* on Windows

Initial Comment:
You have the other spawn* functions, and exec*p*, but
no spawn*p*. It exists on Linux. These functions should
either exist everywhere or nowhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 08:04:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 08:04:09 2005
Subject: [ python-Bugs-1162428 ] subprocess.Popen with copious output hangs
Message-ID: <E1DCY0E-0000w1-N0@sc8-sf-web3.sourceforge.net>

Bugs item #1162428, was opened at 2005-03-13 14:35
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162428&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: neuhauser (neuhauser)
>Assigned to: Peter ?strand (astrand)
Summary: subprocess.Popen with copious output hangs

Initial Comment:
the following script works fine with modest amount of
output from the subprocess, but hangs with 23 kB of output:

import subprocess

c = subprocess.Popen (['svnlook', 'diff',
'/home/svn/repos', '-r', '57'],
                      stdin  = subprocess.PIPE,
                      stdout = subprocess.PIPE,
                      stderr = subprocess.STDOUT)
rc = c.wait ()
lines = [line.rstrip () for line in c.stdout.readlines ()]
if rc:
    raise Exception (lines)
print lines

r57 in the above subversion repository produces a diff
of just under 23 kB, and the code hangs in:

^CTraceback (most recent call last):
  File "/home/roman/tmp/scratch15", line 9, in ?
    rc = c.wait ()
  File "/usr/local/lib/python2.4/subprocess.py", line
1018, in wait
    pid, sts = os.waitpid(self.pid, 0)
KeyboardInterrupt

this is with 2.4 built from the ports on
FreeBSD isis.sigpipe.cz 4.10-STABLE FreeBSD 4.10-STABLE
#3: Sat Aug  7 16:06:48 CEST 2004 i386


----------------------------------------------------------------------

>Comment By: Peter ?strand (astrand)
Date: 2005-03-19 08:04

Message:
Logged In: YES 
user_id=344921

This is not a subprocess bug. You must read away the data
before wait() on the process. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162428&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 08:07:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 08:08:02 2005
Subject: [ python-Bugs-1163759 ] subprocess pipe fails under Emacs
Message-ID: <E1DCY3z-0002cX-PU@sc8-sf-web2.sourceforge.net>

Bugs item #1163759, was opened at 2005-03-15 15:49
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163759&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Anders J. Munch (andersjm)
>Assigned to: Peter ?strand (astrand)
Summary: subprocess pipe fails under Emacs

Initial Comment:
Creating a pipe with subprocess.Popen fails if Python
is running in a non-interactive subshell under XEmacs
on MSWin.

This program
  import subprocess
  pipe = subprocess.Popen(['cmd', '/c', r'echo', 'Hi
there!'],
                        stdout=subprocess.PIPE)
  print pipe.stdout.read()

produces the expected "Hi there!" when run from a
console. But when run from an XEmacs non-interactive
subshell, I get this traceback:

Traceback (most recent call last):
  File "C:\temp\subprocessbug.py", line 3, in ?
    stdout=subprocess.PIPE)
  File "c:\App\Dev\Python24\lib\subprocess.py", line
545, in __init__
    (p2cread, p2cwrite,
  File "c:\App\Dev\Python24\lib\subprocess.py", line
605, in _get_handles
    p2cread = self._make_inheritable(p2cread)
  File "c:\App\Dev\Python24\lib\subprocess.py", line
646, in _make_inheritable
    DUPLICATE_SAME_ACCESS)
TypeError: an integer is required

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)]
W2K, XEmacs 21.4p13


----------------------------------------------------------------------

>Comment By: Peter ?strand (astrand)
Date: 2005-03-19 08:07

Message:
Logged In: YES 
user_id=344921

This problem has been reported on bug 1126208. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163759&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 08:14:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 08:14:49 2005
Subject: [ python-Bugs-1138653 ] subprocesss module retains older license
	header
Message-ID: <E1DCYAZ-0002Hr-81@sc8-sf-web1.sourceforge.net>

Bugs item #1138653, was opened at 2005-02-17 23:46
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tres Seaver (tseaver)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocesss module retains older license header

Initial Comment:
The header of the file seems to imply that the module
is licensed
separately from the standard Python license:


# subprocess - Subprocesses with accessible I/O streams
#
# For more information about this module, see PEP 324.
#
# Copyright (c) 2003-2004 by Peter Astrand
<astrand@lysator.liu.se>
#
# By obtaining, using, and/or copying this software
and/or its
# associated documentation, you agree that you have
read, understood,
# and will comply with the following terms and conditions:
#
# Permission to use, copy, modify, and distribute this
software and
# its associated documentation for any purpose and
without fee is
# hereby granted, provided that the above copyright
notice appears in
# all copies, and that both that copyright notice and
this permission
# notice appear in supporting documentation, and that
the name of the
# author not be used in advertising or publicity
pertaining to
# distribution of the software without specific,
written prior
# permission.
#
# THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE,
# INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS.
# IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
SPECIAL, INDIRECT OR
# CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS
# OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT,
# NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION
# WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.


----------------------------------------------------------------------

>Comment By: Peter ?strand (astrand)
Date: 2005-03-19 08:14

Message:
Logged In: YES 
user_id=344921

>Have you signed a contributor agreement yet, Peter? 

Yes. 

>You can replace the above license if you have signed the
>contributor agreement with:
>
>Copyright 2005 by Peter ?strand.
>Licensed to PSF under a Contributor Agreement

I guess this will work good when subprocess.py is
distributed with the Python distribution, but subprocess.py
is also distributed separately, as an addon to Python
2.2/2.3. In this case, it feels better to include the
license itself. 


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-04 03:45

Message:
Logged In: YES 
user_id=357491

Have you signed a contributor agreement yet, Peter?  If you have your 
code has already been relicensed to the PSF under the PSF license.  If 
you haven't you will be asked to eventually and that will retroactively 
relicense your code over to the PSF, essentially negating all of this pre-
existing license.

You can replace the above license if you have signed the contributor 
agreement with:

Copyright 2005 by Peter ?strand.
Licensed to PSF under a Contributor Agreement

Assuming I am right.  =)  You can double-check by emailing 
psf@python.org or ask at PyCon if you are attending.

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-03-03 22:22

Message:
Logged In: YES 
user_id=344921

How should the license header look like, then? Basically,
I've used xmlrpclib.py as an example. Many other modules
have no license header at all, but this might be a problem
when subprocess.py is distributed separately from Python. Or?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 11:29:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 11:29:33 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DCbD0-0008F7-VO@sc8-sf-web2.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-19 10:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

	/* Now we decref the exception classes.  After this point nothing
	   can raise an exception.  That's okay, because each Fini() method
	   below has been checked to make sure no exceptions are ever
	   raised.
	*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-18 21:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 14:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 11:32:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 11:32:54 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCbGG-0006ub-CN@sc8-sf-web3.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-16 17:07
Message generated for change (Comment added) made by brenck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

>Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 10:32

Message:
Logged In: YES 
user_id=360037

Okay, that's the point.
Thanx for your time and work - bug becomes deleted.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 01:30

Message:
Logged In: YES 
user_id=1038590

Additional text from the descrintro essay, indicating that
it is deliberate that C3 does not trigger an exception:

"""However, if one of the base metaclasses satisfies the
constraint (including the explicitly given __metaclass__, if
any), the first base metaclass found satisfying the
constraint will be used as the metaclass."""

So, unless Guido chooses to change the desired behaviour,
these two snippets pretty much cover what needs to be added
to the docs.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 00:17

Message:
Logged In: YES 
user_id=1038590

To address the documentation side, the following text from
Guido's descrintro essay could be added to the official
documentation:

"""For new-style metaclasses, there is a constraint that the
chosen metaclass is equal to, or a subclass of, each of the
metaclasses of the bases. Consider a class C with two base
classes, B1 and B2. Let's say M = C.__class__, M1 =
B1.__class__, M2 = B2.__class__. Then we require
issubclass(M, M1) and issubclass(M, M2). (This is because a
method of B1 should be able to call a meta-method defined in
M1 on self.__class__, even when self is an instance of a
subclass of B1.)""" 

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 00:14

Message:
Logged In: YES 
user_id=1038590

Minimal case that should throw an exception on C3, but
doesn't (instead, it silently replaces the explicitly
requested metaclass M1 with its subclass M2):

class M1(type):
  pass

class M2(M1):
  pass

class C1(object):
  __metaclass__ = M1

class C2(C1):
  __metaclass__ = M2

class C3(C2):
  __metaclass__ = M1


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-18 19:14

Message:
Logged In: YES 
user_id=764593

Yes, it is intentional.  

class Derived(Base): ...

should mean that you can use an instance of Derived 
anywhere you need an instance of Base.

There are ways to break this, but it isn't a good idea.

Letting Derived ignore part of the metaclass (and creation 
instructions) of Base would make it much easier to create an 
invalid Derived by accident -- and the error could show up as 
memory corruption, instead of something meaningful.


----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 15:48

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 14:41

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 14:13

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 10:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-16 17:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 15:20:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 15:20:07 2005
Subject: [ python-Bugs-1160383 ] digit-only tag values are mishandled in
	Tkinter
Message-ID: <E1DCeo6-00065b-9P@sc8-sf-web3.sourceforge.net>

Bugs item #1160383, was opened at 2005-03-09 22:32
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470

Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. L?wis (loewis)
Summary: digit-only tag values are mishandled in Tkinter

Initial Comment:
It  appears that  most Tkinter tag operations fail on
digit-only tag values

>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()       
>>> c.find_withtag("123")
()

tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm

only say this about tag values:
  "Tags are ordinary strings, and they can contain
anything except whitespace."

So this behaviour seems like a bug.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-19 08:20

Message:
Logged In: YES 
user_id=2772

This is a documentation bug.  The Tk documentation says
(canvas, section "ITEM IDS AND TAGS"):
       Each  item may also have any number of tags
associated with it.  A tag
       is just a string of characters, and it may take any
form  except  that
       of  an  integer.   For example, ??x123?? is OK but
??123?? isn?t.  The
       same tag may be associated with many different items.

Furthermore, the site www.pythonware.com is a third-party
site not run by the Python developers.  The official Python
documentation
(http://docs.python.org/lib/module-Tkinter.html and 'pydoc
Tkinter') doesn't explain the syntax of an item tag anywhere
that I could see)

I recommend closing this bug and notifying pythonware.com /
Fredrik Lundh about the problem via e-mail.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 17:28:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 17:29:00 2005
Subject: [ python-Bugs-1099324 ] Optik OptionParse important undocumented
	option
Message-ID: <E1DCgop-0004u7-Dv@sc8-sf-web1.sourceforge.net>

Bugs item #1099324, was opened at 2005-01-10 04:17
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: ncouture (nicolas_couture)
Assigned to: Greg Ward (gward)
Summary: Optik OptionParse important undocumented option

Initial Comment:
the add_help_option variable is undocumented in
Python's Library Reference, tho it can be figured by
reading the optparse module, I think it would be
usefull to document it on
http://docs.python.org/lib/optparse-generating-help.html.

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-19 11:28

Message:
Logged In: YES 
user_id=14422

Fixed in Optik svn r501.
Ported to Python CVS on 2.4 branch: Doc/lib/liboptparse.tex
rev 1.18.2.2 .

Will port to Python CVS trunk later -- post release of Optik
1.5.1.


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-10 15:57

Message:
Logged In: YES 
user_id=469548

This should probably be addressed by fixing
http://python.org/sf/993601.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 17:30:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 17:30:10 2005
Subject: [ python-Bugs-993601 ] optparse needs reference documentation
Message-ID: <E1DCgq0-00050P-8I@sc8-sf-web1.sourceforge.net>

Bugs item #993601, was opened at 2004-07-19 02:30
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Greg Ward (gward)
Summary: optparse needs reference documentation

Initial Comment:
The optparse libref documentation, while extensive, 
doesn't actually include an API reference. There's no way 
of knowing the valid parameter set of 
OptionParser.add_option() without going through the 
source. 
 
Please consider adding an API reference page for each of 
OptionParser (including OptionContainer), Values, Option 
(aka make_option) and OptionGroup. 
 

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-19 11:30

Message:
Logged In: YES 
user_id=14422

Partially addressed in Optik svn r501 (everything important
but the list of keyword args to parser.add_option() is
documented now).  More updates coming soon, I hope.

Ported to Python CVS on 2.4 branch: Doc/lib/liboptparse.tex
rev 1.18.2.2 .

Will port to Python CVS trunk later -- post release of Optik
1.5.1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 17:53:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 17:53:50 2005
Subject: [ python-Bugs-1160383 ] digit-only tag values are mishandled in
	Tkinter
Message-ID: <E1DChCq-0004pB-BP@sc8-sf-web2.sourceforge.net>

Bugs item #1160383, was opened at 2005-03-10 05:32
Message generated for change (Comment added) made by effbot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470

Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. L?wis (loewis)
Summary: digit-only tag values are mishandled in Tkinter

Initial Comment:
It  appears that  most Tkinter tag operations fail on
digit-only tag values

>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()       
>>> c.find_withtag("123")
()

tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm

only say this about tag values:
  "Tags are ordinary strings, and they can contain
anything except whitespace."

So this behaviour seems like a bug.

----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2005-03-19 17:53

Message:
Logged In: YES 
user_id=38376

Here's the text before the quoted line:

"Everywhere a method expects an item specifier, you can 
use one of the following: * item handles * tags /.../ Item 
handles are integer values that are used to identify a specific 
item on the canvas /.../ Item handles can be passed to the 
various canvas methods either as integers or as strings. /.../"

Note the use of "one of", and the fact that item handles are 
described before tags. (Writing documentation for people who 
only reads random sentences is pretty much impossible...)

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-19 15:20

Message:
Logged In: YES 
user_id=2772

This is a documentation bug.  The Tk documentation says
(canvas, section "ITEM IDS AND TAGS"):
       Each  item may also have any number of tags
associated with it.  A tag
       is just a string of characters, and it may take any
form  except  that
       of  an  integer.   For example, ??x123?? is OK but
??123?? isn?t.  The
       same tag may be associated with many different items.

Furthermore, the site www.pythonware.com is a third-party
site not run by the Python developers.  The official Python
documentation
(http://docs.python.org/lib/module-Tkinter.html and 'pydoc
Tkinter') doesn't explain the syntax of an item tag anywhere
that I could see)

I recommend closing this bug and notifying pythonware.com /
Fredrik Lundh about the problem via e-mail.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 18:05:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 18:06:01 2005
Subject: [ python-Bugs-993601 ] optparse needs reference documentation
Message-ID: <E1DChOh-0000zn-3J@sc8-sf-web4.sourceforge.net>

Bugs item #993601, was opened at 2004-07-19 02:30
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Greg Ward (gward)
Summary: optparse needs reference documentation

Initial Comment:
The optparse libref documentation, while extensive, 
doesn't actually include an API reference. There's no way 
of knowing the valid parameter set of 
OptionParser.add_option() without going through the 
source. 
 
Please consider adding an API reference page for each of 
OptionParser (including OptionContainer), Values, Option 
(aka make_option) and OptionGroup. 
 

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-19 12:05

Message:
Logged In: YES 
user_id=14422

Finished in Optik svn r502 and r503 -- now lists all option
attributes in a separate section.

Ported to Python CVS on 2.4 branch: Doc/lib/liboptparse.tex
rev 1.18.2.3.

Will port to Python CVS trunk later.

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-03-19 11:30

Message:
Logged In: YES 
user_id=14422

Partially addressed in Optik svn r501 (everything important
but the list of keyword args to parser.add_option() is
documented now).  More updates coming soon, I hope.

Ported to Python CVS on 2.4 branch: Doc/lib/liboptparse.tex
rev 1.18.2.2 .

Will port to Python CVS trunk later -- post release of Optik
1.5.1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 18:08:38 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 18:08:40 2005
Subject: [ python-Feature Requests-1073198 ] Extension to optparse: options
	with optional arguments
Message-ID: <E1DChRG-00017x-AH@sc8-sf-web4.sourceforge.net>

Feature Requests item #1073198, was opened at 2004-11-25 09:18
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: pollastri (pollastri)
Assigned to: Greg Ward (gward)
>Summary: Extension to optparse: options with optional arguments

Initial Comment:
When parsing command line options, I found very useful
to have an
option with a facultative value, able to do the following:

1-tell to me if the option was or was not seen on the
command line, return the value None if the option was
not seen;

2-if the option only was specified, return a default value.

3-if the option with a value was specified on the
command line, return the specified value;

A way to reach this goal can be the addition of a new
value for the options actions in module optparse, it
may be something like "store_with_default".





----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2005-01-05 08:19

Message:
Logged In: YES 
user_id=14422

I don't know what "facultative" means, but what you want is
optional option arguments.  Don't worry, I want that feature
too, and have even started implementing it on a branch of
the Optik source repository.  See
http://sourceforge.net/tracker/?func=detail&aid=1050431&group_id=38019&atid=421100
for a similar feature request.

I'm leaving this open, since I haven't finished anything or
merged it into the Python CVS.  It could be a few months
before there's any action here, and it certainly won't
happen before Optik 1.6 / Python 2.5.  Might require Optik
2.0, in which case I'm not certain when it'll get into Python.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 18:11:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 18:11:05 2005
Subject: [ python-Bugs-1118729 ] Error in representation of complex
	numbers(again)
Message-ID: <E1DChTZ-0005ZM-Cz@sc8-sf-web2.sourceforge.net>

Bugs item #1118729, was opened at 2005-02-09 01:26
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Martin v. L?wis (loewis)
Summary: Error in representation of complex numbers(again)

Initial Comment:
>>> -(1+0j)
(-1+-0j)

I encountered this while I was calculating conjugate of 
complex numbers(e.g. z.conjugate()).

Related bug
* http://www.python.org/sf/1013908

One thing to note is that -(0j) can return 0j or -0j 
dependeing on OSes.

Confirmed on SuSE 9.1 & cygwin.

----------------------------------------------------------------------

>Comment By: George Yoshida (quiver)
Date: 2005-03-20 02:11

Message:
Logged In: YES 
user_id=671362

Martin, what's your take on this?

The representation of '-(1+0j)' has changed since Revision 2.71
(complexobject.c) and you applied the patch.

# original patch
making Python LC_NUMERIC agnostic
  http://www.python.org/sf/774665

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2005-02-10 09:02

Message:
Logged In: YES 
user_id=671362

Hi, Bj?rn.

Sorry, not to be clear about what my complaint is.  I'm not 
talking about if -(0j) should be 0j or -0j.  It's been that way 
for a long time, so changing it would break old codes.

My point is the signature of imaginary part. As you can see, 
it's represented as '+-'. Before the commit of patch #774665, 
it was represented as '-1-0j'. But after that, '-1+-0j'.

If you test it with Python <= 2.3, you'll get (-1-0j) and I think 
this is how -(1+0j) should be represented on machines where -
(0j) is represented as -0j.


----------------------------------------------------------------------

Comment By: Bj?rn Lindqvist (sonderblade)
Date: 2005-02-10 03:54

Message:
Logged In: YES 
user_id=51702

What you are seeing is negative zero (-0.0). It is distinct 
from positive zero (0.0) but 0.0 == -0.0 is always true. On 
some machines you can also see it by typing:

>>> -0.0
-0.0

On other machines you will see "0.0" instead. You can also try 
printf("%f\n", -0.0); and you will notice the same thing. So 
I'm not sure it is a bug per se. However, it can be worked 
around by adding "if (v->cval.imag == 0.) v->cval.imag = 
0.0;" to complexobject.c, assuming ofcourse it is OK to 
change negative zeros to positive ones.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 18:16:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 18:16:04 2005
Subject: [ python-Bugs-1086675 ] optparse docs missing section on Extending
Message-ID: <E1DChYQ-0001QJ-BX@sc8-sf-web4.sourceforge.net>

Bugs item #1086675, was opened at 2004-12-16 15:25
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086675&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Greg Ward (gward)
Summary: optparse docs missing section on Extending

Initial Comment:
In Python 2.3 the module docs for optparse include a
fifth section,  6.20.5 Extending optparse. This section
is no longer present in the docs for Python 2.4. It is
still present in the current Optik docs
(http://optik.sourceforge.net/doc/1.5/extending.html)
so my guess is this is an inadvertent omission.

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-19 12:16

Message:
Logged In: YES 
user_id=14422

Fixed in Python 2.4 CVS, Doc/lib/liboptparse.tex rev 1.18.2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086675&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 19:05:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 19:05:57 2005
Subject: [ python-Bugs-777867 ] test_ioctl fails
Message-ID: <E1DCiKf-0000m0-Qy@sc8-sf-web1.sourceforge.net>

Bugs item #777867, was opened at 2003-07-26 08:25
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_ioctl fails

Initial Comment:
test_ioctl
test test_ioctl failed -- errors occurred in
test.test_ioctl.IoctlTests

...
223 tests OK.
1 test failed:
    test_ioctl
31 tests skipped:
    test_aepack test_al test_bsddb185 test_bsddb3
test_bz2 test_cd
    test_cl test_curses test_dbm test_email_codecs
test_gdbm test_gl
    test_imgfile test_linuxaudiodev test_locale test_macfs
    test_macostools test_nis test_normalization
test_ossaudiodev
    test_pep277 test_plistlib test_scriptpackages
test_socket_ssl
    test_socketserver test_sunaudiodev test_timeout
test_unicode_file
    test_urllibnet test_winreg test_winsound
4 skips unexpected on linux2:
    test_dbm test_bz2 test_gdbm test_locale
make: *** [test] Error 1


My system:
 * Python from CVS: Python 2.3c1 (#1, Jul 23 2003,
08:31:24) 
 * Debian testing/unstable
 * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003
i686 unknown unknown GNU/Linux
 * gcc (GCC) 3.3.1 20030626 (Debian prerelease)
 * AMD Athlon XP 1600+


----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2005-03-20 03:05

Message:
Logged In: YES 
user_id=671362

On a linux box for my work, I had similar fail(test_ioctl and 
test_ioctl_mutate).

My System:
* Python : 2.3.3, 2.4
* kernel : 2.4.22
* GCC    : 2.95.3
* glibc  : 2.2

I don't know why but somehow test_ioctl.py seems to be 
invoked in the background on 'make test' process, which 
resuls in 2 fails.

Maybe the easiest way to make test_ioctl fail is :
  $ ./python ./Lib/test/regrtest.py test_ioctl &

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-07-29 00:06

Message:
Logged In: YES 
user_id=6656

Heh, yes it certainly would be easier if I (or anyone else) could 
reproduce this.  However, this is the first I've heard of it, and I'd 
have thought/hoped that there are other people running the 
release candidates on Debian testing... glibc is very much a guess 
scapegoat, don't jeopardize your system just for me.

I suggested the '-r' thing because it's the sort of thing that can be 
done in the background.

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2003-07-29 00:00

Message:
Logged In: YES 
user_id=52562

It's always possible that I'm doing something very silly and
not reporting it.  But, as I am pressed for time, it would
be really good if you could get a failure like this running
on your own box.  Hm.  Maybe this means I should just
upgrade my glibc.

MAIN pion:~$ dpkg --status libc6 | grep ^Version
Version: 2.3.1-16

Hm.

Okay, I'll add -r to TESTOPTS and run lots of &quot;make test&quot;.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-07-28 23:54

Message:
Logged In: YES 
user_id=6656

This is deeply weird.

The most likely scenario that some *other* test (or combination of 
tests, sigh) is tickling a bug in glibc that test_ioctl is revealing.

Evidence for/against this could be acquired by adding '-r' to 
TESTOPTS and running make test a few times.  But I still don't 
understand why running regrtest.py from the shell passes.  Unless 
it's a Heisenbug, or just a flat out bug in the test.

Hmm.  Ten gets you one that it's test_fork1 that buggers it up.

It seems exceedingly unlikely that this points to a real problem in 
Python's ioctl code.  ioctl() is not the easiest thing in the world to 
write tests for...

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2003-07-26 21:20

Message:
Logged In: YES 
user_id=52562

Okay, I added &quot;-v&quot; to TESTOPTS in Makefile.

test_ioctl
test_ioctl (test.test_ioctl.IoctlTests) ... FAIL
test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL

======================================================================
FAIL: test_ioctl (test.test_ioctl.IoctlTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
&quot;/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py&quot;,
line 22, in test_ioctl
    self.assertEquals(pgrp, struct.unpack(&quot;i&quot;, r)[0])
  File
&quot;/home/zooko/playground/python/python/dist/src/Lib/unittest.py&quot;,
line 292, in failUnlessEqual
    raise self.failureException, AssertionError: 32261 != 28460

======================================================================
FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
&quot;/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py&quot;,
line 31, in test_ioctl_mutate
    self.assertEquals(pgrp, buf[0])
  File
&quot;/home/zooko/playground/python/python/dist/src/Lib/unittest.py&quot;,
line 292, in failUnlessEqual
    raise self.failureException, AssertionError: 32261 != 28460

----------------------------------------------------------------------
Ran 2 tests in 0.002s

FAILED (failures=2)
test test_ioctl failed -- errors occurred in
test.test_ioctl.IoctlTests


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-07-26 08:52

Message:
Logged In: YES 
user_id=6656

Oh dear.

Could you hack 'make test' to pass -v to regrtest?

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2003-07-26 08:44

Message:
Logged In: YES 
user_id=52562

I cut and pasted the unit test code and ran it, and it passed.
So I suppose it's a bug in how &quot;make test&quot; invokes the
test_ioctl unit test?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-07-26 08:33

Message:
Logged In: YES 
user_id=6656

Can you dig?  I.e. more info than &quot;test_ioctl fails&quot;... try running 
the code that test_ioctl runs and see what that does

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2003-07-26 08:33

Message:
Logged In: YES 
user_id=52562

The stuff I posted when I opened this bug report was all
from running &quot;make test&quot;.  I have now discovered the
&quot;regrtest.py&quot; file and am experimenting with it.  -s doesn't
seem to work for test_ioctl.py:

HACK pion:~/playground/python/python/dist/src$ ./python
./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py
./Lib/test/test_ioctl
test ./Lib/test/test_ioctl crashed -- exceptions.ValueError:
Empty module name
Traceback (most recent call last):
  File &quot;./Lib/test/regrtest.py&quot;, line 394, in runtest
    the_package = __import__(abstest, globals(), locals(), [])
ValueError: Empty module name
1 test failed:
    ./Lib/test/test_ioctl
Traceback (most recent call last):
  File &quot;./Lib/test/regrtest.py&quot;, line 1005, in ?
    main()
  File &quot;./Lib/test/regrtest.py&quot;, line 332, in main
    os.unlink(filename)
OSError: [Errno 2] No such file or directory: '/tmp/pynexttest'


But running regrtest.py by itself runs a bunch of tests
including test_ioctl, apparently successfully:

HACK pion:~/playground/python/python/dist/src$ ./python
./Lib/test/regrtest.py
...
test_ioctl
...
224 tests OK.
31 tests skipped:
    test_aepack test_al test_bsddb185 test_bsddb3 test_bz2
test_cd
    test_cl test_curses test_dbm test_email_codecs test_gdbm
test_gl
    test_imgfile test_linuxaudiodev test_locale test_macfs
    test_macostools test_nis test_normalization test_ossaudiodev
    test_pep277 test_plistlib test_scriptpackages
test_socket_ssl
    test_socketserver test_sunaudiodev test_timeout
test_unicode_file
    test_urllibnet test_winreg test_winsound
4 skips unexpected on linux2:
    test_dbm test_bz2 test_gdbm test_locale


So I guess this is an &quot;issue&quot; in the make target rather than
in the ioctl code itself...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 19:13:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 19:13:39 2005
Subject: [ python-Bugs-1166582 ] IterableUserDict not in docs
Message-ID: <E1DCiS9-0006XN-2L@sc8-sf-web3.sourceforge.net>

Bugs item #1166582, was opened at 2005-03-19 18:13
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=1166582&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: IterableUserDict not in docs

Initial Comment:
There is no mention of UserDict.IterableUserDict in the
docs (3.7 UserDict). Here is a suggested rewrite:

class UserDict(     [initialdata])
    Class that simulates a dictionary. The instance's
contents are kept in a regular dictionary, which is
accessible via the data attribute of UserDict
instances. If initialdata is provided, data is
initialized with its contents; note that a reference to
initialdata will not be kept, allowing it be used for
other purposes. Note: For backward compatibility,
instances of UserDict are not iterable.

class IterableUserDict( [initialdata])
    Subclass of UserDict that supports direct iteration
(e.g. "for key in myDict").

In addition to supporting the methods and operations of
mappings (see section 2.3.8), UserDict and
IterableUserDict instances provide the following attribute:

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166582&group_id=5470
From noreply at sourceforge.net  Sat Mar 19 22:48:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 19 22:48:25 2005
Subject: [ python-Bugs-1166660 ] The readline module can cause python to
	segfault
Message-ID: <E1DClnz-0000iC-Br@sc8-sf-web1.sourceforge.net>

Bugs item #1166660, was opened at 2005-03-19 23: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=1166660&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
<http://www.scipy.net/roundup/ipython/issue30>.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 00:34:34 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 00:34:38 2005
Subject: [ python-Bugs-1166704 ] [ast branch] fatal error when compiling
	test_bool.py
Message-ID: <E1DCnSk-0002qF-Oe@sc8-sf-web2.sourceforge.net>

Bugs item #1166704, was opened at 2005-03-19 23:34
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=1166704&group_id=5470

Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166704&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 00:59:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 00:59:17 2005
Subject: [ python-Bugs-1166660 ] The readline module can cause python to
	segfault
Message-ID: <E1DCnqd-0001l4-1Q@sc8-sf-web3.sourceforge.net>

Bugs item #1166660, was opened at 2005-03-19 23:48
Message generated for change (Comment added) made by dcoder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
<http://www.scipy.net/roundup/ipython/issue30>.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

----------------------------------------------------------------------

>Comment By: Yariv Ido (dcoder)
Date: 2005-03-20 01:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 01:14:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 01:14:55 2005
Subject: [ python-Bugs-1166714 ] [ast branch] fatal error when compiling
	test_bool.py
Message-ID: <E1DCo5k-0002GF-Go@sc8-sf-web3.sourceforge.net>

Bugs item #1166714, was opened at 2005-03-20 00:14
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=1166714&group_id=5470

Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 02:25:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 02:25:50 2005
Subject: [ python-Bugs-1164631 ] super(...).__new__( ... ) behaves
	"unexpected"
Message-ID: <E1DCpCN-0002IW-Ki@sc8-sf-web4.sourceforge.net>

Bugs item #1164631, was opened at 2005-03-16 12:07
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470

Category: Type/class unification
Group: Python 2.4
Status: Deleted
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A<MC> of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-19 20:25

Message:
Logged In: YES 
user_id=764593

Note that the documentation is known to be very weak 
regarding both metaclasses and the differences between 
classic and new-style classes.

If you (or Nick) wanted to submit a documentation patch, I 
doubt I'm the only one who would appreciate it.

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 05:32

Message:
Logged In: YES 
user_id=360037

Okay, that's the point.
Thanx for your time and work - bug becomes deleted.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-18 20:30

Message:
Logged In: YES 
user_id=1038590

Additional text from the descrintro essay, indicating that
it is deliberate that C3 does not trigger an exception:

"""However, if one of the base metaclasses satisfies the
constraint (including the explicitly given __metaclass__, if
any), the first base metaclass found satisfying the
constraint will be used as the metaclass."""

So, unless Guido chooses to change the desired behaviour,
these two snippets pretty much cover what needs to be added
to the docs.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-18 19:17

Message:
Logged In: YES 
user_id=1038590

To address the documentation side, the following text from
Guido's descrintro essay could be added to the official
documentation:

"""For new-style metaclasses, there is a constraint that the
chosen metaclass is equal to, or a subclass of, each of the
metaclasses of the bases. Consider a class C with two base
classes, B1 and B2. Let's say M = C.__class__, M1 =
B1.__class__, M2 = B2.__class__. Then we require
issubclass(M, M1) and issubclass(M, M2). (This is because a
method of B1 should be able to call a meta-method defined in
M1 on self.__class__, even when self is an instance of a
subclass of B1.)""" 

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-18 19:14

Message:
Logged In: YES 
user_id=1038590

Minimal case that should throw an exception on C3, but
doesn't (instead, it silently replaces the explicitly
requested metaclass M1 with its subclass M2):

class M1(type):
  pass

class M2(M1):
  pass

class C1(object):
  __metaclass__ = M1

class C2(C1):
  __metaclass__ = M2

class C3(C2):
  __metaclass__ = M1


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-18 14:14

Message:
Logged In: YES 
user_id=764593

Yes, it is intentional.  

class Derived(Base): ...

should mean that you can use an instance of Derived 
anywhere you need an instance of Base.

There are ways to break this, but it isn't a good idea.

Letting Derived ignore part of the metaclass (and creation 
instructions) of Base would make it much easier to create an 
invalid Derived by accident -- and the error could show up as 
memory corruption, instead of something meaningful.


----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 10:48

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 09:41

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 09:13

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 05:38

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [...]
  <line 1611, 1612, 1613>
    if (PyType_IsSubtype(tmptype, winner)) {
	winner = tmptype;
	continue;
    }

These three lines mean, it would never be possible to create a 
subclass using a (metatype which is a subclass of the 
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a 
programmer) is ignored and replaced by a metaclass which 
python decides...

... do you really want this to be that way????

This means, one always ends up in a (meta-)class hierarchy 
that is fixed. Programmers dynamically can't decide anymore, 
if there should be a level in their class hierarchy which should 
*NOT* use the 'highest subclassed metaclass' in their class 
hierarchy.

I would consider this a problem, because the use of 
__metaclasses__ will be implicitly restricted

----------------------------------------------------------------------

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-16 12:11

Message:
Logged In: YES 
user_id=360037

Sorry - 2.3 must be corrected:




2.3 Due to the superclass A<MC> of B, create some 


class B which is of type MC as well. Although B 


contains a __metaclass__ = MB statement.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 07:33:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 07:34:03 2005
Subject: [ python-Bugs-1160383 ] digit-only tag values are mishandled in
	Tkinter
Message-ID: <E1DCu0b-000095-GX@sc8-sf-web1.sourceforge.net>

Bugs item #1160383, was opened at 2005-03-09 20:32
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470

Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. L?wis (loewis)
Summary: digit-only tag values are mishandled in Tkinter

Initial Comment:
It  appears that  most Tkinter tag operations fail on
digit-only tag values

>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()       
>>> c.find_withtag("123")
()

tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm

only say this about tag values:
  "Tags are ordinary strings, and they can contain
anything except whitespace."

So this behaviour seems like a bug.

----------------------------------------------------------------------

>Comment By: Ilya Sandler (isandler)
Date: 2005-03-19 22:33

Message:
Logged In: YES 
user_id=971153

>".. Item handles can be passed to the various canvas methods 
> either as integers or as strings..." (from effbot posting)

While I can see how a very careful reader might notice that
there is a potential conflict between this "handles as
strings" statement and "tags can contain anything", I still
think that at the very least this conflict needs to be
mentioned explicitly.

> Furthermore, the site www.pythonware.com is a third-party
> site not run by the Python developers (from  jepler posting)

Actually for whatever reason I thought that pythonware.com
is the authorative source for tkinter docs....

I guess it does bring an interesting question for Fredrik...
Would you consider merging your Tkinter docs (which seem to
be reasonably complete) with python.org docs which seem to
be very spotty?



----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-03-19 08:53

Message:
Logged In: YES 
user_id=38376

Here's the text before the quoted line:

"Everywhere a method expects an item specifier, you can 
use one of the following: * item handles * tags /.../ Item 
handles are integer values that are used to identify a specific 
item on the canvas /.../ Item handles can be passed to the 
various canvas methods either as integers or as strings. /.../"

Note the use of "one of", and the fact that item handles are 
described before tags. (Writing documentation for people who 
only reads random sentences is pretty much impossible...)

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-03-19 06:20

Message:
Logged In: YES 
user_id=2772

This is a documentation bug.  The Tk documentation says
(canvas, section "ITEM IDS AND TAGS"):
       Each  item may also have any number of tags
associated with it.  A tag
       is just a string of characters, and it may take any
form  except  that
       of  an  integer.   For example, ??x123?? is OK but
??123?? isn?t.  The
       same tag may be associated with many different items.

Furthermore, the site www.pythonware.com is a third-party
site not run by the Python developers.  The official Python
documentation
(http://docs.python.org/lib/module-Tkinter.html and 'pydoc
Tkinter') doesn't explain the syntax of an item tag anywhere
that I could see)

I recommend closing this bug and notifying pythonware.com /
Fredrik Lundh about the problem via e-mail.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 11:02:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 11:02:48 2005
Subject: [ python-Bugs-1166378 ] No os.spawn*p* on Windows
Message-ID: <E1DCxGe-0003bG-O9@sc8-sf-web2.sourceforge.net>

Bugs item #1166378, was opened at 2005-03-19 05:41
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Palmer (chris_palmer)
Assigned to: Nobody/Anonymous (nobody)
Summary: No os.spawn*p* on Windows

Initial Comment:
You have the other spawn* functions, and exec*p*, but
no spawn*p*. It exists on Linux. These functions should
either exist everywhere or nowhere.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 12:02

Message:
Logged In: YES 
user_id=539787

This is documented (see
http://docs.python.org/lib/os-process.html). Python lib has
many places where underlying platform controls availability
of functionality.
Suggest closing of this bug or converting it to wishlist item.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 11:28:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 11:28:10 2005
Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS
	encoding
Message-ID: <E1DCxfC-0005dD-9S@sc8-sf-web1.sourceforge.net>

Bugs item #1163244, was opened at 2005-03-14 22:20
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim N. van der Leeuw (tnleeuw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax error on large file with MBCS encoding

Initial Comment:
Large files generated by make-py.py from the win32all
extensions cannot be compiled by Python2.4.1rc1 - they
give a syntax error.

This is a regression from 2.3.5

(With Python2.4, the interpreter crashes. That is fixed
now.)

Removing the mbcs encoding line from the top of the
file, compilation succeeds.

File should be attached, as zip-file. Probably requires
win32all extensions to be installed to be compiled /
imported (generated using build 203 of the win32all
extensions).


----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 12:28

Message:
Logged In: YES 
user_id=539787

Useful pointers: in Python-dev, this has been characterised
as related to pywin32 bug 1085454.  Also related to
www.python.org/sf/1101726 and www.python.org/sf/1089395.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 11:36:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 11:36:50 2005
Subject: [ python-Bugs-1162477 ] Parsing failures in parsedate_tz
Message-ID: <E1DCxnc-0001sS-1z@sc8-sf-web3.sourceforge.net>

Bugs item #1162477, was opened at 2005-03-13 18:11
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162477&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parsing failures in parsedate_tz

Initial Comment:
Some email clients send bad-formed datetimes, not
parsed by parsedate_tz (both rfc822.py and
email._parseaddr.py). 

The format not recognized is "HH.MM.SS".

I don't know if it's worth taking in account but in
doubt I give a small patch for email._parseaddr :

----------------------------------------------------------------
@@ -90,6 +100,14 @@ def parsedate_tz(data):
         tss = '0'
     elif len(tm) == 3:
         [thh, tmm, tss] = tm
+    elif len(tm) == 1:
+        # Small hack to get HH.MM.ss
+        tm = tm[0].split(".")
+        if len(tm) == 2:
+            [thh, tmm] = tm
+            tss = '0'
+        elif len(tm) == 3:
+            [thh, tmm, tss] = tm
     else:
         return None
----------------------------------------------------------------

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 12:36

Message:
Logged In: YES 
user_id=539787

It would be helpful if you could provide some of these
malformed Date headers, so that test cases can be generated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162477&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 12:00:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 12:00:28 2005
Subject: [ python-Bugs-1157255 ] PEP 328 and Python 2.4 error
Message-ID: <E1DCyAU-0005JE-UZ@sc8-sf-web2.sourceforge.net>

Bugs item #1157255, was opened at 2005-03-05 15:23
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157255&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 328 and Python 2.4 error

Initial Comment:
PEP 328 says that 
from __future__ import absolute_import

will be part of Python 2.4, but it is not:

D:\Projects\CB>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
 >>> from __future__ import absolute_import
  File "<stdin>", line 1
SyntaxError: future feature absolute_import is not defined

The PEP should be updated to reflect this.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 13:00

Message:
Logged In: YES 
user_id=539787

This is still not implemented at least in HEAD
(http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/future.c?rev=2.15&view=auto
and 
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/__future__.py?rev=1.13&view=auto
).  I believe new functionality is avoided in micro (x.y.N)
releases, so the PEP probably will have to specify 2.5
instead of 2.4 as version of application.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157255&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 12:48:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 12:48:05 2005
Subject: [ python-Bugs-1155362 ] Bugs in parsedate_tz
Message-ID: <E1DCyuZ-0001Im-5g@sc8-sf-web4.sourceforge.net>

Bugs item #1155362, was opened at 2005-03-02 23:03
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Bugs in parsedate_tz

Initial Comment:
The parsing in emails is incomplete in both rfc822.py
and _parseaddr.py.

For example, "Wed, 02 Mar 2005 09:26:53+0800" is parsed
but "Wed, 02 Mar 2005 09:26:53-0800" is not.

The problem is clear by watching the code : only "+"
timezones are corrected.
Following a patch :

Index : _parseaddr.py
----------------------------------------------------------------
@@ -60,7 +66,11 @@ def parsedate_tz(data):
         if i > 0:
             data[3:] = [s[:i], s[i+1:]]
         else:
-            data.append('') # Dummy tz
+           i = s.find('-')
+           if i > 0:
+               data[3:] = [s[:i], s[i:]]
+           else:
+               data.append('') # Dummy tz
     if len(data) < 5:
         return None
     data = data[:5]
----------------------------------------------------------------

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 13:48

Message:
Logged In: YES 
user_id=539787

Note that parsedate_tz as of current parses correctly "Wed,
02 Mar 2005 09:26:53 -0800" (space before '-'), because
data.split() in line 43 produces five parts: [dow, date,
month, year, time, timezone] (reduced to four by removing
initial dow).   The function includes a special check for
"+" in the time part, and this patch adds the "-" check.

I didn't find any date header in my whole email and
newsgroup archive (12095 messages) missing the space before
[-+].  However, if mail clients or servers exist that
produce such date headers, patch should be applied and bug
closed.

Notes:
Some test should be added too.  I updated
test_parsedate_no_dayofweek (line 2076 of
lib/email/test/test_email.py) adding same test dropping the
space before '-', and test fails before patch, succeeds
after patch.  Perhaps a separate test case should be included.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 13:05:18 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 13:05:21 2005
Subject: [ python-Bugs-874900 ] threading module can deadlock after fork
Message-ID: <E1DCzBG-0001jL-Ss@sc8-sf-web4.sourceforge.net>

Bugs item #874900, was opened at 2004-01-11 16:28
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874900&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael McCandless (mikemccand)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading module can deadlock after fork

Initial Comment:

We have a Python HTTP server that, in the parent
process, uses os.fork to spawn new children, but at the
same time the parent could be spawning new threads (in
threads other than the main thread -- only the main
thread does forking).

Anwyay, it very rarely causes deadlock in a spawned
child when that child tries to start a new thread.

I believe I've tracked this down to the
_active_limbo_lock in the threading module. 
Specifically, if this lock is held by parent (because
another thread is spawning a thread), just as os.fork
happens, the child inherits the held lock and will then
block trying to do any threading.* operations.

Just like the global interp. lock is overwritten in the
child after fork, I think something similar should
happen to threading._active_limbo_lock?  (And more
generally the user needs to be aware of locks passing
through fork; but I think at least threading.py should
"do the right thing").

This thread looks quite relevant:

groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=38E6F2BA.E66CAC90%40ensim.com&rnum=5&prev=/groups%3Fq%3Dpython%2Bfork%2Bthreading%2Bmodule%2B%2Block%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DN%26scoring%3Dd


----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 14:05

Message:
Logged In: YES 
user_id=539787

See some more typical info about mixing forks and threads:
http://mail.python.org/pipermail/python-list/2001-September/066048.html

This seems not to be Python-related, but platform-related.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874900&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 13:12:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 13:12:40 2005
Subject: [ python-Bugs-874900 ] threading module can deadlock after fork
Message-ID: <E1DCzIL-0001w4-HJ@sc8-sf-web4.sourceforge.net>

Bugs item #874900, was opened at 2004-01-11 09:28
Message generated for change (Comment added) made by mikemccand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874900&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael McCandless (mikemccand)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading module can deadlock after fork

Initial Comment:

We have a Python HTTP server that, in the parent
process, uses os.fork to spawn new children, but at the
same time the parent could be spawning new threads (in
threads other than the main thread -- only the main
thread does forking).

Anwyay, it very rarely causes deadlock in a spawned
child when that child tries to start a new thread.

I believe I've tracked this down to the
_active_limbo_lock in the threading module. 
Specifically, if this lock is held by parent (because
another thread is spawning a thread), just as os.fork
happens, the child inherits the held lock and will then
block trying to do any threading.* operations.

Just like the global interp. lock is overwritten in the
child after fork, I think something similar should
happen to threading._active_limbo_lock?  (And more
generally the user needs to be aware of locks passing
through fork; but I think at least threading.py should
"do the right thing").

This thread looks quite relevant:

groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=38E6F2BA.E66CAC90%40ensim.com&rnum=5&prev=/groups%3Fq%3Dpython%2Bfork%2Bthreading%2Bmodule%2B%2Block%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DN%26scoring%3Dd


----------------------------------------------------------------------

>Comment By: Michael McCandless (mikemccand)
Date: 2005-03-20 07:12

Message:
Logged In: YES 
user_id=323786


True -- there are many platform specific issues on the
interaction of forking and threading.

However the _active_limbo_lock is entirely a Python issue (I
think it can deadlock on any platform, unless the platform
releases locks in child process after fork).

After forking, python already resets the GIL, and it should
also reset any other locks that have global impact like
_active_limbo_lock.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 07:05

Message:
Logged In: YES 
user_id=539787

See some more typical info about mixing forks and threads:
http://mail.python.org/pipermail/python-list/2001-September/066048.html

This seems not to be Python-related, but platform-related.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874900&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 13:29:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 13:29:22 2005
Subject: [ python-Bugs-1162477 ] Parsing failures in parsedate_tz
Message-ID: <E1DCzYW-0007rf-Jj@sc8-sf-web4.sourceforge.net>

Bugs item #1162477, was opened at 2005-03-13 16:11
Message generated for change (Comment added) made by therve
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162477&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parsing failures in parsedate_tz

Initial Comment:
Some email clients send bad-formed datetimes, not
parsed by parsedate_tz (both rfc822.py and
email._parseaddr.py). 

The format not recognized is "HH.MM.SS".

I don't know if it's worth taking in account but in
doubt I give a small patch for email._parseaddr :

----------------------------------------------------------------
@@ -90,6 +100,14 @@ def parsedate_tz(data):
         tss = '0'
     elif len(tm) == 3:
         [thh, tmm, tss] = tm
+    elif len(tm) == 1:
+        # Small hack to get HH.MM.ss
+        tm = tm[0].split(".")
+        if len(tm) == 2:
+            [thh, tmm] = tm
+            tss = '0'
+        elif len(tm) == 3:
+            [thh, tmm, tss] = tm
     else:
         return None
----------------------------------------------------------------

----------------------------------------------------------------------

>Comment By: TH (therve)
Date: 2005-03-20 12:29

Message:
Logged In: YES 
user_id=1038797

Of course, here's and example of malformed Date header :
"Wed, 02 Mar 2005 09.26.53 +0800".

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 10:36

Message:
Logged In: YES 
user_id=539787

It would be helpful if you could provide some of these
malformed Date headers, so that test cases can be generated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162477&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 13:35:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 13:35:13 2005
Subject: [ python-Bugs-1155362 ] Bugs in parsedate_tz
Message-ID: <E1DCze3-00080g-09@sc8-sf-web4.sourceforge.net>

Bugs item #1155362, was opened at 2005-03-02 21:03
Message generated for change (Comment added) made by therve
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Bugs in parsedate_tz

Initial Comment:
The parsing in emails is incomplete in both rfc822.py
and _parseaddr.py.

For example, "Wed, 02 Mar 2005 09:26:53+0800" is parsed
but "Wed, 02 Mar 2005 09:26:53-0800" is not.

The problem is clear by watching the code : only "+"
timezones are corrected.
Following a patch :

Index : _parseaddr.py
----------------------------------------------------------------
@@ -60,7 +66,11 @@ def parsedate_tz(data):
         if i > 0:
             data[3:] = [s[:i], s[i+1:]]
         else:
-            data.append('') # Dummy tz
+           i = s.find('-')
+           if i > 0:
+               data[3:] = [s[:i], s[i:]]
+           else:
+               data.append('') # Dummy tz
     if len(data) < 5:
         return None
     data = data[:5]
----------------------------------------------------------------

----------------------------------------------------------------------

>Comment By: TH (therve)
Date: 2005-03-20 12:35

Message:
Logged In: YES 
user_id=1038797

In fact, the mails I've seen with this problem are likely to
be spam. 

I just thought it would be more logical to test both "+" and
"-" as "+" was already well parsed.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 11:48

Message:
Logged In: YES 
user_id=539787

Note that parsedate_tz as of current parses correctly "Wed,
02 Mar 2005 09:26:53 -0800" (space before '-'), because
data.split() in line 43 produces five parts: [dow, date,
month, year, time, timezone] (reduced to four by removing
initial dow).   The function includes a special check for
"+" in the time part, and this patch adds the "-" check.

I didn't find any date header in my whole email and
newsgroup archive (12095 messages) missing the space before
[-+].  However, if mail clients or servers exist that
produce such date headers, patch should be applied and bug
closed.

Notes:
Some test should be added too.  I updated
test_parsedate_no_dayofweek (line 2076 of
lib/email/test/test_email.py) adding same test dropping the
space before '-', and test fails before patch, succeeds
after patch.  Perhaps a separate test case should be included.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 16:02:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 16:02:53 2005
Subject: [ python-Bugs-1166704 ] [ast branch] fatal error when compiling
	test_bool.py
Message-ID: <E1DD1x6-0002cD-AI@sc8-sf-web1.sourceforge.net>

Bugs item #1166704, was opened at 2005-03-19 15:34
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166704&group_id=5470

Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-20 07:02

Message:
Logged In: YES 
user_id=357491

dup of #1166714 .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166704&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 16:20:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 16:20:14 2005
Subject: [ python-Bugs-993580 ] inspect.findsource does not call
	linecache.checkcache
Message-ID: <E1DD2Dn-0007bw-23@sc8-sf-web3.sourceforge.net>

Bugs item #993580, was opened at 2004-07-19 00:45
Message generated for change (Comment added) made by jlcherry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Mobarak (jmobarak)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.findsource does not call linecache.checkcache

Initial Comment:
inspect.findsource does not call linecache.checkcache
thus always returns orignal source of an object
regardless of wether it has changed.



----------------------------------------------------------------------

Comment By: Josh Cherry (jlcherry)
Date: 2005-03-20 10:20

Message:
Logged In: YES 
user_id=957678

Note that if you tack on

execfile(somefile)
print inspect.findsource(foo)

at the end of the example, so that the object does change, 
you still see the old source.


----------------------------------------------------------------------

Comment By: Jason Mobarak (jmobarak)
Date: 2004-07-19 01:01

Message:
Logged In: YES 
user_id=1041478

Not to mention there's intermediate steps where an object's
source could change several times, and be reloaded at one of
those intermediate steps... seems like there's no way for
findsource itself to return the correct source for an object
if it's reloaded. Maybe this should be documented...

----------------------------------------------------------------------

Comment By: Jason Mobarak (jmobarak)
Date: 2004-07-19 00:53

Message:
Logged In: YES 
user_id=1041478

Actually, I'm not sure if this is really a bug, seems to
make sense that inspect shouldn't return the new source of
the object unless the object has changed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 16:22:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 16:22:49 2005
Subject: [ python-Bugs-1166714 ] [ast branch] fatal error when compiling
	test_bool.py
Message-ID: <E1DD2GN-0004iD-BE@sc8-sf-web4.sourceforge.net>

Bugs item #1166714, was opened at 2005-03-19 16:14
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470

Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
>Assigned to: Brett Cannon (bcannon)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 17:28:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 17:28:40 2005
Subject: [ python-Bugs-1166714 ] [ast branch] fatal error when compiling
	test_bool.py
Message-ID: <E1DD3I5-0004hO-TK@sc8-sf-web2.sourceforge.net>

Bugs item #1166714, was opened at 2005-03-19 19:14
Message generated for change (Settings changed) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470

Category: Parser/Compiler
>Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Brett Cannon (bcannon)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470
From noreply at sourceforge.net  Sun Mar 20 21:43:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 20 21:43:45 2005
Subject: [ python-Bugs-1166378 ] No os.spawn*p* on Windows
Message-ID: <E1DD7Gw-00068b-Cb@sc8-sf-web2.sourceforge.net>

Bugs item #1166378, was opened at 2005-03-19 03:41
Message generated for change (Comment added) made by chris_palmer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Palmer (chris_palmer)
Assigned to: Nobody/Anonymous (nobody)
Summary: No os.spawn*p* on Windows

Initial Comment:
You have the other spawn* functions, and exec*p*, but
no spawn*p*. It exists on Linux. These functions should
either exist everywhere or nowhere.

----------------------------------------------------------------------

>Comment By: Chris Palmer (chris_palmer)
Date: 2005-03-20 20:43

Message:
Logged In: YES 
user_id=1242303

Okay, I read the page you point to. It provides no
explanation, just a statement of the fact I had already
discovered. An explanation would be nice.

Don't you think it's strange that these three conditions
should hold:

1. os.exec*p* are supported on Windows;
2. Windows systems have a PATH environment variable with the
same meaning and use as UNIX; and yet
3. os.spawn*p* are not supported on Windows?

If there's some difference to how the environment is treated
or used between exec* and spawn* on Windows, wouldn't it be
easy to emulate the PATH-searching feature?

My options are to emulate the PATH-searching feature myself
and ignore os.spawn*p* on all platforms, or to use it when
it's present and only emulate it on Windows. The first
option is ridiculous, the second is ridiculous and ugly.

If you won't emulate the spawn*p* behavior -- it's three
lines of Python! -- it would help if you could at least
explain why, technically.

Thanks.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 10:02

Message:
Logged In: YES 
user_id=539787

This is documented (see
http://docs.python.org/lib/os-process.html). Python lib has
many places where underlying platform controls availability
of functionality.
Suggest closing of this bug or converting it to wishlist item.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 04:25:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 04:26:02 2005
Subject: [ python-Bugs-1167262 ] Fails assertion in winsig.c under VC 8.0
Message-ID: <E1DDDYF-0008Fb-Hc@sc8-sf-web3.sourceforge.net>

Bugs item #1167262, was opened at 2005-03-21 03:25
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=1167262&group_id=5470

Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Timothy Fitz (timothyfitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails assertion in winsig.c under VC 8.0

Initial Comment:
In 2.4 and current cvs initsignal in signalmodule.c calls 
PyOS_getsig which calls signal with an invalid signal 
number. Under VC 7.1 (and 7.0, and probably before) 
this would return SIG_ERR however under VC 8.0 (beta) 
this causes an assertion failure. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 06:07:25 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 06:07:30 2005
Subject: [ python-Bugs-853411 ] After fork in subthread, signals are blocked
Message-ID: <E1DDF8P-00089K-NI@sc8-sf-web4.sourceforge.net>

Bugs item #853411, was opened at 2003-12-03 16:55
Message generated for change (Comment added) made by moculus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470

Category: Threads
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: G?ran Uddeborg (goeran)
Assigned to: Nobody/Anonymous (nobody)
Summary: After fork in subthread, signals are blocked

Initial Comment:
When a Python program starts a new thread, and this new
thread forks, the forked process ingores signals.  It
will not terminate, or dump core if that would be
applicable, when it receives a signal.

I attach a test case which illustrates the behaviour. 
In this example, the child process is sent a SEGV
signal from the subthread of the parent process.  This
should cause the child process to die and produce a
core.  But execution of the parent program threads
finishes, there is still a python process around,
continuing to sleep.

Apparently, Python subthreads blocks signals.  On
Linux, /proc/*/status for subthreads includes the line

SigBlk: ffffffff7ffbfeff

The Python documentation says one should only install
signal handlers in the main thread, and only the main
thread will recieve signals.  So this makes sense.  But
when the subthread forks, the new process inherits this
signal mask, which seems to be incorrect behaviour.  I
would assume, if Python sets this signal mask for
threads, it should also reset it again after a fork.

I've seen this on these two platforms:
Python 2.2.3 on Red Hat Linux RHEL 3WS (IA32)
Python 2.2.1 on Sun Solaris 8 (Sparc)

----------------------------------------------------------------------

Comment By: Erik Osheim (moculus)
Date: 2005-03-21 05:07

Message:
Logged In: YES 
user_id=542811

I can confirm that on my install of 2.4, I no longer get
this problem.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 08:59

Message:
Logged In: YES 
user_id=6656

I think this should be fixed in Python 2.4.

----------------------------------------------------------------------

Comment By: Erik Osheim (moculus)
Date: 2005-03-18 03:45

Message:
Logged In: YES 
user_id=542811

This bug is still around. I have been experiencing it
firsthand: if I write a simple program with one parent and
one child thread and run rsync in the parent thread (via
os.system), all is well. In the child thread it hangs
indefinitely.

After putting a bunch of debugging into rsync, I discovered
that a USR2 signal was getting sent but never received, and
rsyncs parent thread was waiting for the child to exit, and
that the child was sleeping (having not gotten the signal).

Is there any clue as to why this happens? This has been
widely observed on Linux 2.6.* (this particular case affects
Gentoo).


----------------------------------------------------------------------

Comment By: gmanipon (pymonger)
Date: 2004-12-06 21:24

Message:
Logged In: YES 
user_id=1173063

Sorry for the bother.

Was there any resolution to this bug report?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-01-26 10:02

Message:
Logged In: YES 
user_id=45365

I have absolutely no idea where the bug could be, someone better 
versed in the threading ideosyncracies of the various platforms 
needs to look at this, but I do want to point at hairy_flange's 
comment that fink-python 2.2.3 on OSX does *not* exhibit the bug 
(while on other platforms it does). It may be worthwhile to 
download a fink-python in source form, and see whether they do 
any configure magic.

----------------------------------------------------------------------

Comment By: Steve Muir (hairy_flange)
Date: 2004-01-26 04:04

Message:
Logged In: YES 
user_id=960132

I just submitted a bug report that is a duplicate of this bug
(apologies!), I observed the same behaviour with the Python
shipped with Mac OS X (Python 2.3), and Python 2.2.2 on
RedHat/x86, but Fink Python 2.2.3 for OS X does not have
this bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 06:35:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 06:35:48 2005
Subject: [ python-Bugs-1167300 ] Error "exec"ing python code
Message-ID: <E1DDFZo-0007T2-GF@sc8-sf-web2.sourceforge.net>

Bugs item #1167300, was opened at 2005-03-21 00:35
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=1167300&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error "exec"ing python code

Initial Comment:
I'm trying to 'exec'ing the following code:

class Foo: pass
class Bar:
    f = Foo
    
The error appears when using 'exec f in {}, {}':

>>> f = ''.join(open('/home/stefan/t.py').readlines())
>>> exec f in {}, {}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 2, in ?
  File "<string>", line 3, in Bar
NameError: name 'Foo' is not defined

I tested on python 2.3 and python 2.4, both show the same
behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 07:31:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 07:32:01 2005
Subject: [ python-Bugs-1167329 ] xmlrpclib invalid url
Message-ID: <E1DDGSF-0002gf-6p@sc8-sf-web1.sourceforge.net>

Bugs item #1167329, was opened at 2005-03-21 14:31
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=1167329&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Doukidis (doukm)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib invalid url

Initial Comment:
Within section:

11.22 xmlrpclib -- XML-RPC client access

URL http://ontosys.com/xml-rpc/extensions.html

is invalid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167329&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 10:17:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 10:17:41 2005
Subject: [ python-Bugs-1166378 ] No os.spawn*p* on Windows
Message-ID: <E1DDJ2Z-0005Z4-24@sc8-sf-web3.sourceforge.net>

Bugs item #1166378, was opened at 2005-03-19 05:41
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Palmer (chris_palmer)
Assigned to: Nobody/Anonymous (nobody)
Summary: No os.spawn*p* on Windows

Initial Comment:
You have the other spawn* functions, and exec*p*, but
no spawn*p*. It exists on Linux. These functions should
either exist everywhere or nowhere.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-21 11:17

Message:
Logged In: YES 
user_id=539787

This bug is *not* a bug, so it should be closed, and an
entry made in RFE (Request For Enhancements) aka wishlist.
Google has many pointers.  See for example
http://mail.python.org/pipermail/python-dev/2003-April/034473.html
.
Patches are welcome (either code or documentation).

----------------------------------------------------------------------

Comment By: Chris Palmer (chris_palmer)
Date: 2005-03-20 22:43

Message:
Logged In: YES 
user_id=1242303

Okay, I read the page you point to. It provides no
explanation, just a statement of the fact I had already
discovered. An explanation would be nice.

Don't you think it's strange that these three conditions
should hold:

1. os.exec*p* are supported on Windows;
2. Windows systems have a PATH environment variable with the
same meaning and use as UNIX; and yet
3. os.spawn*p* are not supported on Windows?

If there's some difference to how the environment is treated
or used between exec* and spawn* on Windows, wouldn't it be
easy to emulate the PATH-searching feature?

My options are to emulate the PATH-searching feature myself
and ignore os.spawn*p* on all platforms, or to use it when
it's present and only emulate it on Windows. The first
option is ridiculous, the second is ridiculous and ugly.

If you won't emulate the spawn*p* behavior -- it's three
lines of Python! -- it would help if you could at least
explain why, technically.

Thanks.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 12:02

Message:
Logged In: YES 
user_id=539787

This is documented (see
http://docs.python.org/lib/os-process.html). Python lib has
many places where underlying platform controls availability
of functionality.
Suggest closing of this bug or converting it to wishlist item.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 10:37:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 10:37:16 2005
Subject: [ python-Bugs-1167397 ] Python 2.4 causes BitTorrent 3.4.2 failure
Message-ID: <E1DDJLV-0001Vs-TP@sc8-sf-web2.sourceforge.net>

Bugs item #1167397, was opened at 2005-03-21 09:37
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=1167397&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew P. Lentvorski, Jr. (bsder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 causes BitTorrent 3.4.2 failure

Initial Comment:
The following failure messages gets dumped out of
BitTorrent 3.4.2 when run against Python 2.4:

Traceback (most recent call last):
  File "/usr/local/lib/python2.4/threading.py", line
442, in __bootstrap
    self.run()
  File "/usr/local/lib/python2.4/threading.py", line
422, in run
    self.__target(*self.__args, **self.__kwargs)
  File
"/home/andrewl/python/lib/python2.4/site-packages/BitTorrent/Rerequester.py",
line 84, in rerequest
    h = urlopen(url)
  File "/usr/local/lib/python2.4/urllib2.py", line 130,
in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 364,
in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 468,
in http_response
    code, msg, hdrs = response.code, response.msg,
response.info()
AttributeError: addinfourldecompress instance has no
attribute 'code'


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 10:37:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 10:37:41 2005
Subject: [ python-Bugs-1167397 ] Python 2.4 causes BitTorrent 3.4.2 failure
Message-ID: <E1DDJLv-0003QV-90@sc8-sf-web1.sourceforge.net>

Bugs item #1167397, was opened at 2005-03-21 09:37
Message generated for change (Settings changed) made by bsder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&group_id=5470

>Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew P. Lentvorski, Jr. (bsder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 causes BitTorrent 3.4.2 failure

Initial Comment:
The following failure messages gets dumped out of
BitTorrent 3.4.2 when run against Python 2.4:

Traceback (most recent call last):
  File "/usr/local/lib/python2.4/threading.py", line
442, in __bootstrap
    self.run()
  File "/usr/local/lib/python2.4/threading.py", line
422, in run
    self.__target(*self.__args, **self.__kwargs)
  File
"/home/andrewl/python/lib/python2.4/site-packages/BitTorrent/Rerequester.py",
line 84, in rerequest
    h = urlopen(url)
  File "/usr/local/lib/python2.4/urllib2.py", line 130,
in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 364,
in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 468,
in http_response
    code, msg, hdrs = response.code, response.msg,
response.info()
AttributeError: addinfourldecompress instance has no
attribute 'code'


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 13:11:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 13:12:02 2005
Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS
	encoding
Message-ID: <E1DDLlD-0003BE-Sl@sc8-sf-web4.sourceforge.net>

Bugs item #1163244, was opened at 2005-03-15 07:20
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim N. van der Leeuw (tnleeuw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax error on large file with MBCS encoding

Initial Comment:
Large files generated by make-py.py from the win32all
extensions cannot be compiled by Python2.4.1rc1 - they
give a syntax error.

This is a regression from 2.3.5

(With Python2.4, the interpreter crashes. That is fixed
now.)

Removing the mbcs encoding line from the top of the
file, compilation succeeds.

File should be attached, as zip-file. Probably requires
win32all extensions to be installed to be compiled /
imported (generated using build 203 of the win32all
extensions).


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2005-03-21 23:11

Message:
Logged In: YES 
user_id=14198

I believe this is a different bug than the recent
"long-lines" errors (see below).  I can reproduce this with
a file that uses neither long lines, nor any pywin32
extensions (2.4 branch, trunk)

A Python source file containing:
-- start snippet --
# -*- coding: mbcs -*-
<1532 characters of code or comments>
<cr/lf newline>
x = {}
-- end snippet --

Will yield a SyntaxError when attempting to import the
module.  Running the module as a script does not provoke the
error.
    
To reproduce, there must be exactly 1532 characters where
specified (see the attached file for a demo).  Adding or
removing even a single character will prevent the error.  It
is possible to replace characters with any others, including
valid code, and still see the error - however, the number of
characters must remain the same .cr/lf pairs can also be
replaced with any other 2 characters.  There are other
"block sizes" that will provoke the error, but this is the
only one I have nailed.
    
Apart from the "block" of 1532 characters, the coding line
and the blank line before the dict assignment also appear
critical.  Unlike the other characters in the block, this
last cr/lf pair can not be replaced with comments.  I can't
provoke the error with other encodings (note there are no
encoded characters in the sample - it is trivial).

To reproduce, save the attached file on Windows and execute:
> python -c "import foo2"
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "foo2.py", line 24
x = {}
    ^
SyntaxError: invalid syntax

Note that Python 2.3 and earlier all work.  Also note that
"python foo2.py" also works.  The code is clearly valid.
    
Haven't tried to repro on Linux (mbcs isn't available there,
and I can't get a test case that doesn't use it)

Other pointers/notes: pywin32 bug 1085454 is related to
long-lines, by all accounts that underlying error has been
fixed - I can't verify this as pywin32 no longer generates
insanely long lines.  I can confirm Python bugs
1101726/1089395 still crashes Python 2.3+.  I believe all
(including this) are discrete bugs.

[foo2.py is my attachment - ya gotta love sourceforge :)]

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 21:28

Message:
Logged In: YES 
user_id=539787

Useful pointers: in Python-dev, this has been characterised
as related to pywin32 bug 1085454.  Also related to
www.python.org/sf/1101726 and www.python.org/sf/1089395.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 13:12:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 13:12:32 2005
Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS
	encoding
Message-ID: <E1DDLll-0003CA-2B@sc8-sf-web4.sourceforge.net>

Bugs item #1163244, was opened at 2005-03-15 07:20
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
>Resolution: Accepted
>Priority: 7
Submitted By: Tim N. van der Leeuw (tnleeuw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax error on large file with MBCS encoding

Initial Comment:
Large files generated by make-py.py from the win32all
extensions cannot be compiled by Python2.4.1rc1 - they
give a syntax error.

This is a regression from 2.3.5

(With Python2.4, the interpreter crashes. That is fixed
now.)

Removing the mbcs encoding line from the top of the
file, compilation succeeds.

File should be attached, as zip-file. Probably requires
win32all extensions to be installed to be compiled /
imported (generated using build 203 of the win32all
extensions).


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-03-21 23:11

Message:
Logged In: YES 
user_id=14198

I believe this is a different bug than the recent
"long-lines" errors (see below).  I can reproduce this with
a file that uses neither long lines, nor any pywin32
extensions (2.4 branch, trunk)

A Python source file containing:
-- start snippet --
# -*- coding: mbcs -*-
<1532 characters of code or comments>
<cr/lf newline>
x = {}
-- end snippet --

Will yield a SyntaxError when attempting to import the
module.  Running the module as a script does not provoke the
error.
    
To reproduce, there must be exactly 1532 characters where
specified (see the attached file for a demo).  Adding or
removing even a single character will prevent the error.  It
is possible to replace characters with any others, including
valid code, and still see the error - however, the number of
characters must remain the same .cr/lf pairs can also be
replaced with any other 2 characters.  There are other
"block sizes" that will provoke the error, but this is the
only one I have nailed.
    
Apart from the "block" of 1532 characters, the coding line
and the blank line before the dict assignment also appear
critical.  Unlike the other characters in the block, this
last cr/lf pair can not be replaced with comments.  I can't
provoke the error with other encodings (note there are no
encoded characters in the sample - it is trivial).

To reproduce, save the attached file on Windows and execute:
> python -c "import foo2"
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "foo2.py", line 24
x = {}
    ^
SyntaxError: invalid syntax

Note that Python 2.3 and earlier all work.  Also note that
"python foo2.py" also works.  The code is clearly valid.
    
Haven't tried to repro on Linux (mbcs isn't available there,
and I can't get a test case that doesn't use it)

Other pointers/notes: pywin32 bug 1085454 is related to
long-lines, by all accounts that underlying error has been
fixed - I can't verify this as pywin32 no longer generates
insanely long lines.  I can confirm Python bugs
1101726/1089395 still crashes Python 2.3+.  I believe all
(including this) are discrete bugs.

[foo2.py is my attachment - ya gotta love sourceforge :)]

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 21:28

Message:
Logged In: YES 
user_id=539787

Useful pointers: in Python-dev, this has been characterised
as related to pywin32 bug 1085454.  Also related to
www.python.org/sf/1101726 and www.python.org/sf/1089395.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 14:34:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 14:34:07 2005
Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS
	encoding
Message-ID: <E1DDN2f-0007il-05@sc8-sf-web1.sourceforge.net>

Bugs item #1163244, was opened at 2005-03-14 22:20
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Tim N. van der Leeuw (tnleeuw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax error on large file with MBCS encoding

Initial Comment:
Large files generated by make-py.py from the win32all
extensions cannot be compiled by Python2.4.1rc1 - they
give a syntax error.

This is a regression from 2.3.5

(With Python2.4, the interpreter crashes. That is fixed
now.)

Removing the mbcs encoding line from the top of the
file, compilation succeeds.

File should be attached, as zip-file. Probably requires
win32all extensions to be installed to be compiled /
imported (generated using build 203 of the win32all
extensions).


----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-21 15:34

Message:
Logged In: YES 
user_id=539787

Could be irrelevant but... are the other block sizes close
to n*512 (eg 1536 is 3*512) marks?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-03-21 14:11

Message:
Logged In: YES 
user_id=14198

I believe this is a different bug than the recent
"long-lines" errors (see below).  I can reproduce this with
a file that uses neither long lines, nor any pywin32
extensions (2.4 branch, trunk)

A Python source file containing:
-- start snippet --
# -*- coding: mbcs -*-
<1532 characters of code or comments>
<cr/lf newline>
x = {}
-- end snippet --

Will yield a SyntaxError when attempting to import the
module.  Running the module as a script does not provoke the
error.
    
To reproduce, there must be exactly 1532 characters where
specified (see the attached file for a demo).  Adding or
removing even a single character will prevent the error.  It
is possible to replace characters with any others, including
valid code, and still see the error - however, the number of
characters must remain the same .cr/lf pairs can also be
replaced with any other 2 characters.  There are other
"block sizes" that will provoke the error, but this is the
only one I have nailed.
    
Apart from the "block" of 1532 characters, the coding line
and the blank line before the dict assignment also appear
critical.  Unlike the other characters in the block, this
last cr/lf pair can not be replaced with comments.  I can't
provoke the error with other encodings (note there are no
encoded characters in the sample - it is trivial).

To reproduce, save the attached file on Windows and execute:
> python -c "import foo2"
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "foo2.py", line 24
x = {}
    ^
SyntaxError: invalid syntax

Note that Python 2.3 and earlier all work.  Also note that
"python foo2.py" also works.  The code is clearly valid.
    
Haven't tried to repro on Linux (mbcs isn't available there,
and I can't get a test case that doesn't use it)

Other pointers/notes: pywin32 bug 1085454 is related to
long-lines, by all accounts that underlying error has been
fixed - I can't verify this as pywin32 no longer generates
insanely long lines.  I can confirm Python bugs
1101726/1089395 still crashes Python 2.3+.  I believe all
(including this) are discrete bugs.

[foo2.py is my attachment - ya gotta love sourceforge :)]

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 12:28

Message:
Logged In: YES 
user_id=539787

Useful pointers: in Python-dev, this has been characterised
as related to pywin32 bug 1085454.  Also related to
www.python.org/sf/1101726 and www.python.org/sf/1089395.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 15:55:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 15:55:21 2005
Subject: [ python-Bugs-1167397 ] Python 2.4 causes BitTorrent 3.4.2 failure
Message-ID: <E1DDOJM-0003Ea-71@sc8-sf-web4.sourceforge.net>

Bugs item #1167397, was opened at 2005-03-21 01:37
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew P. Lentvorski, Jr. (bsder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 causes BitTorrent 3.4.2 failure

Initial Comment:
The following failure messages gets dumped out of
BitTorrent 3.4.2 when run against Python 2.4:

Traceback (most recent call last):
  File "/usr/local/lib/python2.4/threading.py", line
442, in __bootstrap
    self.run()
  File "/usr/local/lib/python2.4/threading.py", line
422, in run
    self.__target(*self.__args, **self.__kwargs)
  File
"/home/andrewl/python/lib/python2.4/site-packages/BitTorrent/Rerequester.py",
line 84, in rerequest
    h = urlopen(url)
  File "/usr/local/lib/python2.4/urllib2.py", line 130,
in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 364,
in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 468,
in http_response
    code, msg, hdrs = response.code, response.msg,
response.info()
AttributeError: addinfourldecompress instance has no
attribute 'code'


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-21 06:55

Message:
Logged In: YES 
user_id=357491

Does this happen if the exact same files are run in 2.3?  I can't find 
addinfourldecompress in Python; is it a BitTorrent class?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 18:01:35 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 18:01:37 2005
Subject: [ python-Bugs-1121494 ] distutils.dir_utils not unicode compatible
Message-ID: <E1DDQHX-0003IE-G4@sc8-sf-web1.sourceforge.net>

Bugs item #1121494, was opened at 2005-02-12 15:47
Message generated for change (Comment added) made by camarajm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121494&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Morten Lied Johansen (epcylon)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils.dir_utils not unicode compatible

Initial Comment:
When sourcefiles are passed in as unicodestrings, distutils.dir_utils.
mkpath will throw a DistutilsInternalError, as shown in the example 
attached.

Using:
Python 2.4 (#1, Feb 12 2005, 20:12:07) 
2.6.9-gentoo-r9 GNU/Linux


----------------------------------------------------------------------

Comment By: John M. Camara (camarajm)
Date: 2005-03-21 12:01

Message:
Logged In: YES 
user_id=1242541

patch 1167716 submitted

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121494&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 18:33:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 18:33:43 2005
Subject: [ python-Bugs-812340 ] BasHTTPServer IE Mac 5.1 size problem
Message-ID: <E1DDQmZ-0004hy-Ab@sc8-sf-web4.sourceforge.net>

Bugs item #812340, was opened at 2003-09-25 06:24
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812340&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Sven Passig (coderscom)
Assigned to: Nobody/Anonymous (nobody)
Summary: BasHTTPServer IE Mac 5.1 size problem

Initial Comment:
I run a BaseHTTPServer that way:

import CGIHTTPServer
import BaseHTTPServer
Handler = CGIHTTPServer.CGIHTTPRequestHandler
PORT = 8080
httpd = BaseHTTPServer.HTTPServer((&quot;&quot;, PORT), Handler)
print &quot;Serving at port &quot;, PORT
httpd.serve_forever()

on a linux, windows or OSX System, doasn't matter for 
the problem

When i try to get a a big html-side (static html or cgi, 
doasn't matter) with InternetExplorer 5.1 on OSX or OS9 
the server hangs itself up.

I try to figure out the reason. It deppends on the size:

BaseHTTPServer (V. 06) do in line 43 :
self.copyfile(f, self.wfile)

copyfile is defined in line 146 and just do a

shutil.copyfileobj(source, outputfile)

copyfileobj in shutil is defined in line 14 and try to read 
and write blocks of 16*1024 size.

I changed that and read 1024 byte blocks.
It worked 116 times. After that the IE seams to block. 
(shutil (line 20) try to make the fdst.write(buf) but never 
finished)

Other WebBrowsers (f.e. Apache) are able to support 
bigger sides for the Mac IE 5.1. So it's (at least not only)
an IE problem and should be fixed in the Python Web 
Server (IMHO).
Any ideas how to fix ?


I us Python 2.2 but I installed the newest versions of 
BasHTTPServer, CGIHTTPServer, SimpleHTTPServer and 
SocketServer.

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 14:33

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-08 21:35

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812340&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 18:36:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 18:36:40 2005
Subject: [ python-Bugs-791067 ] Section 11.20: xmlrpclib Details
Message-ID: <E1DDQpT-0005Gu-1L@sc8-sf-web1.sourceforge.net>

Bugs item #791067, was opened at 2003-08-19 05:20
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791067&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: J?rgen Hermann (jhermann)
Assigned to: Nobody/Anonymous (nobody)
Summary: Section 11.20: xmlrpclib Details

Initial Comment:
An important detail is missing from the LaTeX library
ref, namely how to get at the values of the special
types (bool, date, binary); I had to inspect code to
get at this (I think even the module docstrings don't
reveal this).

Naively (with str) you get the repr() values:
  &lt;Boolean True at 8287f8c&gt;,
  &lt;DateTime 20030818T18:42:52 at 829ab94&gt;,
  &lt;xmlrpclib.Binary instance at 0x829aeb4&gt;),

To get at the underlying real values, you need:
  int(boolval) (or bool(boolval) for 2.3)
  dateval.value
  binary.data

This should be documented on the relevant sections
(11.20.2/3/4).


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 14:36

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-11 23:12

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-11 23:12

Message:
Logged In: YES 
user_id=752496

Doc changed a lot, don't know enough about the subject to be
clear to me if the problem is solved or not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791067&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 18:40:18 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 18:40:20 2005
Subject: [ python-Bugs-767150 ] socket.inet_aton on 64bit platform
Message-ID: <E1DDQt0-0005S6-34@sc8-sf-web1.sourceforge.net>

Bugs item #767150, was opened at 2003-07-07 11:03
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767150&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Geert Jansen (geertj)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.inet_aton on 64bit platform

Initial Comment:
Hi,

socket.inet_aton() returns an 8 byte string when built 
on Linux/IA64. This should be 4 bytes on all 
architectures. Example:

&gt;&gt;&gt; import socket
&gt;&gt;&gt; socket.inet_aton('192.168.2.1')
'\xc0\xa8\x02\x01\x00\x00\x00\x00'

The bug is caused by Modules/socketmodule.c using 
sizeof(unsinged long) when constructing the string, 
which is 8 bytes on Linux/IA64.

The bug seems to be fixed in Python 2.3 in the case 
struct in_addr is available. Otherwise it still uses an 
unsigned long.

Geert



----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 14:40

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-11 23:16

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Mats Wichmann (mwichmann)
Date: 2004-08-12 13:45

Message:
Logged In: YES 
user_id=53605

I've just run into this problem, which is still present in
current cvs.   This now (2.3.x and cvs head) occurs for the
code path where inet_aton is not detected by configure, so
it's not a terribly common case. Of course, I have one ...
The conversion needs to be done on a 32-bit quantity.  It's
a one-liner to fix, I'll submit a patch if I can make the
patch manager work for me.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-07 18:10

Message:
Logged In: YES 
user_id=21627

Can you try to come up with a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767150&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 18:43:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 18:43:11 2005
Subject: [ python-Bugs-685846 ] raw_input defers alarm signal
Message-ID: <E1DDQvj-0005Cc-A8@sc8-sf-web4.sourceforge.net>

Bugs item #685846, was opened at 2003-02-13 07:11
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685846&group_id=5470

Category: Python Library
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input defers alarm signal

Initial Comment:
import signal
def handle(a,b):
   print &quot;received signal&quot;
signal.signal(signal.SIGALRM, handle)
signal.alarm(5)
name = raw_input('Please enter your name within 5
seconds: ')


waits for input forever instead of getting the signal
thrown
after 5 seconds.  If you wait more than 5 seconds before
typing your name, the signal does get handled after you
finally enter your input.

The workaround of calling sys.stdin.readline() instead of
raw_input does the right thing, so something is funny about
the raw_input function.


----------------------------------------------------------------------

Comment By: Michael Stone (mbrierst)
Date: 2003-03-19 14:51

Message:
Logged In: YES 
user_id=670441

This isn't just a readline problem,
it's consistent whether or not readline
is used.  Patch #706406 attempts
to fix this problem in a reasonable manner,
but it may not be possible to fix perfectly.
Signals always seem pretty hopeless to
get really right, and python hardly tries
most of the time.  (Only handling them in
the main thread...)

I think raw_input really doesn't WANT to
just give up when receiving a signal, so the
patch has it give up only when the signal
handler throws an exception.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-02-13 08:46

Message:
Logged In: YES 
user_id=6656

I'm 99% sure this is readline's fault.

You might be able to test this by hiding the readline.so
from the interpreter.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685846&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 18:47:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 18:48:01 2005
Subject: [ python-Bugs-1167751 ] Argument genexp corner case
Message-ID: <E1DDR0R-0007y1-P7@sc8-sf-web3.sourceforge.net>

Bugs item #1167751, was opened at 2005-03-21 17:47
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=1167751&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Argument genexp corner case

Initial Comment:
The following raises an unexpected exception; I would
expect it to either work or raise a SyntaxError.  It
seems that the grammar parses it, but the compiler does
not do the right thing.

>>> def foo(a): pass

>>> foo(a = i for i in range(10))

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'i' is not defined

foo(a = (i for i in range(10)) works.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167751&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 19:04:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 19:04:14 2005
Subject: [ python-Bugs-613222 ] memory leaks when importing posix module
Message-ID: <E1DDRG7-0004LH-HA@sc8-sf-web2.sourceforge.net>

Bugs item #613222, was opened at 2002-09-23 11:27
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613222&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: memory leaks when importing posix module

Initial Comment:
The attached program which calls
Py_Initialize/Py_Finalize in a loop demonstrates a
program which grows quite quickly.  This bug effects
2.2.1+ and 2.3.  valgrind reports that the memory is
still reachable, but it seems like a memory leak and
the process definitely grows.

Compile the program with libpython, and run (./mem-test
100000).  Make sure it can import site (which imports
posix module).  While the program is running, do a ps
and watch it grow.  If import site fails, the process
will not grow.

site.py can be as simple as import posix.
I believe the problem is related to
PyStructSequence_Fields for statfs.  But haven't
completely diagnosed the problem.  As I learn more, I
will add comments.

To simply importing or not importing site, mem-test
takes an optional 2nd argument which will
enable/disable loading of site.py.  ./mem-test 100000 1
will prevent import site.

I hope this is understandable, even though the
description wasn't clear.

----------------------------------------------------------------------

>Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 15:04

Message:
Logged In: YES 
user_id=752496

Changed to 2.3 group.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-26 12:16

Message:
Logged In: YES 
user_id=6380

I expect I will have no time to look into this further any
time soon. But if you have fixes that clearly fix leaks,
please check them in!

(Shouldn't this be in the 2.3 group?)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-24 21:37

Message:
Logged In: YES 
user_id=33168

I'm mostly stuck.  I haven't solved the problem, but I do
have some more information.  Attached is a patch to
Object/structseq.c which fixes some problems if memory
allocation fails.  Also, I changed a PyInt_FromLong(1) to
Py_True for __safe_for_unpickling__.  Py_True could also be
used in compile.c::
symtable_load_symbols replacing the variable: implicit.

Some fields which I believe are leaking from the
PyTypeObject are:  tp_members, tp_dict, and tp_bases. 
However, there are more leaks.  I think all the remaining
leaks come from PyType_Ready().  For example, from
add_operators(), PyDescr_NewWrapper().  I thought DECREFing
tp_dict would free these, but it didn't seem to have any effect.

Part of the problem is how should these values be cleaned
up.  Putting cleanup in PyStructSequence_InitType would
guarantee the problem is fixed for all structseqs, but that
doesn't seem like a good idea.  This would assume the
PyTypeObject passed in is initialized.  This is true for
static variables, but not for any other variables.  If
there's a new API for cleanup, all the users of structseq
will need to use it.  Perhaps, this is only an issue in the
core.  I don't know about extension modules.

Finally, I suspect there may be more leaks outside of posix
too.  These seem to mostly come from _Py_ReadyTypes() called
in pythonrun.c::Py_Initialize().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-23 13:32

Message:
Logged In: YES 
user_id=6380

This is a good use of your time.  Thanks for looking into
this! Assign back to me when you have a fix for review or a
stumbling block.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613222&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 19:32:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 19:32:18 2005
Subject: [ python-Bugs-606692 ] xml.sax second time file loading problem
Message-ID: <E1DDRhH-00082e-5u@sc8-sf-web1.sourceforge.net>

Bugs item #606692, was opened at 2002-09-09 09:36
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606692&group_id=5470

Category: XML
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Adam Widera (adamwidera)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax second time file loading problem

Initial Comment:
Platform: windows 2000 SP2 (Pl)
Python version: Python 2.2 (#28, Dec 21 2001, 
12:21:22) [MSC 32 bit (Intel)] on win32

I have noticed strange problem while using the xml.sax 
module. When I run my application using python.exe 
everything is working fine, the error occures only when I 
try to execute my script using pythonw.exe.

The problematic code looks approximately like this (It's 
a PyQT based application btw):

parser = xml.sax.make_parser()
handler = MyAppDocumentHandler()
parser.setContentHandler(handler)
try:
   self.parser.parse(fileName)
   except IOError:
      QMessageBox.information(None,&quot;MyApp&quot;,&quot;Sorry, 
problems occured while loading:\n&quot;+fileName+&quot;\n\nIO 
error:\n&quot;+str(sys.exc_info()[1]))
      return FALSE
   except:
      print &quot;Unhandled exception:&quot;, sys.exc_info()[0]
      QMessageBox.information(None,&quot;MyApp&quot;,&quot;Sorry, 
problems occured while 
loading:\n&quot;+fileName+&quot;\n\nParser error:\n&quot;+str
(sys.exc_info()[0]))
      return FALSE

The first time when I open the file everything works ok, 
the file is parsed, but when I try to open another file I 
catch the IOError [Errno 9] Bad file descriptor error. (The 
file location and everything else is ok.)

Greetings
Adam Widera

PS: If You have more questions about the bug or have 
problems with trigging the bug out get me know. My e-
mail: adamwidera@wp.pl



----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 15:32

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-15 21:38

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Adam Widera (adamwidera)
Date: 2002-09-12 14:23

Message:
Logged In: YES 
user_id=608362

Hi Martin

No. I'm affraid no. It happens even if it is the only one
and the first application that is running on the system
(except background ones). It is verry unpredictible, I have
tested it once again and I have noticed that the smaller and
verry simple xml files (2k) were loading without problems
and the the error occured only while loading the bigger ones
(37k). At the same time yesterday the problem occured while
loading smaller files too. Maybe it is a memory management
problem?

Greetings
Adam Widera


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-09-11 13:37

Message:
Logged In: YES 
user_id=21627

Is there any chance that when you run the application the
second time, that the first instance is still around? Please
use the process viewer to find out whether there are any
remaining Python processes - this could be a sharing violation.

----------------------------------------------------------------------

Comment By: Adam Widera (adamwidera)
Date: 2002-09-09 10:07

Message:
Logged In: YES 
user_id=608362

Platform: windows 2000 SP2 (Pl)
Python version: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC
32 bit (Intel)] on win32

Correction to the previous bug message:
the 5'th line of the example should of course look like this:

parser.parse(fileName)

not

self.parser.parse(fileName)

The bug is still actual (the literal mistake took place only
in the bug report message)

Greetings
Adam Widera



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606692&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 19:35:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 19:35:08 2005
Subject: [ python-Bugs-699068 ] Error using Tkinter embeded in C++
Message-ID: <E1DDRk2-0001yS-Qh@sc8-sf-web3.sourceforge.net>

Bugs item #699068, was opened at 2003-03-06 20:15
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699068&group_id=5470

Category: Tkinter
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: John (johnnoone)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error using Tkinter embeded in C++

Initial Comment:
Using Python 2.2.2 on MS Windows 2000 platform. 
Calling embedded Python from Visual C++ works fine 
until I add a call to Tkinter (version 8.3). Follow the 
example in section 5.3 at the following link:
http://www.python.org/doc/ext/extending-with-
embedding.html
Link call.cpp as is and add a line to multiply.py to 
create a Tkinter frame:
&quot;fr = Tkinter.Tk()&quot;   // added import for Tkinter too!
Yields the following error messages:

C:\Python22\c\vcpp\hello3&gt;hello3 call multiply 2 3
Thy shall add 2 times 3
Traceback (most recent call last):
  File &quot;C:\Python22\c\vcpp\hello3\call.py&quot;, line 7, in 
multiply
    fr = Tk()
  File &quot;C:\Python22\lib\lib-tk\Tkinter.py&quot;, line 1491, in 
__init__
    baseName = os.path.basename(sys.argv[0])
AttributeError: 'module' object has no attribute 'argv'
Call failed

Is there a problem using Tkinter from C++? Python/Tk 
work fine standalone.





----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 15:35

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-11 23:18

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-03-15 10:38

Message:
Logged In: YES 
user_id=21627

Please look at the source of sysmodule.c. sys.argv is only
present if PySys_SetArgv is invoked.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699068&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 19:37:12 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 19:37:15 2005
Subject: [ python-Bugs-532007 ] urllib ftp broken if Win32 proxy
Message-ID: <E1DDRm4-0008GH-Qr@sc8-sf-web1.sourceforge.net>

Bugs item #532007, was opened at 2002-03-19 16:36
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: David Medberry (medberry)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib ftp broken if Win32 proxy

Initial Comment:
If Win32 has a proxy enabled, ftp urls will NOT work in
urllib.

Here is a trace:
Traceback (most recent call last):
  File
&quot;C:\Python22\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py&quot;,
line 301, in RunScript
    exec codeObject in __main__.__dict__
  File &quot;C:\Python22\Lib\urllib.py&quot;, line 1457, in ?
    main()
  File &quot;C:\Python22\Lib\urllib.py&quot;, line 1448, in main
    test(args)
  File &quot;C:\Python22\Lib\urllib.py&quot;, line 1410, in test
    fn, h = urlretrieve(url, None, reporthook)
  File &quot;C:\Python22\Lib\urllib.py&quot;, line 80, in urlretrieve
    return _urlopener.retrieve(url, filename,
reporthook, data)
  File &quot;C:\Python22\Lib\urllib.py&quot;, line 210, in retrieve
    fp = self.open(url, data)
  File &quot;C:\Python22\Lib\urllib.py&quot;, line 178, in open
    return getattr(self, name)(url)
  File &quot;C:\Python22\Lib\urllib.py&quot;, line 438, in open_ftp
    host, path = splithost(url)
  File &quot;C:\Python22\Lib\urllib.py&quot;, line 944, in splithost
    match = _hostprog.match(url)
TypeError: expected string or buffer

If the Win32 proxy is removed, it resumes working. In
urllib splithost, url is None or an empty tuple
(instead of the actual url.)

To reproduce, just enable a proxy on Win32 and execute
the &quot;urllib.py -t&quot; selftest. Disable the proxy and it
will be restored.

I haven't got the setup to check if web_proxy or
ftp_proxy on Posix machines causes the same problem.



----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 15:37

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-15 21:52

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-02-24 18:01

Message:
Logged In: YES 
user_id=57665

Problem is that open_ftp() does not check if the &quot;url&quot;
argument is a string or a tuple.  When ftp_proxy is set it
is a tuple, thus always causes the open() call to fail. 
This is not specific for Win32.

open_http() starts with this check:
       if type(url) is types.StringType:
open_ftp() should do something similar.

This is unrelated to bug 503031.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 20:42

Message:
Logged In: YES 
user_id=6380

Medberry, can you see if the patch from SF bug 503031
(http://www.python.org/sf/503031) solves your problem?

----------------------------------------------------------------------

Comment By: David Medberry (medberry)
Date: 2002-03-19 19:46

Message:
Logged In: YES 
user_id=95087

&lt;bold&gt;Is this bold?&lt;/bold&gt;

----------------------------------------------------------------------

Comment By: David Medberry (medberry)
Date: 2002-03-19 19:44

Message:
Logged In: YES 
user_id=95087

This is _NOT_ a bug under Linux Python 2.2--it works just
fine there. (Makes me curious why it would behave
differently under Windows, but I'm not sure where to look yet.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 20:30:27 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 20:30:31 2005
Subject: [ python-Bugs-516232 ] Windows os.path.isdir bad if drive only
Message-ID: <E1DDSbb-0002TV-Hg@sc8-sf-web1.sourceforge.net>

Bugs item #516232, was opened at 2002-02-11 19:50
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516232&group_id=5470

Category: Extension Modules
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles I. Fuller (cifuller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Windows os.path.isdir bad if drive only

Initial Comment:
It seems that most os functions recognize the Windows 
drive letter without a directory as the current 
directory on the drive, but os.path.isdir still 
returns 0.  If os.listdir('C:') returns data, 
os.path.isdir('C:') should return 1 for consistency.

C:\folder_on_C&gt;python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for 
more information.
&gt;&gt;&gt; import os
&gt;&gt;&gt; os.system('dir C:')
 Volume in drive C has no label.
 Volume Serial Number is E4C9-AD16

 Directory of C:\folder_on_C

02/11/2002  05:29p      &lt;DIR&gt;          .
02/11/2002  05:29p      &lt;DIR&gt;          ..
02/11/2002  05:29p      &lt;DIR&gt;          subA
02/11/2002  05:29p      &lt;DIR&gt;          subB
               0 File(s)              0 bytes
               4 Dir(s)  22,126,567,424 bytes free
0
&gt;&gt;&gt; os.listdir('C:')
['subA', 'subB']
&gt;&gt;&gt; os.path.abspath('C:')
'C:\folder_on_C'
&gt;&gt;&gt; os.path.isdir('C:')
0

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 16:30

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-12 19:33

Message:
Logged In: YES 
user_id=31435

Well, the underlying Microsoft routines are themselves 
inconsistent, and in undocumented ways.  We make a mild 
effort to hide their warts, but it's historical truth that 
doing so introduces other bugs.  The sad fact is that MS 
stat() insists &quot;C:&quot; does not exist, but the MS 
FindFirstFile happily accepts &quot;C:&quot;.  If you think *you* can 
straigten this inherited mess out, happy to accept a patch 
&lt;wink&gt;.

----------------------------------------------------------------------

Comment By: Charles I. Fuller (cifuller)
Date: 2002-02-12 18:54

Message:
Logged In: YES 
user_id=211047

Responding to Tim's followup...

In this case the 'C:' is not the root drive, it is the 
current dir on that drive.  I noticed that os.path.abspath 
was updated between 2.0 and 2.2 to recognize the current 
dir.

It's an inconsistency that tripped me up already.

&gt;&gt;&gt; os.path.isdir('C:')
0
&gt;&gt;&gt; os.path.isdir(os.path.abspath('C:'))
1

The listdir has been working with drive specs (recognizing 
the current dir) for a while.  The abspath code must be 
handling the drive-only input as a special case.  The isdir 
function should do the same for consistency.

There should at least be a warning in the docs...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 20:16

Message:
Logged In: YES 
user_id=31435

Sorry, this is how Microsoft's implementation of the 
underlying stat() function works.  &quot;Root drive&quot; paths must 
be given with a trailing slash or backslash, else MS stat() 
claims they don't exist.  You'll see the same irritating 
behavior in C code.  Attempts to worm around it in the past 
have introduced other bugs; see bug 513572 for a current 
example.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516232&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 20:40:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 20:41:01 2005
Subject: [ python-Bugs-1167329 ] xmlrpclib invalid url
Message-ID: <E1DDSlm-0005Bs-6G@sc8-sf-web3.sourceforge.net>

Bugs item #1167329, was opened at 2005-03-21 00:31
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167329&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Doukidis (doukm)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib invalid url

Initial Comment:
Within section:

11.22 xmlrpclib -- XML-RPC client access

URL http://ontosys.com/xml-rpc/extensions.html

is invalid.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2005-03-21 13:40

Message:
Logged In: YES 
user_id=44345

fixed on 2.3, 2.4 and head

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167329&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 21:44:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 21:44:51 2005
Subject: [ python-Bugs-1167397 ] Python 2.4 causes BitTorrent 3.4.2 failure
Message-ID: <E1DDTlZ-0003qN-3p@sc8-sf-web2.sourceforge.net>

Bugs item #1167397, was opened at 2005-03-21 09:37
Message generated for change (Comment added) made by bsder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew P. Lentvorski, Jr. (bsder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 causes BitTorrent 3.4.2 failure

Initial Comment:
The following failure messages gets dumped out of
BitTorrent 3.4.2 when run against Python 2.4:

Traceback (most recent call last):
  File "/usr/local/lib/python2.4/threading.py", line
442, in __bootstrap
    self.run()
  File "/usr/local/lib/python2.4/threading.py", line
422, in run
    self.__target(*self.__args, **self.__kwargs)
  File
"/home/andrewl/python/lib/python2.4/site-packages/BitTorrent/Rerequester.py",
line 84, in rerequest
    h = urlopen(url)
  File "/usr/local/lib/python2.4/urllib2.py", line 130,
in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.4/urllib2.py", line 364,
in open
    response = meth(req, response)
  File "/usr/local/lib/python2.4/urllib2.py", line 468,
in http_response
    code, msg, hdrs = response.code, response.msg,
response.info()
AttributeError: addinfourldecompress instance has no
attribute 'code'


----------------------------------------------------------------------

>Comment By: Andrew P. Lentvorski, Jr. (bsder)
Date: 2005-03-21 20:44

Message:
Logged In: YES 
user_id=752864

The same BitTorrent version works just fine under 2.3.5.

addinfourldecompress is a BitTorrent object which inherits
from Python's addinfourl in urllib.py.

The following comment was found in a patch that attempted to
work around the issue:

# As of Python 2.4 http_open response also has 'code' and 'msg'
# members, and HTTPErrorProcessor breaks if they don't exist.

This problem has been cited in a couple of different
contexts.  I saw it in a bug report for bittornado on
FreeBSD.  I also saw it in a RedHat list concerning breakage
in the yum utility.

Annoyingly, nobody seems to have filed it upstream with the
Python folks.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-21 14:55

Message:
Logged In: YES 
user_id=357491

Does this happen if the exact same files are run in 2.3?  I can't find 
addinfourldecompress in Python; is it a BitTorrent class?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 22:33:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 22:34:00 2005
Subject: [ python-Bugs-1166274 ] missing sequence tests - pull from deque
Message-ID: <E1DDUX8-000625-2W@sc8-sf-web2.sourceforge.net>

Bugs item #1166274, was opened at 2005-03-18 23:21
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166274&group_id=5470

Category: Python Library
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Walter D?rwald (doerwalter)
Summary: missing sequence tests - pull from deque

Initial Comment:
tuples and lists can be initialized from any sequence, 
including an iterator.  This is not tested.  The iterator 
tests in test_deque would do a good job.

list_tests (for list and UserList) test_remove does not 
test that it is the _first_ occurence that gets removed.  
Again, the deque tests that Raymond just checked in 
are up to the job, if "deque" is replaced by "type2test"

----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-21 22:33

Message:
Logged In: YES 
user_id=89016

Checked in the remove test as:
Lib/test/list_tests.py 1.6
(Note that I've dropped the evil mutator test, because it
doesn't raise an exception).

I'll add the iterator initialization test tomorrow.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166274&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 23:07:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 23:07:03 2005
Subject: [ python-Bugs-1167922 ] Line ending documentation is misleading
Message-ID: <E1DDV37-0001Fi-Cg@sc8-sf-web4.sourceforge.net>

Bugs item #1167922, was opened at 2005-03-21 22:06
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=1167922&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line ending documentation is misleading

Initial Comment:
The documentation of line ending conventions is
misleading when embedding Python.

The only documentation I can find on line endings is in
the language reference - section 2.1.2 "Physical
Lines". This describes a physical line as being
terminated with the platform line terminator.

When referring to source files, this is wrong, as
universal newline support now means that any of CR, LF,
or CRLF is a valid line terminator on all platforms.
When embedding (via something like PyRun_SimpleString)
a C-level newline terminator (ie, "\n") is the line
terminator.

I attach a suggested patch to the ref\ref2.tex
documentation file (patch against CVS HEAD as at 29th Jan).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167922&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 23:07:38 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 23:07:41 2005
Subject: [ python-Bugs-1167922 ] Line ending documentation is misleading
Message-ID: <E1DDV3i-0001GV-Qr@sc8-sf-web4.sourceforge.net>

Bugs item #1167922, was opened at 2005-03-21 22:06
Message generated for change (Settings changed) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167922&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Line ending documentation is misleading

Initial Comment:
The documentation of line ending conventions is
misleading when embedding Python.

The only documentation I can find on line endings is in
the language reference - section 2.1.2 "Physical
Lines". This describes a physical line as being
terminated with the platform line terminator.

When referring to source files, this is wrong, as
universal newline support now means that any of CR, LF,
or CRLF is a valid line terminator on all platforms.
When embedding (via something like PyRun_SimpleString)
a C-level newline terminator (ie, "\n") is the line
terminator.

I attach a suggested patch to the ref\ref2.tex
documentation file (patch against CVS HEAD as at 29th Jan).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167922&group_id=5470
From noreply at sourceforge.net  Mon Mar 21 23:19:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 21 23:19:18 2005
Subject: [ python-Bugs-1167930 ] threading.Thread.join() cannot be
	interrupted by a Ctrl-C
Message-ID: <E1DDVEx-00086K-E3@sc8-sf-web2.sourceforge.net>

Bugs item #1167930, was opened at 2005-03-21 14:19
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=1167930&group_id=5470

Category: Threads
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicholas Veeser (nveeser)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread.join() cannot be interrupted by a Ctrl-C

Initial Comment:
I write a python program that that starts several
threads and then waits on them all.  If I use join() to
wait on the threads, there is no way to Stop the
process with Ctrl-C.  

Threading.Thread.join() uses a lock
(thread.allocate_lock())  to put itself on the
"wait_queue".    It then calls thread.Lock.acquire(),
which blocks indefinitely.  Lock.acquire() (at least in
POSIX) seems to work in such a way as to ignore any
signals.  (both semaphore and condition variable type).
    

PyThread_acquire_lock() will not return until the lock
is acquired, even if a signal is sent.   Effectively,
Ctrl-C is "masked" until the lock is released, (the
joined thread is done), and the main thread comes back
to the interpreter and handles the signal, producing a
KeyboardInterrupt Exception.  But not before the lock
is released, which is once the thread is finished,
which is too late if you want to kill the main thread
and have it gracefully stop its child threads.

So the "main" thread has no way to call, join() and
still respond to Ctrl-C in some way.

One solution could be to change threading.Thread.join()
to use other methods of synchronization which respond
to Ctrl-C more effectively.

Another solution would be to have Lock.acquire() throw
a KeyboardInterruped exception like other system calls.
 This IHMO would make the python objects behave more
like Java, which requires catching the
InterruptedException, giving the developer more control
over how to handle this case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167930&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 01:15:12 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 01:15:27 2005
Subject: [ python-Bugs-1162677 ] Unable to Install Python 2.4.1rc1 on
	windows XP SP2
Message-ID: <E1DDX3A-0008DG-0c@sc8-sf-web1.sourceforge.net>

Bugs item #1162677, was opened at 2005-03-14 01:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sergio Correia (sergiocorreia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to Install  Python 2.4.1rc1 on windows XP SP2

Initial Comment:
First of all, YES i had everything i needed to install,
and yes i read the info on the site.

When i tried to install python-2.4.1c1.msi (or even
ActivePython-2.4.0-244-win32-ix86.msi), install "ended
prematurely because of an error".

I tried everything but, after a while i found a way to
avoid the bug.

I was installing from "F:\Docs\Varios\Sandbox".. i
moved the msi file to C:\ and then the install (both,
python and activepython) worked out perfectly.

Folders were not shared, restricted, compressed or on a
network (it was a normal local hard disk).

Any ideas on why that happened?

Thanks


PS: Sorry about the sp. mistakes. I am not very fluent
on technical english.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-22 01:15

Message:
Logged In: YES 
user_id=21627

Can you please check that the file downloads correctly? I get a zipfile, but 
that only contains a garbage python.log (i.e. no text file). Perhaps you can 
try to attach it uncompressed?

----------------------------------------------------------------------

Comment By: Sergio Correia (sergiocorreia)
Date: 2005-03-15 07:00

Message:
Logged In: YES 
user_id=1238520

Thanks for the reply.

So i uninstalled it, tried again from 
the "F:\Docs\Varios\Sandbox" folder, got the same error, and 
attached the log.

Btw,  F: is a physical drive, and its not SUBSTed.

=)

Oh, the last lines of the log were:
=== Logging stopped: 15/03/2005  00:54:23 ===
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 1708 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Product: Python 2.4.1c1 -- 
Installation failed.

MSI (c) (24:A0) [00:54:23:163]: Grabbed execution mutex.
MSI (c) (24:A0) [00:54:23:163]: Cleaning up uninstalled install 
packages, if any exist
MSI (c) (24:A0) [00:54:23:173]: MainEngineThread is 
returning 1603
=== Verbose logging stopped: 15/03/2005  00:54:23 ===


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 22:36

Message:
Logged In: YES 
user_id=21627

No, but I know how to find out. Please run, in a cmd.exe window,

msiexec /i python-2.4.1c1.msi /l*v python.log

Compress python.log with Winzip, and attach the resulting
file to this report.

As a wild guess: could it be that F: is SUBSTed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 01:27:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 01:27:59 2005
Subject: [ python-Bugs-1162677 ] Unable to Install Python 2.4.1rc1 on
	windows XP SP2
Message-ID: <E1DDXFV-0000n8-7Z@sc8-sf-web3.sourceforge.net>

Bugs item #1162677, was opened at 2005-03-13 19:32
Message generated for change (Comment added) made by sergiocorreia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sergio Correia (sergiocorreia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to Install  Python 2.4.1rc1 on windows XP SP2

Initial Comment:
First of all, YES i had everything i needed to install,
and yes i read the info on the site.

When i tried to install python-2.4.1c1.msi (or even
ActivePython-2.4.0-244-win32-ix86.msi), install "ended
prematurely because of an error".

I tried everything but, after a while i found a way to
avoid the bug.

I was installing from "F:\Docs\Varios\Sandbox".. i
moved the msi file to C:\ and then the install (both,
python and activepython) worked out perfectly.

Folders were not shared, restricted, compressed or on a
network (it was a normal local hard disk).

Any ideas on why that happened?

Thanks


PS: Sorry about the sp. mistakes. I am not very fluent
on technical english.

----------------------------------------------------------------------

>Comment By: Sergio Correia (sergiocorreia)
Date: 2005-03-21 19:27

Message:
Logged In: YES 
user_id=1238520

I uploaded the file again, downloaded it and it worked. ^_^

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-21 19:15

Message:
Logged In: YES 
user_id=21627

Can you please check that the file downloads correctly? I get a zipfile, but 
that only contains a garbage python.log (i.e. no text file). Perhaps you can 
try to attach it uncompressed?

----------------------------------------------------------------------

Comment By: Sergio Correia (sergiocorreia)
Date: 2005-03-15 01:00

Message:
Logged In: YES 
user_id=1238520

Thanks for the reply.

So i uninstalled it, tried again from 
the "F:\Docs\Varios\Sandbox" folder, got the same error, and 
attached the log.

Btw,  F: is a physical drive, and its not SUBSTed.

=)

Oh, the last lines of the log were:
=== Logging stopped: 15/03/2005  00:54:23 ===
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 1708 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Product: Python 2.4.1c1 -- 
Installation failed.

MSI (c) (24:A0) [00:54:23:163]: Grabbed execution mutex.
MSI (c) (24:A0) [00:54:23:163]: Cleaning up uninstalled install 
packages, if any exist
MSI (c) (24:A0) [00:54:23:173]: MainEngineThread is 
returning 1603
=== Verbose logging stopped: 15/03/2005  00:54:23 ===


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 16:36

Message:
Logged In: YES 
user_id=21627

No, but I know how to find out. Please run, in a cmd.exe window,

msiexec /i python-2.4.1c1.msi /l*v python.log

Compress python.log with Winzip, and attach the resulting
file to this report.

As a wild guess: could it be that F: is SUBSTed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 07:58:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 07:58:05 2005
Subject: [ python-Bugs-1168135 ] Python 2.5a0 Tutorial errors and
	observations
Message-ID: <E1DDdL0-0005Mv-Ti@sc8-sf-web1.sourceforge.net>

Bugs item #1168135, was opened at 2005-03-21 22:58
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=1168135&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael R Bax (mrbax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5a0 Tutorial errors and observations

Initial Comment:
Please find attached my updated list of errors and 
observations in response to Python 2.5a0.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 16:38:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 16:38:09 2005
Subject: [ python-Bugs-1168427 ] Possible windows+python bug
Message-ID: <E1DDlSI-0001L8-Gd@sc8-sf-web2.sourceforge.net>

Bugs item #1168427, was opened at 2005-03-22 16:38
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=1168427&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 21:34:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 21:34:51 2005
Subject: [ python-Bugs-1166714 ] [ast branch] fatal error when compiling
	test_bool.py
Message-ID: <E1DDq5R-0004mn-0D@sc8-sf-web1.sourceforge.net>

Bugs item #1166714, was opened at 2005-03-19 16:14
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Brett Cannon (bcannon)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-22 12:34

Message:
Logged In: YES 
user_id=357491

An short example of the failure::

 def outer(a):
    def first(): a
    def last(a): pass

This leads to a fatal Python error.  The issue is having a being a local or 
parameter (can make 'a' be 'a = 1' and not a parameter and still have it 
fail), the first closure reference it, and then the second one use it as a 
parameter.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 22:04:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 22:04:16 2005
Subject: [ python-Bugs-1003195 ] segfault when running smtplib example
Message-ID: <E1DDqXo-0002Zn-9F@sc8-sf-web4.sourceforge.net>

Bugs item #1003195, was opened at 2004-08-04 08:43
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Bertram Scharpf (bertramscharpf)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault when running smtplib example

Initial Comment:
On my system, running the simple smtplib Example
from the Documentation results in a segmentation fault.
Execution stops and no mail is submitted.

I debugged into the Python source code, but my
understanding of the inner mechanisms doesn't
suffice to fix the problem.

I update my system periodically using "apt-get update ;
apt-get upgrade". I don't remember, when it was the last
time Python was upgraded.

I made the files availabe:

http://www.bertram-scharpf.de/tmp/smtpex.py.txt
http://www.bertram-scharpf.de/tmp/smtpex.desc.txt



----------------------------------------------------------------------

Comment By: Bertram Scharpf (bertramscharpf)
Date: 2004-12-27 07:30

Message:
Logged In: YES 
user_id=1097255

> I'll close this bug as "Won't fix".

I think that's OK.



----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 19:00

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Bertram Scharpf (bertramscharpf)
Date: 2004-08-08 04:14

Message:
Logged In: YES 
user_id=1097255

Indeed, I did compile python 2.2.1 with Gcc versions 2.95,
3.0 and 3.3. The segfault only occurs in the 2.95 compiled code.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-07 11:30

Message:
Logged In: YES 
user_id=580910

I cannot reproduce this.

I've tested: 

Python 2.3 (#1, Sep 13 2003, 00:49:11) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

Python 2.3.4 (#2, Jul  5 2004, 09:15:05) 
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2

Python 2.2.3+ (#1, Jun 20 2004, 13:32:48) 
[GCC 3.3.4 (Debian)] on linux2

The first is the system python on MacOS X, the other two are current 
Debian packages (python2.3 and python2.2) on Debian stable.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 22:05:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 22:05:57 2005
Subject: [ python-Bugs-779388 ] sgmllib incorrectly handles entities in
	attributes
Message-ID: <E1DDqZW-0002BU-Rh@sc8-sf-web2.sourceforge.net>

Bugs item #779388, was opened at 2003-07-29 02:43
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779388&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Misha Bergal (mbergal)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib incorrectly handles entities in attributes

Initial Comment:
The following test inserted in test_sgmllib.py fails
    def test_entities_in_attrs(self):
        &quot;&quot;&quot;Be sure quotes entities are treated right 
attributes&quot;&quot;&quot;
        self.check_events(&quot;&lt;a href=\&quot;&amp;amp;\&quot;&gt;&quot;, [
            (&quot;starttag&quot;, &quot;a&quot;, [(&quot;href&quot;, '&amp;')]),
            ])



----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 18:05

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 18:57

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779388&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 22:23:46 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 22:23:50 2005
Subject: [ python-Bugs-608635 ] Unix popen does not return exit status
Message-ID: <E1DDqqo-0003Wx-Go@sc8-sf-web4.sourceforge.net>

Bugs item #608635, was opened at 2002-09-12 19:03
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608635&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Thomas Wouters (twouters)
Summary: Unix popen does not return exit status

Initial Comment:
The documentation for os.popen[234] states that the close
will 
return the rc of the process. This works well on
windows, but the 
unix code does not work, None is
returned.

The 
attached version of popen2.py fixes the problem
by wrapping 
the fromchild fd with an object that
implements the 
documented close() behaviour.

I have also extended the 
test() to cover testing the
rc and run on FreeBSD against 
2.2.1


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 18:23

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 11:46

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Barry Alan Scott (barry-scott)
Date: 2002-09-16 19:15

Message:
Logged In: YES 
user_id=28665

I don't care how this is fixed. I just want a fix.

It would be nice if any fix 
can make it into a 2.2.x maint release rather then wait for 2.3. If you also 
think this way then exploiting 2.3 features is not 
reasonable.

Which version should I diff against to make a 
patch?

On the specific points: Why not return -1?
The -1 is  the 
value set that means no status available.
(See sts variable - not sure 
how this works as a class variable!)
This will be the case if you close 
the fd before the
process exits. Windows version seems to return 
None
in cases where the exit code is not available. But I've not
read 
the code to find out details.

A suppose a __get__() would allow 
forwarding of gets to all of the fd's properties. I may be worth copying the 
functions from the fd to the wrapper for speed.

Note: fd.close() 
returns None not zero.

I was hoping whoever designed the API 
could comment on how they though it should work.


----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2002-09-16 09:29

Message:
Logged In: YES 
user_id=562624

It seems that Taral has beat me to it. 

http://python.org/sf/608182 &quot;Enhanced file constructor&quot;

This patch would make it possible to implement popen as a 
subclass of file.



----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2002-09-16 04:41

Message:
Logged In: YES 
user_id=562624

I think I have a cleaner solution than a wrapper object. Now 
that we can inherit from built-in types it should be possible to 
make a subclass of file and override the close method.

There's a small problem because file.__new__ returns an 
uninitialized file object and there is no way to initialize it in 
Python, only from C. I noticed this a while ago but now that I 
see an actual use for subclassing file objects I think it's time to 
fix it.

Patch coming soon.



----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2002-09-13 06:12

Message:
Logged In: YES 
user_id=34209

Hm, for some reason I thought the C 'close()' function (and
os.close()) did return the status. They don't, it should be
'pclose()'. os.popen() passes this as the 'close' function
to the file constructor, so the rest of the statements still
stand :)


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2002-09-13 06:03

Message:
Logged In: YES 
user_id=34209

Assigned to me because I'm last in the 'assigned to' select box.

 - Points off because you didn't upload a patch, you
uploaded a new version.   I think I diff'ed against the
right version, but a patch is much better.

 - I'm not happy with the selective copying of attributes to
the wrapper object. For example, you aren't copying
xreadlines -- and what else ? Copying all 'public'
attributes (those not starting with _) seems a much safer bet.

 - The test is wrong; you mean 'exit 6', not 'return 6';
return might work in some shells, but it isn't the correct
way and it doesn't work in bash, at least. I'm also not sure
how portable this is; howmany platforms use the popen2 module ?

 - Why do you a result of convert -1 to None ? -1 seems a
valid return value to me, especially if it's documented as
meaning &quot;process has not finished yet&quot; :)

 - I'm not happy with this solution in general. The problem
lies in Python's handling of the (f)close function (and its
return value) on the fileobject.. os.pipe() returns a fd,
which is turned into a fileobject by os.fdopen -- which
passes 'fclose' as the close method, which always returns 0.
I'd much rather go for a solution where fdopen (or a new
function) handles pipes specially, passing in a fake-fclose
that really does 'close' on the fd (the infrastructure is
all there) or the Popen* classes should just provide a
file-wrapper (or subclass?) altogether, and have the close
method call close on the fd.

But that's just me.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608635&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 22:25:35 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 22:25:38 2005
Subject: [ python-Bugs-608033 ] Implied __init__.py not copied
Message-ID: <E1DDqsZ-0003H0-8P@sc8-sf-web2.sourceforge.net>

Bugs item #608033, was opened at 2002-09-11 17:13
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608033&group_id=5470

Category: Distutils
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Tom Epperly (tepperly)
Assigned to: A.M. Kuchling (akuchling)
Summary: Implied __init__.py not copied

Initial Comment:
The setup method in distutils won't allow me to specify
packages and py_modules, and it doesn't correctly
deduce all of the directories that need __init__.py
files copied.  See the attached setup.py for an
example. This setup.py is automatically generated from
a cca.sidl file containing an interface description.

In my example, the directory structure is as follows:
gov/
gov/cca/
gov/cca/ports/
decaf/
decaf/ports
The problem is that gov/ only contains __init__.py.

If I specific packages and py_modules in my setup call,
I see the following:
[epperly@tux06 runPython]$ python2.2 setup.py
--include-dirs=`cd ../../../runtime/python &amp;&amp; pwd`
--include-dirs=`cd ../../../runtime/sidl &amp;&amp; pwd`
--include-dirs=`cd . &amp;&amp; pwd` --library-dirs=`cd
../../../runtime/sidl/.libs &amp;&amp; pwd` install
--prefix=/tmp/pytest
running install
running build
running build_py
error: build_py: supplying both 'packages' and
'py_modules' options is not allowed
[epperly@tux06 runPython]$ 

If I comment out the &quot;packages = []&quot; part and do a
&quot;python setup.py install&quot;, it doesn't copy 
gov/__init__.py, decaf/__init__.py and
decaf/ports/__init__.py to the installation directory.

>From this data, it appears that distutils isn't
deducing the package list correctly from py_modules and
ext_modules. For each element of py_modules, it should
add all the parent modules. For an py_modules entry,
a.b.c.d.e.f, distutils should add a, a.b, a.b.c,
a.b.c.d, and a.b.c.d.e to the package list.

distutils should also glean package names from the
ext_modules list.


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 18:25

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-01 20:56

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-11-06 12:01

Message:
Logged In: YES 
user_id=11375

Actually, it looks like there's code in build_py.py that does add the 
__init__.py file; see the find_modules() method.  It must be broken in some way.  I'll look into it.


----------------------------------------------------------------------

Comment By: Tom Epperly (tepperly)
Date: 2002-09-12 14:28

Message:
Logged In: YES 
user_id=94539

I can fix my particular problem by using packages and not
py_modules.

----------------------------------------------------------------------

Comment By: Tom Epperly (tepperly)
Date: 2002-09-12 14:19

Message:
Logged In: YES 
user_id=94539

I read the section loewis linked me to, and the example
given there has 'mod1' in the &quot;root package&quot; and &quot;pkg.mod2&quot;
in the pkg/ package. This leads me to believe that
py_modules do not go into a single package as loewis suggests.

In addition, distutils should copy __init__.py files implied
by the list of C extension modules.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-09-12 04:04

Message:
Logged In: YES 
user_id=21627

It appears that you are misunderstanding the meaning of the
py_modules argument. See

http://www.python.org/doc/current/dist/setup-script.html#SECTION000320000000000000000

It says &quot;specially the case of a single module that goes in
the ``root package'' &quot;

All py_modules modules are in a single package, irrespective
of their source location.

----------------------------------------------------------------------

Comment By: Tom Epperly (tepperly)
Date: 2002-09-11 17:22

Message:
Logged In: YES 
user_id=94539

I am surprised that sourceforge let me assign this to someone.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608033&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 22:37:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 22:37:34 2005
Subject: [ python-Bugs-1166714 ] [ast branch] fatal error when compiling
	test_bool.py
Message-ID: <E1DDr46-0003wJ-Bj@sc8-sf-web2.sourceforge.net>

Bugs item #1166714, was opened at 2005-03-20 00:14
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Brett Cannon (bcannon)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



----------------------------------------------------------------------

>Comment By: John Ehresman (jpe)
Date: 2005-03-22 21:37

Message:
Logged In: YES 
user_id=22785

The issue seems to be that in symtable_analyze, a free
dictionary is created for the entire module and if a name is
found to be free in any function, it is not converted from a
LOCAL to a CELL is any context seen afterwards.  I think the
free variables need to be recorded on a function-by-function
basis.

  

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-22 20:34

Message:
Logged In: YES 
user_id=357491

An short example of the failure::

 def outer(a):
    def first(): a
    def last(a): pass

This leads to a fatal Python error.  The issue is having a being a local or 
parameter (can make 'a' be 'a = 1' and not a parameter and still have it 
fail), the first closure reference it, and then the second one use it as a 
parameter.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 23:03:18 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 23:03:21 2005
Subject: [ python-Bugs-602627 ] pydoc -g dumps core on Solaris 2.8
Message-ID: <E1DDrT4-0005DI-Oy@sc8-sf-web2.sourceforge.net>

Bugs item #602627, was opened at 2002-08-30 17:51
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470

Category: Demos and Tools
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc -g dumps core on Solaris 2.8

Initial Comment:
Python 2.2.1, Solaris 2.8, gcc 3.2, binutils 2.12.1

When I execute &quot;pydoc -g&quot;, it pops up a dialog box
saying &quot;Starting server&quot; and &quot;Search for&quot;, and then
dumps core before I have time to type anything.
The same problem happens on Solaris 2.7

The traceback:

Core was generated by `/usr/gnu/bin/python
/usr/gnu/bin/pydoc -g'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libsocket.so.1...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /usr/lib/libthread.so.1...done.
Loaded symbols for /usr/lib/libthread.so.1
Reading symbols from
/usr/gnu/lib/libreadline.so.4...done.
Loaded symbols for /usr/gnu/lib/libreadline.so.4
Reading symbols from /usr/lib/libcurses.so.1...done.
Loaded symbols for /usr/lib/libcurses.so.1
Reading symbols from /usr/lib/libcrypt_i.so.1...done.
Loaded symbols for /usr/lib/libcrypt_i.so.1
Reading symbols from /usr/gnu/lib/libtk8.3.so...done.
Loaded symbols for /usr/gnu/lib/libtk8.3.so
Reading symbols from /usr/gnu/lib/libtcl8.3.so...done.
Loaded symbols for /usr/gnu/lib/libtcl8.3.so
Reading symbols from /usr/lib/libX11.so.4...done.
Loaded symbols for /usr/lib/libX11.so.4
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/gnu/lib/libgcc_s.so.1
Reading symbols from /usr/lib/libmp.so.2...done.
Loaded symbols for /usr/lib/libmp.so.2
Reading symbols from /usr/lib/libgen.so.1...done.
Loaded symbols for /usr/lib/libgen.so.1
Reading symbols from
/usr/openwin/lib/libXext.so.0...done.
Loaded symbols for /usr/openwin/lib/libXext.so.0
Reading symbols from
/usr/openwin/lib/libdga.so.1...done.
Loaded symbols for /usr/openwin/lib/libdga.so.1
Reading symbols from
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.
Loaded symbols for
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/strop.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/strop.so
Reading symbols from
/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...done.
Loaded symbols for
/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
Reading symbols from
/usr/openwin/lib/locale/common/xlibi18n.so.2...done.
Loaded symbols for
/usr/openwin/lib/locale/common/xlibi18n.so.2
Reading symbols from
/usr/openwin/lib/locale/common/ximlocal.so.2...done.
Loaded symbols for
/usr/openwin/lib/locale/common/ximlocal.so.2
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/time.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/time.so
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/errno.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/errno.so
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/_socket.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/_socket.so
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/select.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/select.so
#0  0xff0b2be0 in Tk_FreeGC () from
/usr/gnu/lib/libtk8.3.so
(gdb) bt
#0  0xff0b2be0 in Tk_FreeGC () from
/usr/gnu/lib/libtk8.3.so
#1  0xff0da71c in TkButtonWorldChanged () from
/usr/gnu/lib/libtk8.3.so
#2  0xff0da66c in ConfigureButton () from
/usr/gnu/lib/libtk8.3.so
#3  0xff0d9dc8 in ButtonWidgetObjCmd () from
/usr/gnu/lib/libtk8.3.so
#4  0xfefe0b50 in EvalObjv () from
/usr/gnu/lib/libtcl8.3.so
#5  0xfefe0c80 in Tcl_EvalObjv () from
/usr/gnu/lib/libtcl8.3.so
#6  0x0008deb8 in Tkapp_Call (self=0x159c88,
args=0x2c60d8) at Modules/_tkinter.c:619
#7  0x00049e28 in fast_cfunction (func=0x159c88,
pp_stack=0xfe908780, na=1089160)
    at Python/ceval.c:3131
#8  0x00047ea0 in eval_frame (f=0x1cc7c0) at
Python/ceval.c:2007
#9  0x00048b30 in PyEval_EvalCodeEx (co=0x220340,
globals=0x1cc7c0, locals=0x0, args=0x8, 
    argcount=1, kws=0x1c1dd8, kwcount=1, defs=0x1d76ec,
defcount=1, closure=0x0)
    at Python/ceval.c:2585
#10 0x00049f20 in fast_function (func=0x1,
pp_stack=0x8, n=1842656, na=1, nk=1)
    at Python/ceval.c:3161
#11 0x00047de0 in eval_frame (f=0x1c1c80) at
Python/ceval.c:2024
#12 0x00048b30 in PyEval_EvalCodeEx (co=0x1983a8,
globals=0x1c1c80, locals=0x0, args=0x30fd50, 
    argcount=2, kws=0x30fd58, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#13 0x00049f20 in fast_function (func=0x0,
pp_stack=0x30fd50, n=3210584, na=2, nk=0)
    at Python/ceval.c:3161
#14 0x00047de0 in eval_frame (f=0x30fc00) at
Python/ceval.c:2024
#15 0x00048b30 in PyEval_EvalCodeEx (co=0x12f788,
globals=0x30fc00, locals=0x0, args=0x1c0bc8, 
    argcount=1, kws=0x1c0bcc, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#16 0x00049f20 in fast_function (func=0x0,
pp_stack=0x1c0bc8, n=1838028, na=1, nk=0)
    at Python/ceval.c:3161
#17 0x00047de0 in eval_frame (f=0x1c0a70) at
Python/ceval.c:2024
#18 0x00048b30 in PyEval_EvalCodeEx (co=0x300058,
globals=0x1c0a70, locals=0x0, args=0x301a6c, 
    argcount=3, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#19 0x000aaa9c in function_call (func=0x2fc3c0,
arg=0x301a60, kw=0x0) at Objects/funcobject.c:374
#20 0x00095d00 in PyObject_Call (func=0x2fc3c0,
arg=0x301a60, kw=0x0) at Objects/abstract.c:1684
#21 0x0009e644 in instancemethod_call (func=0x2fc3c0,
arg=0x301a60, kw=0x0)
    at Objects/classobject.c:2276
#22 0x00095d00 in PyObject_Call (func=0x2fc3c0,
arg=0x301a60, kw=0x0) at Objects/abstract.c:1684
#23 0x00049fe4 in do_call (func=0x2c5718,
pp_stack=0xfe908fd8, na=3, nk=3152480)
    at Python/ceval.c:3262
#24 0x00047d28 in eval_frame (f=0x1cc5f8) at
Python/ceval.c:2027
#25 0x00048b30 in PyEval_EvalCodeEx (co=0x12f398,
globals=0x1cc5f8, locals=0x0, args=0x2cba54, 
    argcount=3, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#26 0x000aaa9c in function_call (func=0x301bf0,
arg=0x2cba48, kw=0x0) at Objects/funcobject.c:374
#27 0x00095d00 in PyObject_Call (func=0x301bf0,
arg=0x2cba48, kw=0x0) at Objects/abstract.c:1684
#28 0x0009e644 in instancemethod_call (func=0x301bf0,
arg=0x2cba48, kw=0x0)
    at Objects/classobject.c:2276
#29 0x00095d00 in PyObject_Call (func=0x301bf0,
arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684
#30 0x00049c94 in PyEval_CallObjectWithKeywords
(func=0x2da810, arg=0x2e3bb0, kw=0x0)
    at Python/ceval.c:3049
#31 0x00097d9c in PyInstance_New (klass=0x2da810,
arg=0x2e3bb0, kw=0x0) at Objects/classobject.c:557
#32 0x00095d00 in PyObject_Call (func=0x2da810,
arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684
#33 0x00049fe4 in do_call (func=0x316828,
pp_stack=0xfe9094a0, na=2, nk=3029936)
    at Python/ceval.c:3262
#34 0x00047d28 in eval_frame (f=0x1a3d20) at
Python/ceval.c:2027
#35 0x00048b30 in PyEval_EvalCodeEx (co=0x12fab0,
globals=0x1a3d20, locals=0x0, args=0x186414, 
    argcount=3, kws=0x2b1228, kwcount=0, defs=0x1cd87c,
defcount=2, closure=0x0)
    at Python/ceval.c:2585
#36 0x000aaa9c in function_call (func=0x1d1dc8,
arg=0x186408, kw=0x2d6238)
    at Objects/funcobject.c:374
#37 0x00095d00 in PyObject_Call (func=0x1d1dc8,
arg=0x186408, kw=0x2d6238)
    at Objects/abstract.c:1684
#38 0x00049c94 in PyEval_CallObjectWithKeywords
(func=0x1d1dc8, arg=0x186408, kw=0x2d6238)
    at Python/ceval.c:3049

#39 0x000bcb3c in builtin_apply (self=0x0,
args=0x1d1dc8) at Python/bltinmodule.c:95
#40 0x000ba398 in PyCFunction_Call (func=0x101d18,
arg=0x1c4910, kw=0x0)
    at Objects/methodobject.c:69
#41 0x00047ec8 in eval_frame (f=0x1a4078) at
Python/ceval.c:2004
#42 0x00048b30 in PyEval_EvalCodeEx (co=0x2c86c8,
globals=0x1a4078, locals=0x0, args=0x1612d4, 
    argcount=1, kws=0x1612d8, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#43 0x00049f20 in fast_function (func=0x0,
pp_stack=0x1612d4, n=1446616, na=1, nk=0)
    at Python/ceval.c:3161
#44 0x00047de0 in eval_frame (f=0x161180) at
Python/ceval.c:2024
#45 0x00048b30 in PyEval_EvalCodeEx (co=0x2c8cd0,
globals=0x161180, locals=0x0, args=0x265e4c, 
    argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#46 0x000aaa9c in function_call (func=0x2d6518,
arg=0x265e40, kw=0x0) at Objects/funcobject.c:374
#47 0x00095d00 in PyObject_Call (func=0x2d6518,
arg=0x265e40, kw=0x0) at Objects/abstract.c:1684
#48 0x0009e644 in instancemethod_call (func=0x2d6518,
arg=0x265e40, kw=0x0)
    at Objects/classobject.c:2276
#49 0x00095d00 in PyObject_Call (func=0x2d6518,
arg=0x100368, kw=0x0) at Objects/abstract.c:1684
#50 0x00049c94 in PyEval_CallObjectWithKeywords
(func=0x2d7350, arg=0x100368, kw=0x0)
    at Python/ceval.c:3049
#51 0x0007f508 in t_bootstrap (boot_raw=0x28bdf8) at
Modules/threadmodule.c:190


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 19:03

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-30 23:20

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-28 23:17

Message:
Logged In: YES 
user_id=33168

I notice that you are using Tk 8.4.  Have you (or can you)
tried with Tk 8.3?  Do you have the most recent version
8.4.1 from Oct 22, 2002?

----------------------------------------------------------------------

Comment By: Andrew Koenig (arkoenig)
Date: 2003-01-06 14:10

Message:
Logged In: YES 
user_id=418174

I rebuilt python with -O0 and it still crashes.

The new traceback is attached.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-06 10:46

Message:
Logged In: YES 
user_id=33168

Andrew, could I get you to look at bug 662787?
http://python.org/sf/662787

We are having problems with solaris boxes and could use some
help.
Thanks.

----------------------------------------------------------------------

Comment By: Andrew Koenig (arkoenig)
Date: 2002-09-17 11:54

Message:
Logged In: YES 
user_id=418174

I rebuilt python from scratch by saying &quot;make configure&quot;,
then going into Makefile and removing &quot;-O3&quot; from the
definition of the OPT macro, then saying &quot;make&quot;.  The
resulting python still dumps core when executing &quot;./python
Lib/pydoc.py -g&quot;.

Of course there could still be a platform or optimization
dependency in tcl, or tk, or some other library.

Suggestions?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-13 22:30

Message:
Logged In: YES 
user_id=33168

I built python 2.2.1+ w/gcc 2.95.3 and did not have the
problem.  So I think this may be specific to gcc 3.2.  Can
you try building w/lower optimization or turning off
optimization? -O1, -O0 or no -O option?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 23:04:43 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 23:04:48 2005
Subject: [ python-Bugs-487471 ] urllib2 proxyhandle won't work.
Message-ID: <E1DDrUR-0001Ld-5P@sc8-sf-web1.sourceforge.net>

Bugs item #487471, was opened at 2001-11-30 07:54
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Ha Shao (hashao)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 proxyhandle won't work.

Initial Comment:
For python 2.2b2:
Adding proxyhandler with build_opener, install_opener does not
work since order of the handlers does matter (my guess).

In the current code, new handlers are appended at the end
of the handlers list. At least under windows, the proxyhandle
will never got called if it is added with install_opener.
HTTPHandler always get called before proxyhandler if the
default list is altered.

The attached patch try to reserve the order of handlers
based on their baseclass when adding new handlers.

Handlers with the same baseclasses might be added
more than once. Not sure if it is a good thing or bad
thing. Current code will raise except when it trys to remove 
the default handlers twice.

Since order does matter, build_opener
should be repleased by a list like class such that
user can insert their handlers to specific place.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-22 17:04

Message:
Logged In: YES 
user_id=764593

As John J. Lee said, it is fixed now.

The fix was in 1.48, which was apparently included with 
python 2.3beta2 - and therefore the problem doesn't occur.

That said, there is an XXX comment added in 1.57 asking 
# XXX why does self.handlers need to be sorted?

and if they aren't sorted, then the issue will recur in some but 
not all tests.

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:32

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-25 18:58

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-10-30 14:02

Message:
Logged In: YES 
user_id=261020

That last comment was from me (cookie problems, ironically).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-10-30 13:57

Message:
Logged In: NO 

This should be closed. 
 
I don't recall which minor version of 2.2 this was introduced at, 
but there's no need to replace build_opener any more.  The 
most you have to do is to explicitly pass a handler or two to 
build_opener with appropriately set handler_order attributes.  
Or you can subclass the handlers. 

----------------------------------------------------------------------

Comment By: Micah Stetson (micahs)
Date: 2003-05-07 19:29

Message:
Logged In: YES 
user_id=774014

I don't know about Ha Shao, but I have the problem with Python 2.2.2.  My work around was to
modify urllib2.build_opener to add the user's supplied handlers before the defaults.  Shao's idea
of a list-like class is probably better.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-13 16:50

Message:
Logged In: YES 
user_id=33168

Ha Shao, I know there were many changes in Python 2.2.x in
this area.  Do you still have this problem?  Can this bug be
closed?

----------------------------------------------------------------------

Comment By: Ha Shao (hashao)
Date: 2001-11-30 08:10

Message:
Logged In: YES 
user_id=8717

forgot some code and changed a stupid variable name.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 23:05:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 23:05:38 2005
Subject: [ python-Bugs-591287 ] makesetup fails: long Setup.local lines
Message-ID: <E1DDrUn-0001NP-NJ@sc8-sf-web1.sourceforge.net>

Bugs item #591287, was opened at 2002-08-05 17:25
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591287&group_id=5470

Category: Build
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Sam Tannous (stannous)
Assigned to: Nobody/Anonymous (nobody)
Summary: makesetup fails: long Setup.local lines

Initial Comment:
makesetup fails: long Setup.local lines.  I've
included an attachment that describes the problem.

Thanks,
Sam Tannous (employees.org)

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 19:05

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-30 23:18

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-12-03 11:29

Message:
Logged In: YES 
user_id=11375

It's not length; it's the '=' symbol.

Modules/makesetup compares the line to '*=*', and if it matches,
assumes it's a definition, like 'DESTLIB=foo'.  That also matches your 
-DBYTE_ORDER=1234, though, so makesetup just copies the line verbatim into the definition section.

I don't see how to fix it, though; shell pattern matching doesn't seem powerful enough to do something like [^ ]*=*.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591287&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 23:06:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 23:06:57 2005
Subject: [ python-Bugs-591104 ] os.tmpfile() can fail on win32
Message-ID: <E1DDrWR-0005VX-U5@sc8-sf-web4.sourceforge.net>

Bugs item #591104, was opened at 2002-08-05 11:23
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470

Category: Windows
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Joseph Barillari (jdbarillari)
Assigned to: Mark Hammond (mhammond)
Summary: os.tmpfile() can fail on win32

Initial Comment:
I've discovered what appears to be a bug in Python 2.2.1 
on Win32. I'm
using the 2.2.1 build that I downloaded from python.org. 
I'm running
Windows 2000.

If os.tmpfile() is exceuted when the CWD is a UNC path, 
the base of
which is not writeable by the current user, tmpfile will
fail. tempfile.TemporaryFile will work, so I suspect this is 
a bug in os.tmpfile().

For example:

C:\&gt;pwd  
/cygdrive/c   #I use cygwin

C:\&gt;bash    # I have to use bash; the DOS shell doesn't 
support UNC paths
bash: .bashrc: No such file or directory
bash-2.05a$ cd //bopp/jbarilla
bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more 
information.
&gt;&gt;&gt; import os; os.tmpfile()
&lt;open file '&lt;tmpfile&gt;', mode 'w+' at 0x007762C0&gt; # It 
works.
&gt;&gt;&gt; ^Z

If I chmod 555 //bopp/jbarilla (from unix via NFS; 
incidentally,
&quot;chmod 555 .&quot; from cygwin is ineffectual), then tmpfile 
fails:

bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more 
information.
&gt;&gt;&gt; import os; os.tmpfile()
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
OSError: [Errno 13] Permission denied # Oops.

# However, tempfile.TemporaryFile works:

&gt;&gt;&gt; import tempfile; tempfile.TemporaryFile()
&lt;open file 'c:\DOCUME~1\jbarilla\LOCALS~1
\Temp\~1880-0', mode 'w+b' at 0x00779B00&gt;

--Joe

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 19:06

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-30 23:13

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Jonathan Simms (slyphon)
Date: 2002-08-10 03:21

Message:
Logged In: YES 
user_id=404786

Hi, I'm a bit new here, but I'd like to help...

This like a cygwin issue. I've been using cygwin as a 
development environment for about a year, and nothing 
has driven me more crazy than the consistent problems 
converting between unc and win32 paths. There's the 
cygpath utility that you can put to use, it'll convert 
posix to win32 paths and vice-versa. Also, if you want 
to use chmod and unix-style permissions with cygwin, 
you need to make sure that the $CYGWIN variable has 
been set to include 'ntsec'.

related to the cygwin environment variable:
http://cygwin.com/cygwin-ug-net/using-cygwinenv.html


...This advice comes with no warranty, and I apologise 
if I'm mistakenly off-the-mark...

Cheers
--Jonathan

----------------------------------------------------------------------

Comment By: Joseph Barillari (jdbarillari)
Date: 2002-08-06 11:40

Message:
Logged In: YES 
user_id=589825

\quote{BTW, do you really think this has something to do 
with UNC 
paths?  From what you said it seems to be a matter of 
having sufficient permission to scribble in the current 
directory.}

Oops. You're right:

Z:\&gt;touch a
touch: creating `a': Permission denied

Z:\&gt;python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] 
on win32
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more 
information.
&gt;&gt;&gt; import os; os.tmpfile()
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
OSError: [Errno 13] Permission denied
&gt;&gt;&gt;

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-06 00:19

Message:
Logged In: YES 
user_id=31435

Assigned to Mark in case he has another idea, but I think 
you're out of luck.  os.tmpfile() does nothing except call 
Microsoft's tmpfile() function, and that doesn't allow 
specifying a directory.  If you don't have permission to 
create a file in the current directory, you lose, and Python's 
behavior here will change when Microsoft's does.

tempfile.TemporaryFile() &quot;simulates&quot; a temp file via other 
means, and can control which directory it uses.

BTW, do you really think this has something to do with UNC 
paths?  From what you said it seems to be a matter of 
having sufficient permission to scribble in the current 
directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 23:07:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 23:07:56 2005
Subject: [ python-Bugs-579116 ] pthread_exit missing in thread_pthread.h
Message-ID: <E1DDrXV-0001Va-78@sc8-sf-web1.sourceforge.net>

Bugs item #579116, was opened at 2002-07-09 10:45
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470

Category: Threads
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Michael Pronath (micpro)
Assigned to: Nobody/Anonymous (nobody)
Summary: pthread_exit missing in thread_pthread.h

Initial Comment:

I'm using the Python 2.2.1 interpreter for scripting
language in a larger program. When I used the threading
module to create new threads, my main program did not
exit anymore, but hang, because one python thread
always remained.
It got much better when I inserted a call to
pthread_exit into do_PyThread_exit_thread
(thread_pthread.h).

Patchfile is attached.


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 19:07

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-30 23:11

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Valeriy Pogrebitskiy (vpogrebi)
Date: 2003-11-06 11:55

Message:
Logged In: YES 
user_id=902722

I'm using Python 2.2.1 (Unix) in a daemon process that starts 
child threads to handle specific events. I have noticed that 
occasionally (not all the time) child thread &quot;stays&quot; (in a 
SLEEPING) status after thread exits. When this happens, that 
thread never exits until entire process is stopped.

I have log files that have output coming from threading 
module (I have set threading._VERBOSE to 1) that show each 
thread's start and termination events. In addition, I use 
Queue module for inter-thread communication (when thread 
starts execution, it posts &quot;START&quot; message, and when it is 
about to exit its run() method, it posts &quot;END&quot; event).

So, from these logs and from output of &quot;ps -fp &lt;PID&gt; -
o 'user,pid,ppid,pgid,time,stime,lwp,s'&quot; I can see that some 
threads exit (which is indicated by _VERBOSE output and a 
message in a Queue), but still stay (in a SLEEPING state) in 
the process.

Does this behavior have something to do with the problem 
described in this report, or is it something different?

Is there patch (full instalation package) that fixes this 
problem (without me having to update source code and 
recompile the executable)?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-07 22:08

Message:
Logged In: YES 
user_id=33168

Michael do you still have this problem with 2.2.2 or do you
still require this patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 23:09:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 23:09:39 2005
Subject: [ python-Bugs-569316 ] cgi.py broken with xmlrpclib on Python 2
Message-ID: <E1DDrZA-0000pm-8R@sc8-sf-web3.sourceforge.net>

Bugs item #569316, was opened at 2002-06-15 05:53
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569316&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Steve Pike (oztourer)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.py broken with xmlrpclib on Python 2

Initial Comment:
Given a web application which accepts both normal 
HTTP requests and XML-RPC requests, it is 
reasonable for that program to assume it can create a 
cgi.FieldStorage instance in either case. This works 
fine in Python 1.5.2 but causes exceptions in Python 
2.x.x when using the created FieldStorage. This is due 
to the content-type header generated by xmlrpclib.py 
('text/xml') being unrecognised in cgi.py, as a result of 
which no FieldStorage.list is created.

One solution is to reinstate some code in cgi.py from 
the 1.5.2 release, at the end of method __init__, after 
removing the current final two lines:

        #else:
        #    self.read_single()
        # SP 2002/6/15: The following code is taken 
from the Python 1.5.2 version
        # of cgi.py, as incoming xmlrpclib requests 
otherwise do not cause 'list'
        # to be set up correctly.
        elif self.outerboundary:
            # we're in an inner part, but the content-type 
wasn't something we
            # understood.  default to read_single() 
because the resulting
            # FieldStorage won't be a mapping (and 
doesn't need to be).
            self.read_single()
        else:
            # we're in an outer part, but the content-type 
wasn't something we
            # understood.  we still want the resulting 
FieldStorage to be a
            # mapping, so parse it as if it were urlencoded
            self.read_urlencoded()


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 19:09

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-30 23:08

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569316&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 23:11:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 23:11:35 2005
Subject: [ python-Bugs-566037 ] Popen exectuion blocking w/threads
Message-ID: <E1DDraz-0005hO-5t@sc8-sf-web4.sourceforge.net>

Bugs item #566037, was opened at 2002-06-07 21:07
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470

Category: Threads
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 1
Submitted By: Martin Stoufer (mstoufer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen exectuion blocking w/threads

Initial Comment:
The following unit test hangs after the first two lines
of output. This is wholly reproducible (for us) under
2.2.1 and totaly unreproducible under 2.1. We have both
interpreters installed on a RH7.2 PC with linkings
against the apparent same /lib/libthread.so.0

import os, threading,time, sys
def read_output(self, cmd, timeout):
        print &quot;run: %s&quot; % cmd
        (inf,outf) = os.popen4(cmd)
        print &quot;started! out_fd=%d&quot; % outf.fileno()
        while 1:
            line = outf.readline()
            if line == &quot;&quot;: break
            print len(line),line
            sys.stdout.flush()
        return
if __name__ == '__main__': 
    thr =
threading.Thread(target=read_output,args=(1,&quot;ping -c 5
www.mit.edu&quot;,0))
    thr.start()
    print &quot;Started thread&quot;
    while 1: time.sleep(1)

mstoufer@dpsslx05(3)&gt;ldd /usr/local/bin/python2.{1,2}
/usr/local/bin/python2.1:
	libpthread.so.0 =&gt; /lib/libpthread.so.0 (0x40029000)
	libdl.so.2 =&gt; /lib/libdl.so.2 (0x40040000)
	libutil.so.1 =&gt; /lib/libutil.so.1 (0x40044000)
	libstdc++-libc6.1-2.so.3 =&gt;
/usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000)
	libm.so.6 =&gt; /lib/libm.so.6 (0x4008f000)
	libc.so.6 =&gt; /lib/libc.so.6 (0x400b1000)
	/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x40000000)
/usr/local/bin/python2.2:
	libdl.so.2 =&gt; /lib/libdl.so.2 (0x40029000)
	libpthread.so.0 =&gt; /lib/libpthread.so.0 (0x4002d000)
	libutil.so.1 =&gt; /lib/libutil.so.1 (0x40044000)
	libm.so.6 =&gt; /lib/libm.so.6 (0x40047000)
	libc.so.6 =&gt; /lib/libc.so.6 (0x4006a000)
	/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x40000000)

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 19:11

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Martin Stoufer (mstoufer)
Date: 2004-11-30 12:18

Message:
Logged In: YES 
user_id=133905

I have not worked on this bug since I submitted it and have
since gone onto a more saner software model. This bug may be
closed or assigned to someone else to follow up on.

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-29 20:28

Message:
Logged In: YES 
user_id=752496

Works fine in Py2.3.3, Fedora Core 2.

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-29 20:28

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Becky Burwell (burwell)
Date: 2002-10-04 19:01

Message:
Logged In: YES 
user_id=348250

FYI: this happens if the program is a bash shell which calls 
ping.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-04 18:20

Message:
Logged In: YES 
user_id=6380

I can reproduce this in Python 2.3, by the way. I'm just not
sure that there's anything that Python can do to avoid this
-- it feels like a bug in libc (or in ping).

Lowering priority because of that.

----------------------------------------------------------------------

Comment By: Becky Burwell (burwell)
Date: 2002-10-04 17:53

Message:
Logged In: YES 
user_id=348250

We have the same problem in RedHat 7.3 with Python 2.2 
using ping in a thread. If I do a popen or just os.system in a 
thread, the ping hangs for hosts that are not responding 
(works fine IF the host is up.)

Note: this code works fine in Python 2.1.1 and works fine not 
in a thread in Python 2.2

Also: if the command prints out lots of output there is still a 
hang.

The ping command has to be killed with a kill -9.


#!/usr/bin/python2
import os,threading

class MyHost(threading.Thread):
    def __init__(self):
        threading.Thread.__init__(self)

    def run(self):
        ping_string = &quot;/bin/ping -q -c 1 -w 2 hostthatisdown&quot;
        print &quot;about to execute ping string %s\n&quot; % ping_string
        f = os.popen (ping_string,&quot;r&quot;)
        result = f.close ()
        print &quot;result is &quot;,result

thread = MyHost()
thread.start ()


----------------------------------------------------------------------

Comment By: Martin Stoufer (mcstoufer)
Date: 2002-07-24 13:31

Message:
Logged In: YES 
user_id=243169

I've found that using the generic os.popen() call and just 
reading everything back to be a somewhat equitable fix. The 
returned object is file like and the .close() call on it at 
the end seems to clean up house pretty well. Before, with a 
Popen4() object, I was getting a lot of &lt;defunct&gt; processes. 
Now they all go away nicely. I'd be willing to follow up in 
person with anyone here, MCStoufer@lbl.gov


----------------------------------------------------------------------

Comment By: Zoran Bosnjak (zoranbosnjak)
Date: 2002-07-24 10:28

Message:
Logged In: YES 
user_id=583469

I have the same problem with python2.2 (the child 
process does not terminate on SIGTERM - it only 
terminates on SIGKILL). The same program works 
(terminates) fine with python2.1.1 (all other libs are the 
same). Here is my simple testfile: 
#!/usr/bin/env python2.2 
 
import os, time, signal, threading, string 
from popen2 import Popen3, Popen4 
 
pid = 0 
 
def run(): 
    global pid 
    f = Popen4('ping localhost') 
    pid = f.pid 
    while 1: 
        s = f.fromchild.readline() 
        if not s: break 
 
t = threading.Thread(target=run) 
t.start() 
time.sleep(10) 
print 'timeout' 
os.kill(pid, signal.SIGTERM) 
t.join() 
print 'bye' 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-12 01:16

Message:
Logged In: YES 
user_id=6380

Anything is possible. I suggest asking for help in a Linux
threading guru forum.

----------------------------------------------------------------------

Comment By: Martin Stoufer (mcstoufer)
Date: 2002-06-12 01:10

Message:
Logged In: YES 
user_id=243169

This same issue arises when any subprocess is declared that makes 
more than 1 network read/write. From the system side, the Ping process 
is simply sleeping; we feel that the process is looking for the pipe to 
empty so it can finish it's write to stdout.

Replacing cmd with 'ping -c 1  www.mit.edu' works everytime. 
Replacing cmd with 'echo\'Hello. world\'' works as well.

We have beeen using a therading model similar to this under 2.1 and it 
has been quite robust in its execution. Is it possible that this is a 
compile-time issue with the thread linking?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 16:39

Message:
Logged In: YES 
user_id=6380

Mixing forks and threads is often asking for trouble...

Does this also hang with another command that produces more
than two lines of output, or is it limited to ping?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-06-09 05:32

Message:
Logged In: YES 
user_id=21627

I can't reproduce this on a SuSE system, either (which has
glibc 2.2.5), so I'm tempted to declare it a glibc 2.1 bug.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-08 02:42

Message:
Logged In: YES 
user_id=14198

Just noting that current CVS Python works fine on Windows,
but also hangs on RH7.  My Linux debuggings skills are such
that I can offer no further help ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 23:14:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 23:14:48 2005
Subject: [ python-Bugs-530163 ] fpectl build on solaris: -lsunmath
Message-ID: <E1DDre9-00011R-PF@sc8-sf-web3.sourceforge.net>

Bugs item #530163, was opened at 2002-03-15 00:47
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470

Category: Build
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: fpectl build on solaris: -lsunmath

Initial Comment:
This is on Solaris 2.7, with gcc2.95.2

Observed on both the trunk and the release22 branch.

By default, the configure/setup stuff isn't including
 -L/opt/SUNWspro/lib -R/opt/SUNWspro/lib -lsunmath
when linking fpectl.so. This means that this doesn't
produce a working module (it needs libsunmath for
ieee_handler)

My autoconf knowledge isn't excellent, but I'm going
to have a look-see, figure out the easiest way to do
this...



----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 19:14

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-29 20:14

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-03-15 06:22

Message:
Logged In: YES 
user_id=21627

I think there is absolutely no way to find SUNWspro
reliably. /opt is but one location where it might be
installed - on our infrastructure, it is not in /opt, since
that is not NFS shared.

If c89 is on the path, it could give an indication where
SUNWspro may be installed.

In any case, I recommend to perform the necessary
computation in setup.py, not in autoconf.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470
From noreply at sourceforge.net  Tue Mar 22 23:45:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 22 23:45:42 2005
Subject: [ python-Bugs-1166274 ] missing sequence tests - pull from deque
Message-ID: <E1DDs84-0002Pp-2V@sc8-sf-web3.sourceforge.net>

Bugs item #1166274, was opened at 2005-03-18 23:21
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166274&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Walter D?rwald (doerwalter)
Summary: missing sequence tests - pull from deque

Initial Comment:
tuples and lists can be initialized from any sequence, 
including an iterator.  This is not tested.  The iterator 
tests in test_deque would do a good job.

list_tests (for list and UserList) test_remove does not 
test that it is the _first_ occurence that gets removed.  
Again, the deque tests that Raymond just checked in 
are up to the job, if "deque" is replaced by "type2test"

----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-22 23:45

Message:
Logged In: YES 
user_id=89016

Checked in the "construct from iterable" tests as:
Lib/test/seq_tests.py 1.4
Lib/test/test_deque.py 1.22
I've moved the iterables from test_deque to seq_tests, so
that they can be reused.

Closing the report. Thanks for the tip!

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-03-21 22:33

Message:
Logged In: YES 
user_id=89016

Checked in the remove test as:
Lib/test/list_tests.py 1.6
(Note that I've dropped the evil mutator test, because it
doesn't raise an exception).

I'll add the iterator initialization test tomorrow.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166274&group_id=5470
From noreply at sourceforge.net  Wed Mar 23 00:07:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 23 00:07:41 2005
Subject: [ python-Bugs-1168746 ] frame.f_exc_type,value,traceback
Message-ID: <E1DDsTM-0008Bb-3Z@sc8-sf-web2.sourceforge.net>

Bugs item #1168746, was opened at 2005-03-22 23: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=1168746&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: frame.f_exc_type,value,traceback

Initial Comment:
The frame object attributes f_exc_type, f_exc_value, f_exc_traceback are misdocumented.  They are not the last exception caught by the frame, nor the one currently handled, or anything reasonable like that.

They give the last exception raised in the parent frame, and only if another exception was ever raised in the current frame (in all other cases they are None).

I very much doubt this is useful to anyone, so maybe un-publishing the attributes would be sensible, but in any case the doc needs a small fix (ref/types.html and the doc about and in inspect.py).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168746&group_id=5470
From noreply at sourceforge.net  Wed Mar 23 02:21:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 23 02:21:52 2005
Subject: [ python-Bugs-1166714 ] [ast branch] fatal error when compiling
	test_bool.py
Message-ID: <E1DDuZA-0004EK-EJ@sc8-sf-web4.sourceforge.net>

Bugs item #1166714, was opened at 2005-03-20 00:14
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Brett Cannon (bcannon)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



----------------------------------------------------------------------

>Comment By: John Ehresman (jpe)
Date: 2005-03-23 01:21

Message:
Logged In: YES 
user_id=22785

The attached patch seems to fix this by creating a
dictionary for each scope's free vars and only propagating
up the ones that aren't satisfied by a binding.  With this
and the other patches, the test suite runs w/o segfaulting
up through test_unicode.

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2005-03-22 21:37

Message:
Logged In: YES 
user_id=22785

The issue seems to be that in symtable_analyze, a free
dictionary is created for the entire module and if a name is
found to be free in any function, it is not converted from a
LOCAL to a CELL is any context seen afterwards.  I think the
free variables need to be recorded on a function-by-function
basis.

  

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-22 20:34

Message:
Logged In: YES 
user_id=357491

An short example of the failure::

 def outer(a):
    def first(): a
    def last(a): pass

This leads to a fatal Python error.  The issue is having a being a local or 
parameter (can make 'a' be 'a = 1' and not a parameter and still have it 
fail), the first closure reference it, and then the second one use it as a 
parameter.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470
From noreply at sourceforge.net  Wed Mar 23 02:22:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 23 02:22:51 2005
Subject: [ python-Bugs-1166714 ] [ast branch] fatal error when compiling
	test_bool.py
Message-ID: <E1DDua7-0000fq-SV@sc8-sf-web1.sourceforge.net>

Bugs item #1166714, was opened at 2005-03-20 00:14
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Brett Cannon (bcannon)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



----------------------------------------------------------------------

>Comment By: John Ehresman (jpe)
Date: 2005-03-23 01:22

Message:
Logged In: YES 
user_id=22785

Forgot to add the patch

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2005-03-23 01:21

Message:
Logged In: YES 
user_id=22785

The attached patch seems to fix this by creating a
dictionary for each scope's free vars and only propagating
up the ones that aren't satisfied by a binding.  With this
and the other patches, the test suite runs w/o segfaulting
up through test_unicode.

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2005-03-22 21:37

Message:
Logged In: YES 
user_id=22785

The issue seems to be that in symtable_analyze, a free
dictionary is created for the entire module and if a name is
found to be free in any function, it is not converted from a
LOCAL to a CELL is any context seen afterwards.  I think the
free variables need to be recorded on a function-by-function
basis.

  

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-22 20:34

Message:
Logged In: YES 
user_id=357491

An short example of the failure::

 def outer(a):
    def first(): a
    def last(a): pass

This leads to a fatal Python error.  The issue is having a being a local or 
parameter (can make 'a' be 'a = 1' and not a parameter and still have it 
fail), the first closure reference it, and then the second one use it as a 
parameter.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470
From noreply at sourceforge.net  Wed Mar 23 11:05:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 23 11:05:53 2005
Subject: [ python-Bugs-1168983 ] ftplib.py string index out of range
Message-ID: <E1DE2kK-000511-0n@sc8-sf-web4.sourceforge.net>

Bugs item #1168983, was opened at 2005-03-23 10: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=1168983&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: David Carroll (vmlinuxz)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib.py string index out of range

Initial Comment:
The following code works great on all of the 2.3.x
releases I have used.

def
ftpFetch(localPath,remoteFileDate,ftpSite,ftpPass,ftpDir,ftpUser):
    print "Fetching split_mgr report"
    fileList=[]
    processList=[]
    ftp = FTP(ftpSite)
    ftp.login(ftpUser,ftpPass)               
    ftp.dir('LIST '+ftpDir,fileList.append)
    for x in range(len(fileList)):
        if (string.find(fileList[x],remoteFileDate) != -1):
            print fileList[x]
            TMP=fileList[x]
            output=localPath+str(TMP[45:])
            print output
            processList.append(output)
            print processList
            outfile = open(output,'w')
            ftp.retrbinary('RETR '+ftpDir+TMP[45:],
open(output, 'wb').write)
    ftp.quit()
    print processList
    return processList

However I get the following error under 2.4

Traceback (most recent call last):
  File
"C:\Python24\lib\site-packages\PythonCard\widget.py",
line 417, in _dispatch
    handler(background, aWxEvent)
  File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\readwaitreport.py",
line 61, in on_btnRun_command
    mainRwclassLoop(self, mm+dd+yy, yesterday)
  File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py",
line 39, in mainRwclassLoop
    processList =
ftpFetch(localPath,"split_mgr."+date[0:4],ftpSite,ftpPass,ftpDir,ftpUser)
  File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py",
line 173, in ftpFetch
    ftp.dir('LIST '+ftpDir,fileList.append)
  File "C:\Python24\lib\ftplib.py", line 464, in dir
    self.retrlines(cmd, func)
  File "C:\Python24\lib\ftplib.py", line 396, in retrlines
    conn = self.transfercmd(cmd)
  File "C:\Python24\lib\ftplib.py", line 345, in
transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "C:\Python24\lib\ftplib.py", line 328, in
ntransfercmd
    if resp[0] != '1':
IndexError: string index out of range

https://lists.dulug.duke.edu/pipermail/yum/2004-August/005067.html
discusses a similar problem under Linux in the YUM
script, I have reproduced this error under 2000, and XP.

I'm a fairly new programmer, and thus very new to
python so I hope this is enough information.  I will
try and keep track of this and help out with more
information in any capacity I can.

Thank you for all your hard work and dedication.
David Carroll

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&group_id=5470
From noreply at sourceforge.net  Wed Mar 23 14:55:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 23 14:55:05 2005
Subject: [ python-Bugs-1169108 ] PySys_WriteStderr() ->
	WaitForSingleObject() hangs system
Message-ID: <E1DE6K6-0002O2-VP@sc8-sf-web3.sourceforge.net>

Bugs item #1169108, was opened at 2005-03-23 13:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169108&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: stan pinte (stanpinte)
Assigned to: Nobody/Anonymous (nobody)
Summary: PySys_WriteStderr() -> WaitForSingleObject() hangs system

Initial Comment:
hello,

I am running Simpy (python simulation framework) within
pythondotnet (a slightly modified python version, based
on python2.4),
and, even though this process is single-thread, it
hangs misteriously,
in an unpredictable way...

Python console cease to respond to Ctrl-C events...

Here is the current Thread status:

Thread Start Address:
Symbol Name:			Line Number:		PC:
mscoree!_CorExeMain() + 0x0	---			7917D08C

Thread Stack:

ntdll ! KiFastSystemCallRet() + 0x
KERNEL32 ! WaitForSingleObject() + 0x12
python24 ! PySys_WriteStderr() + 0x14d
python24 ! PyTuple_Type() + 0x0

However, I would like to be able to go higher in the
stack, to see what
caused this deadlock.

Any proposed strategy to guess what happened, or to
track down the problem?

thanks a lot,

Stan.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169108&group_id=5470
From noreply at sourceforge.net  Wed Mar 23 16:28:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 23 16:28:59 2005
Subject: [ python-Bugs-1169108 ] PySys_WriteStderr() ->
	WaitForSingleObject() hangs system
Message-ID: <E1DE7my-0001Af-Up@sc8-sf-web1.sourceforge.net>

Bugs item #1169108, was opened at 2005-03-23 13:55
Message generated for change (Comment added) made by stanpinte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169108&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: stan pinte (stanpinte)
Assigned to: Nobody/Anonymous (nobody)
Summary: PySys_WriteStderr() -> WaitForSingleObject() hangs system

Initial Comment:
hello,

I am running Simpy (python simulation framework) within
pythondotnet (a slightly modified python version, based
on python2.4),
and, even though this process is single-thread, it
hangs misteriously,
in an unpredictable way...

Python console cease to respond to Ctrl-C events...

Here is the current Thread status:

Thread Start Address:
Symbol Name:			Line Number:		PC:
mscoree!_CorExeMain() + 0x0	---			7917D08C

Thread Stack:

ntdll ! KiFastSystemCallRet() + 0x
KERNEL32 ! WaitForSingleObject() + 0x12
python24 ! PySys_WriteStderr() + 0x14d
python24 ! PyTuple_Type() + 0x0

However, I would like to be able to go higher in the
stack, to see what
caused this deadlock.

Any proposed strategy to guess what happened, or to
track down the problem?

thanks a lot,

Stan.

----------------------------------------------------------------------

>Comment By: stan pinte (stanpinte)
Date: 2005-03-23 15:28

Message:
Logged In: YES 
user_id=154693

 Hello!

I solved my problem by removing all references to
Queue.queue instances in my python code. --> my usage of
Queues was so heavy that it was triggering a nice bug in
python synchronization code.

I was pointed to threading issues by enabling full trace in
my python code, and some traces were showing code from
threading.py

thanks a lot anyway for the help.

Stan.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169108&group_id=5470
From noreply at sourceforge.net  Wed Mar 23 17:10:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 23 17:10:41 2005
Subject: [ python-Bugs-1169212 ] improvement of ossaudiodev module doc.
Message-ID: <E1DE8RL-0007AS-U3@sc8-sf-web2.sourceforge.net>

Bugs item #1169212, was opened at 2005-03-23 18:10
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=1169212&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: hiower (hiower)
Assigned to: Nobody/Anonymous (nobody)
Summary: improvement of ossaudiodev module doc.

Initial Comment:
from
http://docs.python.org/lib/ossaudio-device-objects.html:

AFMT_U8  	Unsigned, 8-bit audio
AFMT_S16_LE 	Unsigned, 16-bit audio, little-endian byte
order
		(as used by Intel processors)
AFMT_S16_BE 	Unsigned, 16-bit audio, big-endian byte order
		(as used by 68k, PowerPC, Sparc)
AFMT_S8 	Signed, 8 bit audio
AFMT_U16_LE 	Signed, 16-bit little-endian audio
AFMT_U16_BE 	Signed, 16-bit big-endian audio

Note how the U:s and S:s are switched compared to
signed and unsigned, this should surely not be like this? 

Perhaps AFMT_AC3 and AFMT_S16_NE should be included as
well? (if anyone uses it?)


also, maybe this line:

write(  data)
    Write the Python string data to the audio device
and return the number of bytes written.

could be subtituted with something like this:

write(  data)
    Write the Python data to the audio device and
return the number of bytes written. The data should be
a string or a list (of amplitude values...something)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169212&group_id=5470
From noreply at sourceforge.net  Wed Mar 23 17:13:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 23 17:13:52 2005
Subject: [ python-Bugs-1169212 ] small change in ossaudiodev module doc.
Message-ID: <E1DE8UQ-0007PB-Sn@sc8-sf-web2.sourceforge.net>

Bugs item #1169212, was opened at 2005-03-23 18:10
Message generated for change (Settings changed) made by hiower
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169212&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: hiower (hiower)
Assigned to: Nobody/Anonymous (nobody)
>Summary: small change in ossaudiodev module doc.

Initial Comment:
from
http://docs.python.org/lib/ossaudio-device-objects.html:

AFMT_U8  	Unsigned, 8-bit audio
AFMT_S16_LE 	Unsigned, 16-bit audio, little-endian byte
order
		(as used by Intel processors)
AFMT_S16_BE 	Unsigned, 16-bit audio, big-endian byte order
		(as used by 68k, PowerPC, Sparc)
AFMT_S8 	Signed, 8 bit audio
AFMT_U16_LE 	Signed, 16-bit little-endian audio
AFMT_U16_BE 	Signed, 16-bit big-endian audio

Note how the U:s and S:s are switched compared to
signed and unsigned, this should surely not be like this? 

Perhaps AFMT_AC3 and AFMT_S16_NE should be included as
well? (if anyone uses it?)


also, maybe this line:

write(  data)
    Write the Python string data to the audio device
and return the number of bytes written.

could be subtituted with something like this:

write(  data)
    Write the Python data to the audio device and
return the number of bytes written. The data should be
a string or a list (of amplitude values...something)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169212&group_id=5470
From noreply at sourceforge.net  Wed Mar 23 21:56:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 23 21:56:07 2005
Subject: [ python-Bugs-1156441 ] Solaris and Python/pykota
Message-ID: <E1DECtX-0004kC-Tz@sc8-sf-web2.sourceforge.net>

Bugs item #1156441, was opened at 2005-03-04 05:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kelly Ormsby (ormsbyka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris and Python/pykota

Initial Comment:
I have a Solaris 9 system that I have installed Python
2.4 on with the following modules:
egenix-mx-base 2.0.6
jaxml3.0.1
python-snmp 3.4.3
psyco 1.4
reportlab 1.20
and postgresql 3.6.1
net-snmp 5.2.1
which are all required by pykota (a print quota
management system)

I am having the issue that when pykota is plugged in to
my cups system, and I try to print, the print job is
put on hold and printing to that printer is stopped.

I tried running the pykota software from the command
line to see what is causing the problem and from what I
(and Jerome Alet from librelogiciel.com) can work out
it is a problem with the solaris build of python.

I have used gcc 3.3 and binutils 2.14 to build python.

The following is what happens when I try running from
the command line:

#python /usr/local/pykota/pykota/pdlanalyzer.py --debug
~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped)
# pkpgcounter --debug ~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped) 

I have attached the pdlanalyzer.py file for you to look at.

Please let me know what I should do.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-23 21:56

Message:
Logged In: YES 
user_id=21627

When you say Solaris, it is not really clear what you mean: x86 or 
SPARC? I very much doubt that psyco works on SPARC.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-04 11:34

Message:
Logged In: YES 
user_id=6656

Well, that's kind of a large module for us to pick at...

Does it only crash on certain postscript files?  Can you run
it under a debugger/analyze a core file to see where it's
crashing?  Does it only crash with 2.4.0 -- can you try
2.3/release24-maint from CVS/CVS HEAD?

It doesn't crash for me with any of the ps files I happen to
have lying around with release24-maint head (what will soon
be 2.4.1) on linux.  I don't have a version 2.4.0 lying
around though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470
From noreply at sourceforge.net  Thu Mar 24 01:23:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 24 01:23:34 2005
Subject: [ python-Bugs-1156441 ] Solaris and Python/pykota
Message-ID: <E1DEG8I-0005z6-SB@sc8-sf-web2.sourceforge.net>

Bugs item #1156441, was opened at 2005-03-04 12:44
Message generated for change (Comment added) made by ormsbyka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kelly Ormsby (ormsbyka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris and Python/pykota

Initial Comment:
I have a Solaris 9 system that I have installed Python
2.4 on with the following modules:
egenix-mx-base 2.0.6
jaxml3.0.1
python-snmp 3.4.3
psyco 1.4
reportlab 1.20
and postgresql 3.6.1
net-snmp 5.2.1
which are all required by pykota (a print quota
management system)

I am having the issue that when pykota is plugged in to
my cups system, and I try to print, the print job is
put on hold and printing to that printer is stopped.

I tried running the pykota software from the command
line to see what is causing the problem and from what I
(and Jerome Alet from librelogiciel.com) can work out
it is a problem with the solaris build of python.

I have used gcc 3.3 and binutils 2.14 to build python.

The following is what happens when I try running from
the command line:

#python /usr/local/pykota/pykota/pdlanalyzer.py --debug
~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped)
# pkpgcounter --debug ~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped) 

I have attached the pdlanalyzer.py file for you to look at.

Please let me know what I should do.

----------------------------------------------------------------------

>Comment By: Kelly Ormsby (ormsbyka)
Date: 2005-03-24 08:23

Message:
Logged In: YES 
user_id=505289

It is sparc solaris (sorry I always forget solaris runs on
x86 :)

So psyco won't work on sparc architecture? Well that sucks.
I was in the process of freshly installing a machine to try
it out on. I guess I won't bother :(

Thanks for your help!

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-24 04:56

Message:
Logged In: YES 
user_id=21627

When you say Solaris, it is not really clear what you mean: x86 or 
SPARC? I very much doubt that psyco works on SPARC.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-04 18:34

Message:
Logged In: YES 
user_id=6656

Well, that's kind of a large module for us to pick at...

Does it only crash on certain postscript files?  Can you run
it under a debugger/analyze a core file to see where it's
crashing?  Does it only crash with 2.4.0 -- can you try
2.3/release24-maint from CVS/CVS HEAD?

It doesn't crash for me with any of the ps files I happen to
have lying around with release24-maint head (what will soon
be 2.4.1) on linux.  I don't have a version 2.4.0 lying
around though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470
From noreply at sourceforge.net  Thu Mar 24 03:18:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 24 03:18:27 2005
Subject: [ python-Bugs-1168427 ] Possible windows+python bug
Message-ID: <E1DEHvU-0007aQ-2U@sc8-sf-web4.sourceforge.net>

Bugs item #1168427, was opened at 2005-03-22 09:38
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2005-03-23 20:18

Message:
Logged In: YES 
user_id=699438

Running your reproducable on XP SP2 (with real IP) returns
"socket.error: (10022, 'Invalid argument')" for me without a
hard crash.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
From noreply at sourceforge.net  Thu Mar 24 05:04:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 24 05:04:59 2005
Subject: [ python-Bugs-1169633 ] Install fail code 2932 after fail to copy
	python_icon.exe
Message-ID: <E1DEJab-0002Z7-57@sc8-sf-web4.sourceforge.net>

Bugs item #1169633, was opened at 2005-03-24 01:04
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=1169633&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wagner (wks2)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install fail code 2932 after fail to copy python_icon.exe

Initial Comment:

In the Enterprise Windows environment we have a 
Network share as the homedir for all users.

The server forbid to write .exe files to this share.

I can install programs in the local disk (I have lots of 
then installed).

Python-2.4.MSI Installation fails with error code 2932 
after the system rejects the copy of python_icon.exe to 
the homedir.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169633&group_id=5470
From noreply at sourceforge.net  Thu Mar 24 07:43:34 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 24 07:43:37 2005
Subject: [ python-Bugs-1169679 ] modules missing from list of Carbon modules
Message-ID: <E1DEM46-0002H2-O8@sc8-sf-web2.sourceforge.net>

Bugs item #1169679, was opened at 2005-03-23 22:43
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=1169679&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jesse Weinstein (weinsteinj)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules missing from list of Carbon modules

Initial Comment:
help(Carbon) lists 37 modules within the Carbon package
that are not listed on
http://docs.python.org/mac/toolbox.html
Even if nothing can be said about them, they should at
least be listed on that page(and in the ToC) so people
won't miss their existance.

Here's the list:
    Alias
    Aliases
    Appearance
    AppleEvents
    AppleHelp
    CarbonEvents
    Components
    ControlAccessor
    Controls
    CoreFoundation
    CoreGraphics
    Dialogs
    Drag
    Dragconst
    Events
    File
    Files
    Folders
    Fonts
    IBCarbon
    IBCarbonRuntime
    Icn
    Icons
    Lists
    MacHelp
    MacTextEditor
    MediaDescr
    Menus
    QDOffscreen
    QuickDraw
    QuickTime
    Resources
    Sndihooks
    Sound
    TextEdit
    WASTEconst
    Windows

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169679&group_id=5470
From noreply at sourceforge.net  Thu Mar 24 07:45:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 24 07:45:14 2005
Subject: [ python-Bugs-1169679 ] modules missing from list of Carbon modules
Message-ID: <E1DEM5f-0008IF-KU@sc8-sf-web4.sourceforge.net>

Bugs item #1169679, was opened at 2005-03-23 22:43
Message generated for change (Settings changed) made by weinsteinj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169679&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jesse Weinstein (weinsteinj)
>Assigned to: Jack Jansen (jackjansen)
Summary: modules missing from list of Carbon modules

Initial Comment:
help(Carbon) lists 37 modules within the Carbon package
that are not listed on
http://docs.python.org/mac/toolbox.html
Even if nothing can be said about them, they should at
least be listed on that page(and in the ToC) so people
won't miss their existance.

Here's the list:
    Alias
    Aliases
    Appearance
    AppleEvents
    AppleHelp
    CarbonEvents
    Components
    ControlAccessor
    Controls
    CoreFoundation
    CoreGraphics
    Dialogs
    Drag
    Dragconst
    Events
    File
    Files
    Folders
    Fonts
    IBCarbon
    IBCarbonRuntime
    Icn
    Icons
    Lists
    MacHelp
    MacTextEditor
    MediaDescr
    Menus
    QDOffscreen
    QuickDraw
    QuickTime
    Resources
    Sndihooks
    Sound
    TextEdit
    WASTEconst
    Windows

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169679&group_id=5470
From noreply at sourceforge.net  Thu Mar 24 19:24:12 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 24 19:24:15 2005
Subject: [ python-Bugs-1170065 ] HTTPResponse.getheaders() returns
	lowercased header names
Message-ID: <E1DEX08-0002bi-On@sc8-sf-web3.sourceforge.net>

Bugs item #1170065, was opened at 2005-03-24 18:24
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=1170065&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: yain (yain)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPResponse.getheaders() returns lowercased header names

Initial Comment:
I'm not sure, if this is a bug, or intentional
behaviour, because on one hand RFC states that field
names for HTTP headers are case-insensitive, on the
other hand, it's not what server really returns to client.

Example:

print response.getheaders()

Yields this (output formatted a bit for clarity):

[('content-length', '5998'), 
('accept-ranges', 'bytes'), 
('last-modified', 'Sun, 30 Jan 2005 14:36:09 GMT'), 
('connection', 'close'), 
('etag', '"26d79-176e-41fcf0d9"'), 
('date', 'Thu, 24 Mar 2005 18:14:07 GMT'), 
('content-type', 'text/html')]



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170065&group_id=5470
From noreply at sourceforge.net  Thu Mar 24 19:32:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 24 19:32:33 2005
Subject: [ python-Bugs-1170065 ] HTTPResponse.getheaders() returns
	lowercased header names
Message-ID: <E1DEX8B-000203-Ao@sc8-sf-web2.sourceforge.net>

Bugs item #1170065, was opened at 2005-03-24 18:24
Message generated for change (Settings changed) made by yain
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170065&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 3
Submitted By: yain (yain)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPResponse.getheaders() returns lowercased header names

Initial Comment:
I'm not sure, if this is a bug, or intentional
behaviour, because on one hand RFC states that field
names for HTTP headers are case-insensitive, on the
other hand, it's not what server really returns to client.

Example:

print response.getheaders()

Yields this (output formatted a bit for clarity):

[('content-length', '5998'), 
('accept-ranges', 'bytes'), 
('last-modified', 'Sun, 30 Jan 2005 14:36:09 GMT'), 
('connection', 'close'), 
('etag', '"26d79-176e-41fcf0d9"'), 
('date', 'Thu, 24 Mar 2005 18:14:07 GMT'), 
('content-type', 'text/html')]



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170065&group_id=5470
From noreply at sourceforge.net  Thu Mar 24 19:33:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 24 19:33:20 2005
Subject: [ python-Bugs-1170065 ] HTTPResponse.getheaders() returns
	lowercased header names
Message-ID: <E1DEX8v-0007bJ-Vg@sc8-sf-web4.sourceforge.net>

Bugs item #1170065, was opened at 2005-03-24 18:24
Message generated for change (Settings changed) made by yain
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170065&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 1
Submitted By: yain (yain)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPResponse.getheaders() returns lowercased header names

Initial Comment:
I'm not sure, if this is a bug, or intentional
behaviour, because on one hand RFC states that field
names for HTTP headers are case-insensitive, on the
other hand, it's not what server really returns to client.

Example:

print response.getheaders()

Yields this (output formatted a bit for clarity):

[('content-length', '5998'), 
('accept-ranges', 'bytes'), 
('last-modified', 'Sun, 30 Jan 2005 14:36:09 GMT'), 
('connection', 'close'), 
('etag', '"26d79-176e-41fcf0d9"'), 
('date', 'Thu, 24 Mar 2005 18:14:07 GMT'), 
('content-type', 'text/html')]



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170065&group_id=5470
From noreply at sourceforge.net  Thu Mar 24 22:19:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 24 22:19:21 2005
Subject: [ python-Bugs-1156441 ] Solaris and Python/pykota
Message-ID: <E1DEZjO-0001gL-41@sc8-sf-web3.sourceforge.net>

Bugs item #1156441, was opened at 2005-03-04 05:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470

Category: Python Interpreter Core
>Group: 3rd Party
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kelly Ormsby (ormsbyka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris and Python/pykota

Initial Comment:
I have a Solaris 9 system that I have installed Python
2.4 on with the following modules:
egenix-mx-base 2.0.6
jaxml3.0.1
python-snmp 3.4.3
psyco 1.4
reportlab 1.20
and postgresql 3.6.1
net-snmp 5.2.1
which are all required by pykota (a print quota
management system)

I am having the issue that when pykota is plugged in to
my cups system, and I try to print, the print job is
put on hold and printing to that printer is stopped.

I tried running the pykota software from the command
line to see what is causing the problem and from what I
(and Jerome Alet from librelogiciel.com) can work out
it is a problem with the solaris build of python.

I have used gcc 3.3 and binutils 2.14 to build python.

The following is what happens when I try running from
the command line:

#python /usr/local/pykota/pykota/pdlanalyzer.py --debug
~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped)
# pkpgcounter --debug ~kelly/align.ps
/home/staff/kelly/align.ps is a PostScript file
Bus error (core dumped) 

I have attached the pdlanalyzer.py file for you to look at.

Please let me know what I should do.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-24 22:19

Message:
Logged In: YES 
user_id=21627

psyco is a just-in-time compiler, and it only supports x86. However, I very 
much doubt that it is *really* needed by that application. As it doesn't do 
anything but JIT, you should be able to take it out fairly easily.

Closing as third-party bug.

----------------------------------------------------------------------

Comment By: Kelly Ormsby (ormsbyka)
Date: 2005-03-24 01:23

Message:
Logged In: YES 
user_id=505289

It is sparc solaris (sorry I always forget solaris runs on
x86 :)

So psyco won't work on sparc architecture? Well that sucks.
I was in the process of freshly installing a machine to try
it out on. I guess I won't bother :(

Thanks for your help!

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-23 21:56

Message:
Logged In: YES 
user_id=21627

When you say Solaris, it is not really clear what you mean: x86 or 
SPARC? I very much doubt that psyco works on SPARC.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-04 11:34

Message:
Logged In: YES 
user_id=6656

Well, that's kind of a large module for us to pick at...

Does it only crash on certain postscript files?  Can you run
it under a debugger/analyze a core file to see where it's
crashing?  Does it only crash with 2.4.0 -- can you try
2.3/release24-maint from CVS/CVS HEAD?

It doesn't crash for me with any of the ps files I happen to
have lying around with release24-maint head (what will soon
be 2.4.1) on linux.  I don't have a version 2.4.0 lying
around though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470
From noreply at sourceforge.net  Fri Mar 25 02:03:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 25 02:04:00 2005
Subject: [ python-Bugs-1170279 ] BaseCookie does not call value_decode
Message-ID: <E1DEdF0-0000wc-Bu@sc8-sf-web2.sourceforge.net>

Bugs item #1170279, was opened at 2005-03-25 01:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170279&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan Lovett (ryan)
Assigned to: Nobody/Anonymous (nobody)
Summary: BaseCookie does not call value_decode

Initial Comment:
Perhaps I'm misunderstanding its functionality, but I
believe BaseCookie should be calling value_decode
during __getitem__. I created a blowfish Cookie class
with value_encode and value_decode methods, but when I
invoke __getitem__, for example mycookie['mykey'], the
cookie only returns encoded values.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170279&group_id=5470
From noreply at sourceforge.net  Fri Mar 25 03:51:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 25 03:51:58 2005
Subject: [ python-Bugs-1170311 ] zipfile UnicodeDecodeError
Message-ID: <E1DEevU-0008TO-6u@sc8-sf-web1.sourceforge.net>

Bugs item #1170311, was opened at 2005-03-25 02:51
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=1170311&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: adam davis (adamx97)
Assigned to: M.-A. Lemburg (lemburg)
Summary: zipfile UnicodeDecodeError

Initial Comment:
I think this is the same as #  705295, which may have
been prematurely closed.

I think the error is dependent on the data or time.

File "C:\Python24\lib\zipfile.py", line 166, in FileHeader
    return header + self.filename + self.extra
UnicodeDecodeError: 'ascii' codec can't decode byte
0xd0 in position 10: ordinal not in range(128)

The header is packed like this:
        header = struct.pack(structFileHeader,
stringFileHeader,
                 self.extract_version, self.reserved,
self.flag_bits,
                 self.compress_type, dostime, dosdate, CRC,
                 compress_size, file_size,
                 len(self.filename), len(self.extra))

the header is:

[Dbg]>>> header
'PK\x03\x04\x14\x00\x00\x00\x00\x00\xd0\xa9x2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00-\x00\x00\x00'

and here are the parts that made it up:

[Dbg]>>> structFileHeader, stringFileHeader,
self.extract_version, self.reserved,
self.flag_bits,self.compress_type, dostime, dosdate,
CRC, compress_size, file_size, len(self.filename),
len(self.extra)
('<4s2B4HlLL2H', 'PK\x03\x04', 20, 0, 0, 0, 43472,
12920, 0, 0, 0, 45, 0)


here's the pieces of the 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470
From noreply at sourceforge.net  Fri Mar 25 05:05:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 25 05:05:58 2005
Subject: [ python-Bugs-1170331 ] Error in base64.b32decode
Message-ID: <E1DEg55-0002I7-5o@sc8-sf-web4.sourceforge.net>

Bugs item #1170331, was opened at 2005-03-25 05: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=1170331&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: toidinamai (toidinamai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in base64.b32decode

Initial Comment:
Hi,                                                   
                                                      
                                                         
                                                      
                                                      
                                                         
I believe there is an error in base64.b32decode because
it doesn't seem to                                    
                                                          
allow to decode arbitrary binary data:                
                                                      
                                                         

<code>                                                
                                                      
                                                         
#!/usr/bin/env python2.4                              
                                                      
                                                         
                                                      
                                                      
                                                         
import base64                                         
                                                      
                                                         
                                                      
                                                      
                                                         
b64d = base64.b64decode                               
                                                      
                                                         
b64e = base64.b64encode                               
                                                      
                                                         
                                                      
                                                      
                                                         
print "base64: ", repr(b64d(b64e('\x00')))            
                                                      
                                                         
                                                      
                                                      
                                                         
b16d = base64.b16decode                               
                                                      
                                                         
b16e = base64.b16encode                               
                                                      
                                                         
                                                      
                                                      
                                                         
print "base16: ", repr(b16d(b16e('\x00')))            
                                                      
                                                         
                                                      
                                                      
                                                         
b32d = base64.b32decode                               
                                                      
                                                         
b32e = base64.b32encode                               
                                                      
                                                         
                                                      
                                                      
                                                         
print "base32: ", repr(b32d(b32e('\x00')))            
                                                      
                                                         
</code>                                               
                                                      
                                                         
                                                      
                                                      
                                                         
This raises a very strange exception:                 
                                                      
                                                         
                                                      
                                                      
                                                         
Traceback (most recent call last):                    
                                                      
                                                         
  File "test.py", line 18, in ?                       
                                                      
                                                         
    print "base32: ", repr(b32d(b32e('\x00')))        
                                                      
                                                         
  File "/usr/lib/python2.4/base64.py", line 228, in
b32decode                                             
                                                      
     
    last = binascii.unhexlify(hex(acc)[2:-1])         
                                                      
                                                         
TypeError: Odd-length string                          
                                                      
                                                         
                                                      
                                                      
                                                         
b32 should work just like b64 and b16.                
                                                      
                                                      
                                                      
                                                      
                                            

Best regards
Frank Bensktein.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470
From noreply at sourceforge.net  Fri Mar 25 10:56:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 25 10:56:59 2005
Subject: [ python-Bugs-1170422 ] doc speaks of extensions option while it's
	*called* ext_modu
Message-ID: <E1DElYn-0004yN-1y@sc8-sf-web4.sourceforge.net>

Bugs item #1170422, was opened at 2005-03-25 10:56
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=1170422&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: J?rgen A. Erhard (jae)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc speaks of extensions option while it's *called* ext_modu

Initial Comment:
ext_modules, of course (crap bugtracker)

Another minor fix would be to show an import Extension
in at least one example.  Quite a lot easier to see for
the impatient.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170422&group_id=5470
From noreply at sourceforge.net  Fri Mar 25 10:58:27 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 25 10:58:29 2005
Subject: [ python-Bugs-1170424 ] why should URL be required for all packages
Message-ID: <E1DElaF-0001zN-4A@sc8-sf-web2.sourceforge.net>

Bugs item #1170424, was opened at 2005-03-25 10:58
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=1170424&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: J?rgen A. Erhard (jae)
Assigned to: Nobody/Anonymous (nobody)
Summary: why should URL be required for all packages

Initial Comment:
Annoying if you just want to roll an in-house package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170424&group_id=5470
From noreply at sourceforge.net  Fri Mar 25 11:03:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 25 11:03:09 2005
Subject: [ python-Bugs-1170422 ] doc speaks of extensions option while it's
	*called* ext_modu
Message-ID: <E1DElel-0002ni-M5@sc8-sf-web3.sourceforge.net>

Bugs item #1170422, was opened at 2005-03-25 10:56
Message generated for change (Comment added) made by jae
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170422&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: J?rgen A. Erhard (jae)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc speaks of extensions option while it's *called* ext_modu

Initial Comment:
ext_modules, of course (crap bugtracker)

Another minor fix would be to show an import Extension
in at least one example.  Quite a lot easier to see for
the impatient.

----------------------------------------------------------------------

>Comment By: J?rgen A. Erhard (jae)
Date: 2005-03-25 11:03

Message:
Logged In: YES 
user_id=10380

Ouch, forget about the import Extension... it's there, and I
was just blind.  Note to self: the usual ;-)

(I wish I could edit my own submissions)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170422&group_id=5470
From noreply at sourceforge.net  Fri Mar 25 12:22:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 25 12:22:34 2005
Subject: [ python-Bugs-1170460 ] gc module docu
Message-ID: <E1DEmtb-0001Uc-WF@sc8-sf-web1.sourceforge.net>

Bugs item #1170460, was opened at 2005-03-25 12:22
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=1170460&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Renold (martinxyz)
Assigned to: Nobody/Anonymous (nobody)
Summary: gc module docu

Initial Comment:
It says: "To debug a leaking program call
gc.set_debug(gc.DEBUG_LEAK)."

I added this call, found the leak, fixed it, and
watched the memory consumption - argh.

Please add a warning sentence like: "Note: this will
stop freeing the collected memory."


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170460&group_id=5470
From noreply at sourceforge.net  Fri Mar 25 22:54:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 25 22:54:35 2005
Subject: [ python-Bugs-1170766 ] weakref.proxy incorrect behaviour
Message-ID: <E1DEwlE-00069f-JR@sc8-sf-web2.sourceforge.net>

Bugs item #1170766, was opened at 2005-03-26 00:54
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=1170766&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470
From noreply at sourceforge.net  Sat Mar 26 03:51:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 26 03:51:39 2005
Subject: [ python-Bugs-1170279 ] BaseCookie does not call value_decode
Message-ID: <E1DF1Oj-00036q-44@sc8-sf-web1.sourceforge.net>

Bugs item #1170279, was opened at 2005-03-25 01:03
Message generated for change (Settings changed) made by ryan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170279&group_id=5470

Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan Lovett (ryan)
Assigned to: Nobody/Anonymous (nobody)
Summary: BaseCookie does not call value_decode

Initial Comment:
Perhaps I'm misunderstanding its functionality, but I
believe BaseCookie should be calling value_decode
during __getitem__. I created a blowfish Cookie class
with value_encode and value_decode methods, but when I
invoke __getitem__, for example mycookie['mykey'], the
cookie only returns encoded values.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170279&group_id=5470
From noreply at sourceforge.net  Sat Mar 26 11:41:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 26 11:41:36 2005
Subject: [ python-Bugs-853411 ] After fork in subthread, signals are blocked
Message-ID: <E1DF8jS-0007Sr-Nd@sc8-sf-web3.sourceforge.net>

Bugs item #853411, was opened at 2003-12-03 16:55
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470

Category: Threads
Group: Python 2.2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: G?ran Uddeborg (goeran)
Assigned to: Nobody/Anonymous (nobody)
Summary: After fork in subthread, signals are blocked

Initial Comment:
When a Python program starts a new thread, and this new
thread forks, the forked process ingores signals.  It
will not terminate, or dump core if that would be
applicable, when it receives a signal.

I attach a test case which illustrates the behaviour. 
In this example, the child process is sent a SEGV
signal from the subthread of the parent process.  This
should cause the child process to die and produce a
core.  But execution of the parent program threads
finishes, there is still a python process around,
continuing to sleep.

Apparently, Python subthreads blocks signals.  On
Linux, /proc/*/status for subthreads includes the line

SigBlk: ffffffff7ffbfeff

The Python documentation says one should only install
signal handlers in the main thread, and only the main
thread will recieve signals.  So this makes sense.  But
when the subthread forks, the new process inherits this
signal mask, which seems to be incorrect behaviour.  I
would assume, if Python sets this signal mask for
threads, it should also reset it again after a fork.

I've seen this on these two platforms:
Python 2.2.3 on Red Hat Linux RHEL 3WS (IA32)
Python 2.2.1 on Sun Solaris 8 (Sparc)

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-26 10:41

Message:
Logged In: YES 
user_id=6656

Good.  Closing.

----------------------------------------------------------------------

Comment By: Erik Osheim (moculus)
Date: 2005-03-21 05:07

Message:
Logged In: YES 
user_id=542811

I can confirm that on my install of 2.4, I no longer get
this problem.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 08:59

Message:
Logged In: YES 
user_id=6656

I think this should be fixed in Python 2.4.

----------------------------------------------------------------------

Comment By: Erik Osheim (moculus)
Date: 2005-03-18 03:45

Message:
Logged In: YES 
user_id=542811

This bug is still around. I have been experiencing it
firsthand: if I write a simple program with one parent and
one child thread and run rsync in the parent thread (via
os.system), all is well. In the child thread it hangs
indefinitely.

After putting a bunch of debugging into rsync, I discovered
that a USR2 signal was getting sent but never received, and
rsyncs parent thread was waiting for the child to exit, and
that the child was sleeping (having not gotten the signal).

Is there any clue as to why this happens? This has been
widely observed on Linux 2.6.* (this particular case affects
Gentoo).


----------------------------------------------------------------------

Comment By: gmanipon (pymonger)
Date: 2004-12-06 21:24

Message:
Logged In: YES 
user_id=1173063

Sorry for the bother.

Was there any resolution to this bug report?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-01-26 10:02

Message:
Logged In: YES 
user_id=45365

I have absolutely no idea where the bug could be, someone better 
versed in the threading ideosyncracies of the various platforms 
needs to look at this, but I do want to point at hairy_flange's 
comment that fink-python 2.2.3 on OSX does *not* exhibit the bug 
(while on other platforms it does). It may be worthwhile to 
download a fink-python in source form, and see whether they do 
any configure magic.

----------------------------------------------------------------------

Comment By: Steve Muir (hairy_flange)
Date: 2004-01-26 04:04

Message:
Logged In: YES 
user_id=960132

I just submitted a bug report that is a duplicate of this bug
(apologies!), I observed the same behaviour with the Python
shipped with Mac OS X (Python 2.3), and Python 2.2.2 on
RedHat/x86, but Fink Python 2.2.3 for OS X does not have
this bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470
From noreply at sourceforge.net  Sat Mar 26 15:40:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 26 15:41:00 2005
Subject: [ python-Bugs-1171023 ] Thread.join() fails to release Lock on
	KeyboardInterrupt
Message-ID: <E1DFCTB-0006iF-4r@sc8-sf-web4.sourceforge.net>

Bugs item #1171023, was opened at 2005-03-26 09:40
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=1171023&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread.join() fails to release Lock on KeyboardInterrupt

Initial Comment:
In threading.Thread.join(), the Condition/Lock object
called self.__block is acquired upon entry, and
released on exit without an enclosing try/finally to
ensure that the release really occurs.

If the join() call has no timeout, the wait() call that
occurs inside can never be interrupted so there is no
problem.

If the join() call has a timeout, however, the wait()
occurs in a loop which can be interrupted by a Ctrl-C,
raising a KeyboardInterrupt which skips the
self.__block.release() call and leaves the Lock acquired.

This is a problem if the main thread (which is the only
one that will see a KeyboardInterrupt) is the one
calling join() and only if the other thread on which
the join() is being called is a non-daemon thread or,
in the case of a daemon thread, if the main thread
subsequently attempts to wait for the other thread to
terminate (for example, by monitoring isAlive() on the
other thread).

In any event, the lack of a try/finally means the
joined thread will never really finish because any
attempt by it to call its __stop() method will block
forever.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470
From noreply at sourceforge.net  Sat Mar 26 15:50:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 26 15:50:39 2005
Subject: [ python-Bugs-1170766 ] weakref.proxy incorrect behaviour
Message-ID: <E1DFCcX-0005Tm-0N@sc8-sf-web2.sourceforge.net>

Bugs item #1170766, was opened at 2005-03-25 21:54
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2005-03-26 14:50

Message:
Logged In: YES 
user_id=4771

The bug is in weakrefobject:proxy_nonzero(), which calls the underlying object's nb_nonzero slot instead of going through the general PyObject_IsTrue() mecanism.  Built-in types like list and dict don't have a nb_nonzero slot.

As a related bug, (Callable)ProxyType should implement tp_richcompare in addition to tp_compare.  In fact, we should review the code to check if ProxyType knows about the most recent type slots...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470
From noreply at sourceforge.net  Sat Mar 26 15:59:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 26 15:59:30 2005
Subject: [ python-Bugs-1167930 ] threading.Thread.join() cannot be
	interrupted by a Ctrl-C
Message-ID: <E1DFCl4-0005kh-0G@sc8-sf-web2.sourceforge.net>

Bugs item #1167930, was opened at 2005-03-21 17:19
Message generated for change (Comment added) made by phansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167930&group_id=5470

Category: Threads
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicholas Veeser (nveeser)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread.join() cannot be interrupted by a Ctrl-C

Initial Comment:
I write a python program that that starts several
threads and then waits on them all.  If I use join() to
wait on the threads, there is no way to Stop the
process with Ctrl-C.  

Threading.Thread.join() uses a lock
(thread.allocate_lock())  to put itself on the
"wait_queue".    It then calls thread.Lock.acquire(),
which blocks indefinitely.  Lock.acquire() (at least in
POSIX) seems to work in such a way as to ignore any
signals.  (both semaphore and condition variable type).
    

PyThread_acquire_lock() will not return until the lock
is acquired, even if a signal is sent.   Effectively,
Ctrl-C is "masked" until the lock is released, (the
joined thread is done), and the main thread comes back
to the interpreter and handles the signal, producing a
KeyboardInterrupt Exception.  But not before the lock
is released, which is once the thread is finished,
which is too late if you want to kill the main thread
and have it gracefully stop its child threads.

So the "main" thread has no way to call, join() and
still respond to Ctrl-C in some way.

One solution could be to change threading.Thread.join()
to use other methods of synchronization which respond
to Ctrl-C more effectively.

Another solution would be to have Lock.acquire() throw
a KeyboardInterruped exception like other system calls.
 This IHMO would make the python objects behave more
like Java, which requires catching the
InterruptedException, giving the developer more control
over how to handle this case.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 09:59

Message:
Logged In: YES 
user_id=567267

Coincidentally this issue came up in a thread in
comp.lang.python just now.  See tim one's reply at
http://groups.google.ca/groups?selm=mailman.884.1111815188.1799.python-list%40python.org
which indicates that "it's simply not possible for Ctrl+C to
interrupt a mutex acquire".

A workaround is to be sure to call join() with a timeout
value, inside a loop if you absolutely need an indefinite
timeout, but that won't necessarily work because of a
different problem which I just reported as bug 1171023. 
There's a workaround for that problem too though, provided
you can subclass threading.Thread: provide your own join()
which wraps the builtin one and which attempts to release
the lock safely.  I'll attach an example if I can figure out
how... there's no option to do so on this particular page in
Sourceforge. :-(

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167930&group_id=5470
From noreply at sourceforge.net  Sat Mar 26 16:19:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 26 16:19:38 2005
Subject: [ python-Bugs-1171023 ] Thread.join() fails to release Lock on
	KeyboardInterrupt
Message-ID: <E1DFD4a-0006Mz-7W@sc8-sf-web2.sourceforge.net>

Bugs item #1171023, was opened at 2005-03-26 09:40
Message generated for change (Comment added) made by phansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread.join() fails to release Lock on KeyboardInterrupt

Initial Comment:
In threading.Thread.join(), the Condition/Lock object
called self.__block is acquired upon entry, and
released on exit without an enclosing try/finally to
ensure that the release really occurs.

If the join() call has no timeout, the wait() call that
occurs inside can never be interrupted so there is no
problem.

If the join() call has a timeout, however, the wait()
occurs in a loop which can be interrupted by a Ctrl-C,
raising a KeyboardInterrupt which skips the
self.__block.release() call and leaves the Lock acquired.

This is a problem if the main thread (which is the only
one that will see a KeyboardInterrupt) is the one
calling join() and only if the other thread on which
the join() is being called is a non-daemon thread or,
in the case of a daemon thread, if the main thread
subsequently attempts to wait for the other thread to
terminate (for example, by monitoring isAlive() on the
other thread).

In any event, the lack of a try/finally means the
joined thread will never really finish because any
attempt by it to call its __stop() method will block
forever.

----------------------------------------------------------------------

>Comment By: Peter Hansen (phansen)
Date: 2005-03-26 10:19

Message:
Logged In: YES 
user_id=567267

A workaround (tested) is to subclass Thread and ensure that
the lock is released.  I'm not certain this is completely
safe as written, but I'm assuming that you can safely
attempt to release a lock that you don't own and the worst
that can happen is you'll get an exception (which the
workaround code catches and ignores).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470
From noreply at sourceforge.net  Sat Mar 26 16:22:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 26 16:22:21 2005
Subject: [ python-Bugs-1167930 ] threading.Thread.join() cannot be
	interrupted by a Ctrl-C
Message-ID: <E1DFD7B-0006S7-L4@sc8-sf-web2.sourceforge.net>

Bugs item #1167930, was opened at 2005-03-21 17:19
Message generated for change (Comment added) made by phansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167930&group_id=5470

Category: Threads
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicholas Veeser (nveeser)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread.join() cannot be interrupted by a Ctrl-C

Initial Comment:
I write a python program that that starts several
threads and then waits on them all.  If I use join() to
wait on the threads, there is no way to Stop the
process with Ctrl-C.  

Threading.Thread.join() uses a lock
(thread.allocate_lock())  to put itself on the
"wait_queue".    It then calls thread.Lock.acquire(),
which blocks indefinitely.  Lock.acquire() (at least in
POSIX) seems to work in such a way as to ignore any
signals.  (both semaphore and condition variable type).
    

PyThread_acquire_lock() will not return until the lock
is acquired, even if a signal is sent.   Effectively,
Ctrl-C is "masked" until the lock is released, (the
joined thread is done), and the main thread comes back
to the interpreter and handles the signal, producing a
KeyboardInterrupt Exception.  But not before the lock
is released, which is once the thread is finished,
which is too late if you want to kill the main thread
and have it gracefully stop its child threads.

So the "main" thread has no way to call, join() and
still respond to Ctrl-C in some way.

One solution could be to change threading.Thread.join()
to use other methods of synchronization which respond
to Ctrl-C more effectively.

Another solution would be to have Lock.acquire() throw
a KeyboardInterruped exception like other system calls.
 This IHMO would make the python objects behave more
like Java, which requires catching the
InterruptedException, giving the developer more control
over how to handle this case.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 10:22

Message:
Logged In: YES 
user_id=567267

It appears only the original submitter (and admins?) can
attach files, so I've attached the example workaround in the
other bug report that I submitted.  It makes more sense in
that one anyway.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 09:59

Message:
Logged In: YES 
user_id=567267

Coincidentally this issue came up in a thread in
comp.lang.python just now.  See tim one's reply at
http://groups.google.ca/groups?selm=mailman.884.1111815188.1799.python-list%40python.org
which indicates that "it's simply not possible for Ctrl+C to
interrupt a mutex acquire".

A workaround is to be sure to call join() with a timeout
value, inside a loop if you absolutely need an indefinite
timeout, but that won't necessarily work because of a
different problem which I just reported as bug 1171023. 
There's a workaround for that problem too though, provided
you can subclass threading.Thread: provide your own join()
which wraps the builtin one and which attempts to release
the lock safely.  I'll attach an example if I can figure out
how... there's no option to do so on this particular page in
Sourceforge. :-(

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167930&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 01:01:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 01:01:56 2005
Subject: [ python-Bugs-666958 ] repr.repr not always safe
Message-ID: <E1DFLDz-0007tJ-16@sc8-sf-web4.sourceforge.net>

Bugs item #666958, was opened at 2003-01-12 23:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: repr.repr not always safe

Initial Comment:
&gt;&gt;&gt; class A:
...   def __repr__(self):
...     raise Exception
...   def someMethod(self):
...     pass
... 
&gt;&gt;&gt; A()
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;&lt;stdin&gt;&quot;, line 3, in __repr__
Exception
&gt;&gt;&gt; repr.repr(A())
'&lt;A instance at 237360&gt;'
&gt;&gt;&gt; repr.repr(A().someMethod)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;/usr/lib/python2.2/repr.py&quot;, line 15, in repr
    return self.repr1(x, self.maxlevel)
  File &quot;/usr/lib/python2.2/repr.py&quot;, line 24, in repr1
    s = `x`
  File &quot;&lt;stdin&gt;&quot;, line

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-26 19:01

Message:
Logged In: YES 
user_id=80475

The behavior of repr.repr(A().someMethod) is the same as `repr
(A().someMethod)`.

Also, in list example provided, a debugger takes you right to the 
heart of the OP's issue (resolving a faulty user implementation of 
__repr__).

I believe the current behavior both useful and correct.  The 
offered use case is somewhat rare and better solved with pdb. 
Changing the current behavior would likely impact someone's 
existing code (doctests for example).  Recommend closing this 
bug.



----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-15 19:10

Message:
Logged In: YES 
user_id=752496

What seems like a bug to me is that "repr.repr(A())" and
"repr.repr(A().someMethod)" doesn't have the same behaviour.

As this still happens in Py2.3.3, I updated the bug metadata.

.    Facundo

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-06 20:33

Message:
Logged In: YES 
user_id=33168

Bob, I'm not sure I understand what you want (ie, what
behaviour you desire).  If you could provide a patch to the
repr module, that could help me.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-02-03 15:27

Message:
Logged In: YES 
user_id=139309

Yes, of course repr.repr is for debugging use.. and it
*really* sucks if your debugger crashes!  I'm sure that's
why it's inconsistent with __builtins__.repr, the bug I'm
reporting is that it's inconsistent with itself.

Going back to the example of a list again.  If you're
debugging a list that has one or two items that raise an
exception, it's infinitely more useful to know *which* items
have a broken __repr__ (along with the context of the valid
objects), rather than knowing *one or more* items in the
list has a broken __repr__.  repr.repr is often called
recursively; if something bad happens far down in the call
stack it can really be a pain to track down where it
happened (all tracebacks to repr are going to look mostly
the same) unless repr.repr is fixed to handle this situation.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-01-21 15:58

Message:
Logged In: YES 
user_id=539787

Sorry, incomplete last post, I clicked in the wrong place (ie 
SUBMIT) to come back to IE.

The case is that repr.py is documented as for debugging 
use... you suggest that all exceptions are caught, but that 
would not be consistent with __builtins__.repr .

If the module was intended for generic use, I would suggest 
the opposite; no exceptions should be caught (for 
consistency).

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-01-21 15:47

Message:
Logged In: YES 
user_id=539787

Do you suggest to remove the exception catching in 
Repr.repr_instance or adding a try clause in the s = `x` line of 
Repr.repr1 ?

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-01-20 09:11

Message:
Logged In: YES 
user_id=139309

It's not my module, it comes with Python (at least in my 2.2, and 2.3 CVS HEAD).  Look for yourself!

The issue has nothing to do with the fact that it has the same name as the builtin.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-01-20 00:28

Message:
Logged In: YES 
user_id=539787

Did you try to change the module name to, say, repr2 and 
then run it again?  Any specific reason you named the 
module as an internal function?
BTW, what is repr.repr supposed to do?  Please supply the 
repr.py script, along with the full traceback.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-01-13 09:54

Message:
Logged In: YES 
user_id=139309

I say it's a bug because it's inconsistent behavior.  You
can repr the class instance that throws during a __repr__
just fine ('&lt;A instance at 237360&gt;' ), but you can't
__repr__ a bound method of the class instance without
throwing an exception.  In fact, if the __repr__ of the
class instance returns anything but a string, say it returns
None for example, then the exception will bubble all the way
up and you get no useful output from repr.repr.

It's very annoying if you're doing something equivalent to,
but more useful than:
repr.repr([1, 2, 3, 4, A().someMethod, 6, 7, 8, A()])

Note that repr.repr([1, 2, 3, 4, A(), 6, 7, 8]) does not
throw any exceptions.

There should be some sort of graceful way to do it, no?  I
think it ought to handle the bound method broken instance
case just like it handles the broken instance case directly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-12 23:34

Message:
Logged In: YES 
user_id=31435

Why do say this is a bug?  If you raise an exception, yes, 
you get an exception.  Most __repr__ *implementations* 
try hard not to raise any exceptions, but it's never 
guaranteed that they won't.  For example, just about any 
__repr__ implementation may run out of memory while 
trying to build its result string, so MemoryError is almost 
always a possible exception.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 04:50:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 04:50:30 2005
Subject: [ python-Bugs-666958 ] repr.repr not always safe
Message-ID: <E1DFNr8-0002Fu-D5@sc8-sf-web3.sourceforge.net>

Bugs item #666958, was opened at 2003-01-12 23:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: repr.repr not always safe

Initial Comment:
&gt;&gt;&gt; class A:
...   def __repr__(self):
...     raise Exception
...   def someMethod(self):
...     pass
... 
&gt;&gt;&gt; A()
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;&lt;stdin&gt;&quot;, line 3, in __repr__
Exception
&gt;&gt;&gt; repr.repr(A())
'&lt;A instance at 237360&gt;'
&gt;&gt;&gt; repr.repr(A().someMethod)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;/usr/lib/python2.2/repr.py&quot;, line 15, in repr
    return self.repr1(x, self.maxlevel)
  File &quot;/usr/lib/python2.2/repr.py&quot;, line 24, in repr1
    s = `x`
  File &quot;&lt;stdin&gt;&quot;, line

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-26 21:50

Message:
Logged In: YES 
user_id=80475

That previous comment should have started with:

The behavior of repr.repr(A().someMethod) is the same as
__builtin__.repr(A().someMethod)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-26 19:01

Message:
Logged In: YES 
user_id=80475

The behavior of repr.repr(A().someMethod) is the same as `repr
(A().someMethod)`.

Also, in list example provided, a debugger takes you right to the 
heart of the OP's issue (resolving a faulty user implementation of 
__repr__).

I believe the current behavior both useful and correct.  The 
offered use case is somewhat rare and better solved with pdb. 
Changing the current behavior would likely impact someone's 
existing code (doctests for example).  Recommend closing this 
bug.



----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-15 19:10

Message:
Logged In: YES 
user_id=752496

What seems like a bug to me is that "repr.repr(A())" and
"repr.repr(A().someMethod)" doesn't have the same behaviour.

As this still happens in Py2.3.3, I updated the bug metadata.

.    Facundo

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-06 20:33

Message:
Logged In: YES 
user_id=33168

Bob, I'm not sure I understand what you want (ie, what
behaviour you desire).  If you could provide a patch to the
repr module, that could help me.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-02-03 15:27

Message:
Logged In: YES 
user_id=139309

Yes, of course repr.repr is for debugging use.. and it
*really* sucks if your debugger crashes!  I'm sure that's
why it's inconsistent with __builtins__.repr, the bug I'm
reporting is that it's inconsistent with itself.

Going back to the example of a list again.  If you're
debugging a list that has one or two items that raise an
exception, it's infinitely more useful to know *which* items
have a broken __repr__ (along with the context of the valid
objects), rather than knowing *one or more* items in the
list has a broken __repr__.  repr.repr is often called
recursively; if something bad happens far down in the call
stack it can really be a pain to track down where it
happened (all tracebacks to repr are going to look mostly
the same) unless repr.repr is fixed to handle this situation.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-01-21 15:58

Message:
Logged In: YES 
user_id=539787

Sorry, incomplete last post, I clicked in the wrong place (ie 
SUBMIT) to come back to IE.

The case is that repr.py is documented as for debugging 
use... you suggest that all exceptions are caught, but that 
would not be consistent with __builtins__.repr .

If the module was intended for generic use, I would suggest 
the opposite; no exceptions should be caught (for 
consistency).

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-01-21 15:47

Message:
Logged In: YES 
user_id=539787

Do you suggest to remove the exception catching in 
Repr.repr_instance or adding a try clause in the s = `x` line of 
Repr.repr1 ?

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-01-20 09:11

Message:
Logged In: YES 
user_id=139309

It's not my module, it comes with Python (at least in my 2.2, and 2.3 CVS HEAD).  Look for yourself!

The issue has nothing to do with the fact that it has the same name as the builtin.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-01-20 00:28

Message:
Logged In: YES 
user_id=539787

Did you try to change the module name to, say, repr2 and 
then run it again?  Any specific reason you named the 
module as an internal function?
BTW, what is repr.repr supposed to do?  Please supply the 
repr.py script, along with the full traceback.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-01-13 09:54

Message:
Logged In: YES 
user_id=139309

I say it's a bug because it's inconsistent behavior.  You
can repr the class instance that throws during a __repr__
just fine ('&lt;A instance at 237360&gt;' ), but you can't
__repr__ a bound method of the class instance without
throwing an exception.  In fact, if the __repr__ of the
class instance returns anything but a string, say it returns
None for example, then the exception will bubble all the way
up and you get no useful output from repr.repr.

It's very annoying if you're doing something equivalent to,
but more useful than:
repr.repr([1, 2, 3, 4, A().someMethod, 6, 7, 8, A()])

Note that repr.repr([1, 2, 3, 4, A(), 6, 7, 8]) does not
throw any exceptions.

There should be some sort of graceful way to do it, no?  I
think it ought to handle the bound method broken instance
case just like it handles the broken instance case directly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-12 23:34

Message:
Logged In: YES 
user_id=31435

Why do say this is a bug?  If you raise an exception, yes, 
you get an exception.  Most __repr__ *implementations* 
try hard not to raise any exceptions, but it's never 
guaranteed that they won't.  For example, just about any 
__repr__ implementation may run out of memory while 
trying to build its result string, so MemoryError is almost 
always a possible exception.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 13:17:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 13:17:05 2005
Subject: [ python-Bugs-1170766 ] weakref.proxy incorrect behaviour
Message-ID: <E1DFVlO-0006KL-9B@sc8-sf-web2.sourceforge.net>

Bugs item #1170766, was opened at 2005-03-25 16:54
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-27 06:17

Message:
Logged In: YES 
user_id=80475

Fixed the __nonzero__ problem for Py2.5 and will backport to
Py2.4.  See Objects/weakrefobject.c 1.21.

Leaviing this report open until the rest of the module can
be checked and fixed.



----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-26 09:50

Message:
Logged In: YES 
user_id=4771

The bug is in weakrefobject:proxy_nonzero(), which calls the underlying object's nb_nonzero slot instead of going through the general PyObject_IsTrue() mecanism.  Built-in types like list and dict don't have a nb_nonzero slot.

As a related bug, (Callable)ProxyType should implement tp_richcompare in addition to tp_compare.  In fact, we should review the code to check if ProxyType knows about the most recent type slots...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 20:49:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 20:49:05 2005
Subject: [ python-Bugs-210834 ] urlparse and HTTP parameters (PR#205)
Message-ID: <E1DFcoo-0001fp-4s@sc8-sf-web4.sourceforge.net>

Bugs item #210834, was opened at 2000-08-01 14:13
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=210834&group_id=5470

Category: Python Library
Group: Feature Request
Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: urlparse and HTTP parameters (PR#205)

Initial Comment:
Jitterbug-Id: 205
Submitted-By: mnot@akamai.com
Date: Tue, 15 Feb 2000 17:09:44 -0500 (EST)
Version: 1.5.2
OS: All


Python parses urls into the following data structure:
  (scheme, netloc, path, params, query, fragment)
and references RFC1808. 1808 has been updated by RFC2396, which allows
on each path segment, not just the last. This would imply a data structure
either like this:
  (scheme, netloc, path, query, fragment)
or this:
  (scheme, netloc, [(segment, parameters)...], query, fragment)

Rather than updating urlparse.py (and introducing incompatibility), it may be
nice to introduce a new class (say, uriparse.py) that implements 2396. If
there's enough interest, I may give it a go...


====================================================================
Audit trail:
Wed Feb 23 21:39:30 2000	guido	sent reply 1
Wed Feb 23 21:39:42 2000	guido	changed notes
Wed Feb 23 21:39:42 2000	guido	moved from incoming to request

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-04-18 23:28

Message:
Logged In: YES 
user_id=357491

is urlparse still not compatible?  The regression tests test against RFC 
2396 examples now.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-10-03 07:14

Message:
added to pep 42


----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2000-09-16 15:07

Message:
Jeremy seems like the best person to decide about this.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:03

Message:
Please do triage on this bug.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-08-16 19:02

Message:
An excellent idea; it can be incorporated in the existing urlparse module using new names.  This won't be done for Python 2.0 at any rate, however.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:13

Message:
Go for it!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:13

Message:
From: Guido van Rossum &lt;bugs-py@python.org&gt;
Subject: Re: urlparse and HTTP parameters (PR#205)
Date: Wed Feb 23 21:39:30 2000

Go for it!

--Guido van Rossum


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=210834&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 21:02:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 21:02:07 2005
Subject: [ python-Bugs-1171023 ] Thread.join() fails to release Lock on
	KeyboardInterrupt
Message-ID: <E1DFd1P-00027o-35@sc8-sf-web4.sourceforge.net>

Bugs item #1171023, was opened at 2005-03-26 06:40
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470

Category: Threads
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread.join() fails to release Lock on KeyboardInterrupt

Initial Comment:
In threading.Thread.join(), the Condition/Lock object
called self.__block is acquired upon entry, and
released on exit without an enclosing try/finally to
ensure that the release really occurs.

If the join() call has no timeout, the wait() call that
occurs inside can never be interrupted so there is no
problem.

If the join() call has a timeout, however, the wait()
occurs in a loop which can be interrupted by a Ctrl-C,
raising a KeyboardInterrupt which skips the
self.__block.release() call and leaves the Lock acquired.

This is a problem if the main thread (which is the only
one that will see a KeyboardInterrupt) is the one
calling join() and only if the other thread on which
the join() is being called is a non-daemon thread or,
in the case of a daemon thread, if the main thread
subsequently attempts to wait for the other thread to
terminate (for example, by monitoring isAlive() on the
other thread).

In any event, the lack of a try/finally means the
joined thread will never really finish because any
attempt by it to call its __stop() method will block
forever.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 11:02

Message:
Logged In: YES 
user_id=357491

Duplicate of bug #1171023.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 07:19

Message:
Logged In: YES 
user_id=567267

A workaround (tested) is to subclass Thread and ensure that
the lock is released.  I'm not certain this is completely
safe as written, but I'm assuming that you can safely
attempt to release a lock that you don't own and the worst
that can happen is you'll get an exception (which the
workaround code catches and ignores).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 21:02:10 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 21:02:13 2005
Subject: [ python-Bugs-1167930 ] threading.Thread.join() cannot be
	interrupted by a Ctrl-C
Message-ID: <E1DFd1W-00027w-Gh@sc8-sf-web4.sourceforge.net>

Bugs item #1167930, was opened at 2005-03-21 14:19
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167930&group_id=5470

Category: Threads
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicholas Veeser (nveeser)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread.join() cannot be interrupted by a Ctrl-C

Initial Comment:
I write a python program that that starts several
threads and then waits on them all.  If I use join() to
wait on the threads, there is no way to Stop the
process with Ctrl-C.  

Threading.Thread.join() uses a lock
(thread.allocate_lock())  to put itself on the
"wait_queue".    It then calls thread.Lock.acquire(),
which blocks indefinitely.  Lock.acquire() (at least in
POSIX) seems to work in such a way as to ignore any
signals.  (both semaphore and condition variable type).
    

PyThread_acquire_lock() will not return until the lock
is acquired, even if a signal is sent.   Effectively,
Ctrl-C is "masked" until the lock is released, (the
joined thread is done), and the main thread comes back
to the interpreter and handles the signal, producing a
KeyboardInterrupt Exception.  But not before the lock
is released, which is once the thread is finished,
which is too late if you want to kill the main thread
and have it gracefully stop its child threads.

So the "main" thread has no way to call, join() and
still respond to Ctrl-C in some way.

One solution could be to change threading.Thread.join()
to use other methods of synchronization which respond
to Ctrl-C more effectively.

Another solution would be to have Lock.acquire() throw
a KeyboardInterruped exception like other system calls.
 This IHMO would make the python objects behave more
like Java, which requires catching the
InterruptedException, giving the developer more control
over how to handle this case.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 11:02

Message:
Logged In: YES 
user_id=357491

The other bug report phansen is talking about is bug #1171023 (http://
www.python.org/sf/1171023).  Closed as a duplicate but it can still be used 
for file uploads by phansen.

Also worth reading for its explanation.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 07:22

Message:
Logged In: YES 
user_id=567267

It appears only the original submitter (and admins?) can
attach files, so I've attached the example workaround in the
other bug report that I submitted.  It makes more sense in
that one anyway.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 06:59

Message:
Logged In: YES 
user_id=567267

Coincidentally this issue came up in a thread in
comp.lang.python just now.  See tim one's reply at
http://groups.google.ca/groups?selm=mailman.884.1111815188.1799.python-list%40python.org
which indicates that "it's simply not possible for Ctrl+C to
interrupt a mutex acquire".

A workaround is to be sure to call join() with a timeout
value, inside a loop if you absolutely need an indefinite
timeout, but that won't necessarily work because of a
different problem which I just reported as bug 1171023. 
There's a workaround for that problem too though, provided
you can subclass threading.Thread: provide your own join()
which wraps the builtin one and which attempts to release
the lock safely.  I'll attach an example if I can figure out
how... there's no option to do so on this particular page in
Sourceforge. :-(

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167930&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 21:48:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 21:48:29 2005
Subject: [ python-Bugs-1170331 ] Error in base64.b32decode
Message-ID: <E1DFdkI-0002pu-1z@sc8-sf-web2.sourceforge.net>

Bugs item #1170331, was opened at 2005-03-24 22:05
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: toidinamai (toidinamai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in base64.b32decode

Initial Comment:
Hi,                                                   
                                                      
                                                         
                                                      
                                                      
                                                         
I believe there is an error in base64.b32decode because
it doesn't seem to                                    
                                                          
allow to decode arbitrary binary data:                
                                                      
                                                         

<code>                                                
                                                      
                                                         
#!/usr/bin/env python2.4                              
                                                      
                                                         
                                                      
                                                      
                                                         
import base64                                         
                                                      
                                                         
                                                      
                                                      
                                                         
b64d = base64.b64decode                               
                                                      
                                                         
b64e = base64.b64encode                               
                                                      
                                                         
                                                      
                                                      
                                                         
print "base64: ", repr(b64d(b64e('\x00')))            
                                                      
                                                         
                                                      
                                                      
                                                         
b16d = base64.b16decode                               
                                                      
                                                         
b16e = base64.b16encode                               
                                                      
                                                         
                                                      
                                                      
                                                         
print "base16: ", repr(b16d(b16e('\x00')))            
                                                      
                                                         
                                                      
                                                      
                                                         
b32d = base64.b32decode                               
                                                      
                                                         
b32e = base64.b32encode                               
                                                      
                                                         
                                                      
                                                      
                                                         
print "base32: ", repr(b32d(b32e('\x00')))            
                                                      
                                                         
</code>                                               
                                                      
                                                         
                                                      
                                                      
                                                         
This raises a very strange exception:                 
                                                      
                                                         
                                                      
                                                      
                                                         
Traceback (most recent call last):                    
                                                      
                                                         
  File "test.py", line 18, in ?                       
                                                      
                                                         
    print "base32: ", repr(b32d(b32e('\x00')))        
                                                      
                                                         
  File "/usr/lib/python2.4/base64.py", line 228, in
b32decode                                             
                                                      
     
    last = binascii.unhexlify(hex(acc)[2:-1])         
                                                      
                                                         
TypeError: Odd-length string                          
                                                      
                                                         
                                                      
                                                      
                                                         
b32 should work just like b64 and b16.                
                                                      
                                                      
                                                      
                                                      
                                            

Best regards
Frank Bensktein.


----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2005-03-27 13:48

Message:
Logged In: YES 
user_id=699438

patch 1171487 posted.  It is pure python so you should be
able to incorporate into your existing codebase relatively
easily.  You won't need to rebuild the python executable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 22:42:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 22:42:13 2005
Subject: [ python-Bugs-1162677 ] Unable to Install Python 2.4.1rc1 on
	windows XP SP2
Message-ID: <E1DFeaJ-0005Ge-08@sc8-sf-web4.sourceforge.net>

Bugs item #1162677, was opened at 2005-03-14 01:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470

Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Sergio Correia (sergiocorreia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to Install  Python 2.4.1rc1 on windows XP SP2

Initial Comment:
First of all, YES i had everything i needed to install,
and yes i read the info on the site.

When i tried to install python-2.4.1c1.msi (or even
ActivePython-2.4.0-244-win32-ix86.msi), install "ended
prematurely because of an error".

I tried everything but, after a while i found a way to
avoid the bug.

I was installing from "F:\Docs\Varios\Sandbox".. i
moved the msi file to C:\ and then the install (both,
python and activepython) worked out perfectly.

Folders were not shared, restricted, compressed or on a
network (it was a normal local hard disk).

Any ideas on why that happened?

Thanks


PS: Sorry about the sp. mistakes. I am not very fluent
on technical english.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-27 22:42

Message:
Logged In: YES 
user_id=21627

Unfortunately, I have still no clue what could be causing
this problem. Message 1708 means "Installation operation
failed.", message 2262 is "Stream does not exist: [2].
System error: [3]." Here, 2: is meant to be the stream name
- but Installer does not try to use any stream name.

I'm also confused that you say you are running from
f:\Docs\Varios\Sandbox, yet the log file says that the
package being installed is "C:\python-2.4.1c1.msi" (see the
first lines of the log file); the value of OriginalDatabase
is supposed to point to the file you have msiexec'ed.

Since you have a work-around, I'll be closing this as "won't
fix".

----------------------------------------------------------------------

Comment By: Sergio Correia (sergiocorreia)
Date: 2005-03-22 01:27

Message:
Logged In: YES 
user_id=1238520

I uploaded the file again, downloaded it and it worked. ^_^

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-22 01:15

Message:
Logged In: YES 
user_id=21627

Can you please check that the file downloads correctly? I get a zipfile, but 
that only contains a garbage python.log (i.e. no text file). Perhaps you can 
try to attach it uncompressed?

----------------------------------------------------------------------

Comment By: Sergio Correia (sergiocorreia)
Date: 2005-03-15 07:00

Message:
Logged In: YES 
user_id=1238520

Thanks for the reply.

So i uninstalled it, tried again from 
the "F:\Docs\Varios\Sandbox" folder, got the same error, and 
attached the log.

Btw,  F: is a physical drive, and its not SUBSTed.

=)

Oh, the last lines of the log were:
=== Logging stopped: 15/03/2005  00:54:23 ===
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 1708 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Product: Python 2.4.1c1 -- 
Installation failed.

MSI (c) (24:A0) [00:54:23:163]: Grabbed execution mutex.
MSI (c) (24:A0) [00:54:23:163]: Cleaning up uninstalled install 
packages, if any exist
MSI (c) (24:A0) [00:54:23:173]: MainEngineThread is 
returning 1603
=== Verbose logging stopped: 15/03/2005  00:54:23 ===


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-14 22:36

Message:
Logged In: YES 
user_id=21627

No, but I know how to find out. Please run, in a cmd.exe window,

msiexec /i python-2.4.1c1.msi /l*v python.log

Compress python.log with Winzip, and attach the resulting
file to this report.

As a wild guess: could it be that F: is SUBSTed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 22:43:25 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 22:43:28 2005
Subject: [ python-Bugs-1166660 ] The readline module can cause python to
	segfault
Message-ID: <E1DFebV-0005KI-Hv@sc8-sf-web4.sourceforge.net>

Bugs item #1166660, was opened at 2005-03-19 21:48
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
>Assigned to: Michael Hudson (mwh)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
<http://www.scipy.net/roundup/ipython/issue30>.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:43

Message:
Logged In: YES 
user_id=6656

I'll take a look at this.

Did you submit a bug on the set_startup_hook problem mentioned in the 
ipython tracker?

----------------------------------------------------------------------

Comment By: Yariv Ido (dcoder)
Date: 2005-03-19 23:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 22:56:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 22:56:08 2005
Subject: [ python-Bugs-1169212 ] small change in ossaudiodev module doc.
Message-ID: <E1DFenl-0005hu-D9@sc8-sf-web4.sourceforge.net>

Bugs item #1169212, was opened at 2005-03-23 16:10
Message generated for change (Settings changed) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169212&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: hiower (hiower)
>Assigned to: Greg Ward (gward)
Summary: small change in ossaudiodev module doc.

Initial Comment:
from
http://docs.python.org/lib/ossaudio-device-objects.html:

AFMT_U8  	Unsigned, 8-bit audio
AFMT_S16_LE 	Unsigned, 16-bit audio, little-endian byte
order
		(as used by Intel processors)
AFMT_S16_BE 	Unsigned, 16-bit audio, big-endian byte order
		(as used by 68k, PowerPC, Sparc)
AFMT_S8 	Signed, 8 bit audio
AFMT_U16_LE 	Signed, 16-bit little-endian audio
AFMT_U16_BE 	Signed, 16-bit big-endian audio

Note how the U:s and S:s are switched compared to
signed and unsigned, this should surely not be like this? 

Perhaps AFMT_AC3 and AFMT_S16_NE should be included as
well? (if anyone uses it?)


also, maybe this line:

write(  data)
    Write the Python string data to the audio device
and return the number of bytes written.

could be subtituted with something like this:

write(  data)
    Write the Python data to the audio device and
return the number of bytes written. The data should be
a string or a list (of amplitude values...something)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169212&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 22:59:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 22:59:25 2005
Subject: [ python-Bugs-1167262 ] Fails assertion in winsig.c under VC 8.0
Message-ID: <E1DFeqx-00059h-Dn@sc8-sf-web2.sourceforge.net>

Bugs item #1167262, was opened at 2005-03-21 03:25
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470

Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Timothy Fitz (timothyfitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails assertion in winsig.c under VC 8.0

Initial Comment:
In 2.4 and current cvs initsignal in signalmodule.c calls 
PyOS_getsig which calls signal with an invalid signal 
number. Under VC 7.1 (and 7.0, and probably before) 
this would return SIG_ERR however under VC 8.0 (beta) 
this causes an assertion failure. 


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:59

Message:
Logged In: YES 
user_id=6656

Ew.  My first thought is, is that allowed by ANSI C?  I'd guess it's 
undefined behaviour.  It still seems excessively unfriendly -- have you 
reported this to MS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 23:16:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 23:16:57 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DFf7u-0005fx-U1@sc8-sf-web2.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 14:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Remy Blank (remyblank)
Assigned to: Michael Hudson (mwh)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-27 22:16

Message:
Logged In: YES 
user_id=6656

> > remyblank: let me guess your code wasn't doing what
> > you thought it did? :)
> 
> Err... Not sure what you mean... What would be the correct
> way to do what I thought it did?

Well, I don't know, but what it was doing was trying to create a method 
bound to None...

I'll check this in soon.

----------------------------------------------------------------------

Comment By: Remy Blank (remyblank)
Date: 2005-03-17 20:13

Message:
Logged In: YES 
user_id=568100

> remyblank: let me guess your code wasn't doing what you
thought it did? :)

Err... Not sure what you mean... What would be the correct
way to do what I thought it did?

The code was largely inspired by a Cookbook entry. These are
still my first steps with decorators, and I have to admit I
don't yet fully understand why I have to create a MethodType
manually.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 18:43

Message:
Logged In: YES 
user_id=6380

Looks OK on cursory inspection.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:28

Message:
Logged In: YES 
user_id=6656

Let's attach a test case too.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:15

Message:
Logged In: YES 
user_id=6656

Well, it's a bit more subtle than I thought:

>>> def f(): pass
... 
>>> print f.__get__(1).im_class
None

The problem occurs when *both* im_self and im_class are None; and I'm 
now reasonably convinced that calling the type object is the only way this 
can be acheived.  So a simple check along these lines in 
instancemethod_new would suffice (patch attached), and seems less likely 
to break code.

I suspect this has missed 2.4.1.

remyblank: let me guess your code wasn't doing what you thought it did? :)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 17:03

Message:
Logged In: YES 
user_id=6380

Looks like I wasn't finished with the thought when I checked
it in. I think I was trying to make instancemethod generally
useful as a currying primitive. That should probably be
considered more careful; please roll it back.

(I think it may have been part of the aborted experiment to
get rid of bound methods.)

Is there time to backport this to 2.4.1?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 16:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test <poke> (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 15:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Sun Mar 27 23:21:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 27 23:21:48 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DFfCb-0005pE-72@sc8-sf-web2.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
>Assigned to: Tim Peters (tim_one)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-27 22:21

Message:
Logged In: YES 
user_id=6656

Tim, I'd like to check this in.  You get a few days to object :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 10:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

	/* Now we decref the exception classes.  After this point nothing
	   can raise an exception.  That's okay, because each Fini() method
	   below has been checked to make sure no exceptions are ever
	   raised.
	*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-18 21:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 14:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 02:43:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 02:43:11 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DFiLU-0004US-DE@sc8-sf-web4.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 00:18
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
>Assigned to: Michael Hudson (mwh)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-27 19:43

Message:
Logged In: YES 
user_id=31435

Yup, I agree it's an improvement.  Sorry I didn't have time to 
look at it last week (was at PyCon all day 7 days straight).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 16:21

Message:
Logged In: YES 
user_id=6656

Tim, I'd like to check this in.  You get a few days to object :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 05:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

	/* Now we decref the exception classes.  After this point nothing
	   can raise an exception.  That's okay, because each Fini() method
	   below has been checked to make sure no exceptions are ever
	   raised.
	*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-18 16:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 10:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 10:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 09:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 04:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 04:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 04:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 01:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 02:46:35 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 02:46:38 2005
Subject: [ python-Bugs-1171023 ] Thread.join() fails to release Lock on
	KeyboardInterrupt
Message-ID: <E1DFiOp-0004Xt-2r@sc8-sf-web4.sourceforge.net>

Bugs item #1171023, was opened at 2005-03-26 06:40
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470

Category: Threads
Group: Python 2.4
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread.join() fails to release Lock on KeyboardInterrupt

Initial Comment:
In threading.Thread.join(), the Condition/Lock object
called self.__block is acquired upon entry, and
released on exit without an enclosing try/finally to
ensure that the release really occurs.

If the join() call has no timeout, the wait() call that
occurs inside can never be interrupted so there is no
problem.

If the join() call has a timeout, however, the wait()
occurs in a loop which can be interrupted by a Ctrl-C,
raising a KeyboardInterrupt which skips the
self.__block.release() call and leaves the Lock acquired.

This is a problem if the main thread (which is the only
one that will see a KeyboardInterrupt) is the one
calling join() and only if the other thread on which
the join() is being called is a non-daemon thread or,
in the case of a daemon thread, if the main thread
subsequently attempts to wait for the other thread to
terminate (for example, by monitoring isAlive() on the
other thread).

In any event, the lack of a try/finally means the
joined thread will never really finish because any
attempt by it to call its __stop() method will block
forever.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 16:46

Message:
Logged In: YES 
user_id=357491

That was supposed to be bug #1167930, not this bug itself.  =)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 11:02

Message:
Logged In: YES 
user_id=357491

Duplicate of bug #1171023.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 07:19

Message:
Logged In: YES 
user_id=567267

A workaround (tested) is to subclass Thread and ensure that
the lock is released.  I'm not certain this is completely
safe as written, but I'm assuming that you can safely
attempt to release a lock that you don't own and the worst
that can happen is you'll get an exception (which the
workaround code catches and ignores).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 04:41:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 04:41:55 2005
Subject: [ python-Bugs-1169212 ] small change in ossaudiodev module doc.
Message-ID: <E1DFkCO-0007PN-L3@sc8-sf-web4.sourceforge.net>

Bugs item #1169212, was opened at 2005-03-23 11:10
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169212&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: hiower (hiower)
Assigned to: Greg Ward (gward)
Summary: small change in ossaudiodev module doc.

Initial Comment:
from
http://docs.python.org/lib/ossaudio-device-objects.html:

AFMT_U8  	Unsigned, 8-bit audio
AFMT_S16_LE 	Unsigned, 16-bit audio, little-endian byte
order
		(as used by Intel processors)
AFMT_S16_BE 	Unsigned, 16-bit audio, big-endian byte order
		(as used by 68k, PowerPC, Sparc)
AFMT_S8 	Signed, 8 bit audio
AFMT_U16_LE 	Signed, 16-bit little-endian audio
AFMT_U16_BE 	Signed, 16-bit big-endian audio

Note how the U:s and S:s are switched compared to
signed and unsigned, this should surely not be like this? 

Perhaps AFMT_AC3 and AFMT_S16_NE should be included as
well? (if anyone uses it?)


also, maybe this line:

write(  data)
    Write the Python string data to the audio device
and return the number of bytes written.

could be subtituted with something like this:

write(  data)
    Write the Python data to the audio device and
return the number of bytes written. The data should be
a string or a list (of amplitude values...something)


----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2005-03-27 21:41

Message:
Logged In: YES 
user_id=14422

Oops, good catch on the signed/unsigned thing.  Thanks!

Fixed on release24-maint branch: Doc/lib/libossaudiodev.tex
rev 1.12.4.4.
Merged to trunk: Doc/lib/libossaudiodev.tex rev 1.15.

As for explaining the write() method: the ossaudiodev docs
are no place for a tutorial on audio encoding formats.  If
it's not immediately obvious what the string passed to
write() should be, the reader should consult OSS docs.

Hmmm... since AFMT_S16_NE may be defined by ossaudiodev, but
AFMT_U16_NE is not, I'll just leave the missing AFMT_*'s out
of the 2.4 docs and straighten things out on the trunk (for
2.5).  Specifically, I'll make ossaudiodev conditionally
define all AFMT_* macros currently documented by OSS.  Won't
bother adding everything to the docs, since the OSS ref
should be definitive.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169212&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 04:43:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 04:43:09 2005
Subject: [ python-Bugs-467924 ] Improve the ZipFile Interface
Message-ID: <E1DFkDZ-0007RQ-GB@sc8-sf-web4.sourceforge.net>

Bugs item #467924, was opened at 2001-10-04 11:54
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467924&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Improve the ZipFile Interface

Initial Comment:
There exist two methods to write to a ZipFile

     write(self, filename, arcname=None, compress_type=None)  
     writestr(self, zinfo, bytes)

but only one to read from it

     read(self, name)

Additionally, the two 'write's behave differently with respect to compression.

---
(a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, 
     but 'read' is not the reverse operation. 'read' should be called 'readstr' since it 
     much better matches to 'writestr'.

(b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, 
     or into the ZipFile? It would be more obvious if ZipFile has 4 methods which 
     pair-wise fit together:

     writestr (self, zinfo, bytes)
          # same as now
     readstr (self, name)
          # returns bytes (as string), currently called 'read'
          # 'read' could still live but should be deprecated
     add (self, filename, arcname=None, compress_type=None)
          # currently 'write'
          # 'write' could still live but should be deprecated
     extract (self, name, filename, arcname=None)
          # new, desired functionality

(c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was 
     passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via 
     zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( 
     It should not do that! It rather should:
     - allow more parameters in the signature of the constructor
        to also pass the compression type (and some other attributes, too)
     - default to 'None', so that 'writestr' can see this, and then take 
        the default from the 'ZipFile' instance.





----------------------------------------------------------------------

Comment By: Myers Carpenter (myers_carpenter)
Date: 2004-05-09 14:23

Message:
Logged In: YES 
user_id=335935

The zipfile interface should match the tarfile interface. 
At the mininum is should work for this example:

import zipfile
zip = zipfile.open("sample.zip", "r")
for zipinfo in zip:
    print tarinfo.name, "is", tarinfo.size, "bytes in size
and is",
    zip.extract(zipinfo)
zip.close()

This closely matchs the 'tarfile' module.


----------------------------------------------------------------------

Comment By: Matt Zimmerman (mzimmerman)
Date: 2003-07-31 10:22

Message:
Logged In: YES 
user_id=196786

It would also be very useful to be able to have ZipFile
read/write the uncompressed file data from/to a file-like
object, instead of just strings and files (respectively).

I would like to use this module to work with zip files
containing large files, but this is unworkable because the
current implementation would use excessive amounts of memory.

Currently, read() reads all of the compressed data into
memory, then uncompresses it into memory.  For files which
may be hundreds of megabytes compressed, this is undesirable.

Likewise for write(), I would like to be able to stream data
into a zip file, passing in a ZipInfo to specify the
metadata as is done with writestr().

The implementation of this functionality is quite
straightforward, but I am not sure whether (or how) the
interface should change.  Some other parts of the library
allow for a file object to be passed to the same interface
which accepts a filename.  The object is examined to see if
it has the necessary read/write methods and if not, it is
assumed to be a filename.  Would this be the correct way to
do it?

I, too, am a bit irked by the lack of symmetry exhibited by
read vs. write/writestr, and think that the interface
suggested above would be a significant improvement.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-01-05 15:54

Message:
Logged In: YES 
user_id=92689

In Python 2.3, writestr() has an enhanced signature: the
first arg may now also be an archive name, in which case the
correct default settings are used (ie. the compression value
is taken from the file). See patch #651621.

extract() could be moderately useful (although I don't
understand the 'arcname' arg, how's that different from
'name'?) but would have to deal with file modes (bin/text).
The file mode isn't in the archive so would have to
(optionally) be supplied by the caller.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467924&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 08:00:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 08:00:52 2005
Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super
Message-ID: <E1DFnIw-0004sl-8k@sc8-sf-web2.sourceforge.net>

Bugs item #1163367, was opened at 2005-03-14 16:39
Message generated for change (Settings changed) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Category: Documentation
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
    def meth(self, arg):
        super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 10:39:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 10:39:22 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DFpmH-0008MA-Ia@sc8-sf-web1.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 16:18
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Michael Hudson (mwh)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-28 18:39

Message:
Logged In: YES 
user_id=29957

This patch won't compile for me on the 2.4 branch or the
trunk - there's no PyExceptionClass_Check defined that I can
find in the codebase, nor can I find anything that looks
like this anywhere. 


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-28 10:43

Message:
Logged In: YES 
user_id=31435

Yup, I agree it's an improvement.  Sorry I didn't have time to 
look at it last week (was at PyCon all day 7 days straight).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-28 07:21

Message:
Logged In: YES 
user_id=6656

Tim, I'd like to check this in.  You get a few days to object :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 21:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

	/* Now we decref the exception classes.  After this point nothing
	   can raise an exception.  That's okay, because each Fini() method
	   below has been checked to make sure no exceptions are ever
	   raised.
	*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-19 08:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 02:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 02:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 01:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 01:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-19 01:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 20:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 20:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 20:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 17:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 13:53:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 13:53:20 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DFso1-00085U-9N@sc8-sf-web4.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Michael Hudson (mwh)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-28 12:53

Message:
Logged In: YES 
user_id=6656

Oh, pig.  Here's the patch with the irrelevant stuff from my new-style 
exceptions work chopped out (I should check that in soon, too I guess).

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-28 09:39

Message:
Logged In: YES 
user_id=29957

This patch won't compile for me on the 2.4 branch or the
trunk - there's no PyExceptionClass_Check defined that I can
find in the codebase, nor can I find anything that looks
like this anywhere. 


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-28 01:43

Message:
Logged In: YES 
user_id=31435

Yup, I agree it's an improvement.  Sorry I didn't have time to 
look at it last week (was at PyCon all day 7 days straight).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 22:21

Message:
Logged In: YES 
user_id=6656

Tim, I'd like to check this in.  You get a few days to object :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 10:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

	/* Now we decref the exception classes.  After this point nothing
	   can raise an exception.  That's okay, because each Fini() method
	   below has been checked to make sure no exceptions are ever
	   raised.
	*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-18 21:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 14:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 14:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 06:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 14:40:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 14:40:51 2005
Subject: [ python-Bugs-1171023 ] Thread.join() fails to release Lock on
	KeyboardInterrupt
Message-ID: <E1DFtY0-0001qm-43@sc8-sf-web2.sourceforge.net>

Bugs item #1171023, was opened at 2005-03-26 09:40
Message generated for change (Comment added) made by phansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470

Category: Threads
Group: Python 2.4
>Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread.join() fails to release Lock on KeyboardInterrupt

Initial Comment:
In threading.Thread.join(), the Condition/Lock object
called self.__block is acquired upon entry, and
released on exit without an enclosing try/finally to
ensure that the release really occurs.

If the join() call has no timeout, the wait() call that
occurs inside can never be interrupted so there is no
problem.

If the join() call has a timeout, however, the wait()
occurs in a loop which can be interrupted by a Ctrl-C,
raising a KeyboardInterrupt which skips the
self.__block.release() call and leaves the Lock acquired.

This is a problem if the main thread (which is the only
one that will see a KeyboardInterrupt) is the one
calling join() and only if the other thread on which
the join() is being called is a non-daemon thread or,
in the case of a daemon thread, if the main thread
subsequently attempts to wait for the other thread to
terminate (for example, by monitoring isAlive() on the
other thread).

In any event, the lack of a try/finally means the
joined thread will never really finish because any
attempt by it to call its __stop() method will block
forever.

----------------------------------------------------------------------

>Comment By: Peter Hansen (phansen)
Date: 2005-03-28 07:40

Message:
Logged In: YES 
user_id=567267

I confirmed with Brett offline that this bug is indeed
distinct from #1167930 and should be reopened.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 19:46

Message:
Logged In: YES 
user_id=357491

That was supposed to be bug #1167930, not this bug itself.  =)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 14:02

Message:
Logged In: YES 
user_id=357491

Duplicate of bug #1171023.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 10:19

Message:
Logged In: YES 
user_id=567267

A workaround (tested) is to subclass Thread and ensure that
the lock is released.  I'm not certain this is completely
safe as written, but I'm assuming that you can safely
attempt to release a lock that you don't own and the worst
that can happen is you'll get an exception (which the
workaround code catches and ignores).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 15:05:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 15:05:53 2005
Subject: [ python-Bugs-1171819 ] Error in code example in main tutorial,
	section 9.3.4
Message-ID: <E1DFtwF-0002Nq-DY@sc8-sf-web4.sourceforge.net>

Bugs item #1171819, was opened at 2005-03-28 15: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=1171819&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Niek (niekbouman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in code example in main tutorial, section 9.3.4

Initial Comment:
Tutorial version:

Online, Current
Release 2.4
30 November 2004

Bug:
In section 9.3.4 Method Objects, the second code
example reads:
=========
xf = x.f
while True:
    print xf()
=========

There should be parentheses after x.f

Suggested new version:
=========
xf = x.f()
while True:
    print xf()
=========

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171819&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 17:15:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 17:15:21 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DFvxV-0007fq-TN@sc8-sf-web3.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 16:18
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Michael Hudson (mwh)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-29 01:15

Message:
Logged In: YES 
user_id=29957

This patch applies, and seems to work. I can't see any
reasons for it to _not_ go into 2.4.1 final, unless someone
else can see a reason to avoid it, I'll check it in, in the
morning.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-28 21:53

Message:
Logged In: YES 
user_id=6656

Oh, pig.  Here's the patch with the irrelevant stuff from my new-style 
exceptions work chopped out (I should check that in soon, too I guess).

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-28 18:39

Message:
Logged In: YES 
user_id=29957

This patch won't compile for me on the 2.4 branch or the
trunk - there's no PyExceptionClass_Check defined that I can
find in the codebase, nor can I find anything that looks
like this anywhere. 


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-28 10:43

Message:
Logged In: YES 
user_id=31435

Yup, I agree it's an improvement.  Sorry I didn't have time to 
look at it last week (was at PyCon all day 7 days straight).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-28 07:21

Message:
Logged In: YES 
user_id=6656

Tim, I'd like to check this in.  You get a few days to object :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 21:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

	/* Now we decref the exception classes.  After this point nothing
	   can raise an exception.  That's okay, because each Fini() method
	   below has been checked to make sure no exceptions are ever
	   raised.
	*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-19 08:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 02:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 02:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 01:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 01:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-19 01:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 20:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 20:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 20:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 17:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 17:20:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 17:20:09 2005
Subject: [ python-Bugs-1171819 ] Error in code example in main tutorial,
	section 9.3.4
Message-ID: <E1DFw2A-0000gt-NB@sc8-sf-web2.sourceforge.net>

Bugs item #1171819, was opened at 2005-03-28 15:05
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171819&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Niek (niekbouman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in code example in main tutorial, section 9.3.4

Initial Comment:
Tutorial version:

Online, Current
Release 2.4
30 November 2004

Bug:
In section 9.3.4 Method Objects, the second code
example reads:
=========
xf = x.f
while True:
    print xf()
=========

There should be parentheses after x.f

Suggested new version:
=========
xf = x.f()
while True:
    print xf()
=========

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-28 17:20

Message:
Logged In: YES 
user_id=21627

Why do you think so? The documentation is correct as-is; the
whole point of the paragraph is that the parentheses are
omitted in the assignment to xf.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171819&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 17:30:00 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 17:30:02 2005
Subject: [ python-Bugs-1170460 ] gc module docu
Message-ID: <E1DFwBk-0000HV-I7@sc8-sf-web4.sourceforge.net>

Bugs item #1170460, was opened at 2005-03-25 12:22
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170460&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin Renold (martinxyz)
Assigned to: Nobody/Anonymous (nobody)
Summary: gc module docu

Initial Comment:
It says: "To debug a leaking program call
gc.set_debug(gc.DEBUG_LEAK)."

I added this call, found the leak, fixed it, and
watched the memory consumption - argh.

Please add a warning sentence like: "Note: this will
stop freeing the collected memory."


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2005-03-28 17:30

Message:
Logged In: YES 
user_id=21627

Thanks for the report. Fixed in libgc.tex 1.17 and 1.15.4.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170460&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 19:49:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 19:49:42 2005
Subject: [ python-Bugs-1171994 ] error in documentation for splitting empty
	string 
Message-ID: <E1DFyMu-0006mq-6z@sc8-sf-web3.sourceforge.net>

Bugs item #1171994, was opened at 2005-03-28 09:49
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=1171994&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in documentation for splitting empty string 

Initial Comment:
Below is extracted from http://www.python.org/doc/2.4/
lib/string-methods.html describing the string method 
split().

-----------------------------------------------------------------------
split([sep [,maxsplit]])

    ... Splitting an empty string with a specified separator 
returns an empty list.

    If sep is not specified or is None, a different splitting 
algorithm is applied. ... Splitting an empty string returns 
"['']".

-----------------------------------------------------------------------

The rationale for different treatment of splitting an empty 
string seems to be discussed in 811604. However the 
documentation seems to be the opposite of actual result.

>>> ''.split(',')
['']
>>> ''.split()
[]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171994&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 20:20:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 20:20:17 2005
Subject: [ python-Bugs-1172011 ] BaseCookie does not call value_decode
Message-ID: <E1DFyqV-00082N-D2@sc8-sf-web1.sourceforge.net>

Bugs item #1172011, was opened at 2005-03-28 18: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=1172011&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan Lovett (ryan)
Assigned to: Nobody/Anonymous (nobody)
Summary: BaseCookie does not call value_decode

Initial Comment:
Perhaps I'm misunderstanding its functionality, but I
believe BaseCookie should be calling value_decode
during __getitem__. I created a blowfish Cookie class
with value_encode and value_decode methods, but when I
invoke __getitem__, for example mycookie['mykey'], the
cookie only returns encoded values.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172011&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 20:48:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 20:48:32 2005
Subject: [ python-Bugs-1171819 ] Error in code example in main tutorial,
	section 9.3.4
Message-ID: <E1DFzHp-00019v-MG@sc8-sf-web4.sourceforge.net>

Bugs item #1171819, was opened at 2005-03-28 15:05
Message generated for change (Comment added) made by niekbouman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171819&group_id=5470

Category: Documentation
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Niek (niekbouman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in code example in main tutorial, section 9.3.4

Initial Comment:
Tutorial version:

Online, Current
Release 2.4
30 November 2004

Bug:
In section 9.3.4 Method Objects, the second code
example reads:
=========
xf = x.f
while True:
    print xf()
=========

There should be parentheses after x.f

Suggested new version:
=========
xf = x.f()
while True:
    print xf()
=========

----------------------------------------------------------------------

>Comment By: Niek (niekbouman)
Date: 2005-03-28 20:48

Message:
Logged In: YES 
user_id=1247970

Oops, how stupid of me.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-28 17:20

Message:
Logged In: YES 
user_id=21627

Why do you think so? The documentation is correct as-is; the
whole point of the paragraph is that the parentheses are
omitted in the assignment to xf.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171819&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 21:12:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 21:12:59 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DFzfV-0002Kk-3F@sc8-sf-web1.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 00:18
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-28 14:12

Message:
Logged In: YES 
user_id=31435

Note that I already marked the patch as Accepted.

Re-assigning to Anthony, since he said he'll check it in.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-28 10:15

Message:
Logged In: YES 
user_id=29957

This patch applies, and seems to work. I can't see any
reasons for it to _not_ go into 2.4.1 final, unless someone
else can see a reason to avoid it, I'll check it in, in the
morning.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-28 06:53

Message:
Logged In: YES 
user_id=6656

Oh, pig.  Here's the patch with the irrelevant stuff from my new-style 
exceptions work chopped out (I should check that in soon, too I guess).

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-28 03:39

Message:
Logged In: YES 
user_id=29957

This patch won't compile for me on the 2.4 branch or the
trunk - there's no PyExceptionClass_Check defined that I can
find in the codebase, nor can I find anything that looks
like this anywhere. 


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-27 19:43

Message:
Logged In: YES 
user_id=31435

Yup, I agree it's an improvement.  Sorry I didn't have time to 
look at it last week (was at PyCon all day 7 days straight).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 16:21

Message:
Logged In: YES 
user_id=6656

Tim, I'd like to check this in.  You get a few days to object :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 05:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

	/* Now we decref the exception classes.  After this point nothing
	   can raise an exception.  That's okay, because each Fini() method
	   below has been checked to make sure no exceptions are ever
	   raised.
	*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-18 16:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 10:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 10:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 09:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-18 09:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 04:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 04:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 04:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 01:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Mon Mar 28 21:34:19 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 28 21:34:21 2005
Subject: [ python-Bugs-1171023 ] Thread.join() fails to release Lock on
	KeyboardInterrupt
Message-ID: <E1DG00B-0003fu-Ul@sc8-sf-web3.sourceforge.net>

Bugs item #1171023, was opened at 2005-03-26 06:40
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
>Resolution: None
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread.join() fails to release Lock on KeyboardInterrupt

Initial Comment:
In threading.Thread.join(), the Condition/Lock object
called self.__block is acquired upon entry, and
released on exit without an enclosing try/finally to
ensure that the release really occurs.

If the join() call has no timeout, the wait() call that
occurs inside can never be interrupted so there is no
problem.

If the join() call has a timeout, however, the wait()
occurs in a loop which can be interrupted by a Ctrl-C,
raising a KeyboardInterrupt which skips the
self.__block.release() call and leaves the Lock acquired.

This is a problem if the main thread (which is the only
one that will see a KeyboardInterrupt) is the one
calling join() and only if the other thread on which
the join() is being called is a non-daemon thread or,
in the case of a daemon thread, if the main thread
subsequently attempts to wait for the other thread to
terminate (for example, by monitoring isAlive() on the
other thread).

In any event, the lack of a try/finally means the
joined thread will never really finish because any
attempt by it to call its __stop() method will block
forever.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-28 04:40

Message:
Logged In: YES 
user_id=567267

I confirmed with Brett offline that this bug is indeed
distinct from #1167930 and should be reopened.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 16:46

Message:
Logged In: YES 
user_id=357491

That was supposed to be bug #1167930, not this bug itself.  =)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 11:02

Message:
Logged In: YES 
user_id=357491

Duplicate of bug #1171023.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 07:19

Message:
Logged In: YES 
user_id=567267

A workaround (tested) is to subclass Thread and ensure that
the lock is released.  I'm not certain this is completely
safe as written, but I'm assuming that you can safely
attempt to release a lock that you don't own and the worst
that can happen is you'll get an exception (which the
workaround code catches and ignores).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 00:33:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 00:34:00 2005
Subject: [ python-Bugs-1166660 ] The readline module can cause python to
	segfault
Message-ID: <E1DG2ny-0005HE-UQ@sc8-sf-web2.sourceforge.net>

Bugs item #1166660, was opened at 2005-03-19 23:48
Message generated for change (Comment added) made by dcoder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Michael Hudson (mwh)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
<http://www.scipy.net/roundup/ipython/issue30>.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

----------------------------------------------------------------------

>Comment By: Yariv Ido (dcoder)
Date: 2005-03-29 00:33

Message:
Logged In: YES 
user_id=326689

I haven't (Completely forgot about it, after finding the
main one...). Should I post a seperate bug report, or will
this one do?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 22:43

Message:
Logged In: YES 
user_id=6656

I'll take a look at this.

Did you submit a bug on the set_startup_hook problem mentioned in the 
ipython tracker?

----------------------------------------------------------------------

Comment By: Yariv Ido (dcoder)
Date: 2005-03-20 01:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 00:54:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 00:54:49 2005
Subject: [ python-Bugs-672115 ] Assignment to __bases__ of direct object
	subclasses
Message-ID: <E1DG389-0004vi-5i@sc8-sf-web1.sourceforge.net>

Bugs item #672115, was opened at 2003-01-21 13:45
Message generated for change (Comment added) made by glchapman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Assignment to __bases__ of direct object subclasses

Initial Comment:
I'm not entirely sure this is a bug, but I think it is 
surprising:

Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC 
v.1200 32 bit (Intel)] on win32
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more 
information.
&gt;&gt;&gt; class A(object):
...     pass
...
&gt;&gt;&gt; class B(object):
...     pass
...
&gt;&gt;&gt; B.__bases__ = (A,)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
TypeError: __bases__ assignment: 'A' deallocator differs 
from 'object'

It seems like you should be able to change the 
__bases__ of a new-style class (implemented in 
Python) which inherits directly from object to another 
new-style class.  (Will the deallocator issue ever come 
into play if the only types involved are HEAPTYPES and 
object as the ultimate base?)


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2005-03-28 13:54

Message:
Logged In: YES 
user_id=86307

Still here -- sorry not to reply sooner.  I couldn't
actually remember what my patch was supposed to do, or more
specifically I couldn't remember what it did to check that
this sort of change in __bases__ was safe.  So, anyway, I
finally got around to looking at the patch again, and at
typeobject.c, and I can say that I'm less sure of the
subtleties involved now than I was then.  Anyway, with that
caveat, what you suggest sounds reasonable enough, though I
suppose you'd have to reinsert a dict descriptor if
__bases__ was later changed back to (object,).  (It looks
like the patch would have supported changing __bases__ back
to (object,), though perhaps it shouldn't.)

It seems to me nobody is particularly troubled by this
limitation on assignment to __bases__ (perhaps you know
differently?).  Maybe it's best just to close this as "not a
bug."


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-16 04:22

Message:
Logged In: YES 
user_id=6656

Two years on, I think about this again.  Still here? :)

The motivating thought is that:

class A(object): pass
class B(object): pass
B.__bases__ = (A,)

and 

class A(object): pass
class B(A): pass

should be equivalent.

An issue that hadn't occurred to me before is that in the first example both 
A and B have a __dict__ (and __weakref__) descriptor, and in the second 
B doesn't.  Should B's __dict__ descriptor be removed on the 
__bases__ assignment?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-02-05 05:22

Message:
Logged In: YES 
user_id=6656

Mhmm.  That looks OK to me (after realizing that solid_base
worries about __slots__).

But I don't know how one can be sure :-(

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-04 17:39

Message:
Logged In: YES 
user_id=86307

Well, I wrote a small patch which I'm attaching.  However, I 
can't say that I'm partcularly confident in it.  It works for the 
simple cases I've  been able to think of (and for 
test_descr.py), but looking at typeobject.c, I get the nagging 
feeling that a lot more tests are required to be sure it's OK.  
The problem is, I'm just not sure what they (the tests) are.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-31 09:09

Message:
Logged In: YES 
user_id=6656

Are you interested in working up a patch for this?  Hacking
this kind of stuff requires motivation I'm not sure I can
drum up in time for 2.3...

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-01-23 08:03

Message:
Logged In: YES 
user_id=86307

Sorry about the parenthetical comment; I think what I was trying 
to say is basically what you have in your last paragraph.

As for use cases, I don't have any myself (I ran into this with 
some test code for a metaclass which &quot;overrides&quot; __bases__).  
However, grepping through the standard library, I note that one 
place where assignment to __bases__ is used is in 
xmlrpclib.SlowParser.  It appears to me that if SlowParser and 
xmllib.XMLParser (neither of which has a base class) were 
converted to new-style classes, the assignment to __bases__ 
would generate this exception.  Of course, that shouldn't be too 
hard to work around if that turns out to be necessary.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-22 02:50

Message:
Logged In: YES 
user_id=6656

I agree this is a bit surprising.  When I was writing this
code I went for the conservative-as-possible approach as I
didn't want to introduce instabilities to Python.

It certainly may be that I've overdone it.  In this case I
probably have; if the tp_dealloc of the class being adjusted
is subtype_dealloc and the tp_dealloc that ultimately gets
invoked is the same we're probably OK.  But I'm not sure and
it's been a while since I thought about this.

It also happens that my motivating use-case for this isn't
troubled by this restriction.

I don't understand your last, parenthetical, comment. 
HEAPTYPES as such doesn't come into it, does it?  

You might be right that we don't need to worry about
tp_dealloc if the ultimate solid_base doesn't change and all
the tp_deallocs on the way there are subtype_dealloc...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 14:10:34 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 14:10:37 2005
Subject: [ python-Bugs-1166660 ] The readline module can cause python to
	segfault
Message-ID: <E1DGFYI-0001yL-M5@sc8-sf-web1.sourceforge.net>

Bugs item #1166660, was opened at 2005-03-19 21:48
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Michael Hudson (mwh)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
<http://www.scipy.net/roundup/ipython/issue30>.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-29 13:10

Message:
Logged In: YES 
user_id=6656

Unless there's some reason to suspect they share a common
cause (and, I don't see one) a second report is more
appropriate.

Also, if you understand what's going on, you can explain
there :)

----------------------------------------------------------------------

Comment By: Yariv Ido (dcoder)
Date: 2005-03-28 23:33

Message:
Logged In: YES 
user_id=326689

I haven't (Completely forgot about it, after finding the
main one...). Should I post a seperate bug report, or will
this one do?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:43

Message:
Logged In: YES 
user_id=6656

I'll take a look at this.

Did you submit a bug on the set_startup_hook problem mentioned in the 
ipython tracker?

----------------------------------------------------------------------

Comment By: Yariv Ido (dcoder)
Date: 2005-03-19 23:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 14:21:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 14:21:25 2005
Subject: [ python-Bugs-672115 ] Assignment to __bases__ of direct object
	subclasses
Message-ID: <E1DGFij-0003GR-NL@sc8-sf-web2.sourceforge.net>

Bugs item #672115, was opened at 2003-01-21 22:45
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Assignment to __bases__ of direct object subclasses

Initial Comment:
I'm not entirely sure this is a bug, but I think it is 
surprising:

Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC 
v.1200 32 bit (Intel)] on win32
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more 
information.
&gt;&gt;&gt; class A(object):
...     pass
...
&gt;&gt;&gt; class B(object):
...     pass
...
&gt;&gt;&gt; B.__bases__ = (A,)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
TypeError: __bases__ assignment: 'A' deallocator differs 
from 'object'

It seems like you should be able to change the 
__bases__ of a new-style class (implemented in 
Python) which inherits directly from object to another 
new-style class.  (Will the deallocator issue ever come 
into play if the only types involved are HEAPTYPES and 
object as the ultimate base?)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-29 13:21

Message:
Logged In: YES 
user_id=6656

Well, my motivation is to better understand what's going on
in typeobject.c.  There are a number of unclear sections (to
put it mildly) and undocumented assumptions and this makes
it hard to work out whether things (like this) are bugs or not.

I'm now fairly confident that the line
"compatible_for_assigment(new_base, self->tp_base)" is
asking the right question (and, thus, your patch is not
really correct, though I doubt it's actually unsafe).  The
spelling is a bit funny though.

This issue in and of itself isn't that high a priority, but
understanding (and documenting that understanding) of
typeobject.c does seem worth working on...

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2005-03-28 23:54

Message:
Logged In: YES 
user_id=86307

Still here -- sorry not to reply sooner.  I couldn't
actually remember what my patch was supposed to do, or more
specifically I couldn't remember what it did to check that
this sort of change in __bases__ was safe.  So, anyway, I
finally got around to looking at the patch again, and at
typeobject.c, and I can say that I'm less sure of the
subtleties involved now than I was then.  Anyway, with that
caveat, what you suggest sounds reasonable enough, though I
suppose you'd have to reinsert a dict descriptor if
__bases__ was later changed back to (object,).  (It looks
like the patch would have supported changing __bases__ back
to (object,), though perhaps it shouldn't.)

It seems to me nobody is particularly troubled by this
limitation on assignment to __bases__ (perhaps you know
differently?).  Maybe it's best just to close this as "not a
bug."


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-16 13:22

Message:
Logged In: YES 
user_id=6656

Two years on, I think about this again.  Still here? :)

The motivating thought is that:

class A(object): pass
class B(object): pass
B.__bases__ = (A,)

and 

class A(object): pass
class B(A): pass

should be equivalent.

An issue that hadn't occurred to me before is that in the first example both 
A and B have a __dict__ (and __weakref__) descriptor, and in the second 
B doesn't.  Should B's __dict__ descriptor be removed on the 
__bases__ assignment?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-02-05 14:22

Message:
Logged In: YES 
user_id=6656

Mhmm.  That looks OK to me (after realizing that solid_base
worries about __slots__).

But I don't know how one can be sure :-(

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 02:39

Message:
Logged In: YES 
user_id=86307

Well, I wrote a small patch which I'm attaching.  However, I 
can't say that I'm partcularly confident in it.  It works for the 
simple cases I've  been able to think of (and for 
test_descr.py), but looking at typeobject.c, I get the nagging 
feeling that a lot more tests are required to be sure it's OK.  
The problem is, I'm just not sure what they (the tests) are.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-31 18:09

Message:
Logged In: YES 
user_id=6656

Are you interested in working up a patch for this?  Hacking
this kind of stuff requires motivation I'm not sure I can
drum up in time for 2.3...

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-01-23 17:03

Message:
Logged In: YES 
user_id=86307

Sorry about the parenthetical comment; I think what I was trying 
to say is basically what you have in your last paragraph.

As for use cases, I don't have any myself (I ran into this with 
some test code for a metaclass which &quot;overrides&quot; __bases__).  
However, grepping through the standard library, I note that one 
place where assignment to __bases__ is used is in 
xmlrpclib.SlowParser.  It appears to me that if SlowParser and 
xmllib.XMLParser (neither of which has a base class) were 
converted to new-style classes, the assignment to __bases__ 
would generate this exception.  Of course, that shouldn't be too 
hard to work around if that turns out to be necessary.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-22 11:50

Message:
Logged In: YES 
user_id=6656

I agree this is a bit surprising.  When I was writing this
code I went for the conservative-as-possible approach as I
didn't want to introduce instabilities to Python.

It certainly may be that I've overdone it.  In this case I
probably have; if the tp_dealloc of the class being adjusted
is subtype_dealloc and the tp_dealloc that ultimately gets
invoked is the same we're probably OK.  But I'm not sure and
it's been a while since I thought about this.

It also happens that my motivating use-case for this isn't
troubled by this restriction.

I don't understand your last, parenthetical, comment. 
HEAPTYPES as such doesn't come into it, does it?  

You might be right that we don't need to worry about
tp_dealloc if the ultimate solid_base doesn't change and all
the tp_deallocs on the way there are subtype_dealloc...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 15:23:34 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 15:23:38 2005
Subject: [ python-Bugs-1170766 ] weakref.proxy incorrect behaviour
Message-ID: <E1DGGgw-0002yK-1K@sc8-sf-web3.sourceforge.net>

Bugs item #1170766, was opened at 2005-03-25 21:54
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2005-03-29 13:23

Message:
Logged In: YES 
user_id=4771

The following type slots appear to be missing in the proxy types:

* nb_(inplace_){floor,true}_divide
* sq_repeat, sq_concat, sq_item, sq_ass_item, sq_inplace_concat, sq_inplace_repeat (which are needed for operator.repeat(), operator.concat(), etc. to work)
* tp_as_buffer
* tp_richcompare (tp_compare alone is not enough)
* tp_descr_get, tp_descr_set (for proxies to descriptors...)
* nb_coerce (though it seems that only an explicit call to coerce() can show that this is missing; implicit coercion is done correctly in other operators)
* nb_oct, nb_hex

As far as I can tell, there is no existing operator that is broken in the same way that nb_nonzero was.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-27 11:17

Message:
Logged In: YES 
user_id=80475

Fixed the __nonzero__ problem for Py2.5 and will backport to
Py2.4.  See Objects/weakrefobject.c 1.21.

Leaviing this report open until the rest of the module can
be checked and fixed.



----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-26 14:50

Message:
Logged In: YES 
user_id=4771

The bug is in weakrefobject:proxy_nonzero(), which calls the underlying object's nb_nonzero slot instead of going through the general PyObject_IsTrue() mecanism.  Built-in types like list and dict don't have a nb_nonzero slot.

As a related bug, (Callable)ProxyType should implement tp_richcompare in addition to tp_compare.  In fact, we should review the code to check if ProxyType knows about the most recent type slots...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 15:36:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 15:36:39 2005
Subject: [ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault
	with threads
Message-ID: <E1DGGtY-0006jV-2I@sc8-sf-web1.sourceforge.net>

Bugs item #1165761, was opened at 2005-03-18 16:18
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470

Category: Threads
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659                    case END_FINALLY:
1660                            v = POP();
1661                            if (PyInt_Check(v)) {
1662                                    why = (enum why_code) 
PyInt_AS_LONG(v);
1663                                    assert(why != WHY_YIELD);
1664                                    if (why == WHY_RETURN ||
1665                                        why == WHY_CONTINUE)
1666                                            retval = POP();
1667                            }



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-29 23:36

Message:
Logged In: YES 
user_id=29957

Checked in on 2.4 branch and on trunk.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-29 05:12

Message:
Logged In: YES 
user_id=31435

Note that I already marked the patch as Accepted.

Re-assigning to Anthony, since he said he'll check it in.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-29 01:15

Message:
Logged In: YES 
user_id=29957

This patch applies, and seems to work. I can't see any
reasons for it to _not_ go into 2.4.1 final, unless someone
else can see a reason to avoid it, I'll check it in, in the
morning.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-28 21:53

Message:
Logged In: YES 
user_id=6656

Oh, pig.  Here's the patch with the irrelevant stuff from my new-style 
exceptions work chopped out (I should check that in soon, too I guess).

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-28 18:39

Message:
Logged In: YES 
user_id=29957

This patch won't compile for me on the 2.4 branch or the
trunk - there's no PyExceptionClass_Check defined that I can
find in the codebase, nor can I find anything that looks
like this anywhere. 


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-28 10:43

Message:
Logged In: YES 
user_id=31435

Yup, I agree it's an improvement.  Sorry I didn't have time to 
look at it last week (was at PyCon all day 7 days straight).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-28 07:21

Message:
Logged In: YES 
user_id=6656

Tim, I'd like to check this in.  You get a few days to object :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 21:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

	/* Now we decref the exception classes.  After this point nothing
	   can raise an exception.  That's okay, because each Fini() method
	   below has been checked to make sure no exceptions are ever
	   raised.
	*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-19 08:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 02:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 02:30

Message:
Logged In: YES 
user_id=6656

Chop chop chop.  Attached seems fairly minimal.  It's
something to do with exception handling in __del__ methods
that are called during interpreter tear down.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 01:53

Message:
Logged In: YES 
user_id=6656

Duh, most of that was in the original report :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 01:52

Message:
Logged In: YES 
user_id=6656

And on linux too.

Gdb poking finds that the crash is in
socket._fileobject.close which is being called from
socket._fileobject.__del__ which is being called from  ...
PyThreadState_Clear, PyInterpreterState_Clear, Py_Finalize.
 So I still think it's some kind of tear-down horror.  Hmm.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-19 01:15

Message:
Logged In: YES 
user_id=92222

2.4 crashes also on Windows.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 20:56

Message:
Logged In: YES 
user_id=6656

Oh, and I should say, I'm on OS X.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 20:53

Message:
Logged In: YES 
user_id=6656

Does this always dump core for you?  When I ^C CVS HEAD running this 
a variety of nasty things happen, including one core dump and one "Fatal 
Python error: PyImport_GetModuleDict: no module dictionary!", but more 
often it's something like:

cccc^CTraceback (most recent call last):
  File "/Users/mwh/Desktop/thread_crash.py", line 67, in ?
    main(sys.argv)
  File "/Users/mwh/Desktop/thread_crash.py", line 64, in main
    run (20)
  File "/Users/mwh/Desktop/thread_crash.py", line 56, in run
    thread.start ()
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 418, in 
start
    _sleep(0.000001)    # 1 usec, to let the thread run (Solaris hack)
KeyboardInterrupt
Exception in thread Thread-4 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:
Exception in thread Thread-2 (most likely raised during interpreter 
shutdown):
Traceback (most recent call last):
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 442, in 
__bootstrap
  File "/Users/mwh/Source/python/dist/src/Lib/threading.py", line 422, in 
run
  File "/Users/mwh/Desktop/thread_crash.py", line 23, in run
  File "/Users/mwh/Desktop/thread_crash.py", line 33, in runOnce
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 129, in 
urlopen
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 439, in 
build_opener
  File "/Users/mwh/Source/python/dist/src/Lib/urllib2.py", line 291, in 
add_handler
<class 'exceptions.TypeError'>: 'NoneType' object is not callable
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

with the last bit repeated a few times.

At a guess, it's some kind of interpreter tear-down horror.

Python 2.3 seems to behave much more sensibly.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 20:00

Message:
Logged In: YES 
user_id=6656

Can you try 2.3?  There were some changes in the area for 2.4.

I'll try to poke at it too.

----------------------------------------------------------------------

Comment By: Jeff Stearns (jeffstearns)
Date: 2005-03-18 17:44

Message:
Logged In: YES 
user_id=660929

The bug also exists when Python is compiled with --with-pydebug:

% ./python2.4  -c 'import clientLoadSimulator; clientLoadSimulator.run(20)'
cccccccccccccCc.cCcCccCcc.CCC..CCC......C...........C.C..Traceback (most 
recent call last):
  File "<string>", line 1, in ?
  File "clientLoadSimulator.py", line 67, in run
    thread.join (1.0)
  File "/usr/local/lib/python2.4/threading.py", line 550, in join
    self.__block.wait(delay)
  File "/usr/local/lib/python2.4/threading.py", line 222, in wait
    _sleep(delay)
KeyboardInterrupt
[29492 refs]
Segmentation fault (core dumped)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165761&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 15:39:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 15:39:06 2005
Subject: [ python-Bugs-1170766 ] weakref.proxy incorrect behaviour
Message-ID: <E1DGGvv-0006r5-UR@sc8-sf-web1.sourceforge.net>

Bugs item #1170766, was opened at 2005-03-25 21:54
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-29 14:39

Message:
Logged In: YES 
user_id=6656

Also see bug #1075356 (which is very minor, but might as
well get fixed at the same time).

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-29 14:23

Message:
Logged In: YES 
user_id=4771

The following type slots appear to be missing in the proxy types:

* nb_(inplace_){floor,true}_divide
* sq_repeat, sq_concat, sq_item, sq_ass_item, sq_inplace_concat, sq_inplace_repeat (which are needed for operator.repeat(), operator.concat(), etc. to work)
* tp_as_buffer
* tp_richcompare (tp_compare alone is not enough)
* tp_descr_get, tp_descr_set (for proxies to descriptors...)
* nb_coerce (though it seems that only an explicit call to coerce() can show that this is missing; implicit coercion is done correctly in other operators)
* nb_oct, nb_hex

As far as I can tell, there is no existing operator that is broken in the same way that nb_nonzero was.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-27 12:17

Message:
Logged In: YES 
user_id=80475

Fixed the __nonzero__ problem for Py2.5 and will backport to
Py2.4.  See Objects/weakrefobject.c 1.21.

Leaviing this report open until the rest of the module can
be checked and fixed.



----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-26 14:50

Message:
Logged In: YES 
user_id=4771

The bug is in weakrefobject:proxy_nonzero(), which calls the underlying object's nb_nonzero slot instead of going through the general PyObject_IsTrue() mecanism.  Built-in types like list and dict don't have a nb_nonzero slot.

As a related bug, (Callable)ProxyType should implement tp_richcompare in addition to tp_compare.  In fact, we should review the code to check if ProxyType knows about the most recent type slots...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 16:22:34 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 16:22:36 2005
Subject: [ python-Bugs-1172554 ] "cmp" should be "key" in sort doc
Message-ID: <E1DGHc2-00021H-7i@sc8-sf-web2.sourceforge.net>

Bugs item #1172554, was opened at 2005-03-29 14:22
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=1172554&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172554&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 17:02:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 17:02:44 2005
Subject: [ python-Bugs-1172581 ] "cmp" should be "key" in sort doc
Message-ID: <E1DGIEs-0000eE-Ex@sc8-sf-web4.sourceforge.net>

Bugs item #1172581, was opened at 2005-03-29 15:02
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=1172581&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 17:35:10 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 17:35:36 2005
Subject: [ python-Bugs-1172554 ] "cmp" should be "key" in sort doc
Message-ID: <E1DGIkI-00072z-0V@sc8-sf-web2.sourceforge.net>

Bugs item #1172554, was opened at 2005-03-29 09:22
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172554&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-29 10:35

Message:
Logged In: YES 
user_id=80475

Thanks for the report.
This was already fixed.
You should see it in the new Py2.4.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172554&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 20:11:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 20:11:24 2005
Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Message-ID: <E1DGLBM-0007ch-Vc@sc8-sf-web2.sourceforge.net>

Bugs item #1075984, was opened at 2004-11-30 14:13
Message generated for change (Comment added) made by bernhard
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory fault pyexpat.so on SGI

Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m

cc -version
MIPSpro Compilers: Version 7.3.1.3m

- make tests passes test_pyexpat without error
- running this code leads to a core dump

-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)

<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)

- running this code from an interactive session leads
not to a coredump

I need some assistance howto provide further debug
information.

--maik./

----------------------------------------------------------------------

Comment By: Bernhard Herzog (bernhard)
Date: 2005-03-29 20:11

Message:
Logged In: YES 
user_id=2369

I ran into this problem as well on a debian GNU/Linux system
on x86 hardware.  It occurs both with pygtk 2.4 and wxPython
2.5 both built against gtk 2.4.

bos' patch at least solves the immediate problem of the
segmentation fault.  It may be a good idea to print a
warning message if some of the error codes cannot be
translated to strings, though.


----------------------------------------------------------------------

Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-05 00:16

Message:
Logged In: YES 
user_id=28380

With the GNU linker, you can pass in -Bstatic to force it to resolve the symbols in the local shared library, instead of globally. This also works on Irix. I don't know about other Unixes.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-02-02 11:35

Message:
Logged In: YES 
user_id=6656

It's a nasty one, I'll give you that.

Fred, what do you think of bos's patch?  It solves the immediate issue, 
but I'm not sure it's a complete fix.

It seems to me that it would be better to resolve the expat symbols at 
builf time, but I don't know how to arrange for that.

----------------------------------------------------------------------

Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-02 07:09

Message:
Logged In: YES 
user_id=28380

By the way, this is not an SGI-specific bug. This will bite any Unix system with a modern sysv-style dynamic linker. The priority of this bug should be higher, IMO.

----------------------------------------------------------------------

Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-01 08:53

Message:
Logged In: YES 
user_id=28380

I've been bitten by the same bug. In my case, the problem was with Qt, not GTK.

It's not actually necessary to check the expat version; just see if XML_ErrorString actually returns anything.

Here's the patch I use for this problem:

--- python/Modules/pyexpat.c        2005-01-06 16:26:13 -08:00
+++ python/Modules/pyexpat.c  2005-01-31 23:46:36 -08:00
@@ -1936,9 +1936,12 @@
     }
 #endif

-#define MYCONST(name) -    PyModule_AddStringConstant(errors_module, #name, -                               (char*)XML_ErrorString(name))
+#define MYCONST(name)                           +    { +        char *_v = (char*)XML_ErrorString(name); +        if (_v) +            PyModule_AddStringConstant(errors_module, #name, _v); +    }

     MYCONST(XML_ERROR_NO_MEMORY);
     MYCONST(XML_ERROR_SYNTAX);


----------------------------------------------------------------------

Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 14:46

Message:
Logged In: YES 
user_id=471223

pyexpat initializes using its internal copy of expat. 
libexpat.so is still mapped in (after pyexpat has
initilized), but gdb finds the python copy of
XML_ErrorString and other functions.

I suspect that this will be a problem if the system version
of expat is newer than Python's.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-12-13 14:01

Message:
Logged In: YES 
user_id=6656

1) Good sleuthing.
2) Argh!
3) What happens if you import pyexpat before pygtk?

----------------------------------------------------------------------

Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 10:29

Message:
Logged In: YES 
user_id=471223

I've looked at the program that was dumping core and the
sequence is this:

1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which
in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pyexpat calls XML_ErrorString, but as ld.so has already
linked in XML_ErrorString from /usr/local/lib/libexpat.so it
calls that version, not the one in pyexpat.so.  
5) pyexpat looks up an error defined by the later version of
expat it is expecting and gets a NULL pointer from the
earlier version it has.  It attempts to use it without
checking (strlen) and dumps core.

----------------------------------------------------------------------

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 18:01

Message:
Logged In: YES 
user_id=471223

Maybe it compiled against its own copy of expat, but pulled
in the system's copy when run?  

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-12-10 17:52

Message:
Logged In: YES 
user_id=6656

Uh, Python includes its own copy of expat, and I really
thought we were supposed to prefer our own version over
anything found on the system...

----------------------------------------------------------------------

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 17:46

Message:
Logged In: YES 
user_id=471223

I also got a core dump importing pyexpat on Solaris (SPARC)
and somebody else reported it on a *BSD system.

It appears to be a problem with older versions of expat not
being tested for.  I used gdb to trace it down to line 1972
in pyexpat.c where it attempts to define the first constant
from 1.95.8.  I had expat 1.95.7.  After upgrading to 1.95.8
it worked fine, as did the *BSD system. 

I think Python needs to check the expat version, as it does
elsewhere in the file, before defining those constants. 

I am still puzzelled over how it managed to compile
pyexpat.c in the first place...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 22:23:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 22:23:07 2005
Subject: [ python-Bugs-1172763 ] dumbdbm hoses index on load failure
Message-ID: <E1DGNEu-0001rs-Tx@sc8-sf-web3.sourceforge.net>

Bugs item #1172763, was opened at 2005-03-29 15:23
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=1172763&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: currivan (currivan)
Assigned to: Nobody/Anonymous (nobody)
Summary: dumbdbm hoses index on load failure

Initial Comment:
Using python to read a dumbdbm db created with jython
on Windows, the index got erased.  The load failed with
an exception due to the python os.linesep being "\n",
while the jython version created the db with "\r\n".  

On exit, the python dumbdbm module committed the empty
index it had read, destroying the db.  commit (or sync)
is implicitly being called on exit from python.

dumbdbm ignores the flag it was opened with and commits
even if it was opened with 'r'.  jython doesn't seem to
support any other standard dbm implementation, so I'm
stuck with dumbdbm.

The problem can be worked around by setting os.linesep
manually to enforce consistency.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172763&group_id=5470
From noreply at sourceforge.net  Tue Mar 29 22:50:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 29 22:50:55 2005
Subject: [ python-Bugs-1172785 ] doctest.script_from_examples() result
	sometimes un-exec-able
Message-ID: <E1DGNfp-0003It-8y@sc8-sf-web3.sourceforge.net>

Bugs item #1172785, was opened at 2005-03-29 15:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172785&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan E. Guyer (jguyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest.script_from_examples() result sometimes un-exec-able

Initial Comment:
doctest.script_from_examples() can sometimes return results that 
cannot be passed to exec. The docstring for script_from_examples() 
itself is an example:

guyer% python2.4
Python 2.4 (#1, Mar 10 2005, 18:08:38) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> text = '''
...     Here are examples of simple math.
...         Python has super accurate integer addition
...         >>> 2 + 2
...         5
... 
...         And very friendly error messages:
... 
...         >>> 1/0
...         To Infinity 
...         And
...         Beyond
... 
...         You can use logic if you want:
... 
...         >>> if 0:
...         ...    blay 
...         ...    blah
...         ...
... 
...         Ho hum
...         '''
>>> exec doctest.script_from_examples(text)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 21
    #     Ho hum
              ^
SyntaxError: invalid syntax


The issue seems to be the lack of trailing '\n', which is documented 
as required by compile(), although not for exec. 

We never saw a problem with this in Python 2.3's doctest, probably 
because comment lines, such as "Ho hum", were stripped out and 
apparently adequate '\n' were appended.

Python 2.4 on Mac OS X 10.3.8

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172785&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 12:10:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 12:10:57 2005
Subject: [ python-Bugs-1166660 ] The readline module can cause python to
	segfault
Message-ID: <E1DGaA3-0007SQ-5g@sc8-sf-web1.sourceforge.net>

Bugs item #1166660, was opened at 2005-03-19 21:48
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Michael Hudson (mwh)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
<http://www.scipy.net/roundup/ipython/issue30>.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-30 11:10

Message:
Logged In: YES 
user_id=6656

While it does seem a bit odd to call the completer function in the thread 
that calls set_completer and not the thread that calls readline(), I don't 
immediately see how this is leading to segfaults.  Do you?

Anyway, I can reproduce the problem, so if your fix fixes it, I'll check it in 
(irrespective of fixing segfaults, it just makes more sense).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-29 13:10

Message:
Logged In: YES 
user_id=6656

Unless there's some reason to suspect they share a common
cause (and, I don't see one) a second report is more
appropriate.

Also, if you understand what's going on, you can explain
there :)

----------------------------------------------------------------------

Comment By: Yariv Ido (dcoder)
Date: 2005-03-28 23:33

Message:
Logged In: YES 
user_id=326689

I haven't (Completely forgot about it, after finding the
main one...). Should I post a seperate bug report, or will
this one do?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:43

Message:
Logged In: YES 
user_id=6656

I'll take a look at this.

Did you submit a bug on the set_startup_hook problem mentioned in the 
ipython tracker?

----------------------------------------------------------------------

Comment By: Yariv Ido (dcoder)
Date: 2005-03-19 23:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 13:23:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 13:23:58 2005
Subject: [ python-Bugs-1166660 ] The readline module can cause python to
	segfault
Message-ID: <E1DGbIg-0003KH-Ta@sc8-sf-web4.sourceforge.net>

Bugs item #1166660, was opened at 2005-03-19 21:48
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470

Category: Threads
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Michael Hudson (mwh)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
<http://www.scipy.net/roundup/ipython/issue30>.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-30 12:23

Message:
Logged In: YES 
user_id=6656

Oh, forget all that, I had a leap in understanding about the existing threads-
vs-hooks code in readline.c: it's all insane nonsense.

I used the PyGILState_* API rather than your suggestion, on the very faint 
chance that an embedder might be calling readline() directly and thus have 
not be setting _PyOS_ReadlineTState.

I also fixed the 'checking the return value from a hook function' while I was 
there, so you don't need to submit a new report for that.

Modules/readline.c revision 2.83.

Thanks for the report!


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-30 11:10

Message:
Logged In: YES 
user_id=6656

While it does seem a bit odd to call the completer function in the thread 
that calls set_completer and not the thread that calls readline(), I don't 
immediately see how this is leading to segfaults.  Do you?

Anyway, I can reproduce the problem, so if your fix fixes it, I'll check it in 
(irrespective of fixing segfaults, it just makes more sense).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-29 13:10

Message:
Logged In: YES 
user_id=6656

Unless there's some reason to suspect they share a common
cause (and, I don't see one) a second report is more
appropriate.

Also, if you understand what's going on, you can explain
there :)

----------------------------------------------------------------------

Comment By: Yariv Ido (dcoder)
Date: 2005-03-28 23:33

Message:
Logged In: YES 
user_id=326689

I haven't (Completely forgot about it, after finding the
main one...). Should I post a seperate bug report, or will
this one do?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:43

Message:
Logged In: YES 
user_id=6656

I'll take a look at this.

Did you submit a bug on the set_startup_hook problem mentioned in the 
ipython tracker?

----------------------------------------------------------------------

Comment By: Yariv Ido (dcoder)
Date: 2005-03-19 23:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166660&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 14:40:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 14:40:33 2005
Subject: [ python-Bugs-1167300 ] Error "exec"ing python code
Message-ID: <E1DGcUp-0008Dt-ML@sc8-sf-web3.sourceforge.net>

Bugs item #1167300, was opened at 2005-03-21 00:35
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error "exec"ing python code

Initial Comment:
I'm trying to 'exec'ing the following code:

class Foo: pass
class Bar:
    f = Foo
    
The error appears when using 'exec f in {}, {}':

>>> f = ''.join(open('/home/stefan/t.py').readlines())
>>> exec f in {}, {}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 2, in ?
  File "<string>", line 3, in Bar
NameError: name 'Foo' is not defined

I tested on python 2.3 and python 2.4, both show the same
behavior.

----------------------------------------------------------------------

>Comment By: Michael Chermside (mcherm)
Date: 2005-03-30 07:40

Message:
Logged In: YES 
user_id=99874

I can confirm this... it appears that things which are set
in the global scope within an "exec ... in {}, {}" are not
then correctly accessed in the global scope when being read.
The following two examples illustrate the problem:

>>> exec """... x = 3
... def f():
...     global x
...     print x
... f()
... """ in {}, {}
3

... and again without the global definition:

>>> exec """... x = 3
... def f():
...     print x
... f()
... """ in {}, {}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 4, in ?
  File "<string>", line 3, in f
NameError: global name 'x' is not defined

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 17:42:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 17:42:32 2005
Subject: [ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'
Message-ID: <E1DGfKs-0002Sy-Gq@sc8-sf-web3.sourceforge.net>

Bugs item #1173407, was opened at 2005-03-30 15: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=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 18:32:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 18:32:52 2005
Subject: [ python-Bugs-1165306 ] Property access with decorator makes
	interpreter crash
Message-ID: <E1DGg7c-0003KR-Gb@sc8-sf-web4.sourceforge.net>

Bugs item #1165306, was opened at 2005-03-17 14:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Remy Blank (remyblank)
Assigned to: Michael Hudson (mwh)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

joe@pat TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-30 17:32

Message:
Logged In: YES 
user_id=6656

Fixed, in 

Objects/classobject.c revision 2.177
Lib/test/test_new.py revision 1.20

Thanks for the report!

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 22:16

Message:
Logged In: YES 
user_id=6656

> > remyblank: let me guess your code wasn't doing what
> > you thought it did? :)
> 
> Err... Not sure what you mean... What would be the correct
> way to do what I thought it did?

Well, I don't know, but what it was doing was trying to create a method 
bound to None...

I'll check this in soon.

----------------------------------------------------------------------

Comment By: Remy Blank (remyblank)
Date: 2005-03-17 20:13

Message:
Logged In: YES 
user_id=568100

> remyblank: let me guess your code wasn't doing what you
thought it did? :)

Err... Not sure what you mean... What would be the correct
way to do what I thought it did?

The code was largely inspired by a Cookbook entry. These are
still my first steps with decorators, and I have to admit I
don't yet fully understand why I have to create a MethodType
manually.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 18:43

Message:
Logged In: YES 
user_id=6380

Looks OK on cursory inspection.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:28

Message:
Logged In: YES 
user_id=6656

Let's attach a test case too.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:15

Message:
Logged In: YES 
user_id=6656

Well, it's a bit more subtle than I thought:

>>> def f(): pass
... 
>>> print f.__get__(1).im_class
None

The problem occurs when *both* im_self and im_class are None; and I'm 
now reasonably convinced that calling the type object is the only way this 
can be acheived.  So a simple check along these lines in 
instancemethod_new would suffice (patch attached), and seems less likely 
to break code.

I suspect this has missed 2.4.1.

remyblank: let me guess your code wasn't doing what you thought it did? :)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 17:03

Message:
Logged In: YES 
user_id=6380

Looks like I wasn't finished with the thought when I checked
it in. I think I was trying to make instancemethod generally
useful as a currying primitive. That should probably be
considered more careful; please roll it back.

(I think it may have been part of the aborted experiment to
get rid of bound methods.)

Is there time to backport this to 2.4.1?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 16:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test <poke> (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 15:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 18:54:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 18:54:06 2005
Subject: [ python-Bugs-542314 ] long file name support broken in windows
Message-ID: <E1DGgSB-0003sk-Ni@sc8-sf-web1.sourceforge.net>

Bugs item #542314, was opened at 2002-04-10 21:23
Message generated for change (Comment added) made by stunorton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: long file name support broken in windows

Initial Comment:
>From c.l.py, thread &quot;&quot;

Peter D:
I'm using windows and trying to call os.path.getmtime
() after using os.path.walk... However, I'm choking 
with &quot;[Errno 38] Filename too long&quot; on paths with len 
&gt; ~260

Adding Martin's reply in a new comment (so it is not 
at the top of each and every mail I get on this bug :)

----------------------------------------------------------------------

Comment By: Stuart Norton (stunorton)
Date: 2005-03-30 08:54

Message:
Logged In: YES 
user_id=1152606

I came across this suggestion while googling... and I would 
have expected it to work, but this code:

import os

os.chdir("\\ussvs-file02
\radpubs\wip\zStaging\translation\D10
\previous_test\cumulative\Common\Reference\API\Borland
.Eco.Persistence.Configuration\classes\PersistenceMapper
DefinitionCollection\Methods")
for filename in os.listdir("."):
    print filename
    infile = file(filename)

gives me 

C:\Documents and 
Settings\snorton\Desktop\h2build\buildtools>test.py
PersistenceMapperDefinitionCollection.AddRange.xml
PersistenceMapperDefinitionCollection.Assign.xml
PersistenceMapperDefinitionCollection.FindByName.xml
PersistenceMapperDefinitionCollection.NameExists.xml
PersistenceMapperDefinitionCollection.PersistenceMapperDefi
nitionCollection.xml
Traceback (most recent call last):
  File "C:\Documents and 
Settings\snorton\Desktop\h2build\buildtools\test.py", line 6, 
in ?
    infile = file(filename)
IOError: [Errno 2] No such file or 
directory: 'PersistenceMapperDefinitionCollection.Persistence
MapperDefinitionCollection.xml'

... funny that the file with the long path comes up in listdir() 
but isn't found with file()...


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-10 21:26

Message:
Logged In: YES 
user_id=14198

Martin v. Loewis's reply on c.l.py:

Since you are asking for a work-around: cd into one of the 
more nested directories when the path gets longer 
(os.chdir), and use relative paths from then on.

If you want to study how to solve the problem: the relevant 
code snippet is in Modules/posixmodule.c

	/* the library call can blow up if the file name is 
too long! */
	if (pathlen &gt; MAX_PATH) {
		PyMem_Free(pathfree);
		errno = ENAMETOOLONG;
		return posix_error();
	}

There might be different ways to approach this:

- challenge the correctness of the comment:
   - try to establish why the author of that code
     thought that the C library could blow up
   - analyse whether these arguments are still true
     with the current compiler version
  -or-
   - prove the argument wrong by analysing the source 
     code of the C library
- then remove the constraint
-or-
- use different API to achieve the same effect without
  suffering from the constraint.

I'm serious about these suggestions: users would appreciate 
if this gets fixed somehow - apparently, the system allows 
longer file names, and apparently, the system itself can 
deal with that quite well. This
can be only true if the system either doesn't use its C 
library, or if the C library does not have this restriction.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 19:29:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 19:29:36 2005
Subject: [ python-Feature Requests-700921 ] Wide-character curses
Message-ID: <E1DGh0T-0004ia-KL@sc8-sf-web2.sourceforge.net>

Feature Requests item #700921, was opened at 2003-03-10 16:45
Message generated for change (Comment added) made by moculus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wide-character curses

Initial Comment:
There exists a standard for wide-character curses
(http://www.opengroup.org/onlinepubs/7908799/cursesix.html)
and at least ncurses implements it (almost completely;
you need to enable this when configuring it).  It is
essensial for getting the maximum of modern UTF-8
terminals (e.g. xterm).
It would make sense for python's curses module to
support all the wide functions on systems where the
wide curses interface is present, especially since
Python already supports unicode.


----------------------------------------------------------------------

Comment By: Erik Osheim (moculus)
Date: 2005-03-30 17:29

Message:
Logged In: YES 
user_id=542811

Is there any work still being done on this? I have been
hoping that a feature like this would be included for
awhile, and it's more than two years since this request was
posted.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-11 14:52

Message:
Logged In: YES 
user_id=6656

Cool.

You should be able to extend the current preprocessor
hackery to relieve some of the drudgery, shouldn't you?

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2003-03-11 14:49

Message:
Logged In: YES 
user_id=36166

OK.  I don't care much whether it gets official quickly, I
do want something to play with :-) (of course I want it to
become official when it's good enough).

I've looked a bit at the code.  The prospect of
double-casing all functions to use the wide interface is not
pleasant but I don't see a better alternative yet; I'd like
to factor things out if I find a way...  And yes, any code I
produce wll certainly require review :-).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-11 14:06

Message:
Logged In: YES 
user_id=6656

It sounds like you've given this more thought already than
I'm likely to for some time :-)

This is unlikely to make 2.3, I'd have thought, so there's
no hurry, really.

I can answer any questions about details of implementation
and review any code you produce, but I think you have a
better handle on design issues.

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2003-03-11 13:38

Message:
Logged In: YES 
user_id=36166

One more issue: constants.

I think the ``A_`` attribute constants  should not be
duplicated as ``WA_``; rather the same ``A_`` values will be
accepted in all cases and translated to the corresponding
``WA_`` values when passing them to wide curses functions.
``WA_`` attributes that have no ``A_`` counterpart in curses
should get one, possibly a long int:
A_{HORIZONTAL,LEFT,LOW,RIGHT,TOP,VERTICAL}.  Wait, we 
already define them ;-).  But they might be availiable on
some platforms only as ``WA_`` and not ``A_``...

The ``ACS_`` constants also have ``WACS_`` counterparts that
are (cchar_t *).  Probably the later should be exposed as
unicode strings instead of the 

Other constants added in XSI curses are:

* EOF/WEOF (actually declared in &lt;stdio.h&gt;, &lt;wchar.h&gt;;
returned by `.getch()` - should be either exposed in the
module or converted to something sensible (None?).  getkey()
currently segfaults(!) on end of file, should return empty
string for consistency with `file.read()`...

* KEY_CODE_YES - return value of `get_wch()` to indicate the
code is a key.  Should not be exposed.

Update to previous message: the ``_wchstr`` family need not
be supported, at least as long as ``chstr`` family isn't (I
didn't notice there is such a thing).  In long run, it might
be useful (but then a completely new high-level wrapper of
windows as directly subscriptable/sliceable and 2D arrays
would be even better...  Let's leave it for now).

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2003-03-10 20:55

Message:
Logged In: YES 
user_id=36166

Good question :-).
Here are the basic additions of the wide curses interface:

* `chtype` (which must be an integral type) donesn't have
enough place to hold a character OR-ed with the attributes,
nor would that be useful enough since combining characters
must be handled.  Therefore two types are intoroduced:

** attr_t - an integral type used to hold an OR-ed set of
attributes that begin with the prefix ``WA_``.  These
attributes are semantically a superset of the ``A_`` ones
and can have different values (although in ncurses they are
the same).

** cchar_t - a type representing one character cell: at most
one spacing character, an implementation-defined number of
combining characters, attributes and a color pair.

* A whole lot of new functions are provided using these new
types.  The distinguishing naming style is the separation of
words with underscope.

** Functions that work on single chars have counterparts
(``_wch``) that recieve/return cchar_t (except for get_wch
which is a bogus mutation).

** Functions that work on strings have counterparts
(``_wstr``) that recieve/return (wchar_t *); many also are
duplicated with a (cchar_t *) interface (``_wchstr``).

** All old functions having to do with characters are
semantically just degenerate compatibility interfaces to the
new ones.

* Semantics are defined for adding combining characters: if
only non-spacing characters are given, they are added to the
existing complex character; if a spacing character is
present, the whole cell is replaced.

* Semantics are defined for double-width characters  (what
happens when you break them in various ways).

The simplest thing is just to wrap all the extra functions,
exposing two APIs in Python, with the later only availible
when the platform supports it.  This would be painful to
work with and I'd rather avoid it.

A better approach is just to overload the old names to work
with unicode strings.  For single-character methods (e.g.
`addch`), it's harder.  The (character ordinal | attributes)
interface for should be deprecated and only work for ascii
chars, in a backwards-compatible way.  The interface where
the character and attributes are given as separate arguments
can be cleanly extended to accept unicode characters/ordinals.

The behaivour w.r.t. combing and double-width characters
should be defined.  Complex chars should be repsented as
multi-char unicode strings (therefore unicode ordinals are a
limited representation).  I don't think anything special is
needed for sensible double-width handling?

The (char_t *) interfaces (``_wchstr``) are convenient for
storing many characters with inividual attributes; I'm not
sure how to expose them (list of char, attr tuples?).

There is the question of what to do in the absense of wide
curses in the platform, when the unicode interface will be
called.  I think that some settable &quot;curses default
encoding&quot; should be used as a fallback, so that people can
keep their sanity.  This should be specific to curses, or
maybe even settable per-window, so that some basic
input/output methods can implemented as a codec (this is
suboptimal but I think could be useful as a quick solution).

I can write an initial patch but don't expect it quickly. 
This could use the counsel of somebody with wide-curses
expereince (I'm a newbe to this, I want to start
experimenting in Python rather than C :-).


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-10 17:48

Message:
Logged In: YES 
user_id=6656

What steps need to be taken to acheive this?  Would you be
interested in working up a patch?

I do most of my terminal hacking below the level of curses
these days...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 19:41:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 19:41:57 2005
Subject: [ python-Bugs-1172581 ] "cmp" should be "key" in sort doc
Message-ID: <E1DGhCV-0000d7-97@sc8-sf-web3.sourceforge.net>

Bugs item #1172581, was opened at 2005-03-29 10:02
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 12:41

Message:
Logged In: YES 
user_id=593130

This has been fixed in the 2.4.1 doc released today
http://docs.python.org/lib/typesseq-mutable.html

(The old url with  /doc/current added no longer works for me).

Please close as 'fixed' if you can.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 19:56:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 19:56:55 2005
Subject: [ python-Bugs-1171994 ] error in documentation for splitting empty
	string 
Message-ID: <E1DGhQz-0007Io-J2@sc8-sf-web1.sourceforge.net>

Bugs item #1171994, was opened at 2005-03-28 12:49
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171994&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in documentation for splitting empty string 

Initial Comment:
Below is extracted from http://www.python.org/doc/2.4/
lib/string-methods.html describing the string method 
split().

-----------------------------------------------------------------------
split([sep [,maxsplit]])

    ... Splitting an empty string with a specified separator 
returns an empty list.

    If sep is not specified or is None, a different splitting 
algorithm is applied. ... Splitting an empty string returns 
"['']".

-----------------------------------------------------------------------

The rationale for different treatment of splitting an empty 
string seems to be discussed in 811604. However the 
documentation seems to be the opposite of actual result.

>>> ''.split(',')
['']
>>> ''.split()
[]


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 12:56

Message:
Logged In: YES 
user_id=593130

The new 2.4.1 doc (released today) at
http://docs.python.org/lib/string-methods.html
remains the same.

Verified behavior on 2.2.  If unchanged (lest code be broken), 
there does seem to be a problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171994&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 20:03:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 20:03:19 2005
Subject: [ python-Bugs-1172581 ] "cmp" should be "key" in sort doc
Message-ID: <E1DGhX9-0007hz-Tk@sc8-sf-web1.sourceforge.net>

Bugs item #1172581, was opened at 2005-03-29 10:02
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:03

Message:
Logged In: YES 
user_id=593130

Ignore previous comment about 'old url'.  Did not 
notice 'www.python' versus 'doc.python'.  It seems 
that 'www.python.org/doc/current' and 'docs.python.org' are 
aliased prefixes leading to the 'current' docs.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 12:41

Message:
Logged In: YES 
user_id=593130

This has been fixed in the 2.4.1 doc released today
http://docs.python.org/lib/typesseq-mutable.html

(The old url with  /doc/current added no longer works for me).

Please close as 'fixed' if you can.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 20:12:43 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 20:12:46 2005
Subject: [ python-Bugs-1170424 ] why should URL be required for all packages
Message-ID: <E1DGhgJ-0006yl-AK@sc8-sf-web2.sourceforge.net>

Bugs item #1170424, was opened at 2005-03-25 04:58
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170424&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: J?rgen A. Erhard (jae)
Assigned to: Nobody/Anonymous (nobody)
Summary: why should URL be required for all packages

Initial Comment:
Annoying if you just want to roll an in-house package.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:12

Message:
Logged In: YES 
user_id=593130

Bugs are a discrepancy between intended/claimed behavior and 
actual behavior.  Since this does not appear to report such a 
discrepancy, it does not appear to be a bug report.  Please close 
and ask your question and make your comment on the Python 
discussion mailing list or newsgroup (comp.lang.python).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170424&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 20:29:27 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 20:29:32 2005
Subject: [ python-Bugs-1170422 ] doc speaks of extensions option while it's
	*called* ext_modu
Message-ID: <E1DGhwV-0000yY-3w@sc8-sf-web4.sourceforge.net>

Bugs item #1170422, was opened at 2005-03-25 04:56
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170422&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: J?rgen A. Erhard (jae)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc speaks of extensions option while it's *called* ext_modu

Initial Comment:
ext_modules, of course (crap bugtracker)

Another minor fix would be to show an import Extension
in at least one example.  Quite a lot easier to see for
the impatient.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:29

Message:
Logged In: YES 
user_id=593130

What I understand is that you want something (literally 'extention 
option'?) replaced by 'ext_module' somewhere.  Could you be 
more specific as to where (which section of which document, or 
a url) and what something?  Giving the current phrase or 
sentence and your suggested replacement makes a change 
decision easier.

----------------------------------------------------------------------

Comment By: J?rgen A. Erhard (jae)
Date: 2005-03-25 05:03

Message:
Logged In: YES 
user_id=10380

Ouch, forget about the import Extension... it's there, and I
was just blind.  Note to self: the usual ;-)

(I wish I could edit my own submissions)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170422&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 20:35:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 20:35:42 2005
Subject: [ python-Bugs-1170331 ] Error in base64.b32decode
Message-ID: <E1DGi2V-00086I-Hv@sc8-sf-web2.sourceforge.net>

Bugs item #1170331, was opened at 2005-03-24 23:05
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: toidinamai (toidinamai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in base64.b32decode

Initial Comment:
Hi,                                                   
                                                      
                                                         
                                                      
                                                      
                                                         
I believe there is an error in base64.b32decode because
it doesn't seem to                                    
                                                          
allow to decode arbitrary binary data:                
                                                      
                                                         

<code>                                                
                                                      
                                                         
#!/usr/bin/env python2.4                              
                                                      
                                                         
                                                      
                                                      
                                                         
import base64                                         
                                                      
                                                         
                                                      
                                                      
                                                         
b64d = base64.b64decode                               
                                                      
                                                         
b64e = base64.b64encode                               
                                                      
                                                         
                                                      
                                                      
                                                         
print "base64: ", repr(b64d(b64e('\x00')))            
                                                      
                                                         
                                                      
                                                      
                                                         
b16d = base64.b16decode                               
                                                      
                                                         
b16e = base64.b16encode                               
                                                      
                                                         
                                                      
                                                      
                                                         
print "base16: ", repr(b16d(b16e('\x00')))            
                                                      
                                                         
                                                      
                                                      
                                                         
b32d = base64.b32decode                               
                                                      
                                                         
b32e = base64.b32encode                               
                                                      
                                                         
                                                      
                                                      
                                                         
print "base32: ", repr(b32d(b32e('\x00')))            
                                                      
                                                         
</code>                                               
                                                      
                                                         
                                                      
                                                      
                                                         
This raises a very strange exception:                 
                                                      
                                                         
                                                      
                                                      
                                                         
Traceback (most recent call last):                    
                                                      
                                                         
  File "test.py", line 18, in ?                       
                                                      
                                                         
    print "base32: ", repr(b32d(b32e('\x00')))        
                                                      
                                                         
  File "/usr/lib/python2.4/base64.py", line 228, in
b32decode                                             
                                                      
     
    last = binascii.unhexlify(hex(acc)[2:-1])         
                                                      
                                                         
TypeError: Odd-length string                          
                                                      
                                                         
                                                      
                                                      
                                                         
b32 should work just like b64 and b16.                
                                                      
                                                      
                                                      
                                                      
                                            

Best regards
Frank Bensktein.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:35

Message:
Logged In: YES 
user_id=593130

Your original report somehow got larded with blank lines that  
spread it over 4 screens.  If you can somehow prevent this next 
time, it would be much easier to read.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2005-03-27 14:48

Message:
Logged In: YES 
user_id=699438

patch 1171487 posted.  It is pure python so you should be
able to incorporate into your existing codebase relatively
easily.  You won't need to rebuild the python executable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 20:39:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 20:39:08 2005
Subject: [ python-Bugs-1170311 ] zipfile UnicodeDecodeError
Message-ID: <E1DGi5m-0001OG-2o@sc8-sf-web4.sourceforge.net>

Bugs item #1170311, was opened at 2005-03-24 21:51
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: adam davis (adamx97)
Assigned to: M.-A. Lemburg (lemburg)
Summary: zipfile UnicodeDecodeError

Initial Comment:
I think this is the same as #  705295, which may have
been prematurely closed.

I think the error is dependent on the data or time.

File "C:\Python24\lib\zipfile.py", line 166, in FileHeader
    return header + self.filename + self.extra
UnicodeDecodeError: 'ascii' codec can't decode byte
0xd0 in position 10: ordinal not in range(128)

The header is packed like this:
        header = struct.pack(structFileHeader,
stringFileHeader,
                 self.extract_version, self.reserved,
self.flag_bits,
                 self.compress_type, dostime, dosdate, CRC,
                 compress_size, file_size,
                 len(self.filename), len(self.extra))

the header is:

[Dbg]>>> header
'PK\x03\x04\x14\x00\x00\x00\x00\x00\xd0\xa9x2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00-\x00\x00\x00'

and here are the parts that made it up:

[Dbg]>>> structFileHeader, stringFileHeader,
self.extract_version, self.reserved,
self.flag_bits,self.compress_type, dostime, dosdate,
CRC, compress_size, file_size, len(self.filename),
len(self.extra)
('<4s2B4HlLL2H', 'PK\x03\x04', 20, 0, 0, 0, 43472,
12920, 0, 0, 0, 45, 0)


here's the pieces of the 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:39

Message:
Logged In: YES 
user_id=593130

Your report ends with 'here's the pieces of the'.  Was something 
cut off?  If you meant to attach a file, try again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 20:45:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 20:45:49 2005
Subject: [ python-Bugs-1169108 ] PySys_WriteStderr() ->
	WaitForSingleObject() hangs system
Message-ID: <E1DGiCH-0000ET-Uc@sc8-sf-web2.sourceforge.net>

Bugs item #1169108, was opened at 2005-03-23 08:55
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169108&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: stan pinte (stanpinte)
Assigned to: Nobody/Anonymous (nobody)
Summary: PySys_WriteStderr() -> WaitForSingleObject() hangs system

Initial Comment:
hello,

I am running Simpy (python simulation framework) within
pythondotnet (a slightly modified python version, based
on python2.4),
and, even though this process is single-thread, it
hangs misteriously,
in an unpredictable way...

Python console cease to respond to Ctrl-C events...

Here is the current Thread status:

Thread Start Address:
Symbol Name:			Line Number:		PC:
mscoree!_CorExeMain() + 0x0	---			7917D08C

Thread Stack:

ntdll ! KiFastSystemCallRet() + 0x
KERNEL32 ! WaitForSingleObject() + 0x12
python24 ! PySys_WriteStderr() + 0x14d
python24 ! PyTuple_Type() + 0x0

However, I would like to be able to go higher in the
stack, to see what
caused this deadlock.

Any proposed strategy to guess what happened, or to
track down the problem?

thanks a lot,

Stan.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:45

Message:
Logged In: YES 
user_id=593130

Unless you claim/believe that there is a bug in unmodified 
CPython 2.4.1 (just released) please close this item.

----------------------------------------------------------------------

Comment By: stan pinte (stanpinte)
Date: 2005-03-23 10:28

Message:
Logged In: YES 
user_id=154693

 Hello!

I solved my problem by removing all references to
Queue.queue instances in my python code. --> my usage of
Queues was so heavy that it was triggering a nice bug in
python synchronization code.

I was pointed to threading issues by enabling full trace in
my python code, and some traces were showing code from
threading.py

thanks a lot anyway for the help.

Stan.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169108&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 21:06:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 21:06:15 2005
Subject: [ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'
Message-ID: <E1DGiW5-0002fQ-0S@sc8-sf-web4.sourceforge.net>

Bugs item #1173407, was opened at 2005-03-30 10:42
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 21:27:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 21:27:59 2005
Subject: [ python-Bugs-1170311 ] zipfile UnicodeDecodeError
Message-ID: <E1DGir6-0003fg-LR@sc8-sf-web1.sourceforge.net>

Bugs item #1170311, was opened at 2005-03-25 03:51
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: adam davis (adamx97)
>Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile UnicodeDecodeError

Initial Comment:
I think this is the same as #  705295, which may have
been prematurely closed.

I think the error is dependent on the data or time.

File "C:\Python24\lib\zipfile.py", line 166, in FileHeader
    return header + self.filename + self.extra
UnicodeDecodeError: 'ascii' codec can't decode byte
0xd0 in position 10: ordinal not in range(128)

The header is packed like this:
        header = struct.pack(structFileHeader,
stringFileHeader,
                 self.extract_version, self.reserved,
self.flag_bits,
                 self.compress_type, dostime, dosdate, CRC,
                 compress_size, file_size,
                 len(self.filename), len(self.extra))

the header is:

[Dbg]>>> header
'PK\x03\x04\x14\x00\x00\x00\x00\x00\xd0\xa9x2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00-\x00\x00\x00'

and here are the parts that made it up:

[Dbg]>>> structFileHeader, stringFileHeader,
self.extract_version, self.reserved,
self.flag_bits,self.compress_type, dostime, dosdate,
CRC, compress_size, file_size, len(self.filename),
len(self.extra)
('<4s2B4HlLL2H', 'PK\x03\x04', 20, 0, 0, 0, 43472,
12920, 0, 0, 0, 45, 0)


here's the pieces of the 

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-30 21:27

Message:
Logged In: YES 
user_id=38388

The problem is not the data in the file, but the fact that
your filename is probably a Unicode object which fails to
concatenate with the header (which clearly isn't ASCII :-).

I have no idea whether ZIP files support anything other than
ASCII filenames. If you have a reference, please let us know.

If your filename only contains ASCII characters, you should
be able to open the file correctly by first encoding the
filename to ASCII: filename.encode('ascii').
Perhaps zipfile.py should do that for you ?!


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 20:39

Message:
Logged In: YES 
user_id=593130

Your report ends with 'here's the pieces of the'.  Was something 
cut off?  If you meant to attach a file, try again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 21:37:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 21:37:55 2005
Subject: [ python-Bugs-1168427 ] Possible windows+python bug
Message-ID: <E1DGj0i-0004CB-6x@sc8-sf-web4.sourceforge.net>

Bugs item #1168427, was opened at 2005-03-22 10:38
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:37

Message:
Logged In: YES 
user_id=593130

Do you get the same problem with either of the current releases 
(2.3.5 and/or 2.4.1)?

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2005-03-23 21:18

Message:
Logged In: YES 
user_id=699438

Running your reproducable on XP SP2 (with real IP) returns
"socket.error: (10022, 'Invalid argument')" for me without a
hard crash.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 22:41:38 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 22:41:40 2005
Subject: [ python-Bugs-1172581 ] "cmp" should be "key" in sort doc
Message-ID: <E1DGk0Q-0007WE-5v@sc8-sf-web1.sourceforge.net>

Bugs item #1172581, was opened at 2005-03-29 10:02
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:03

Message:
Logged In: YES 
user_id=593130

Ignore previous comment about 'old url'.  Did not 
notice 'www.python' versus 'doc.python'.  It seems 
that 'www.python.org/doc/current' and 'docs.python.org' are 
aliased prefixes leading to the 'current' docs.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 12:41

Message:
Logged In: YES 
user_id=593130

This has been fixed in the 2.4.1 doc released today
http://docs.python.org/lib/typesseq-mutable.html

(The old url with  /doc/current added no longer works for me).

Please close as 'fixed' if you can.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 22:46:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 22:46:05 2005
Subject: [ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'
Message-ID: <E1DGk4g-0007KF-O4@sc8-sf-web4.sourceforge.net>

Bugs item #1173407, was opened at 2005-03-30 10:42
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 15:46

Message:
Logged In: YES 
user_id=80475

Sorry.  Am closing this to eliminate noise from the tracker.
 The grammar nit arguable and inconsequential (because it is
not in the main documentation and is readable as-ias).

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 23:01:46 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 23:01:48 2005
Subject: [ python-Bugs-1168135 ] Python 2.5a0 Tutorial errors and
	observations
Message-ID: <E1DGkJu-00074W-Ba@sc8-sf-web2.sourceforge.net>

Bugs item #1168135, was opened at 2005-03-22 01:58
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael R Bax (mrbax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5a0 Tutorial errors and observations

Initial Comment:
Please find attached my updated list of errors and 
observations in response to Python 2.5a0.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 16:01

Message:
Logged In: YES 
user_id=593130

Subject to reading that particular version (.5a0), I generally 
agree with your suggestions.  Here are some specific comments 
on your comments.  Feel free to incorporate them into a revised 
suggestion list if you wish.

-----------
Your first correction is wrong.  -ly adverbs are never hyphenated 
(Chicago Manual of Style, Table 6.1, for instance).

-----------
3.1.2
>>> word[:1] = 'Splat'
	-- This is trying to assign 5 letters to one?

Slice assignment is replacement, not overwriting.  This is 
replacing 1 byte with 5, which *is* valid, and perhaps the point 
being made.  Perhaps you would recommend another change to 
be clearer?

-----------
##5.1.3
##Combining these two special cases, we see that "map(None, 
list1, list2)" is a convenient way of turning a pair of lists into a list 
of pairs
#	-- Shouldn't one rather use zip()?

I would agree that 'convenient' should be removed and a note 
added that this has been superceded by zip unless one wants 
the different behavior of extending shorter sequences.

----------
5.1.3
filter(function, sequence)" returns a sequence (of the same type, 
if possible)
	-- How could this ever be impossible?

I suppose a broken class, but then what would filter do?  If 
filter 'works' for all builtins, I agree that we should just say so.  
Perhaps 'returns a sequence of the same type (for all builtins 
and sensible user classes)' -- if that is true

--------
5.2
There is a way to remove an item from a list given its index 
instead of its value: the del statement. 
	-- How is this different to pop?

pop, builtin on top of del, also saves and returns the deleted value 
so it can be bound to something, which takes longer.  ie
def pop(self, i):
  ret = self[i]
  del self[i]
  return ret

----------------------------
5.3
Sequence unpacking requires that the list of variables on the left 
have the same number of elements as the length of the sequence
	-- requires that the list of variables on the left has 
(grammar)
	-- requires the list of variables on the left to have 
(alternate)

Since the code sequence on the left is not a Python list but only 
a common-meaning list, I think even better would be
"Sequence unpacking requires that the number of variables on 
the left be the same as the length of the sequence on the right"

------------------
5.7
Comparisons may be combined by the Boolean operators and 
and or
	-- combined using the (style)

In general, the return value of a short-circuit operator, when 
used as a general value and not as a Boolean, is the last 
evaluated argument. 
	-- rewrite: When used as a general value and not as a 
Boolean, the return value of a short-circuit operator is the last 
evaluated argument.

I would personally be a bit more radical here.  As has been said 
often on c.l.p in response to newby misconceptions about 'and' 
and 'or', they are not operators, in the sense of syntactically 
abbreviating function calls, but flow-control keywords 
abbreviating if-else constructs.  Saying so in the tutorial 
might 'short-circuit' some of the misconceptions.

-------------
9
a derived class can override any methods of its base class or 
classes, a method can call the method of a base class with the 
same name.
	-- classes, and a method (last phrase in a list)

There are no special constructors or destructors.
	-- What about __init__, or is that a "normal" 
constructor?

The special method __new__ constructs (and initializes 
immutables) (so why isn't it a 'special constructor'?), __init__ 
initializes,  But as I remember, the quoted sentence does seem 
confusing.

---------------
9.2
Otherwise, all variables found outside of the innermost scope are 
read-only.
	-- Explain what happens when you try to assign to a 
read-only variable?

You create a new local of the same name and will not be able to 
read the masked variable.

------------
9.8
raise Class, instance
	-- What's the point?  In the example thereafter, these 
three have the same effect:
		raise c()
		raise B, c()

raise instance
	-- wasn't this "new form" covered in 8.5 (raise MyClass
(2*2))?

I personally agree that the tutorial should emphasize the newest 
form (raise instance) and only mention back-compatible forms in 
passing.

...
- What is an example of an exception that is NOT a class?

Last I knew, strings are still legal, though deprecated.

-------------
9.11
sum(i*i for i in range(10))
	-- Why does this work?! 

because generator expressions require their own parentheses 
*unless* already directly enclosed by function-call parens.  I 
agree that this nice quirk should be explained,

-------------
B.1
...
>>> 7205759403792794L * 10L**30 / 2L**56
	-- The "L" extension does not appear to be necessary 
for the input -- why is it used?

Used to be needed before int-long unification.  I agree that 
tutorial should be updated to future-oriented present.

----------
C
The socket module uses the functions, getaddrinfo, and 
getnameinfo
	-- remove comma after "functions" [grammar]

and after getaddrinfo

-------------





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 23:08:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 23:08:55 2005
Subject: [ python-Bugs-1168135 ] Python 2.5a0 Tutorial errors and
	observations
Message-ID: <E1DGkQn-0008NP-7P@sc8-sf-web4.sourceforge.net>

Bugs item #1168135, was opened at 2005-03-22 01:58
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael R Bax (mrbax)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Python 2.5a0 Tutorial errors and observations

Initial Comment:
Please find attached my updated list of errors and 
observations in response to Python 2.5a0.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 16:01

Message:
Logged In: YES 
user_id=593130

Subject to reading that particular version (.5a0), I generally 
agree with your suggestions.  Here are some specific comments 
on your comments.  Feel free to incorporate them into a revised 
suggestion list if you wish.

-----------
Your first correction is wrong.  -ly adverbs are never hyphenated 
(Chicago Manual of Style, Table 6.1, for instance).

-----------
3.1.2
>>> word[:1] = 'Splat'
	-- This is trying to assign 5 letters to one?

Slice assignment is replacement, not overwriting.  This is 
replacing 1 byte with 5, which *is* valid, and perhaps the point 
being made.  Perhaps you would recommend another change to 
be clearer?

-----------
##5.1.3
##Combining these two special cases, we see that "map(None, 
list1, list2)" is a convenient way of turning a pair of lists into a list 
of pairs
#	-- Shouldn't one rather use zip()?

I would agree that 'convenient' should be removed and a note 
added that this has been superceded by zip unless one wants 
the different behavior of extending shorter sequences.

----------
5.1.3
filter(function, sequence)" returns a sequence (of the same type, 
if possible)
	-- How could this ever be impossible?

I suppose a broken class, but then what would filter do?  If 
filter 'works' for all builtins, I agree that we should just say so.  
Perhaps 'returns a sequence of the same type (for all builtins 
and sensible user classes)' -- if that is true

--------
5.2
There is a way to remove an item from a list given its index 
instead of its value: the del statement. 
	-- How is this different to pop?

pop, builtin on top of del, also saves and returns the deleted value 
so it can be bound to something, which takes longer.  ie
def pop(self, i):
  ret = self[i]
  del self[i]
  return ret

----------------------------
5.3
Sequence unpacking requires that the list of variables on the left 
have the same number of elements as the length of the sequence
	-- requires that the list of variables on the left has 
(grammar)
	-- requires the list of variables on the left to have 
(alternate)

Since the code sequence on the left is not a Python list but only 
a common-meaning list, I think even better would be
"Sequence unpacking requires that the number of variables on 
the left be the same as the length of the sequence on the right"

------------------
5.7
Comparisons may be combined by the Boolean operators and 
and or
	-- combined using the (style)

In general, the return value of a short-circuit operator, when 
used as a general value and not as a Boolean, is the last 
evaluated argument. 
	-- rewrite: When used as a general value and not as a 
Boolean, the return value of a short-circuit operator is the last 
evaluated argument.

I would personally be a bit more radical here.  As has been said 
often on c.l.p in response to newby misconceptions about 'and' 
and 'or', they are not operators, in the sense of syntactically 
abbreviating function calls, but flow-control keywords 
abbreviating if-else constructs.  Saying so in the tutorial 
might 'short-circuit' some of the misconceptions.

-------------
9
a derived class can override any methods of its base class or 
classes, a method can call the method of a base class with the 
same name.
	-- classes, and a method (last phrase in a list)

There are no special constructors or destructors.
	-- What about __init__, or is that a "normal" 
constructor?

The special method __new__ constructs (and initializes 
immutables) (so why isn't it a 'special constructor'?), __init__ 
initializes,  But as I remember, the quoted sentence does seem 
confusing.

---------------
9.2
Otherwise, all variables found outside of the innermost scope are 
read-only.
	-- Explain what happens when you try to assign to a 
read-only variable?

You create a new local of the same name and will not be able to 
read the masked variable.

------------
9.8
raise Class, instance
	-- What's the point?  In the example thereafter, these 
three have the same effect:
		raise c()
		raise B, c()

raise instance
	-- wasn't this "new form" covered in 8.5 (raise MyClass
(2*2))?

I personally agree that the tutorial should emphasize the newest 
form (raise instance) and only mention back-compatible forms in 
passing.

...
- What is an example of an exception that is NOT a class?

Last I knew, strings are still legal, though deprecated.

-------------
9.11
sum(i*i for i in range(10))
	-- Why does this work?! 

because generator expressions require their own parentheses 
*unless* already directly enclosed by function-call parens.  I 
agree that this nice quirk should be explained,

-------------
B.1
...
>>> 7205759403792794L * 10L**30 / 2L**56
	-- The "L" extension does not appear to be necessary 
for the input -- why is it used?

Used to be needed before int-long unification.  I agree that 
tutorial should be updated to future-oriented present.

----------
C
The socket module uses the functions, getaddrinfo, and 
getnameinfo
	-- remove comma after "functions" [grammar]

and after getaddrinfo

-------------





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 23:11:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 23:11:10 2005
Subject: [ python-Bugs-1167300 ] Error "exec"ing python code
Message-ID: <E1DGkSx-0000U2-4u@sc8-sf-web1.sourceforge.net>

Bugs item #1167300, was opened at 2005-03-21 00:35
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error "exec"ing python code

Initial Comment:
I'm trying to 'exec'ing the following code:

class Foo: pass
class Bar:
    f = Foo
    
The error appears when using 'exec f in {}, {}':

>>> f = ''.join(open('/home/stefan/t.py').readlines())
>>> exec f in {}, {}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 2, in ?
  File "<string>", line 3, in Bar
NameError: name 'Foo' is not defined

I tested on python 2.3 and python 2.4, both show the same
behavior.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 16:11

Message:
Logged In: YES 
user_id=593130

I got a similar NameError in 2.2.1, so this is not due to a recent 
change.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2005-03-30 07:40

Message:
Logged In: YES 
user_id=99874

I can confirm this... it appears that things which are set
in the global scope within an "exec ... in {}, {}" are not
then correctly accessed in the global scope when being read.
The following two examples illustrate the problem:

>>> exec """... x = 3
... def f():
...     global x
...     print x
... f()
... """ in {}, {}
3

... and again without the global definition:

>>> exec """... x = 3
... def f():
...     print x
... f()
... """ in {}, {}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 4, in ?
  File "<string>", line 3, in f
NameError: global name 'x' is not defined

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 23:12:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 23:12:10 2005
Subject: [ python-Bugs-1170766 ] weakref.proxy incorrect behaviour
Message-ID: <E1DGkTv-0002qu-GD@sc8-sf-web3.sourceforge.net>

Bugs item #1170766, was opened at 2005-03-25 16:54
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-03-29 08:39

Message:
Logged In: YES 
user_id=6656

Also see bug #1075356 (which is very minor, but might as
well get fixed at the same time).

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-29 08:23

Message:
Logged In: YES 
user_id=4771

The following type slots appear to be missing in the proxy types:

* nb_(inplace_){floor,true}_divide
* sq_repeat, sq_concat, sq_item, sq_ass_item, sq_inplace_concat, sq_inplace_repeat (which are needed for operator.repeat(), operator.concat(), etc. to work)
* tp_as_buffer
* tp_richcompare (tp_compare alone is not enough)
* tp_descr_get, tp_descr_set (for proxies to descriptors...)
* nb_coerce (though it seems that only an explicit call to coerce() can show that this is missing; implicit coercion is done correctly in other operators)
* nb_oct, nb_hex

As far as I can tell, there is no existing operator that is broken in the same way that nb_nonzero was.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-27 06:17

Message:
Logged In: YES 
user_id=80475

Fixed the __nonzero__ problem for Py2.5 and will backport to
Py2.4.  See Objects/weakrefobject.c 1.21.

Leaviing this report open until the rest of the module can
be checked and fixed.



----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-03-26 09:50

Message:
Logged In: YES 
user_id=4771

The bug is in weakrefobject:proxy_nonzero(), which calls the underlying object's nb_nonzero slot instead of going through the general PyObject_IsTrue() mecanism.  Built-in types like list and dict don't have a nb_nonzero slot.

As a related bug, (Callable)ProxyType should implement tp_richcompare in addition to tp_compare.  In fact, we should review the code to check if ProxyType knows about the most recent type slots...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 23:15:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 23:15:18 2005
Subject: [ python-Bugs-1168427 ] Possible windows+python bug
Message-ID: <E1DGkWy-0002yy-3g@sc8-sf-web3.sourceforge.net>

Bugs item #1168427, was opened at 2005-03-22 16:38
Message generated for change (Comment added) made by holo9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


----------------------------------------------------------------------

>Comment By: holo9 (holo9)
Date: 2005-03-30 23:15

Message:
Logged In: YES 
user_id=1244385

I tested this on Python 2.3.4. But there is no problem in 
Python. This bug could be reproduced in C, for example. The 
main problem is in Windows built-in firewall. For explanation 
take a look at:

http://seclist.org/lists/bugtraq/2005/Mar/0409.html

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 21:37

Message:
Logged In: YES 
user_id=593130

Do you get the same problem with either of the current releases 
(2.3.5 and/or 2.4.1)?

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2005-03-24 03:18

Message:
Logged In: YES 
user_id=699438

Running your reproducable on XP SP2 (with real IP) returns
"socket.error: (10022, 'Invalid argument')" for me without a
hard crash.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 23:37:00 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 23:37:02 2005
Subject: [ python-Bugs-1173637 ] quit should quit
Message-ID: <E1DGks0-0003vM-Qs@sc8-sf-web3.sourceforge.net>

Bugs item #1173637, was opened at 2005-03-30 16:37
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=1173637&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Chaput (mchaput)
Assigned to: Nobody/Anonymous (nobody)
Summary: quit should quit

Initial Comment:
When the user types "quit" in the interpreter, instead
of quitting the program gives him or her a lecture on
the "proper" way to quit.

This is very obnoxious.

Since the interpreter obviously understands the "quit"
command, it should just quit, dammit.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470
From noreply at sourceforge.net  Wed Mar 30 23:51:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 30 23:51:53 2005
Subject: [ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'
Message-ID: <E1DGl6M-0004Vy-SC@sc8-sf-web3.sourceforge.net>

Bugs item #1173407, was opened at 2005-03-30 15:42
Message generated for change (Comment added) made by gyrof
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

----------------------------------------------------------------------

>Comment By: gyrof (gyrof)
Date: 2005-03-30 21:51

Message:
Logged In: YES 
user_id=1249584

It is a very minor issue, but the change is not arguable
from the perspective of correct English grammar.

If I submit a diff, will it (eventually) be reviewed or applied?

-gyro

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 20:46

Message:
Logged In: YES 
user_id=80475

Sorry.  Am closing this to eliminate noise from the tracker.
 The grammar nit arguable and inconsequential (because it is
not in the main documentation and is readable as-ias).

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 19:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
From noreply at sourceforge.net  Thu Mar 31 00:01:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 31 00:01:58 2005
Subject: [ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'
Message-ID: <E1DGlG5-0004uo-30@sc8-sf-web3.sourceforge.net>

Bugs item #1173407, was opened at 2005-03-30 10: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=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-03-30 17:01

Message:
Logged In: YES 
user_id=31435

I mentally replaced "data is" by "data are", and disliked how 
it read then.  So, no, I won't apply such a patch.  English 
grammar changes over time to match what careful English 
speakers actually use, so I'll view this is a crusade to stamp 
out effete elitism -- "data are" my ass <wink>.

----------------------------------------------------------------------

Comment By: gyrof (gyrof)
Date: 2005-03-30 16:51

Message:
Logged In: YES 
user_id=1249584

It is a very minor issue, but the change is not arguable
from the perspective of correct English grammar.

If I submit a diff, will it (eventually) be reviewed or applied?

-gyro

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 15:46

Message:
Logged In: YES 
user_id=80475

Sorry.  Am closing this to eliminate noise from the tracker.
 The grammar nit arguable and inconsequential (because it is
not in the main documentation and is readable as-ias).

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
From noreply at sourceforge.net  Thu Mar 31 00:11:25 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 31 00:11:27 2005
Subject: [ python-Bugs-1173637 ] quit should quit
Message-ID: <E1DGlPJ-0005Mt-4p@sc8-sf-web3.sourceforge.net>

Bugs item #1173637, was opened at 2005-03-30 16:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Chaput (mchaput)
Assigned to: Nobody/Anonymous (nobody)
Summary: quit should quit

Initial Comment:
When the user types "quit" in the interpreter, instead
of quitting the program gives him or her a lecture on
the "proper" way to quit.

This is very obnoxious.

Since the interpreter obviously understands the "quit"
command, it should just quit, dammit.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 17:11

Message:
Logged In: YES 
user_id=80475

I concur!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470
From noreply at sourceforge.net  Thu Mar 31 00:24:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 31 00:24:14 2005
Subject: [ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'
Message-ID: <E1DGlbh-0005se-19@sc8-sf-web3.sourceforge.net>

Bugs item #1173407, was opened at 2005-03-30 15:42
Message generated for change (Comment added) made by gyrof
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

----------------------------------------------------------------------

>Comment By: gyrof (gyrof)
Date: 2005-03-30 22:24

Message:
Logged In: YES 
user_id=1249584

Fair enough. I should have known that Mr. Peters would have
considered this already. 

Just-trying-to-make-Python-docs-more-appealing-to-pedants-like-me'ly
yours,
gyro

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-03-30 22:01

Message:
Logged In: YES 
user_id=31435

I mentally replaced "data is" by "data are", and disliked how 
it read then.  So, no, I won't apply such a patch.  English 
grammar changes over time to match what careful English 
speakers actually use, so I'll view this is a crusade to stamp 
out effete elitism -- "data are" my ass <wink>.

----------------------------------------------------------------------

Comment By: gyrof (gyrof)
Date: 2005-03-30 21:51

Message:
Logged In: YES 
user_id=1249584

It is a very minor issue, but the change is not arguable
from the perspective of correct English grammar.

If I submit a diff, will it (eventually) be reviewed or applied?

-gyro

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 20:46

Message:
Logged In: YES 
user_id=80475

Sorry.  Am closing this to eliminate noise from the tracker.
 The grammar nit arguable and inconsequential (because it is
not in the main documentation and is readable as-ias).

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 19:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
From noreply at sourceforge.net  Thu Mar 31 04:04:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 31 04:04:09 2005
Subject: [ python-Bugs-1168427 ] Possible windows+python bug
Message-ID: <E1DGp2U-0001fd-UJ@sc8-sf-web2.sourceforge.net>

Bugs item #1168427, was opened at 2005-03-22 10:38
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 21:04

Message:
Logged In: YES 
user_id=593130

If there is no problem in Python itself, then perhaps you could 
close this.

----------------------------------------------------------------------

Comment By: holo9 (holo9)
Date: 2005-03-30 16:15

Message:
Logged In: YES 
user_id=1244385

I tested this on Python 2.3.4. But there is no problem in 
Python. This bug could be reproduced in C, for example. The 
main problem is in Windows built-in firewall. For explanation 
take a look at:

http://seclist.org/lists/bugtraq/2005/Mar/0409.html

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:37

Message:
Logged In: YES 
user_id=593130

Do you get the same problem with either of the current releases 
(2.3.5 and/or 2.4.1)?

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2005-03-23 21:18

Message:
Logged In: YES 
user_id=699438

Running your reproducable on XP SP2 (with real IP) returns
"socket.error: (10022, 'Invalid argument')" for me without a
hard crash.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
From noreply at sourceforge.net  Thu Mar 31 04:19:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 31 04:19:16 2005
Subject: [ python-Bugs-1173773 ] multiple broken links in profiler docs
Message-ID: <E1DGpH7-00045X-5h@sc8-sf-web1.sourceforge.net>

Bugs item #1173773, was opened at 2005-03-30 18:19
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=1173773&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: multiple broken links in profiler docs

Initial Comment:
I'm looking at  
http://www.python.org/doc/current/lib/lib.html

and multiple links in profiler section seem to be broken:

10.1 Introduction...  (Error 404)
http://www.python.org/doc/current/lib/node434.html

10.2 How is this profiler different: (Error 404)
http://www.python.org/doc/current/lib/node435.html
 
10.3. What's is deterministic... (leads to wrong page)
http://www.python.org/doc/current/lib/node437.html

10.8 Extensions... (Error 404)
http://www.python.org/doc/current/lib/node442.html

10.10.1 Command Line Interface (leads to wrong page)
http://www.python.org/doc/current/lib/node448.html

10.10.2  Examples (Error 404)
http://www.python.org/doc/current/lib/node449.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173773&group_id=5470
From noreply at sourceforge.net  Thu Mar 31 05:51:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 31 05:51:48 2005
Subject: [ python-Bugs-1170311 ] zipfile UnicodeDecodeError
Message-ID: <E1DGqif-0004vx-Lb@sc8-sf-web2.sourceforge.net>

Bugs item #1170311, was opened at 2005-03-25 02:51
Message generated for change (Comment added) made by adamx97
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: adam davis (adamx97)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile UnicodeDecodeError

Initial Comment:
I think this is the same as #  705295, which may have
been prematurely closed.

I think the error is dependent on the data or time.

File "C:\Python24\lib\zipfile.py", line 166, in FileHeader
    return header + self.filename + self.extra
UnicodeDecodeError: 'ascii' codec can't decode byte
0xd0 in position 10: ordinal not in range(128)

The header is packed like this:
        header = struct.pack(structFileHeader,
stringFileHeader,
                 self.extract_version, self.reserved,
self.flag_bits,
                 self.compress_type, dostime, dosdate, CRC,
                 compress_size, file_size,
                 len(self.filename), len(self.extra))

the header is:

[Dbg]>>> header
'PK\x03\x04\x14\x00\x00\x00\x00\x00\xd0\xa9x2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00-\x00\x00\x00'

and here are the parts that made it up:

[Dbg]>>> structFileHeader, stringFileHeader,
self.extract_version, self.reserved,
self.flag_bits,self.compress_type, dostime, dosdate,
CRC, compress_size, file_size, len(self.filename),
len(self.extra)
('<4s2B4HlLL2H', 'PK\x03\x04', 20, 0, 0, 0, 43472,
12920, 0, 0, 0, 45, 0)


here's the pieces of the 

----------------------------------------------------------------------

>Comment By: adam davis (adamx97)
Date: 2005-03-31 03:51

Message:
Logged In: YES 
user_id=175166

The "here's the pieces of the" was an accident, you can
ignore it.

My filename was pure ascii, something like
"myemail@test.com.crt"

It seems to me the problem is that the header isn't
decodable.  0xd0 is  208, which is > 128.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-30 19:27

Message:
Logged In: YES 
user_id=38388

The problem is not the data in the file, but the fact that
your filename is probably a Unicode object which fails to
concatenate with the header (which clearly isn't ASCII :-).

I have no idea whether ZIP files support anything other than
ASCII filenames. If you have a reference, please let us know.

If your filename only contains ASCII characters, you should
be able to open the file correctly by first encoding the
filename to ASCII: filename.encode('ascii').
Perhaps zipfile.py should do that for you ?!


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 18:39

Message:
Logged In: YES 
user_id=593130

Your report ends with 'here's the pieces of the'.  Was something 
cut off?  If you meant to attach a file, try again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470
From noreply at sourceforge.net  Thu Mar 31 05:54:18 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 31 05:54:20 2005
Subject: [ python-Bugs-1168427 ] Possible windows+python bug
Message-ID: <E1DGql8-0000QL-HB@sc8-sf-web3.sourceforge.net>

Bugs item #1168427, was opened at 2005-03-22 16:38
Message generated for change (Settings changed) made by holo9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470

Category: Windows
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-31 04:04

Message:
Logged In: YES 
user_id=593130

If there is no problem in Python itself, then perhaps you could 
close this.

----------------------------------------------------------------------

Comment By: holo9 (holo9)
Date: 2005-03-30 23:15

Message:
Logged In: YES 
user_id=1244385

I tested this on Python 2.3.4. But there is no problem in 
Python. This bug could be reproduced in C, for example. The 
main problem is in Windows built-in firewall. For explanation 
take a look at:

http://seclist.org/lists/bugtraq/2005/Mar/0409.html

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 21:37

Message:
Logged In: YES 
user_id=593130

Do you get the same problem with either of the current releases 
(2.3.5 and/or 2.4.1)?

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2005-03-24 03:18

Message:
Logged In: YES 
user_id=699438

Running your reproducable on XP SP2 (with real IP) returns
"socket.error: (10022, 'Invalid argument')" for me without a
hard crash.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
From noreply at sourceforge.net  Thu Mar 31 08:24:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 31 08:24:19 2005
Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode
Message-ID: <E1DGt6F-00061J-DI@sc8-sf-web3.sourceforge.net>

Bugs item #1163563, was opened at 2005-03-15 03:56
Message generated for change (Comment added) made by goatpunch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: anothermax (yetanothermax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sub threads execute in restricted mode

Initial Comment:
I'm using the JEP product which allows integration
of Java with Python (see http://jepp.sourceforge.net) via
starting a Python interpreter in the same process as the 
JVM.
This integrates with python via the C interface, allowing 
the user to 'eval' python code (amongst other features).

It seems that since Python 2.3.5 any threads (using the 
threading module) created via code that has been 
evaluated through the jep.eval() interface (i.e.Python C 
interface )are executed in restricted mode and cannot, 
for example, create files. Code that is just evaled (i.e not 
in a subthread) thread has no restrictions.

The error reported is:
IOError: file() constructor not accessible in restricted 
mode

(see http://sourceforge.net/forum/forum.php?
thread_id=1247793&forum_id=376782) - I've given a JEP 
specific example here.

There seems to be a similar problem with mod_python
(see 
http://www.modpython.org/pipermail/mod_python/2005-
January/017129.html)

Reading through the release notes for Python 2.3.5
I see:
 Bug #754449: threading.Thread will no longer mask 
exceptions raised during interpreter shutdown with 
another exception caused by attempting to output the 
initial exception. This fix also includes a backport of rev. 
1.41 from HEAD. 

This might be the problem as it seems to involve the 
porting of 2.4 threading code back to the 2.3 tree.

I've attached a Java file which shows the problem when 
using JEP.
The error output is:
Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\Lib\threading.py", line 442, in 
__bootstrap
  File "<string>", line 5, in run
IOError: file() constructor not accessible in restricted 
mode

2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 
bit (Intel)]
Creating file from main thread...
Done
Creating file from sub thread...
Done


----------------------------------------------------------------------

Comment By: Alan Davies (goatpunch)
Date: 2005-03-31 01:24

Message:
Logged In: YES 
user_id=967140

The same problem definately does occur with mod_python, 
I've found it to occur with Python 2.3.5 and 2.4 on Win32:

http://www.modpython.org/pipermail/mod_python/2005-
March/017802.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470
From noreply at sourceforge.net  Thu Mar 31 11:49:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 31 11:49:26 2005
Subject: [ python-Bugs-1173637 ] quit should quit
Message-ID: <E1DGwIl-0003aX-OT@sc8-sf-web2.sourceforge.net>

Bugs item #1173637, was opened at 2005-03-30 22:37
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Chaput (mchaput)
Assigned to: Nobody/Anonymous (nobody)
Summary: quit should quit

Initial Comment:
When the user types "quit" in the interpreter, instead
of quitting the program gives him or her a lecture on
the "proper" way to quit.

This is very obnoxious.

Since the interpreter obviously understands the "quit"
command, it should just quit, dammit.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2005-03-31 10:49

Message:
Logged In: YES 
user_id=6656

I'm not so sure typing quit should quit -- that doesn't seem like Python to 
me (how would you implement it?)

Having quit be the same object as sys.exit seems sensible.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 23:11

Message:
Logged In: YES 
user_id=80475

I concur!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470