From noreply@sourceforge.net  Sun Jun  1 06:21:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 31 May 2003 22:21:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete
Message-ID: <E19MLHy-0006aC-00@sc8-sf-web2.sourceforge.net>

Bugs item #742911, was opened at 2003-05-24 18:29
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Memory fault on complex weakref/weakkeydict delete

Initial Comment:
Attached find two modules which together form a
test-case.  The cache.py file is ripped out of a
production system (OpenGLContext), and I am seeing
memory faults under both Python 2.2.2 and 2.2.3 when I
run the code.  Under 2.2.2 while single-stepping
through the code I was able to provoke an error-message:

Fatal Python error: GC object already in linked list

The error message doesn't show up under 2.2.3, but the
memory-fault does.

Modules here don't use any extension modules, so there
shouldn't be any loose memory references or the like. 
Note, you'll likely need to make weakkeydictionary's
__delitem__ use keys instead of iterkeys to even get to
the crashing.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-01 01:21

Message:
Logged In: YES 
user_id=31435

Which service pack <wink>?  Thanks for reporting this in 
time for 2.2.3, Mike.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-05-31 15:21

Message:
Logged In: YES 
user_id=34901

2.2.3 fixes the original problem on Win2k.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-29 17:35

Message:
Logged In: YES 
user_id=33168

2.3 works for me with the original, but didn't before. 
Redhat 9.

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

Comment By: Jeff Epler (jepler)
Date: 2003-05-29 16:47

Message:
Logged In: YES 
user_id=2772

Just one question: does the final test-case cover the
original bug?  I have a redhat 9 system with Python 2.2.2,
and temp2.py runs just fine:
$ python2 temp2.py 
<__main__.Oops object at 0x8162ecc>
$

The Python version is:
Python 2.2.2 (#1, Feb 24 2003, 19:13:11) 
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2

I have not tried any other version of the test-case.  I also
didn't try a non-redhat version, so it's barely possible
that some patch they apply affected this issue.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-29 10:53

Message:
Logged In: YES 
user_id=31435

Just changed Resolution to Fixed.  Thanks everyone!

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-29 10:35

Message:
Logged In: YES 
user_id=6380

Thanks to Tim for the analysis, to Neal for the simplified
test, and to Mike for the bug report! The fix was actually
simple: clear the weak ref list *before* calling __del__ or
clearing __dict__. This is the same order as used by classic
classes, so can't be wrong. Applied to 2.2.3 branch and 2.3
trunk, with test case.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-05-28 21:16

Message:
Logged In: YES 
user_id=34901

To give timeline: This is from real-life code (PyOpenGL's
OpenGLContext demo/teaching module).  It's currently about
to go beta, with a release date target of end-of-summer. 
I've worked around the problem for the most common case w/in
the system (exiting from the VRML browser), but that
work-around's not usable for end-user long-running projects
until the users can deallocate the scenegraph to load
another (i.e. go from world to world within a single run of
the application).

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-28 19:26

Message:
Logged In: YES 
user_id=31435

That's cool.  The analysis is much easier to follow if you run 
Neal's little program, which crashes right away in a debug 
build.  Then the analysis just follows the call stack, and it's 
instantly obvious (if you know to look for it <wink>) that 
we're trying to deallocate a single object twice.

One thing subtype_delloc does that instance_dealloc 
doesn't is clear the instance dict before clearing the 
weakrefs.  Clearing the instance dict can end up executing 
anything, and in this case does, in particular materializing a 
strong reference to the object we're in the middle of 
deallocating (via a weakref that hasn't been cleared).  That 
seems to be the key point.

Mike found the problem in 2.2.2, I believe in his real-life 
OpenGL code.  That's why I'm keen to see it fixed for 2.2.3.

I'll be in the office Thursday, BTW.

Ah, here, I'll attach a simpler program that has the same 
kind of problem (temp2.py).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-28 18:16

Message:
Logged In: YES 
user_id=6380

Tim, let's look at this when you're back in the office. My
head spins from just reading the analysis below.

Note that this is a 2.2 and 2.3 bug. I don't necessarily
want to hold up the 2.2.3 release until this is fixed,
unless we have a quick breakthrough.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-25 00:49

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I suspect the problem lies in 
the order subtype_dealloc does things.

With reference to Neal's whittled-down case:  when 
makeSome() ends, we decref i and then decref item.  item's 
refcount hits 0 then.  There's a weakref remaining to item 
(in CacheHolder.client), but subtype_dealloc doesn't clear 
the weakref at this point.  First it clears item's instance 
dict.  That contains the last strong reference to i.  
subtype_dealloc is inovked again, and clears i's instance 
dict, and then deals with the weak reference to i.  The 
weakref to i has a callback associated with it, and 
CacheHolder.__call__() is invoked.  That invokes self.client
(), still a weakref to item, and because item's weakrefs still 
haven't been dealt with, self.client() returns item.

Now we're hosed.  item *had* a refcount of 0 at this point, 
and is still in the process of getting cleaned out by the first 
call to subtype_dealloc (it still thinks it's clearing item's 
instance dict).  We already called _Py_ForgetReference on 
item when its refcount fell to 0.  Its refcount gets boosted 
back to 1 by virtue of item getting returned by the 
self.client() weakref call.  Cleaning out the frame for 
CacheHolder.__call__() knocks the refcount down to 0 
again, and the second attempt to call _Py_ForgetReference 
on it blows up.

In a release build, nothing visibly bad happens when I try 
it.  It crashes if I add

        print client.items

at the end of __call__ in a release-build run, though.  Looks 
like that's just the luck of the draw after things have gone 
insane.

I note that instance_dealloc deals with weakrefs much 
earlier in the process, so that when Neal makes Items a 
classic class instead, the eventual call to self.client() 
returns None (instead of items), and nothing bad happens.. 

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-24 22:53

Message:
Logged In: YES 
user_id=31435

Outstanding, Neal -- thanks!  I can confirm that this crashes 
in a current 2.3 debug build on Windows too.  I'm feeling 
sick and won't pursue it now, though.  When cleaning up 
from the call to makeSome() (the body of makeSome() has 
completed, and we're cleaning up its execution frame, 
decref'ing the locals), we're dying in _Py_ForgetReference 
with a NULL-pointer derefernce.  The refcount on an Items 
object has just fallen to 0, and the code is trying to verify 
that the object is in the debug-build "list of all objects".  But 
its prev and next pointers are both NULL -- it's not in the 
list, and simply trying to check that it is blows up.

I don't have a theory for what's causing this, but it's 
probably not a good thing <heh>.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-24 19:31

Message:
Logged In: YES 
user_id=33168

I cut out a lot of stuff from the test.  The new file is
much more minimal, but still crashes for me in a 2.3 debug
build.  You only need the one file too (not both files).

There is an issue with new style classes.  If Items doesn't
derive from object, I don't get a crash.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470


From noreply@sourceforge.net  Sun Jun  1 07:21:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 31 May 2003 23:21:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-746895 ] socket.sendto(SOCK_DGRAM) very slow on OSX!
Message-ID: <E19MMEB-0007EG-00@sc8-sf-web4.sourceforge.net>

Bugs item #746895, was opened at 2003-06-01 02: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=746895&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Kangas (mkangas)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.sendto(SOCK_DGRAM) very slow on OSX!

Initial Comment:
I'm trying to send UDP packets using socket.sendto().
With Python 2.2 on Linux, this works like a champ. On
Mac OS X, something's terribly wrong.

Time to send 100 UDP packets using test code + Python
2.2.1:
- Linux 2.4.18 (RedHat 8): 0.009 sec
- MacOS X 10.2.6: > 1 sec, sometimes > 2 sec.

I've tried the following Python builds on OS X, all
with the same results:
- Stock 2.2 build that comes with OS X 10.2
- 2.2.1 provided by Fink
- built-from-scratch 2.2.3: "./configure; make"

provided are sample programs in Python and C.
ktrace/kdump seem to indicate that both programs make
the same sequence of syscalls. the C program runs
blazingly fast on OS X, while the Python one seems to
stall on every call to socket.sendto().

why does socket.sendto() perform so poorly on OS X?

----------------- python sample ----------------
 
#
# UDP socket test: how fast can we write?
# (5/2003 kangas)
#
# time to run with python 2.2.1:
# - Linux 2.4.18:     0.009 sec
# - Mac OS x 10.2.6:  1.272 sec (!!!)

import socket, time, sys

PORT = 9999
DEST_ADDR = ("192.168.1.60", PORT)

def run():
    maxcount = 100
    data = "pingme pingme pingme pingme pingme..."
    dest = DEST_ADDR

    print "opening socket"
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    
    print "Sending %i packets" % maxcount
    t0 = time.time()
    for i in xrange(0, maxcount):
        s.sendto(data, dest)
    t1 = time.time() - t0
    print "%0.4f secs elapsed" % t1

    s.close()

if __name__=="__main__":
    run()
    

----------------- C sample ----------------

/*
 * UDP socket test: how fast can we write?
 * (5/2003 kangas)
 *
 * Tested on Mac OS X 10.2.6 and Linux 2.4
 */

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>

static const int MAXCOUNT = 100;
static const char DATA[] = "pingme pingme pingme pingme
pingme...";
    
int main(void) {
    int s, i, err;
    struct sockaddr_in serverAddr;

    bzero(&serverAddr, sizeof(serverAddr));
    serverAddr.sin_family = AF_INET;
    serverAddr.sin_port = htons(9999);
    
    inet_pton(AF_INET, "192.168.1.60",
&serverAddr.sin_addr);
    
    printf("opening socket\n");
    if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
	perror("socket");
	exit(1);
    }

    printf("sending %i packets\n", MAXCOUNT);
    for (i=0; i<MAXCOUNT; i++) {
	err = sendto(s, DATA, strlen(DATA), 0,
		     (struct sockaddr *)&serverAddr, sizeof(serverAddr));
	if (err < 0) {
	    perror("sendto");
	    break;
	}
	printf(".");
     };
    printf("\n");

    printf("closing...\n");
    close(s);
    printf("done!\n");
    return 0;
}


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470


From noreply@sourceforge.net  Sun Jun  1 08:27:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 01 Jun 2003 00:27:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-745320 ] threads broke on FreeBSD current
Message-ID: <E19MNFN-0003WD-00@sc8-sf-web1.sourceforge.net>

Bugs item #745320, was opened at 2003-05-29 13:46
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745320&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Till Plewe (tpx)
Assigned to: Nobody/Anonymous (nobody)
Summary: threads broke on FreeBSD current

Initial Comment:
default configuration builts with the snapshot taken at
05-24-230001 but not with the snapshot from
05-26-230001 (--without-threads builts)

I get the following compiler complaint when trying to
build python_2003-05-26-230001: 

c++  -Wl,--export-dynamic -o python  Modules/python.o 
libpython2.3.a -lutil   -
lm  
libpython2.3.a(posixmodule.o): In function `posix_tmpnam':
Modules/posixmodule.c:5785: warning: tmpnam() possibly
used unsafely; consider u
sing mkstemp()
libpython2.3.a(posixmodule.o): In function `posix_tempnam':
Modules/posixmodule.c:5738: warning: tempnam() possibly
used unsafely; consider 
using mkstemp()
libpython2.3.a(thread.o): In function
`PyThread_start_new_thread':
Python/thread_pthread.h:217: undefined reference to
`pthread_create'
Python/thread_pthread.h:253: undefined reference to
`pthread_detach'
*** Error code 1



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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-01 17:27

Message:
Logged In: YES 
user_id=250749

I think what's missing here is the correct library reference.

I don't have a 5.x box at the moment, so can't check, but as
I recall, there are 2 options at the moment:-
 - libkse;
 - libthr.

Could you check my recollection and try adding the
appropriate library reference to the Makefile to see whether
you get a viable build?

Some autoconf-fu would then be required to make the setting
stick.

As the FreeBSD core team haven't yet designated anything
from the 5.x line as stable, this makes keeping track of the
non-trivial threading changes hard.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745320&group_id=5470


From noreply@sourceforge.net  Sun Jun  1 08:47:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 01 Jun 2003 00:47:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current
Message-ID: <E19MNYt-0000b3-00@sc8-sf-web4.sourceforge.net>

Bugs item #740234, was opened at 2003-05-20 13:50
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Till Plewe (tpx)
Assigned to: Nobody/Anonymous (nobody)
Summary: test/build-failures on FreeBSD stable/current

Initial Comment:
Using snapshot: python_2003-05-19_230000.tar.gz
STABLE (FreeBSD 4.8-STABLE #14: Mon Apr  7)
CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue
May 20)

BUILDFAILURE
curses does not build; neither on CURRENT nor on STABLE
(compiler complaint:

/usr/include/ncurses.h:289: conflicting types for `wchar_t'
/usr/include/stdlib.h:57: previous declaration of `wchar_t'
/usr/include/ncurses.h:292: conflicting types for `wint_t'
/usr/include/wchar.h:96: previous declaration of `wint_t'

if lines /usr/include/ncurses.h:288-293 

#ifndef __wchar_t
typedef unsigned long wchar_t;
#endif /* __wchar_t */
#ifndef __wint_t
typedef long int wint_t;
#endif /* __wint_t */

are deleted then curses builds)

TESTFAILURES
test_re fails on both CURRENT and STABLE
 
test_long
test_pow 
and many more (probably related) tests 

fail on current

See attached file for details


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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-01 17:47

Message:
Logged In: YES 
user_id=250749

Sigh...

Stacksize is indeed the problem with the test_re failure.

In the pthreads case, on FreeBSD prior to 5.x (I have no
info about 5.x, but from what you say it looks the same),
linking to libc_r causes the "initial" thread to get a hard
coded 1MB stack.  The stack size cannot be changed
(currently) without rebuilding libc_r :-(

As all these regression tests are running on the "initial"
thread, by virtue of not having been explicitly started in a
thread.

The problem is worse with gcc 3.x than 2.95, as gcc 3.x (I
tested with 3.2.2) seems to the stack  more aggressively.

I plan to post a patch to _sre.c extending the FreeBSD/gcc
specific #ifdef'ery (which was put in just before 2.3b1, and
was broken again by _sre commits shortly after 2.3b1).

configure --without-threads doesn't have a problem.

building a threaded interpreter with the Linuxthreads port
also doesn't suffer this problem.

I will be looking into preparing a FreeBSD patch to try and
allow a way to vary the "initial" thread stack size at
compile time, rather than libc_r build time.

This problem has been giving me the irrits since it first
appeared at the beginning of April.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-27 12:37

Message:
Logged In: YES 
user_id=782552

I forgot to mention that stack size is probably not the problem
(FreeBSD 5.1 and 4.8 behave identical with respect to
test_re.py) 
====================================
FreeBSD 4.8-STABLE FreeBSD 4.8-STABLE #14: Mon Apr  7
17:43:45 JST 2003  i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  524288
stack size              (kbytes, -s)  65536
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  896
open files                      (-n)  1792
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited

================================================================
FreeBSD 5.1-BETA FreeBSD 5.1-BETA #25: Thu May 22 09:10:55
JST 2003 i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  1572864
stack size              (kbytes, -s)  1572864
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  5547
open files                      (-n)  11095
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited


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

Comment By: Till Plewe (tpx)
Date: 2003-05-27 11:59

Message:
Logged In: YES 
user_id=782552

it seems that test_stack_overflow is the culprit

...
    def test_stack_overflow(self):
        # nasty case that overflows the straightforward
recursive
        # implementation of repeated groups.
        self.assertRaises(RuntimeError, re.match, '(x)*',
50000*'x')
        self.assertRaises(RuntimeError, re.match, '(x)*y',
50000*'x'+'y')
        self.assertRaises(RuntimeError, re.match, '(x)*?y',
50000*'x'+'y')
...

>>> A.test_stack_overflow()

Process Python bus error (core dumped)

Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*', 5000*'x')
<_sre.SRE_Match object at 0x81d2b20>
>>> re.match('(x)*', 50000*'x')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*y', 50000*'x'+'y')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*?y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*?y', 50000*'x'+'y')

Process Python bus error (core dumped)


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-25 09:40

Message:
Logged In: YES 
user_id=33168

Can you determine what the conflict in the header files
which prevents curses from building?

My guess is that test_bug_418626() is causing the core dump
(from test_re.py).  Can you verify the problem is in that
function?  If so, can you test each of the
re.match/re.search in the interpreter to determine which
line is failling?

My guess is that it's related to the recursion limit (likely
the last line).  Your stack size limit may be too small for
the python recursion limit.  You can try doing a ulimit -a
to see all the limits.  ulimit -s 8192 is what my stack size
is set to (but on Linux).  Doing that command may work for
you.  But this is all conjecture until you investigate further.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-22 15:04

Message:
Logged In: YES 
user_id=782552

Most of the test failures on FreeBSD CURRENT seem to be gcc
bugs.
(I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release))
Rebuilding world with the additional compiler flag 
  -mno-sse2
got rid of most test failures.

Now only the curses build failure and the test_re failure
remain.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-22 14:57

Message:
Logged In: YES 
user_id=782552

I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release).

Most of the test failures seem to be gcc-bugs.
Rebuilding world with the extra compiler flag 

   -mno-sse2

got rid of most test failures. Now only the test_re failure and
the curses build failure remain.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 08:34

Message:
Logged In: YES 
user_id=33168

I think many of the failures are due to the test_long
failure.  If that problem is fixed, my guess is several
other tests will start working.

What compiler are you using?  Can you try to debug the
test_long failure?  I don't think any python developers have
access to a freebsd box.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470


From noreply@sourceforge.net  Sun Jun  1 11:26:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 01 Jun 2003 03:26:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-746953 ] indentation error in unixcompiler.py
Message-ID: <E19MQ2W-00082k-00@sc8-sf-web1.sourceforge.net>

Bugs item #746953, was opened at 2003-06-01 12:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746953&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fedor Baart (siggyf)
Assigned to: Nobody/Anonymous (nobody)
Summary: indentation error in unixcompiler.py

Initial Comment:
in  the function runtime_library_dir_option(self, dir) in module  
distutils/unixcompiler the indentation of the if elif is incorrect.  
The "elif sys.platform[:5] == "hp-ux":" is not in line with "if 
sys.platform[:6] == "darwin":" 
 
 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746953&group_id=5470


From noreply@sourceforge.net  Sun Jun  1 20:28:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 01 Jun 2003 12:28:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-746953 ] indentation error in unixcompiler.py
Message-ID: <E19MYVR-0006ir-00@sc8-sf-web3.sourceforge.net>

Bugs item #746953, was opened at 2003-06-01 12:26
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746953&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fedor Baart (siggyf)
Assigned to: Nobody/Anonymous (nobody)
Summary: indentation error in unixcompiler.py

Initial Comment:
in  the function runtime_library_dir_option(self, dir) in module  
distutils/unixcompiler the indentation of the if elif is incorrect.  
The "elif sys.platform[:5] == "hp-ux":" is not in line with "if 
sys.platform[:6] == "darwin":" 
 
 

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-01 21:28

Message:
Logged In: YES 
user_id=45365

Fixed in unixccompiler.py rev 1.54. Thanks for the report!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746953&group_id=5470


From noreply@sourceforge.net  Mon Jun  2 03:57:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 01 Jun 2003 19:57:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-745320 ] threads broke on FreeBSD current
Message-ID: <E19MfVa-00067T-00@sc8-sf-web1.sourceforge.net>

Bugs item #745320, was opened at 2003-05-29 03:46
Message generated for change (Comment added) made by tpx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745320&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Till Plewe (tpx)
Assigned to: Nobody/Anonymous (nobody)
Summary: threads broke on FreeBSD current

Initial Comment:
default configuration builts with the snapshot taken at
05-24-230001 but not with the snapshot from
05-26-230001 (--without-threads builts)

I get the following compiler complaint when trying to
build python_2003-05-26-230001: 

c++  -Wl,--export-dynamic -o python  Modules/python.o 
libpython2.3.a -lutil   -
lm  
libpython2.3.a(posixmodule.o): In function `posix_tmpnam':
Modules/posixmodule.c:5785: warning: tmpnam() possibly
used unsafely; consider u
sing mkstemp()
libpython2.3.a(posixmodule.o): In function `posix_tempnam':
Modules/posixmodule.c:5738: warning: tempnam() possibly
used unsafely; consider 
using mkstemp()
libpython2.3.a(thread.o): In function
`PyThread_start_new_thread':
Python/thread_pthread.h:217: undefined reference to
`pthread_create'
Python/thread_pthread.h:253: undefined reference to
`pthread_detach'
*** Error code 1



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

>Comment By: Till Plewe (tpx)
Date: 2003-06-02 02:57

Message:
Logged In: YES 
user_id=782552

adding 

     LIBC=-lkse 

to the Makefile seems to do the trick. Python builds without
any 
further problems (I didn't use autoconf)


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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-01 07:27

Message:
Logged In: YES 
user_id=250749

I think what's missing here is the correct library reference.

I don't have a 5.x box at the moment, so can't check, but as
I recall, there are 2 options at the moment:-
 - libkse;
 - libthr.

Could you check my recollection and try adding the
appropriate library reference to the Makefile to see whether
you get a viable build?

Some autoconf-fu would then be required to make the setting
stick.

As the FreeBSD core team haven't yet designated anything
from the 5.x line as stable, this makes keeping track of the
non-trivial threading changes hard.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745320&group_id=5470


From noreply@sourceforge.net  Mon Jun  2 06:18:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 01 Jun 2003 22:18:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-747320 ] rfc2822 formatdate functionality duplication
Message-ID: <E19Mhhx-00071r-00@sc8-sf-web2.sourceforge.net>

Bugs item #747320, was opened at 2003-06-01 23: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=747320&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: rfc2822 formatdate functionality duplication

Initial Comment:
There are at least 4 places in the standard Python 2.3 library which 
build an RFC 2822 formatted string:

rfc822.formatstring
email.Utils.formatdate
logging.handlers.SMTPHandler.date_time
BaseHTTPServer.HTTPServer.date_time_string

Looking at them, it makes sense to me to
  - replace rfc822's implementation with email's
      (that's the most flexible of the bunch)

  - start a migration so that email uses the one
      from rfc822, if available, else it's own implementation
      (since email is distributed to older Pythons)

  - have logging use the one in rfc822.

  - have BaseHTTPServer use the one in rfc822

If this is deemed an appropriate change, I can send in
a patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747320&group_id=5470


From noreply@sourceforge.net  Mon Jun  2 07:13:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 01 Jun 2003 23:13:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-747320 ] rfc2822 formatdate functionality duplication
Message-ID: <E19MiZl-0000hq-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: rfc2822 formatdate functionality duplication

Initial Comment:
There are at least 4 places in the standard Python 2.3 library which 
build an RFC 2822 formatted string:

rfc822.formatstring
email.Utils.formatdate
logging.handlers.SMTPHandler.date_time
BaseHTTPServer.HTTPServer.date_time_string

Looking at them, it makes sense to me to
  - replace rfc822's implementation with email's
      (that's the most flexible of the bunch)

  - start a migration so that email uses the one
      from rfc822, if available, else it's own implementation
      (since email is distributed to older Pythons)

  - have logging use the one in rfc822.

  - have BaseHTTPServer use the one in rfc822

If this is deemed an appropriate change, I can send in
a patch.

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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-06-02 16:13

Message:
Logged In: YES 
user_id=29957

It's not just formatdate - various email formatting tasks
are probably the
single largest source of duplication in the std library...



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747320&group_id=5470


From noreply@sourceforge.net  Mon Jun  2 07:52:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 01 Jun 2003 23:52:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-747348 ] docstring mistake in BaseHTTPServer
Message-ID: <E19MjAt-0002IC-00@sc8-sf-web3.sourceforge.net>

Bugs item #747348, was opened at 2003-06-02 00:52
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=747348&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: docstring mistake in BaseHTTPServer

Initial Comment:
The docstring for BaseHTTPServer .. parse_request starts


    def parse_request(self):
        """Parse a request (internal).

        The request should be stored in self.raw_request;


That should be "self.raw_requestline" because a few
lines further in it says

        requestline = self.raw_requestline


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747348&group_id=5470


From noreply@sourceforge.net  Mon Jun  2 11:45:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 02 Jun 2003 03:45:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-747460 ] make test errors Tru64 UNIX V5.1A
Message-ID: <E19MmoI-0002cw-00@sc8-sf-web4.sourceforge.net>

Bugs item #747460, was opened at 2003-06-02 12: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=747460&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gottfried Mueller (muellergm4t9)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test errors Tru64 UNIX V5.1A

Initial Comment:
What can I do? 
 
1. Test Error 
python Lib/test/test_compile.py 
 
Testing whether compiler catches assignment to 
__debug__ 
Running tests on argument handling 
testing complex args 
1 2 
1 2 
3 4 
1 2 3 
1 2 3 
2 3 4 
testing bad float literals 
testing literals with leading zeroes 
Traceback (most recent call last): 
  File "Lib/test/test_compile.py", line 128, in ? 
    expect_same("0xffffffff", -1) 
  File "Lib/test/test_compile.py", line 90, in expect_same 
    raise TestFailed("eval(%r) gave %r, but expected %r" 
% 
test_support.TestFailed: eval('0xffffffff') gave 
4294967295, but expected -1 
 
2.Test Error 
python Lib/test/test_long.py    
 
long / * % divmod 
long bit-operation identities 
long str/hex/oct/atol 
long miscellaneous operations 
auto-convert int->long on overflow 
long->float overflow 
Traceback (most recent call last): 
  File "Lib/test/test_long.py", line 409, in ? 
    test_float_overflow() 
  File "Lib/test/test_long.py", line 362, in 
test_float_overflow 
    eval(test, namespace) 
  File "<string>", line 0, in ? 
ValueError: invalid literal for float(): 
123451234512345123451234512345123451234 
51234512345123451234512345123451234512345123451234512345123451234512345123451234 
51234512345123451234512345123451234512345123451234512345123451234512345123451234 
5 
 
3. Test Error 
python Lib/test/test_sax.py 
 
Passed test_attrs_empty 
Passed test_attrs_wattr 
Passed test_double_quoteattr 
Passed test_escape_all 
Passed test_escape_basic 
Passed test_escape_extra 
Passed test_expat_attrs_empty 
Passed test_expat_attrs_wattr 
Passed test_expat_dtdhandler 
Passed test_expat_entityresolver 
Passed test_expat_file 
Passed test_expat_incomplete 
Passed test_expat_incremental 
Passed test_expat_incremental_reset 
Passed test_expat_inpsource_filename 
Passed test_expat_inpsource_location 
Passed test_expat_inpsource_stream 
Passed test_expat_inpsource_sysid 
Passed test_expat_locator_noinfo 
Passed test_expat_locator_withinfo 
Passed test_expat_nsattrs_empty 
Passed test_expat_nsattrs_wattr 
Expected: 
[('start', ('http://xml.python.org/1', 'abc'), 'abc'), 
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'), 
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'), 
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'), 
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'), 
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')] 
Received: 
[('start', (u'http://xml.python.org/1', u'abc'), None), 
 ('start', (u'http://xml.python.org/2', u'def'), None), 
 ('end', (u'http://xml.python.org/2', u'def'), None), 
 ('start', (u'http://xml.python.org/1', u'ghi'), None), 
 ('end', (u'http://xml.python.org/1', u'ghi'), None), 
 ('end', (u'http://xml.python.org/1', u'abc'), None)] 
Failed test_expat_nsdecl_pair_diff 
Expected: 
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'), 
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'), 
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'), 
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), 
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), 
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')] 
Received: 
[('start', (u'http://xml.python.org/', u'abc'), None), 
 ('start', (u'http://xml.python.org/', u'def'), None), 
 ('end', (u'http://xml.python.org/', u'def'), None), 
 ('start', (u'http://xml.python.org/', u'ghi'), None), 
 ('end', (u'http://xml.python.org/', u'ghi'), None), 
 ('end', (u'http://xml.python.org/', u'abc'), None)] 
Failed test_expat_nsdecl_pair_same 
Expected: 
[('start', ('http://xml.python.org/', 'abc'), 'abc'), 
 ('end', ('http://xml.python.org/', 'abc'), 'abc')] 
Received: 
[('start', (u'http://xml.python.org/', u'abc'), None), 
 ('end', (u'http://xml.python.org/', u'abc'), None)] 
Failed test_expat_nsdecl_single 
Passed test_filter_basic 
Passed test_make_parser 
Passed test_make_parser2 
Passed test_nsattrs_empty 
Passed test_nsattrs_wattr 
Passed test_quoteattr_basic 
Passed test_single_double_quoteattr 
Passed test_single_quoteattr 
Passed test_xmlgen_attr_escape 
Passed test_xmlgen_basic 
Passed test_xmlgen_content 
Passed test_xmlgen_content_escape 
Passed test_xmlgen_ignorable 
Passed test_xmlgen_ns 
Passed test_xmlgen_pi 
40 tests, 3 failures 
Traceback (most recent call last): 
  File "Lib/test/test_sax.py", line 707, in ? 
    raise TestFailed, "%d of %d tests failed" % (fails, tests) 
test_support.TestFailed: 3 of 40 tests failed 
 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747460&group_id=5470


From noreply@sourceforge.net  Mon Jun  2 12:47:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 02 Jun 2003 04:47:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support
Message-ID: <E19Mnmm-0005Ul-00@sc8-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure does NOT set properly *FLAGS for thread support

Initial Comment:
On Tru64Unix 5.1A(but also older version like Digital
Unix 4.0 for example), there have to be specified
CFLAGS="-pthread" and CXXFLAGS="-pthread", so that
configure can detect working pthread.h.

In case of Python-2.3b1 even when user set those both
variables before running configure, at the link step gets:

cc   -o python \
                Modules/ccpython.o \
                libpython2.3.a -lrt -L/usr/local/lib
-L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib   -lm  
ld:
Unresolved:
__pthread_self
__pthread_create
__pthread_detach
make: *** [python] Error 1
$

This can be easily fixed:

$ cc -pthread -o python Modules/ccpython.o
libpython2.3.a -lrt -L/usr/local/lib
-L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib -lm 
$

I guess in this case LDFLAGS are in effect. So,
configure should make sure -pthread is appended to all,
CFLAGS, CXXFLAGS and LDFLAGS.

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

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-02 13:47

Message:
Logged In: YES 
user_id=696559

Sorry, but my  Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.3) Gecko/20030523  does not recognize the link to
download page (the "Download" word really is NOT clickable).
Trying to access
http://sourceforge.net/tracker/download.php?group_id=5470&amp;atid=305470&amp;file_id=47386&amp;aid=719359
manually gives me:


ERROR - No ID Passed

I'm sorry for the delay in communication, I was away for a
week from net. Could anyone send me the latest version of
patches I should use for Python-2.3b1? I'll try cvs as I
read that some stuff was already merged into ... I'm a bit
lost what is alread checked in and what not yet, so ...




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-26 16:02

Message:
Logged In: YES 
user_id=33168

A solution was already checked in that solves thread
problems for several architectures.  Please test current CVS
and report if it works or not.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-25 18:44

Message:
Logged In: YES 
user_id=33168

This problem has a tentative solution.  Please test the
patch in http://python.org/sf/719359
Scroll to the bottom and click Download on the
osf-opts.patch line.  Thanks.

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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 16:20

Message:
Logged In: YES 
user_id=696559

So, this is a solution:

CC="cc -pthread" CXX="cxx -pthread" CFLAGS="$CFLAGS
-pthread" CXXFLAGS=$CFLAGS ./configure



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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 10:28

Message:
Logged In: YES 
user_id=696559

BTW: With gcc, I don't get even to the link step:

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o
Modules/posixmodule.o
Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1851: `stat' undeclared (first use in
this function)
Modules/posixmodule.c:1851: (Each undeclared identifier is
reported only once
Modules/posixmodule.c:1851: for each function it appears in.)
Modules/posixmodule.c: In function `posix_plock':
Modules/posixmodule.c:2956: warning: implicit declaration of
function `plock'
Modules/posixmodule.c: In function `posix_lstat':
Modules/posixmodule.c:4683: `lstat' undeclared (first use in
this function)
Modules/posixmodule.c: In function `posix_unsetenv':
Modules/posixmodule.c:5431: warning: implicit declaration of
function `unsetenv'
make: *** [Modules/posixmodule.o] Error 1


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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 09:24

Message:
Logged In: YES 
user_id=696559

This is specific for Dec/Compaq/HP compiler. The manpage for
cc says:

  -pthread
      Directs the linker to use the threadsafe version of
any library speci-
      fied with the -l option when linking programs. This
option also tells
      the linker to include the POSIX 1003.1c-conformant
DECthreads inter-
      faces in libpthread when linking the program. This
option also defines
      the _REENTRANT macro.


As I remeber from experience, it's not enough to use it
really as LDFLAG supplied to ld. The code has to be compiled
with that flag already and therefore I set CC or CFLAGS to
contain this value. Same applies for CXX or CXXFLAGS.

Actually, there's a configure macro check, I saw it
somewhere in documentation on the web. I posted that once
into some my bugreport in GNOME bugzilla. You can dig out
from there that URL. Unfortunately, bugzilla searches never
worked for me. :(

As for gcc:
$ CFLAGS="-O2" CXXFLAGS="-O2" CC=gcc CXX=g++ ./configure
[...]
checking whether pthreads are available without options... no
checking whether gcc accepts -Kpthread... no
[...]
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking cthreads.h usability... no
checking cthreads.h presence... no
checking for cthreads.h... no
checking mach/cthreads.h usability... no
checking mach/cthreads.h presence... no
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... yes
checking for pthread_sigmask... yes

from config.log:

configure:3753: checking whether pthreads are available
without options
configure:3779: gcc -o conftest -O2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c -L/usr/l
ocal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib >&5
In file included from configure:3763:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3782: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3761 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3802: result: no



So, to conclude, -pthread has to be specified even for
gcc/g++. Simply, always on 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 05:34

Message:
Logged In: YES 
user_id=33168

Is this only with the Dec/Compaq/HP compiler (cc/cxx)?  Do
you know if python links ok with gcc?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470


From noreply@sourceforge.net  Mon Jun  2 13:37:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 02 Jun 2003 05:37:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-747320 ] rfc2822 formatdate functionality duplication
Message-ID: <E19MoZ2-0007Nb-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: rfc2822 formatdate functionality duplication

Initial Comment:
There are at least 4 places in the standard Python 2.3 library which 
build an RFC 2822 formatted string:

rfc822.formatstring
email.Utils.formatdate
logging.handlers.SMTPHandler.date_time
BaseHTTPServer.HTTPServer.date_time_string

Looking at them, it makes sense to me to
  - replace rfc822's implementation with email's
      (that's the most flexible of the bunch)

  - start a migration so that email uses the one
      from rfc822, if available, else it's own implementation
      (since email is distributed to older Pythons)

  - have logging use the one in rfc822.

  - have BaseHTTPServer use the one in rfc822

If this is deemed an appropriate change, I can send in
a patch.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-06-02 08:37

Message:
Logged In: YES 
user_id=12800

Personally, I'd like to see the email package's date formatting (and other 
email related tasks) be the canonical standard, and for other modules to use 
its rules when appropriate.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-06-02 02:13

Message:
Logged In: YES 
user_id=29957

It's not just formatdate - various email formatting tasks
are probably the
single largest source of duplication in the std library...



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747320&group_id=5470


From noreply@sourceforge.net  Mon Jun  2 13:45:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 02 Jun 2003 05:45:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support
Message-ID: <E19Mogo-0007kP-00@sc8-sf-web4.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure does NOT set properly *FLAGS for thread support

Initial Comment:
On Tru64Unix 5.1A(but also older version like Digital
Unix 4.0 for example), there have to be specified
CFLAGS="-pthread" and CXXFLAGS="-pthread", so that
configure can detect working pthread.h.

In case of Python-2.3b1 even when user set those both
variables before running configure, at the link step gets:

cc   -o python \
                Modules/ccpython.o \
                libpython2.3.a -lrt -L/usr/local/lib
-L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib   -lm  
ld:
Unresolved:
__pthread_self
__pthread_create
__pthread_detach
make: *** [python] Error 1
$

This can be easily fixed:

$ cc -pthread -o python Modules/ccpython.o
libpython2.3.a -lrt -L/usr/local/lib
-L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib -lm 
$

I guess in this case LDFLAGS are in effect. So,
configure should make sure -pthread is appended to all,
CFLAGS, CXXFLAGS and LDFLAGS.

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

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-02 14:45

Message:
Logged In: YES 
user_id=696559

If you are curious about the status of gcc/g++ ability to
cpmpile python(current cvs on alpha-osf), then see below:

$ CC=gcc CXX=g++ CFLAGS=-g2 CXXFLAGS=-g2 ./configure
--prefix=/software/@sys/usr
$ make
gcc -pthread -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-I. -I./Include  -DPy_BUILD_CORE -o Modules/main.o
Modules/main.c
gcc -pthread -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-I. -I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o
Modules/gcmodule.c
gcc -pthread  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/threadmodule.c -o
Modules/threadmodule.o
gcc -pthread  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/signalmodule.c -o
Modules/signalmodule.o
gcc -pthread  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o
Modules/posixmodule.o
Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1775: `stat' undeclared (first use in
this function)
Modules/posixmodule.c:1775: (Each undeclared identifier is
reported only once
Modules/posixmodule.c:1775: for each function it appears in.)
Modules/posixmodule.c: In function `posix_plock':
Modules/posixmodule.c:2880: warning: implicit declaration of
function `plock'
Modules/posixmodule.c: In function `posix_lstat':
Modules/posixmodule.c:4607: `lstat' undeclared (first use in
this function)
Modules/posixmodule.c: In function `posix_unsetenv':
Modules/posixmodule.c:5351: warning: implicit declaration of
function `unsetenv'
make: *** [Modules/posixmodule.o] Error 1
$

from config.log:

configure:3774: checking whether pthreads are available
without options
configure:3800: gcc -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c -L/usr/lo
cal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib >&5
In file included from configure:3784:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3803: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3782 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3823: result: no
configure:3836: checking whether gcc accepts -Kpthread
configure:3864: gcc -Kpthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c
 -L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
gcc: unrecognized option `-Kpthread'
In file included from configure:3848:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3867: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3846 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3887: result: no
configure:3898: checking whether gcc accepts -Kthread
configure:3926: gcc -Kthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c 
-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
gcc: unrecognized option `-Kthread'
In file included from configure:3910:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3929: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3908 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3949: result: no
configure:3960: checking whether gcc accepts -pthread
configure:3988: gcc -pthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c 
-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
configure:3991: $? = 0
configure:3993: ./conftest
configure:3996: $? = 0
configure:4011: result: yes


configure:4214: checking pthread.h usability
configure:4223: gcc -c -g2 -I/software/@sys/usr/include
-I/usr/local/include -I/usr/local/openssl/include conftest.c >&5
In file included from configure:4251:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:4226: $? = 1
[...]
configure:4241: result: no
configure:4245: checking pthread.h presence
configure:4252: gcc -E -I/software/@sys/usr/include
-I/usr/local/include -I/usr/local/openssl/include conftest.c
In file included from configure:4248:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:4258: $? = 1
[...]
configure:9269: checking for pthread_t
configure:9291: gcc -pthread -c -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include conftest.c >&5
configure:9294: $? = 0
configure:9297: test -s conftest.o
configure:9300: $? = 0
configure:9308: result: yes
configure:9312: checking size of pthread_t
configure:9334: gcc -pthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c 
-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
configure:9337: $? = 0
configure:9339: ./conftest
configure:9342: $? = 0
configure:9357: result: 8


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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-02 13:47

Message:
Logged In: YES 
user_id=696559

Sorry, but my  Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.3) Gecko/20030523  does not recognize the link to
download page (the "Download" word really is NOT clickable).
Trying to access
http://sourceforge.net/tracker/download.php?group_id=5470&amp;atid=305470&amp;file_id=47386&amp;aid=719359
manually gives me:


ERROR - No ID Passed

I'm sorry for the delay in communication, I was away for a
week from net. Could anyone send me the latest version of
patches I should use for Python-2.3b1? I'll try cvs as I
read that some stuff was already merged into ... I'm a bit
lost what is alread checked in and what not yet, so ...




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-26 16:02

Message:
Logged In: YES 
user_id=33168

A solution was already checked in that solves thread
problems for several architectures.  Please test current CVS
and report if it works or not.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-25 18:44

Message:
Logged In: YES 
user_id=33168

This problem has a tentative solution.  Please test the
patch in http://python.org/sf/719359
Scroll to the bottom and click Download on the
osf-opts.patch line.  Thanks.

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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 16:20

Message:
Logged In: YES 
user_id=696559

So, this is a solution:

CC="cc -pthread" CXX="cxx -pthread" CFLAGS="$CFLAGS
-pthread" CXXFLAGS=$CFLAGS ./configure



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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 10:28

Message:
Logged In: YES 
user_id=696559

BTW: With gcc, I don't get even to the link step:

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o
Modules/posixmodule.o
Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1851: `stat' undeclared (first use in
this function)
Modules/posixmodule.c:1851: (Each undeclared identifier is
reported only once
Modules/posixmodule.c:1851: for each function it appears in.)
Modules/posixmodule.c: In function `posix_plock':
Modules/posixmodule.c:2956: warning: implicit declaration of
function `plock'
Modules/posixmodule.c: In function `posix_lstat':
Modules/posixmodule.c:4683: `lstat' undeclared (first use in
this function)
Modules/posixmodule.c: In function `posix_unsetenv':
Modules/posixmodule.c:5431: warning: implicit declaration of
function `unsetenv'
make: *** [Modules/posixmodule.o] Error 1


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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 09:24

Message:
Logged In: YES 
user_id=696559

This is specific for Dec/Compaq/HP compiler. The manpage for
cc says:

  -pthread
      Directs the linker to use the threadsafe version of
any library speci-
      fied with the -l option when linking programs. This
option also tells
      the linker to include the POSIX 1003.1c-conformant
DECthreads inter-
      faces in libpthread when linking the program. This
option also defines
      the _REENTRANT macro.


As I remeber from experience, it's not enough to use it
really as LDFLAG supplied to ld. The code has to be compiled
with that flag already and therefore I set CC or CFLAGS to
contain this value. Same applies for CXX or CXXFLAGS.

Actually, there's a configure macro check, I saw it
somewhere in documentation on the web. I posted that once
into some my bugreport in GNOME bugzilla. You can dig out
from there that URL. Unfortunately, bugzilla searches never
worked for me. :(

As for gcc:
$ CFLAGS="-O2" CXXFLAGS="-O2" CC=gcc CXX=g++ ./configure
[...]
checking whether pthreads are available without options... no
checking whether gcc accepts -Kpthread... no
[...]
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking cthreads.h usability... no
checking cthreads.h presence... no
checking for cthreads.h... no
checking mach/cthreads.h usability... no
checking mach/cthreads.h presence... no
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... yes
checking for pthread_sigmask... yes

from config.log:

configure:3753: checking whether pthreads are available
without options
configure:3779: gcc -o conftest -O2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c -L/usr/l
ocal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib >&5
In file included from configure:3763:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3782: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3761 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3802: result: no



So, to conclude, -pthread has to be specified even for
gcc/g++. Simply, always on 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 05:34

Message:
Logged In: YES 
user_id=33168

Is this only with the Dec/Compaq/HP compiler (cc/cxx)?  Do
you know if python links ok with gcc?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470


From noreply@sourceforge.net  Mon Jun  2 15:26:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 02 Jun 2003 07:26:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-747348 ] docstring mistake in BaseHTTPServer
Message-ID: <E19MqGU-0008PR-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: docstring mistake in BaseHTTPServer

Initial Comment:
The docstring for BaseHTTPServer .. parse_request starts


    def parse_request(self):
        """Parse a request (internal).

        The request should be stored in self.raw_request;


That should be "self.raw_requestline" because a few
lines further in it says

        requestline = self.raw_requestline


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-02 09:26

Message:
Logged In: YES 
user_id=80475

Fixed.  See BaseHTTPServer.py 1.27

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747348&group_id=5470


From noreply@sourceforge.net  Tue Jun  3 07:36:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 02 Jun 2003 23:36:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-747954 ] site.py KeyError
Message-ID: <E19N5P7-0001aB-00@sc8-sf-web1.sourceforge.net>

Bugs item #747954, was opened at 2003-06-03 06:36
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=747954&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Lenihan (brianl)
Assigned to: Jack Jansen (jackjansen)
Summary: site.py KeyError

Initial Comment:
site.py has a darwin specific check on line 180 to add
/Users/nnn/Library/Python2.x/site-packages to sitedirs

The test is: if os.environ['HOME']:
instead if os.environ.get('HOME')

This causes site.py to fail to load in some
circumstances,such as running a script under Apache,
which then causes site-packages to be missing from
sys.path.
 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747954&group_id=5470


From noreply@sourceforge.net  Tue Jun  3 08:09:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 03 Jun 2003 00:09:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-542482 ] Can't compile when using alt. thread lib when pthread avail.
Message-ID: <E19N5uy-00030i-00@sc8-sf-web1.sourceforge.net>

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

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't compile when using alt. thread lib when pthread avail.

Initial Comment:
Hi,

I try to compile Python-2.2.1 on my linux slackware 8
with gcc-3.0.4
there was no problem with the configure, but for the
make i got this :

# gmake
gcc -c -DNDEBUG -g -O3 -march=i686 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c
In file included from Python/thread.c:109:
Python/thread_pth.h: In function
`PyThread_start_new_thread':
Python/thread_pth.h:59: warning: return makes integer
from pointer without a cast
In file included from Python/thread.c:113:
Python/thread_pthread.h:113:1: warning: "CHECK_STATUS"
redefined
Python/thread_pth.h:31:1: warning: this is the location
of the previous definition
In file included from Python/thread.c:113:
Python/thread_pthread.h: At top level:
Python/thread_pthread.h:139: redefinition of
`PyThread__init_thread'
Python/thread_pth.h:38: `PyThread__init_thread'
previously defined here
Python/thread_pthread.h:154: redefinition of
`PyThread_start_new_thread'
Python/thread_pth.h:48: `PyThread_start_new_thread'
previously defined here
Python/thread_pthread.h:235: redefinition of
`PyThread_get_thread_ident'
Python/thread_pth.h:63: `PyThread_get_thread_ident'
previously defined here
Python/thread_pthread.h:250: redefinition of
`do_PyThread_exit_thread'
Python/thread_pth.h:73: `do_PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:262: redefinition of
`PyThread_exit_thread'
Python/thread_pth.h:84: `PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:268: redefinition of
`PyThread__exit_thread'
Python/thread_pth.h:89: `PyThread__exit_thread'
previously defined here
Python/thread_pthread.h:302: redefinition of
`PyThread_allocate_lock'
Python/thread_pth.h:119: `PyThread_allocate_lock'
previously defined here
Python/thread_pthread.h:335: redefinition of
`PyThread_free_lock'
Python/thread_pth.h:145: `PyThread_free_lock'
previously defined here
Python/thread_pthread.h:352: redefinition of
`PyThread_acquire_lock'
Python/thread_pth.h:154: `PyThread_acquire_lock'
previously defined here
Python/thread_pthread.h:390: redefinition of
`PyThread_release_lock'
Python/thread_pth.h:191: `PyThread_release_lock'
previously defined here
Python/thread_pthread.h:413: redefinition of `struct
semaphore'
Python/thread_pthread.h:421: redefinition of
`PyThread_allocate_sema'
Python/thread_pth.h:221: `PyThread_allocate_sema'
previously defined here
Python/thread_pthread.h:449: redefinition of
`PyThread_free_sema'
Python/thread_pth.h:246: `PyThread_free_sema'
previously defined here
Python/thread_pthread.h:463: redefinition of
`PyThread_down_sema'
Python/thread_pth.h:254: `PyThread_down_sema'
previously defined here
Python/thread_pthread.h:493: redefinition of
`PyThread_up_sema'
Python/thread_pth.h:283: `PyThread_up_sema' previously
defined here
gmake: *** [Python/thread.o] Error 1


It would be great if you could help me with this !

Best regards,

Pierre.




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

>Comment By: Pierre (pierre42)
Date: 2003-06-03 09:09

Message:
Logged In: YES 
user_id=512388

There is no more problem w/2.3b1


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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-17 03:46

Message:
Logged In: YES 
user_id=357491

Anyone care to answer Neal's question?  =)  Might be nice to see if this can 
be solved before 2.2.3 goes out the door.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-11-02 03:45

Message:
Logged In: YES 
user_id=33168

Is this still a problem w/2.2.2?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-14 01:04

Message:
Logged In: YES 
user_id=21627

You are right; this is the intention. It turns out that a 
configuration of an alternate thread library is not 
supported if pthreads are also available on the system. 
 
I'll try to come up with a work-around, but this is not 
high-priority, and may take a while. 

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

Comment By: Pierre (pierre42)
Date: 2002-04-13 15:18

Message:
Logged In: YES 
user_id=512388

I did ./configure  --with-threads --with-pth
I thought it means "enable thread support, and for this use
gnu pth". 

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-13 10:31

Message:
Logged In: YES 
user_id=21627

I think I can see the problem now. For some reason, Python
tries to use both GNU pth and pthreads for threading; this
cannot work.

How did you invoke configure?

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

Comment By: Pierre (pierre42)
Date: 2002-04-13 04:29

Message:
Logged In: YES 
user_id=512388

In fact i can't attach the file thread.i, it is too big :(

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

Comment By: Pierre (pierre42)
Date: 2002-04-13 04:26

Message:
Logged In: YES 
user_id=512388

Ok i have done :

root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3
-march=i686 -Wall -Wstrict-prototypes -dD --save-temps
--trace-includes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c >& compile.log

I attach you the file compile.log and the file thread.i


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-11 23:59

Message:
Logged In: YES 
user_id=21627

Can you please add the options "-dD --save-temps
--trace-includes" to the gcc invocation, and attach both the
compiler (error) output and thread.i to this report?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470


From noreply@sourceforge.net  Tue Jun  3 11:56:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 03 Jun 2003 03:56:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-747954 ] site.py KeyError
Message-ID: <E19N9SU-0006V9-00@sc8-sf-web3.sourceforge.net>

Bugs item #747954, was opened at 2003-06-03 08:36
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747954&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brian Lenihan (brianl)
Assigned to: Jack Jansen (jackjansen)
Summary: site.py KeyError

Initial Comment:
site.py has a darwin specific check on line 180 to add
/Users/nnn/Library/Python2.x/site-packages to sitedirs

The test is: if os.environ['HOME']:
instead if os.environ.get('HOME')

This causes site.py to fail to load in some
circumstances,such as running a script under Apache,
which then causes site-packages to be missing from
sys.path.
 

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-03 12:56

Message:
Logged In: YES 
user_id=45365

Fixed in site.py rev. 1.51. Thanks for the report!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747954&group_id=5470


From noreply@sourceforge.net  Tue Jun  3 13:49:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 03 Jun 2003 05:49:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E19NBDp-0003li-00@sc8-sf-web3.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 20:12
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


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

>Comment By: Matthias Klose (doko)
Date: 2003-06-03 12:49

Message:
Logged In: YES 
user_id=60903

PEP 304 addresses one part: the location of the generated
.py[co] files. I fail to see, how it adds support to put .py
files in /usr/share.

So it partly solves the problem.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-21 04:38

Message:
Logged In: YES 
user_id=357491

Will PEP 304 solve your problem?

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

Comment By: Matthias Klose (doko)
Date: 2002-08-31 08:59

Message:
Logged In: YES 
user_id=60903

Ok, I'll give --fhs-prefix a try. some questions:

- the lib_python in getpath.c hardcodes lib/pythonX.Y to 
search for the libraries. Is it enouogh to set PYTHONPATH to 
pythonX.Y?

- who to ask for distutils? are there concerns if a 
module/library is splitted over two directories? Or should there 
symlinks from /usr/lib/pythonX.Y to /usr/share/pythonX.Y?

- currently there is only one site-packages directory. how 
should two site-packages be supported (lib and share)?

- speaking of etc: this is a configuration file and should belong 
into the etc hierarchy. should etc be searched before or after 
the library directories?

Python's include files: not all packages separate platform 
specific headers from generic headers, probably therefore the 
FHS puts them in /usr/include.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 20:51

Message:
Logged In: YES 
user_id=45365

The layouts are similar, but not the same. MacPython-OS9 uses the source tree layout, and Windows-Python too, IIRC.
MacPython-OSX in a framework build uses a normal layout, but in a very funny place, with lots of symlinks to make it behave like a framework. I would be very surprised if, say WinCE python or AS/400 python had anything resembling a unix layout. But all these layouts are similar enough that I've never come across a Python where I felt completely lost.

I think there's nothing wrong with enabling people to use their preferred layout, if they have a good reason for it, but I would be against enforcing it unless the advantages are clear and universal.

And someone has to do the work:-)


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

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 20:32

Message:
Logged In: YES 
user_id=163326

Sorry, Matthias. I was confusing the FHS with the Linux
Standard Base.

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 20:24

Message:
Logged In: YES 
user_id=163326

I assume that the Python directory layout is the same on all
currently supported platforms by Python. I really don't know
enough to be sure - the less that's true, the less my
following argument will be valid:

There are really two concerns:
1) make Python conform to the FHS
2) make Python behave the same cross-platform (Windows,
Unix, Mac, BeOS, OS/2, VMS, AS/400, ...)

You can't have both unless you force the FHS directory
layout onto all other platforms. I personally think that 2)
is a good thing.

I welcome the proposal of a configuration option to make
Python FHS-compliant, but I think it should not be the
default. Btw. you'd probably have to patch distutils, too.

Jack said that Pyhon include files should be cross-platform.
AFAIK they are, with one exceptions: pyconfig.h.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 12:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 12:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

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

Comment By: Matthias Klose (doko)
Date: 2002-08-30 11:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


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

Comment By: Matthias Klose (doko)
Date: 2002-08-30 10:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 08:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-30 06:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 12:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 11:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

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

Comment By: Matthias Klose (doko)
Date: 2002-07-30 20:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Tue Jun  3 14:20:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 03 Jun 2003 06:20:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-542482 ] Can't compile when using alt. thread lib when pthread avail.
Message-ID: <E19NBi1-0004ev-00@sc8-sf-web4.sourceforge.net>

Bugs item #542482, was opened at 2002-04-11 08:48
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470

Category: Build
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't compile when using alt. thread lib when pthread avail.

Initial Comment:
Hi,

I try to compile Python-2.2.1 on my linux slackware 8
with gcc-3.0.4
there was no problem with the configure, but for the
make i got this :

# gmake
gcc -c -DNDEBUG -g -O3 -march=i686 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c
In file included from Python/thread.c:109:
Python/thread_pth.h: In function
`PyThread_start_new_thread':
Python/thread_pth.h:59: warning: return makes integer
from pointer without a cast
In file included from Python/thread.c:113:
Python/thread_pthread.h:113:1: warning: "CHECK_STATUS"
redefined
Python/thread_pth.h:31:1: warning: this is the location
of the previous definition
In file included from Python/thread.c:113:
Python/thread_pthread.h: At top level:
Python/thread_pthread.h:139: redefinition of
`PyThread__init_thread'
Python/thread_pth.h:38: `PyThread__init_thread'
previously defined here
Python/thread_pthread.h:154: redefinition of
`PyThread_start_new_thread'
Python/thread_pth.h:48: `PyThread_start_new_thread'
previously defined here
Python/thread_pthread.h:235: redefinition of
`PyThread_get_thread_ident'
Python/thread_pth.h:63: `PyThread_get_thread_ident'
previously defined here
Python/thread_pthread.h:250: redefinition of
`do_PyThread_exit_thread'
Python/thread_pth.h:73: `do_PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:262: redefinition of
`PyThread_exit_thread'
Python/thread_pth.h:84: `PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:268: redefinition of
`PyThread__exit_thread'
Python/thread_pth.h:89: `PyThread__exit_thread'
previously defined here
Python/thread_pthread.h:302: redefinition of
`PyThread_allocate_lock'
Python/thread_pth.h:119: `PyThread_allocate_lock'
previously defined here
Python/thread_pthread.h:335: redefinition of
`PyThread_free_lock'
Python/thread_pth.h:145: `PyThread_free_lock'
previously defined here
Python/thread_pthread.h:352: redefinition of
`PyThread_acquire_lock'
Python/thread_pth.h:154: `PyThread_acquire_lock'
previously defined here
Python/thread_pthread.h:390: redefinition of
`PyThread_release_lock'
Python/thread_pth.h:191: `PyThread_release_lock'
previously defined here
Python/thread_pthread.h:413: redefinition of `struct
semaphore'
Python/thread_pthread.h:421: redefinition of
`PyThread_allocate_sema'
Python/thread_pth.h:221: `PyThread_allocate_sema'
previously defined here
Python/thread_pthread.h:449: redefinition of
`PyThread_free_sema'
Python/thread_pth.h:246: `PyThread_free_sema'
previously defined here
Python/thread_pthread.h:463: redefinition of
`PyThread_down_sema'
Python/thread_pth.h:254: `PyThread_down_sema'
previously defined here
Python/thread_pthread.h:493: redefinition of
`PyThread_up_sema'
Python/thread_pth.h:283: `PyThread_up_sema' previously
defined here
gmake: *** [Python/thread.o] Error 1


It would be great if you could help me with this !

Best regards,

Pierre.




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

Comment By: Pierre (pierre42)
Date: 2003-06-03 03:09

Message:
Logged In: YES 
user_id=512388

There is no more problem w/2.3b1


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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-16 21:46

Message:
Logged In: YES 
user_id=357491

Anyone care to answer Neal's question?  =)  Might be nice to see if this can 
be solved before 2.2.3 goes out the door.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-11-01 21:45

Message:
Logged In: YES 
user_id=33168

Is this still a problem w/2.2.2?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-13 19:04

Message:
Logged In: YES 
user_id=21627

You are right; this is the intention. It turns out that a 
configuration of an alternate thread library is not 
supported if pthreads are also available on the system. 
 
I'll try to come up with a work-around, but this is not 
high-priority, and may take a while. 

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

Comment By: Pierre (pierre42)
Date: 2002-04-13 09:18

Message:
Logged In: YES 
user_id=512388

I did ./configure  --with-threads --with-pth
I thought it means "enable thread support, and for this use
gnu pth". 

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-13 04:31

Message:
Logged In: YES 
user_id=21627

I think I can see the problem now. For some reason, Python
tries to use both GNU pth and pthreads for threading; this
cannot work.

How did you invoke configure?

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

Comment By: Pierre (pierre42)
Date: 2002-04-12 22:29

Message:
Logged In: YES 
user_id=512388

In fact i can't attach the file thread.i, it is too big :(

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

Comment By: Pierre (pierre42)
Date: 2002-04-12 22:26

Message:
Logged In: YES 
user_id=512388

Ok i have done :

root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3
-march=i686 -Wall -Wstrict-prototypes -dD --save-temps
--trace-includes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c >& compile.log

I attach you the file compile.log and the file thread.i


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-11 17:59

Message:
Logged In: YES 
user_id=21627

Can you please add the options "-dD --save-temps
--trace-includes" to the gcc invocation, and attach both the
compiler (error) output and thread.i to this report?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470


From noreply@sourceforge.net  Tue Jun  3 15:14:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 03 Jun 2003 07:14:35 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-748201 ] time.strptime() should display format and date on error
Message-ID: <E19NCYd-00076i-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #748201, was opened at 2003-06-03 14:14
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=748201&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strptime() should display format and date on error

Initial Comment:
Hi!

It would be very nice if the ValueError of
time.strptime() would
display the format and the date if there is a mismatch.

Up to now (python 2.2.2) the Error looks like this:
 ValueError: format mismatch
It would be nice if it would look like this:
 format mismatch: str=2002.12.24 format=%Y-%m-%d

 thomas

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=748201&group_id=5470


From noreply@sourceforge.net  Tue Jun  3 17:38:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 03 Jun 2003 09:38:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E19NEo4-0006vA-00@sc8-sf-web3.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 13:12
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-03 09:38

Message:
Logged In: YES 
user_id=357491

It won't help with that request.  Doing that would require changing install 
paths as suggested below.

As for your questions about implementing --fhs-prefix, I can answer a few.  
For Distutils questions you can just email python-dev to get the attention of 
Distutils developers.  For adding a second site-packages directory I am 
against (use PYTHONPATH if that is needed).

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

Comment By: Matthias Klose (doko)
Date: 2003-06-03 05:49

Message:
Logged In: YES 
user_id=60903

PEP 304 addresses one part: the location of the generated
.py[co] files. I fail to see, how it adds support to put .py
files in /usr/share.

So it partly solves the problem.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-20 21:38

Message:
Logged In: YES 
user_id=357491

Will PEP 304 solve your problem?

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

Comment By: Matthias Klose (doko)
Date: 2002-08-31 01:59

Message:
Logged In: YES 
user_id=60903

Ok, I'll give --fhs-prefix a try. some questions:

- the lib_python in getpath.c hardcodes lib/pythonX.Y to 
search for the libraries. Is it enouogh to set PYTHONPATH to 
pythonX.Y?

- who to ask for distutils? are there concerns if a 
module/library is splitted over two directories? Or should there 
symlinks from /usr/lib/pythonX.Y to /usr/share/pythonX.Y?

- currently there is only one site-packages directory. how 
should two site-packages be supported (lib and share)?

- speaking of etc: this is a configuration file and should belong 
into the etc hierarchy. should etc be searched before or after 
the library directories?

Python's include files: not all packages separate platform 
specific headers from generic headers, probably therefore the 
FHS puts them in /usr/include.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 13:51

Message:
Logged In: YES 
user_id=45365

The layouts are similar, but not the same. MacPython-OS9 uses the source tree layout, and Windows-Python too, IIRC.
MacPython-OSX in a framework build uses a normal layout, but in a very funny place, with lots of symlinks to make it behave like a framework. I would be very surprised if, say WinCE python or AS/400 python had anything resembling a unix layout. But all these layouts are similar enough that I've never come across a Python where I felt completely lost.

I think there's nothing wrong with enabling people to use their preferred layout, if they have a good reason for it, but I would be against enforcing it unless the advantages are clear and universal.

And someone has to do the work:-)


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

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 13:32

Message:
Logged In: YES 
user_id=163326

Sorry, Matthias. I was confusing the FHS with the Linux
Standard Base.

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 13:24

Message:
Logged In: YES 
user_id=163326

I assume that the Python directory layout is the same on all
currently supported platforms by Python. I really don't know
enough to be sure - the less that's true, the less my
following argument will be valid:

There are really two concerns:
1) make Python conform to the FHS
2) make Python behave the same cross-platform (Windows,
Unix, Mac, BeOS, OS/2, VMS, AS/400, ...)

You can't have both unless you force the FHS directory
layout onto all other platforms. I personally think that 2)
is a good thing.

I welcome the proposal of a configuration option to make
Python FHS-compliant, but I think it should not be the
default. Btw. you'd probably have to patch distutils, too.

Jack said that Pyhon include files should be cross-platform.
AFAIK they are, with one exceptions: pyconfig.h.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 05:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 05:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

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

Comment By: Matthias Klose (doko)
Date: 2002-08-30 04:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


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

Comment By: Matthias Klose (doko)
Date: 2002-08-30 03:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 01:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-29 23:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 05:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 04:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

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

Comment By: Matthias Klose (doko)
Date: 2002-07-30 13:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 00:58:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 03 Jun 2003 16:58:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-748542 ] csv, QUOTE_ALWAYS!=QUOTE_ALL
Message-ID: <E19NLfb-0001CP-00@sc8-sf-web4.sourceforge.net>

Bugs item #748542, was opened at 2003-06-03 23: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=748542&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: nestor (nestor5)
Assigned to: Nobody/Anonymous (nobody)
Summary: csv, QUOTE_ALWAYS!=QUOTE_ALL

Initial Comment:
Current Release 2.3b,1 May 28, 2003 of the Python 
documentation for the csv module lists the 
QUOTE_ALWAYS constant. The 2.3b1 release of the 
module seems to be using the QUOTE_ALL constant. 
Needs to be syncronized one way or another.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748542&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 15:53:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 07:53:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support
Message-ID: <E19NZeD-0000h1-00@sc8-sf-web1.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure does NOT set properly *FLAGS for thread support

Initial Comment:
On Tru64Unix 5.1A(but also older version like Digital
Unix 4.0 for example), there have to be specified
CFLAGS="-pthread" and CXXFLAGS="-pthread", so that
configure can detect working pthread.h.

In case of Python-2.3b1 even when user set those both
variables before running configure, at the link step gets:

cc   -o python \
                Modules/ccpython.o \
                libpython2.3.a -lrt -L/usr/local/lib
-L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib   -lm  
ld:
Unresolved:
__pthread_self
__pthread_create
__pthread_detach
make: *** [python] Error 1
$

This can be easily fixed:

$ cc -pthread -o python Modules/ccpython.o
libpython2.3.a -lrt -L/usr/local/lib
-L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib -lm 
$

I guess in this case LDFLAGS are in effect. So,
configure should make sure -pthread is appended to all,
CFLAGS, CXXFLAGS and LDFLAGS.

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

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-04 16:53

Message:
Logged In: YES 
user_id=696559

OK, I can confirm this bug is fixed in cvs. I used
--with-dec-threads configure option and -pthread -ieee were
corrently appended to CFLAGS by configure itself. Thanks!

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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-02 14:45

Message:
Logged In: YES 
user_id=696559

If you are curious about the status of gcc/g++ ability to
cpmpile python(current cvs on alpha-osf), then see below:

$ CC=gcc CXX=g++ CFLAGS=-g2 CXXFLAGS=-g2 ./configure
--prefix=/software/@sys/usr
$ make
gcc -pthread -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-I. -I./Include  -DPy_BUILD_CORE -o Modules/main.o
Modules/main.c
gcc -pthread -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-I. -I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o
Modules/gcmodule.c
gcc -pthread  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/threadmodule.c -o
Modules/threadmodule.o
gcc -pthread  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/signalmodule.c -o
Modules/signalmodule.o
gcc -pthread  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o
Modules/posixmodule.o
Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1775: `stat' undeclared (first use in
this function)
Modules/posixmodule.c:1775: (Each undeclared identifier is
reported only once
Modules/posixmodule.c:1775: for each function it appears in.)
Modules/posixmodule.c: In function `posix_plock':
Modules/posixmodule.c:2880: warning: implicit declaration of
function `plock'
Modules/posixmodule.c: In function `posix_lstat':
Modules/posixmodule.c:4607: `lstat' undeclared (first use in
this function)
Modules/posixmodule.c: In function `posix_unsetenv':
Modules/posixmodule.c:5351: warning: implicit declaration of
function `unsetenv'
make: *** [Modules/posixmodule.o] Error 1
$

from config.log:

configure:3774: checking whether pthreads are available
without options
configure:3800: gcc -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c -L/usr/lo
cal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib >&5
In file included from configure:3784:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3803: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3782 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3823: result: no
configure:3836: checking whether gcc accepts -Kpthread
configure:3864: gcc -Kpthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c
 -L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
gcc: unrecognized option `-Kpthread'
In file included from configure:3848:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3867: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3846 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3887: result: no
configure:3898: checking whether gcc accepts -Kthread
configure:3926: gcc -Kthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c 
-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
gcc: unrecognized option `-Kthread'
In file included from configure:3910:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3929: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3908 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3949: result: no
configure:3960: checking whether gcc accepts -pthread
configure:3988: gcc -pthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c 
-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
configure:3991: $? = 0
configure:3993: ./conftest
configure:3996: $? = 0
configure:4011: result: yes


configure:4214: checking pthread.h usability
configure:4223: gcc -c -g2 -I/software/@sys/usr/include
-I/usr/local/include -I/usr/local/openssl/include conftest.c >&5
In file included from configure:4251:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:4226: $? = 1
[...]
configure:4241: result: no
configure:4245: checking pthread.h presence
configure:4252: gcc -E -I/software/@sys/usr/include
-I/usr/local/include -I/usr/local/openssl/include conftest.c
In file included from configure:4248:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:4258: $? = 1
[...]
configure:9269: checking for pthread_t
configure:9291: gcc -pthread -c -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include conftest.c >&5
configure:9294: $? = 0
configure:9297: test -s conftest.o
configure:9300: $? = 0
configure:9308: result: yes
configure:9312: checking size of pthread_t
configure:9334: gcc -pthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c 
-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
configure:9337: $? = 0
configure:9339: ./conftest
configure:9342: $? = 0
configure:9357: result: 8


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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-02 13:47

Message:
Logged In: YES 
user_id=696559

Sorry, but my  Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.3) Gecko/20030523  does not recognize the link to
download page (the "Download" word really is NOT clickable).
Trying to access
http://sourceforge.net/tracker/download.php?group_id=5470&amp;atid=305470&amp;file_id=47386&amp;aid=719359
manually gives me:


ERROR - No ID Passed

I'm sorry for the delay in communication, I was away for a
week from net. Could anyone send me the latest version of
patches I should use for Python-2.3b1? I'll try cvs as I
read that some stuff was already merged into ... I'm a bit
lost what is alread checked in and what not yet, so ...




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-26 16:02

Message:
Logged In: YES 
user_id=33168

A solution was already checked in that solves thread
problems for several architectures.  Please test current CVS
and report if it works or not.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-25 18:44

Message:
Logged In: YES 
user_id=33168

This problem has a tentative solution.  Please test the
patch in http://python.org/sf/719359
Scroll to the bottom and click Download on the
osf-opts.patch line.  Thanks.

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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 16:20

Message:
Logged In: YES 
user_id=696559

So, this is a solution:

CC="cc -pthread" CXX="cxx -pthread" CFLAGS="$CFLAGS
-pthread" CXXFLAGS=$CFLAGS ./configure



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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 10:28

Message:
Logged In: YES 
user_id=696559

BTW: With gcc, I don't get even to the link step:

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o
Modules/posixmodule.o
Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1851: `stat' undeclared (first use in
this function)
Modules/posixmodule.c:1851: (Each undeclared identifier is
reported only once
Modules/posixmodule.c:1851: for each function it appears in.)
Modules/posixmodule.c: In function `posix_plock':
Modules/posixmodule.c:2956: warning: implicit declaration of
function `plock'
Modules/posixmodule.c: In function `posix_lstat':
Modules/posixmodule.c:4683: `lstat' undeclared (first use in
this function)
Modules/posixmodule.c: In function `posix_unsetenv':
Modules/posixmodule.c:5431: warning: implicit declaration of
function `unsetenv'
make: *** [Modules/posixmodule.o] Error 1


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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 09:24

Message:
Logged In: YES 
user_id=696559

This is specific for Dec/Compaq/HP compiler. The manpage for
cc says:

  -pthread
      Directs the linker to use the threadsafe version of
any library speci-
      fied with the -l option when linking programs. This
option also tells
      the linker to include the POSIX 1003.1c-conformant
DECthreads inter-
      faces in libpthread when linking the program. This
option also defines
      the _REENTRANT macro.


As I remeber from experience, it's not enough to use it
really as LDFLAG supplied to ld. The code has to be compiled
with that flag already and therefore I set CC or CFLAGS to
contain this value. Same applies for CXX or CXXFLAGS.

Actually, there's a configure macro check, I saw it
somewhere in documentation on the web. I posted that once
into some my bugreport in GNOME bugzilla. You can dig out
from there that URL. Unfortunately, bugzilla searches never
worked for me. :(

As for gcc:
$ CFLAGS="-O2" CXXFLAGS="-O2" CC=gcc CXX=g++ ./configure
[...]
checking whether pthreads are available without options... no
checking whether gcc accepts -Kpthread... no
[...]
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking cthreads.h usability... no
checking cthreads.h presence... no
checking for cthreads.h... no
checking mach/cthreads.h usability... no
checking mach/cthreads.h presence... no
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... yes
checking for pthread_sigmask... yes

from config.log:

configure:3753: checking whether pthreads are available
without options
configure:3779: gcc -o conftest -O2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c -L/usr/l
ocal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib >&5
In file included from configure:3763:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3782: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3761 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3802: result: no



So, to conclude, -pthread has to be specified even for
gcc/g++. Simply, always on 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 05:34

Message:
Logged In: YES 
user_id=33168

Is this only with the Dec/Compaq/HP compiler (cc/cxx)?  Do
you know if python links ok with gcc?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 15:55:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 07:55:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-747460 ] make test errors Tru64 UNIX V5.1A
Message-ID: <E19NZfL-0001LI-00@sc8-sf-web4.sourceforge.net>

Bugs item #747460, was opened at 2003-06-02 12:45
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747460&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gottfried Mueller (muellergm4t9)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test errors Tru64 UNIX V5.1A

Initial Comment:
What can I do? 
 
1. Test Error 
python Lib/test/test_compile.py 
 
Testing whether compiler catches assignment to 
__debug__ 
Running tests on argument handling 
testing complex args 
1 2 
1 2 
3 4 
1 2 3 
1 2 3 
2 3 4 
testing bad float literals 
testing literals with leading zeroes 
Traceback (most recent call last): 
  File "Lib/test/test_compile.py", line 128, in ? 
    expect_same("0xffffffff", -1) 
  File "Lib/test/test_compile.py", line 90, in expect_same 
    raise TestFailed("eval(%r) gave %r, but expected %r" 
% 
test_support.TestFailed: eval('0xffffffff') gave 
4294967295, but expected -1 
 
2.Test Error 
python Lib/test/test_long.py    
 
long / * % divmod 
long bit-operation identities 
long str/hex/oct/atol 
long miscellaneous operations 
auto-convert int->long on overflow 
long->float overflow 
Traceback (most recent call last): 
  File "Lib/test/test_long.py", line 409, in ? 
    test_float_overflow() 
  File "Lib/test/test_long.py", line 362, in 
test_float_overflow 
    eval(test, namespace) 
  File "<string>", line 0, in ? 
ValueError: invalid literal for float(): 
123451234512345123451234512345123451234 
51234512345123451234512345123451234512345123451234512345123451234512345123451234 
51234512345123451234512345123451234512345123451234512345123451234512345123451234 
5 
 
3. Test Error 
python Lib/test/test_sax.py 
 
Passed test_attrs_empty 
Passed test_attrs_wattr 
Passed test_double_quoteattr 
Passed test_escape_all 
Passed test_escape_basic 
Passed test_escape_extra 
Passed test_expat_attrs_empty 
Passed test_expat_attrs_wattr 
Passed test_expat_dtdhandler 
Passed test_expat_entityresolver 
Passed test_expat_file 
Passed test_expat_incomplete 
Passed test_expat_incremental 
Passed test_expat_incremental_reset 
Passed test_expat_inpsource_filename 
Passed test_expat_inpsource_location 
Passed test_expat_inpsource_stream 
Passed test_expat_inpsource_sysid 
Passed test_expat_locator_noinfo 
Passed test_expat_locator_withinfo 
Passed test_expat_nsattrs_empty 
Passed test_expat_nsattrs_wattr 
Expected: 
[('start', ('http://xml.python.org/1', 'abc'), 'abc'), 
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'), 
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'), 
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'), 
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'), 
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')] 
Received: 
[('start', (u'http://xml.python.org/1', u'abc'), None), 
 ('start', (u'http://xml.python.org/2', u'def'), None), 
 ('end', (u'http://xml.python.org/2', u'def'), None), 
 ('start', (u'http://xml.python.org/1', u'ghi'), None), 
 ('end', (u'http://xml.python.org/1', u'ghi'), None), 
 ('end', (u'http://xml.python.org/1', u'abc'), None)] 
Failed test_expat_nsdecl_pair_diff 
Expected: 
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'), 
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'), 
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'), 
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), 
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), 
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')] 
Received: 
[('start', (u'http://xml.python.org/', u'abc'), None), 
 ('start', (u'http://xml.python.org/', u'def'), None), 
 ('end', (u'http://xml.python.org/', u'def'), None), 
 ('start', (u'http://xml.python.org/', u'ghi'), None), 
 ('end', (u'http://xml.python.org/', u'ghi'), None), 
 ('end', (u'http://xml.python.org/', u'abc'), None)] 
Failed test_expat_nsdecl_pair_same 
Expected: 
[('start', ('http://xml.python.org/', 'abc'), 'abc'), 
 ('end', ('http://xml.python.org/', 'abc'), 'abc')] 
Received: 
[('start', (u'http://xml.python.org/', u'abc'), None), 
 ('end', (u'http://xml.python.org/', u'abc'), None)] 
Failed test_expat_nsdecl_single 
Passed test_filter_basic 
Passed test_make_parser 
Passed test_make_parser2 
Passed test_nsattrs_empty 
Passed test_nsattrs_wattr 
Passed test_quoteattr_basic 
Passed test_single_double_quoteattr 
Passed test_single_quoteattr 
Passed test_xmlgen_attr_escape 
Passed test_xmlgen_basic 
Passed test_xmlgen_content 
Passed test_xmlgen_content_escape 
Passed test_xmlgen_ignorable 
Passed test_xmlgen_ns 
Passed test_xmlgen_pi 
40 tests, 3 failures 
Traceback (most recent call last): 
  File "Lib/test/test_sax.py", line 707, in ? 
    raise TestFailed, "%d of %d tests failed" % (fails, tests) 
test_support.TestFailed: 3 of 40 tests failed 
 

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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-04 16:55

Message:
Logged In: YES 
user_id=696559

Try current cvs sources, they work for me on same platform.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747460&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 15:59:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 07:59:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support
Message-ID: <E19NZjR-0000wv-00@sc8-sf-web1.sourceforge.net>

Bugs item #741307, was opened at 2003-05-21 14:53
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure does NOT set properly *FLAGS for thread support

Initial Comment:
On Tru64Unix 5.1A(but also older version like Digital
Unix 4.0 for example), there have to be specified
CFLAGS="-pthread" and CXXFLAGS="-pthread", so that
configure can detect working pthread.h.

In case of Python-2.3b1 even when user set those both
variables before running configure, at the link step gets:

cc   -o python \
                Modules/ccpython.o \
                libpython2.3.a -lrt -L/usr/local/lib
-L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib   -lm  
ld:
Unresolved:
__pthread_self
__pthread_create
__pthread_detach
make: *** [python] Error 1
$

This can be easily fixed:

$ cc -pthread -o python Modules/ccpython.o
libpython2.3.a -lrt -L/usr/local/lib
-L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib -lm 
$

I guess in this case LDFLAGS are in effect. So,
configure should make sure -pthread is appended to all,
CFLAGS, CXXFLAGS and LDFLAGS.

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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-04 10:53

Message:
Logged In: YES 
user_id=696559

OK, I can confirm this bug is fixed in cvs. I used
--with-dec-threads configure option and -pthread -ieee were
corrently appended to CFLAGS by configure itself. Thanks!

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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-02 08:45

Message:
Logged In: YES 
user_id=696559

If you are curious about the status of gcc/g++ ability to
cpmpile python(current cvs on alpha-osf), then see below:

$ CC=gcc CXX=g++ CFLAGS=-g2 CXXFLAGS=-g2 ./configure
--prefix=/software/@sys/usr
$ make
gcc -pthread -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-I. -I./Include  -DPy_BUILD_CORE -o Modules/main.o
Modules/main.c
gcc -pthread -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-I. -I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o
Modules/gcmodule.c
gcc -pthread  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/threadmodule.c -o
Modules/threadmodule.o
gcc -pthread  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/signalmodule.c -o
Modules/signalmodule.o
gcc -pthread  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o
Modules/posixmodule.o
Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1775: `stat' undeclared (first use in
this function)
Modules/posixmodule.c:1775: (Each undeclared identifier is
reported only once
Modules/posixmodule.c:1775: for each function it appears in.)
Modules/posixmodule.c: In function `posix_plock':
Modules/posixmodule.c:2880: warning: implicit declaration of
function `plock'
Modules/posixmodule.c: In function `posix_lstat':
Modules/posixmodule.c:4607: `lstat' undeclared (first use in
this function)
Modules/posixmodule.c: In function `posix_unsetenv':
Modules/posixmodule.c:5351: warning: implicit declaration of
function `unsetenv'
make: *** [Modules/posixmodule.o] Error 1
$

from config.log:

configure:3774: checking whether pthreads are available
without options
configure:3800: gcc -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c -L/usr/lo
cal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib >&5
In file included from configure:3784:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3803: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3782 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3823: result: no
configure:3836: checking whether gcc accepts -Kpthread
configure:3864: gcc -Kpthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c
 -L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
gcc: unrecognized option `-Kpthread'
In file included from configure:3848:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3867: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3846 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3887: result: no
configure:3898: checking whether gcc accepts -Kthread
configure:3926: gcc -Kthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c 
-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
gcc: unrecognized option `-Kthread'
In file included from configure:3910:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3929: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3908 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3949: result: no
configure:3960: checking whether gcc accepts -pthread
configure:3988: gcc -pthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c 
-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
configure:3991: $? = 0
configure:3993: ./conftest
configure:3996: $? = 0
configure:4011: result: yes


configure:4214: checking pthread.h usability
configure:4223: gcc -c -g2 -I/software/@sys/usr/include
-I/usr/local/include -I/usr/local/openssl/include conftest.c >&5
In file included from configure:4251:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:4226: $? = 1
[...]
configure:4241: result: no
configure:4245: checking pthread.h presence
configure:4252: gcc -E -I/software/@sys/usr/include
-I/usr/local/include -I/usr/local/openssl/include conftest.c
In file included from configure:4248:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:4258: $? = 1
[...]
configure:9269: checking for pthread_t
configure:9291: gcc -pthread -c -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include conftest.c >&5
configure:9294: $? = 0
configure:9297: test -s conftest.o
configure:9300: $? = 0
configure:9308: result: yes
configure:9312: checking size of pthread_t
configure:9334: gcc -pthread -o conftest -g2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c 
-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib >&5
configure:9337: $? = 0
configure:9339: ./conftest
configure:9342: $? = 0
configure:9357: result: 8


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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-02 07:47

Message:
Logged In: YES 
user_id=696559

Sorry, but my  Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.3) Gecko/20030523  does not recognize the link to
download page (the "Download" word really is NOT clickable).
Trying to access
http://sourceforge.net/tracker/download.php?group_id=5470&amp;atid=305470&amp;file_id=47386&amp;aid=719359
manually gives me:


ERROR - No ID Passed

I'm sorry for the delay in communication, I was away for a
week from net. Could anyone send me the latest version of
patches I should use for Python-2.3b1? I'll try cvs as I
read that some stuff was already merged into ... I'm a bit
lost what is alread checked in and what not yet, so ...




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-26 10:02

Message:
Logged In: YES 
user_id=33168

A solution was already checked in that solves thread
problems for several architectures.  Please test current CVS
and report if it works or not.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-25 12:44

Message:
Logged In: YES 
user_id=33168

This problem has a tentative solution.  Please test the
patch in http://python.org/sf/719359
Scroll to the bottom and click Download on the
osf-opts.patch line.  Thanks.

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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 10:20

Message:
Logged In: YES 
user_id=696559

So, this is a solution:

CC="cc -pthread" CXX="cxx -pthread" CFLAGS="$CFLAGS
-pthread" CXXFLAGS=$CFLAGS ./configure



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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 04:28

Message:
Logged In: YES 
user_id=696559

BTW: With gcc, I don't get even to the link step:

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o
Modules/posixmodule.o
Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1851: `stat' undeclared (first use in
this function)
Modules/posixmodule.c:1851: (Each undeclared identifier is
reported only once
Modules/posixmodule.c:1851: for each function it appears in.)
Modules/posixmodule.c: In function `posix_plock':
Modules/posixmodule.c:2956: warning: implicit declaration of
function `plock'
Modules/posixmodule.c: In function `posix_lstat':
Modules/posixmodule.c:4683: `lstat' undeclared (first use in
this function)
Modules/posixmodule.c: In function `posix_unsetenv':
Modules/posixmodule.c:5431: warning: implicit declaration of
function `unsetenv'
make: *** [Modules/posixmodule.o] Error 1


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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-05-22 03:24

Message:
Logged In: YES 
user_id=696559

This is specific for Dec/Compaq/HP compiler. The manpage for
cc says:

  -pthread
      Directs the linker to use the threadsafe version of
any library speci-
      fied with the -l option when linking programs. This
option also tells
      the linker to include the POSIX 1003.1c-conformant
DECthreads inter-
      faces in libpthread when linking the program. This
option also defines
      the _REENTRANT macro.


As I remeber from experience, it's not enough to use it
really as LDFLAG supplied to ld. The code has to be compiled
with that flag already and therefore I set CC or CFLAGS to
contain this value. Same applies for CXX or CXXFLAGS.

Actually, there's a configure macro check, I saw it
somewhere in documentation on the web. I posted that once
into some my bugreport in GNOME bugzilla. You can dig out
from there that URL. Unfortunately, bugzilla searches never
worked for me. :(

As for gcc:
$ CFLAGS="-O2" CXXFLAGS="-O2" CC=gcc CXX=g++ ./configure
[...]
checking whether pthreads are available without options... no
checking whether gcc accepts -Kpthread... no
[...]
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking cthreads.h usability... no
checking cthreads.h presence... no
checking for cthreads.h... no
checking mach/cthreads.h usability... no
checking mach/cthreads.h presence... no
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... yes
checking for pthread_sigmask... yes

from config.log:

configure:3753: checking whether pthreads are available
without options
configure:3779: gcc -o conftest -O2
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  conftest.c -L/usr/l
ocal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib
-L/usr/lib >&5
In file included from configure:3763:
/usr/include/pthread.h:312:4: #error "Please compile the
module including pthread.h with -pthread"
configure:3782: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 3761 "configure"
#include "confdefs.h"

#include <pthread.h>

void* routine(void* p){return NULL;}

int main(){
  pthread_t p;
  if(pthread_create(&p,NULL,routine,NULL)!=0)
    return 1;
  (void)pthread_detach(p);
  return 0;
}

configure:3802: result: no



So, to conclude, -pthread has to be specified even for
gcc/g++. Simply, always on 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-21 23:34

Message:
Logged In: YES 
user_id=33168

Is this only with the Dec/Compaq/HP compiler (cc/cxx)?  Do
you know if python links ok with gcc?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 16:16:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 08:16:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-741843 ] _locale in Python-2.3b1/Tru64Unix 5.1A doesn't link
Message-ID: <E19NZzt-0006zq-00@sc8-sf-web2.sourceforge.net>

Bugs item #741843, was opened at 2003-05-22 18:25
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
>Summary: _locale in Python-2.3b1/Tru64Unix 5.1A doesn't link

Initial Comment:
I have managed to compile python on Tru64Unix, but am
curious when I rerun "make", I get:

make
case $MAKEFLAGS in \
*-s*)  CC='cc -pthread' LDSHARED='ld -shared
-expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E
./setup.py -q build;; \
*)  CC='cc -pthread' LDSHARED='ld -shared
-expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E
./setup.py build;; \
esac
running build
running build_ext
building '_locale' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_localemodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -o
build/lib.osf1-V5.1-alpha-2.3/_locale.so
*** WARNING: renaming "_locale" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol
"libintl_gettext" unresolved
building '_curses' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
*** WARNING: renaming "_curses" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_curses.so: symbol
"_acs_map" unresolved
building '_curses_panel' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_curses_panel.c -o
build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o
cc: Severe: /mnt/Python-2.3b1/Modules/_curses_panel.c,
line 17: Cannot find file <panel.h> specified in
#include directive. (noinclfilef)
#include <panel.h>
-^
running build_scripts


This looks suspicious. I have ncurses available on the
system too, also termcap

I see that ncurses isn't found because newer version
are in $prefix/include/ncurses/ and not anymore in
$prefix/include/. There configure fails to detect them.
So, I have to configure as:

F77=f77 F90=f90 CC="cc -pthread" CXX="cxx -pthread"
CFLAGS="$CFLAGS -pthread -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses" CPPFLAGS=$CFLAGS
CXXFLAGS=$CFLAGS ./configure
--prefix=/software/@sys/usr --host=alphaev56-dec-osf5.1
--with-dec-threads --enable-large-file

But even in this case, CPPFLAGS weren't propagated to
Makefiles:
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_curses_panel.c -o
build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o
cc: Severe: /mnt/Python-2.3b1/./Include/py_curses.h,
line 16: Cannot find file <ncurses.h> specified in
#include directive. (noinclfilef)
#include <ncurses.h>
-^


Ooops! Not propagated, they are NOT USED! See
config.status:

s,@CXX@,cxx -pthread,;t t
s,@MAINOBJ@,python.o,;t t
s,@EXEEXT@,,;t t
s,@CC@,cc -pthread,;t t
s,@CFLAGS@,-O2 -arch ev56 -pthread
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses,;t t
s,@LDFLAGS@,,;t t
s,@CPPFLAGS@,-O2 -arch ev56 -pthread
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses,;t t
s,@ac_ct_CC@,,;t t
s,@OBJEXT@,o,;t t
s,@CPP@,cc -pthread -E,;t t

And during build I still see:

case $MAKEFLAGS in \
*-s*)  CC='cc -pthread -O2 -arch ev56
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses' LDSHARED='ld
-shared -expect_unresolved "*"' OPT='-DNDEBUG -O'
./python -E ./setup.py -q build;; \
*)  CC='cc -pthread -O2 -arch ev56
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses' LDSHARED='ld
-shared -expect_unresolved "*"' OPT='-DNDEBUG -O'
./python -E ./setup.py build;; \
esac
running build
running build_ext
building '_locale' extension
cc -pthread -O2 -arch ev56 -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses -DNDEBUG -O
-Olimit 1500 -I. -I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_localemodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -o
build/lib.osf1-V5.1-alpha-2.3/_locale.so
*** WARNING: renaming "_locale" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol
"libintl_gettext" unresolved
running build_scripts


I've reinstalled gettext/libiconv/ncurses, but no
difference. 



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

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-04 17:16

Message:
Logged In: YES 
user_id=696559

I believe linking additionally against -lintl will solve the
problem.

I think configur ehas to be improved to detect cases when
-lintl and -lgettextlib might be needed.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 16:23:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 08:23:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs a last distribution
Message-ID: <E19Na72-0002D0-00@sc8-sf-web1.sourceforge.net>

Bugs item #748926, was opened at 2003-06-04 17: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=748926&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken ncurses support in current cvs a last distribution

Initial Comment:
I found configure looks for ncurses.h instead of
ncurses/ncurses.h. Please note that newer version of
ncurses have moved ncurses.h to a subdirectory ncurses/.

Even after fixing configure and
Modules/_curses_panel.c, I get:

cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 506: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addch (const chtype);      
                 /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 507: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchnstr (const chtype *,
int);             /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 508: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchstr (const chtype *); 
                 /* generated */
---------------------------^

Any ideas?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 16:25:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 08:25:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-748928 ] last threads fixes broke linker
Message-ID: <E19Na9H-0002Om-00@sc8-sf-web1.sourceforge.net>

Bugs item #748928, was opened at 2003-06-04 17: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=748928&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: last threads fixes broke linker

Initial Comment:
In current cvs, -pthread and -ieee is properly set for
OSF1/Tru64Unix. Unfortunately, -ieee is somewhat passed
to linker:

building '_curses' extension
cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/mnt/python/dist/src/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/python/dist/src/Include -I/mnt/python/dist/src
-c /mnt/python/dist/src/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved * -ieee -std -Olimit 1500
-DNDEBUG -O -I. -I./Include
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
ld:
-ieee: Unknown flag
ld: Usage: ld [options] file [...]
building '_curses_panel' extension


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 16:32:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 08:32:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-748542 ] csv, QUOTE_ALWAYS!=QUOTE_ALL
Message-ID: <E19NaFA-0002mu-00@sc8-sf-web1.sourceforge.net>

Bugs item #748542, was opened at 2003-06-03 18:58
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748542&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: nestor (nestor5)
>Assigned to: Skip Montanaro (montanaro)
Summary: csv, QUOTE_ALWAYS!=QUOTE_ALL

Initial Comment:
Current Release 2.3b,1 May 28, 2003 of the Python 
documentation for the csv module lists the 
QUOTE_ALWAYS constant. The 2.3b1 release of the 
module seems to be using the QUOTE_ALL constant. 
Needs to be syncronized one way or another.


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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-06-04 10:32

Message:
Logged In: YES 
user_id=44345

Thanks.  Fixed in CVS: Doc/lib/libcsv.tex 1.6.  QUOTE_ALL is the correct
name.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748542&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 18:42:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 10:42:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-511261 ] WIN32 os.path.normpath('./') incorrect
Message-ID: <E19NcHk-0002dM-00@sc8-sf-web4.sourceforge.net>

Bugs item #511261, was opened at 2002-01-31 08:22
Message generated for change (Comment added) made by mshomphe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=511261&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Knight (stevenknight)
Assigned to: Nobody/Anonymous (nobody)
Summary: WIN32 os.path.normpath('./') incorrect

Initial Comment:
os.path.normpath() on WIN32 systems returns a null 
string for . followed by a directory separator:

>>> os.path.normpath('./')
''
>>> os.path.normpath('.\')
''
>>> os.path.normpath('.')
'.'
>>>

Contrast with what happens on Linux:

>>> os.path.normpath('./')
'.'
>>> os.path.normpath('.')
'.'
>>>

Sorry, I don't have a later version than 2.1.1 
available to check whether this is fixed in a later 
version, but I did do a search for other reports of 
this bug and found none.

    --SK




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

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-04 10:42

Message:
Logged In: YES 
user_id=716326

This appears to be fixed in 2.3b1:

Python 2.3b1 (#40, Apr 25 2003, 19:06:24) [MSC v.1200 32 
bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import os
>>> os.path.normpath('./')
'.'
>>> os.path.normpath('.\')
'.'
>>> os.path.normpath('.')
'.'

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

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 07:36

Message:
Logged In: YES 
user_id=4923

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.normpath('./')
'.'
>>> os.path.normpath('.\')
'.'
>>> os.path.normpath('.')
'.'
>>>


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=511261&group_id=5470


From noreply@sourceforge.net  Wed Jun  4 23:47:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 15:47:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-749210 ] bdist --formats=zip,wininst and bdist --formats=wininst,zip
Message-ID: <E19Nh28-0000EY-00@sc8-sf-web4.sourceforge.net>

Bugs item #749210, was opened at 2003-06-05 02: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=749210&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Dubner (dubnerm)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist --formats=zip,wininst and bdist --formats=wininst,zip

Initial Comment:
Commands
setup.py bdist --formats=zip,wininst
and
setup.py bdist --formats=wininst,zip
should create the same two archives, but in my config
first version (zip,wininst) creates broken .exe file -
no SCRIPTS and DATA directories - only PURELIB.
I'm using ActiveState Python 2.2.2 with included
distutils 1.0.3 under WinXP.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470


From noreply@sourceforge.net  Thu Jun  5 01:28:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 17:28:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-749210 ] bdist --formats=zip,wininst and bdist --formats=wininst,zip
Message-ID: <E19NicI-0008S1-00@sc8-sf-web3.sourceforge.net>

Bugs item #749210, was opened at 2003-06-05 02:47
Message generated for change (Settings changed) made by dubnerm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470

>Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Dubner (dubnerm)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist --formats=zip,wininst and bdist --formats=wininst,zip

Initial Comment:
Commands
setup.py bdist --formats=zip,wininst
and
setup.py bdist --formats=wininst,zip
should create the same two archives, but in my config
first version (zip,wininst) creates broken .exe file -
no SCRIPTS and DATA directories - only PURELIB.
I'm using ActiveState Python 2.2.2 with included
distutils 1.0.3 under WinXP.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470


From noreply@sourceforge.net  Thu Jun  5 02:03:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 04 Jun 2003 18:03:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-749261 ] os.path.split does not handle . & .. properly
Message-ID: <E19Nj9h-0004wO-00@sc8-sf-web4.sourceforge.net>

Bugs item #749261, was opened at 2003-06-04 18: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=749261&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Curtis Siemens (csiemens)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.split does not handle . & .. properly

Initial Comment:
The os.path.split() & posixpath.split() functions in my
opinion do not handle '.' & '..' at the end of a path
properly which causes os.path.dirname() &
os.path.basename() to also return the wrong result
because they are directly based on os.path.split().

I'll demonstrate the Unix Python case (the Windows
ntpath.py case is just a close parallel variation).

Example:
>python
Python 2.1.1
>>> posixpath.split('.')
('', '.')
>>> posixpath.split('..')
('', '..')

Yet:
>>> posixpath.split('./')
('..', '')
>>> posixpath.split('../')
('..', '')

Now '.' really represents './', and '..' really
represents '../'
Since the split() function simply uses a string split
on '/' to
find directories, it goofs up on this one case.  The
'.' and
'..' are like the slash character in the sense that
they all
only refer to directories.
The '.' & '..' can never be files in Unix or Windows, so I
think that the split() function should treat paths like:
    .
    ..
    dir/.
    dir/..
    /dir1/dir2/.
    /dir1/dir2/..
as not having a file portion, just as if:
    ./
    ../
    dir/./
    dir/../
    /dir1/dir2/./
    /dir1/dir2/../
respectively were given instead.

The fix in posixpath.py for this is just to put a
little path
processing code at the beginning of the split() function
that looks for the follow cases:
    if p in ['.','..'] or p[-2:] == '/.' or p[-3:] ==
'/..':
        p = p+'/'
And then go into all the regular split() code.
In fix in ntpath.py is very similar.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749261&group_id=5470


From noreply@sourceforge.net  Thu Jun  5 12:30:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 05 Jun 2003 04:30:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-749480 ] strange  __subclasses__ behaviour
Message-ID: <E19Nswy-00058s-00@sc8-sf-web2.sourceforge.net>

Bugs item #749480, was opened at 2003-06-05 11:30
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=749480&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: strange  __subclasses__ behaviour

Initial Comment:
I am not entirely sure whether this is a bug, because I
can't find documentation on __subclasses__ and am
unable to read the source (don't know C). But the name
__subclasses__ implies that a collection of all
subclasses would be returned; however, it doesn't on my
system. It seems as if some subclasses are only listed
*after* they have been looked up in the subclasses'
__bases__, while others are included without that:

$ python
Python 2.3b1+ (#2, Jun  4 2003, 17:16:59)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> float in object.__subclasses__()
False
  1 >>> object in float.__bases__
True
  2 >>> float in object.__subclasses__()
True  3 >>> object.__subclasses__
<built-in method __subclasses__ of type object at
0x8107d60>
  4 >>> object.__subclasses__()
[<type 'type'>, <type 'int'>, <type 'basestring'>,
<type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>, <type
'zipimport.zipimporter'>, <type 'posix.stat_result'>,
<type 'posix.statvfs_result'>, <type 'dict'>, <type
'function'>, <type 'file'>, <type 'float'>, <type
'dictproxy'>]
  5 >>> long in object.__subclasses__()
False
  6 >>> long()
0L
  7 >>> long in object.__subclasses__()
False
  8 >>> long.__bases__
(<type 'object'>,)
  9 >>> long in object.__subclasses__()
True
$ python -c "print object.__subclasses__()"
[<type 'type'>, <type 'int'>, <type 'basestring'>,
<type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>, <type
'zipimport.zipimporter'>, <type 'posix.stat_result'>,
<type 'posix.statvfs_result'>, <type 'dict'>, <type
'function'>, <type 'file'>]
$ python -S -c "print object.__subclasses__()"
[<type 'type'>, <type 'int'>, <type 'basestring'>,
<type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>, <type
'zipimport.zipimporter'>, <type 'function'>, <type
'posix.stat_result'>, <type 'posix.statvfs_result'>,
<type 'dict'>]


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749480&group_id=5470


From noreply@sourceforge.net  Thu Jun  5 12:36:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 05 Jun 2003 04:36:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-749480 ] strange  __subclasses__ behaviour
Message-ID: <E19Nt3D-0007Hv-00@sc8-sf-web3.sourceforge.net>

Bugs item #749480, was opened at 2003-06-05 11:30
Message generated for change (Comment added) made by gerrit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749480&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: strange  __subclasses__ behaviour

Initial Comment:
I am not entirely sure whether this is a bug, because I
can't find documentation on __subclasses__ and am
unable to read the source (don't know C). But the name
__subclasses__ implies that a collection of all
subclasses would be returned; however, it doesn't on my
system. It seems as if some subclasses are only listed
*after* they have been looked up in the subclasses'
__bases__, while others are included without that:

$ python
Python 2.3b1+ (#2, Jun  4 2003, 17:16:59)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> float in object.__subclasses__()
False
  1 >>> object in float.__bases__
True
  2 >>> float in object.__subclasses__()
True  3 >>> object.__subclasses__
<built-in method __subclasses__ of type object at
0x8107d60>
  4 >>> object.__subclasses__()
[<type 'type'>, <type 'int'>, <type 'basestring'>,
<type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>, <type
'zipimport.zipimporter'>, <type 'posix.stat_result'>,
<type 'posix.statvfs_result'>, <type 'dict'>, <type
'function'>, <type 'file'>, <type 'float'>, <type
'dictproxy'>]
  5 >>> long in object.__subclasses__()
False
  6 >>> long()
0L
  7 >>> long in object.__subclasses__()
False
  8 >>> long.__bases__
(<type 'object'>,)
  9 >>> long in object.__subclasses__()
True
$ python -c "print object.__subclasses__()"
[<type 'type'>, <type 'int'>, <type 'basestring'>,
<type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>, <type
'zipimport.zipimporter'>, <type 'posix.stat_result'>,
<type 'posix.statvfs_result'>, <type 'dict'>, <type
'function'>, <type 'file'>]
$ python -S -c "print object.__subclasses__()"
[<type 'type'>, <type 'int'>, <type 'basestring'>,
<type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>, <type
'zipimport.zipimporter'>, <type 'function'>, <type
'posix.stat_result'>, <type 'posix.statvfs_result'>,
<type 'dict'>]


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

>Comment By: Gerrit Holl (gerrit)
Date: 2003-06-05 11:36

Message:
Logged In: YES 
user_id=13298

I accidently pressed enter to early, here is some more
information:

$ python2.2 -S -c "print object.__subclasses__()"
[<type 'type'>, <type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>]

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749480&group_id=5470


From noreply@sourceforge.net  Thu Jun  5 19:51:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 05 Jun 2003 11:51:52 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-749722 ] isinstance and weakref proxies.
Message-ID: <E19Nzq4-00065p-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #749722, was opened at 2003-06-05 13:51
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=749722&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Williamson (tuck_williamson)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance and weakref proxies.

Initial Comment:
I suggest adding proxy support to isinstance along the
lines of  the following pseudocode.

if object is instance of ProxyTypes:
    check using object.__class__ (which is accessed via
the proxy)
else:
    perform normal isinstance checking.

weakref.proxy is intended to hide the details of using
weakrefs . The illusion is dispelled when using
isinstance. Ideally isinstance shouldn't be modified
and the proxy class should just do the right thing, but
I am not sure that is feasable to attain that level of
info hiding while retaining the abitily to do both
isinstance(x, weakref.ProxyTypes) and isinstance(x,
xParentTypes).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=749722&group_id=5470


From noreply@sourceforge.net  Thu Jun  5 23:04:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 05 Jun 2003 15:04:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-749831 ] pickle raises SystemError when __getstate__ refers to class
Message-ID: <E19O2q3-0002OM-00@sc8-sf-web1.sourceforge.net>

Bugs item #749831, was opened at 2003-06-05 22: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=749831&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle raises SystemError when __getstate__ refers to class

Initial Comment:
I'm sorry that I'm so far unable to track this down
better, but my app is quite complex I think. But if I'm
right cPickle should never raise a SystemError:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 265, in ?
    main()
  File "./brian.py", line 235, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 216, in save
    self.level.save(fp)
  File "level.py", line 113, in save
    cPickle.dump(self, f, -1)
SystemError: NULL object passed to Py_BuildValue
$ python -c 'import sys;print sys.version'
2.3b1+ (#2, Jun  4 2003, 17:16:59)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)]

When I use (Py)pickle instead of cPickle, the traceback
becomes:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 266, in ?
    main()
  File "./brian.py", line 236, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 217, in save
    self.level.save(fp)
  File "/home/gerrit/cvs/brian/level.py", line 114, in save
    cPickle.dump(self, f, -1)
  File "/usr/local/lib/python2.3/pickle.py", line 1382,
in dump
    Pickler(file, protocol, bin).dump(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 231,
in dump
    self.save(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 338,
in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/local/lib/python2.3/pickle.py", line 433,
in save_reduce
    save(state)
  File "/usr/local/lib/python2.3/pickle.py", line 293,
in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/local/lib/python2.3/pickle.py", line 663,
in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/local/lib/python2.3/pickle.py", line 695,
in _batch_setitems
    save(v)
  File "/usr/local/lib/python2.3/pickle.py", line 313,
in save
    rv = reduce(self.proto)
SystemError: NULL object passed to Py_BuildValue

'self' is an object whose __dict__ has 4 items. The
'data' item is a set (Sets.set) with approx. 450 items.
Those are all instances of a class Sprite or one of its
subclasses. This is where it goes wrong.

The interesting part is that if a reference to
__class__ in __getstate__ of this Sprite is commented
out, (line 200 of
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/basesprites.py?annotate=1.18)
this bug no longer occurs. The file then pickled is
attached (it is gzipped). Unfortunately, the
__getstate__ relies on some images available.

The full CVS tree of the app concerned is available via
SF:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/
When 'brian' is called without basesprites.py#200
commented out, this error occurs for Python 2.3.

I am going to try to track this down further tomorrow
and beyond, because I think that with the line in
getstate I am very far already.

Gerrit.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 02:21:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 05 Jun 2003 18:21:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19O5vW-0008HO-00@sc8-sf-web2.sourceforge.net>

Bugs item #749911, was opened at 2003-06-05 21: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=749911&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Reed (dr2048)
Assigned to: Nobody/Anonymous (nobody)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 09:23:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 01:23:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-744841 ] Python-Profiler bug: Bad call
Message-ID: <E19OCVi-0005lh-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dieter Maurer (dmaurer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-Profiler bug: Bad call

Initial Comment:
There is a timing problem between the call of 
"call_trace(profile_func,...,'return',...)" and 
"reset_exc_info" in Pythons main interpreter loop.

The main loop first calls "call_trace" (at the end of
function execution). With the
standard "profile.Profile" profiler this leads to a pop
of the current frame from the profiler stack while
the current frame is still on the interpreter stack.
Then "reset_exc_info" is called. When this call releases 
an instance with a destructor ("__del__" method), the 
"call_trace(profile_func,...'call',...)" for the destructor 
observes the inconsistency between the profiler and the 
interpreter stack and raises a "Bad call" exception. This 
exception disables profiling effectively. However, the 
exception is later ignored (as we are in a destructor) and 
program execution continues. When the profiling is later 
finished, all time after the exception is accounted for the 
last function, that was on top of the profiler stack when 
profiling was disabled. This can be extremely confusing.

The attached script reproduces the problem. Run it 
through the Python interpreter. When you see an 
"Exception Bad call ... ignored", the interpreter has the 
described problem. We observed the problem in Python 
2.1.3
(on Linux, Solaris and Windows).


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

>Comment By: Dieter Maurer (dmaurer)
Date: 2003-06-06 08:23

Message:
Logged In: YES 
user_id=265829

Apparently, a colleague observed the bug also in Python 2.2.2.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-29 00:01

Message:
Logged In: YES 
user_id=33168

The good news is that this has been fixed in Python 2.2.x
and beyond.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744841&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 11:11:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 03:11:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-740424 ] MacPython-OS9 distutils breaks on OSX
Message-ID: <E19OEBy-0004OK-00@sc8-sf-web4.sourceforge.net>

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

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacPython-OS9 distutils breaks on OSX

Initial Comment:
MacPython-OS9 distutils (or actually the underlying mkcwproject 
package) does not always work on OSX. The problem is that 
references to the GUSI source tree are relative pathnames to the 
Python sourcetree with :: in them, and CW (at least CW7) doesn't 
understand this when running on OSX. 

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

>Comment By: Just van Rossum (jvr)
Date: 2003-06-06 12:11

Message:
Logged In: YES 
user_id=92689

I have attached a screenshot which illustrates the problem 
(access paths are OS9-style but with OSX separator). This 
is with OS9MacPython 2.2.3 as posted today. Do you have any 
tips on where to look? I'm not familiar with the distutils CW back 
end at all.

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

Comment By: Just van Rossum (jvr)
Date: 2003-05-23 16:31

Message:
Logged In: YES 
user_id=92689

I didn't do a _lot_ of testing, but it sure looked like it simply doesn't work at 
all.

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-05-23 16:11

Message:
Logged In: YES 
user_id=45365

Just: do you mean that *no* distutils-based packages build correctly with 
MacPython-OS9 on OSX with CW8 because of the incorrect pathnames?

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

Comment By: Just van Rossum (jvr)
Date: 2003-05-20 18:18

Message:
Logged In: YES 
user_id=92689

I've observed that (at least with CW8) _all_ pathnames are wrong: they do use 
/, but the paths are constructed as if they are OS9 paths, ie. the start with 
the volume name ( /MyHD/rest/of/path )

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 13:39:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 05:39:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-740424 ] MacPython-OS9 distutils breaks on OSX
Message-ID: <E19OGVM-0004FX-00@sc8-sf-web2.sourceforge.net>

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

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacPython-OS9 distutils breaks on OSX

Initial Comment:
MacPython-OS9 distutils (or actually the underlying mkcwproject 
package) does not always work on OSX. The problem is that 
references to the GUSI source tree are relative pathnames to the 
Python sourcetree with :: in them, and CW (at least CW7) doesn't 
understand this when running on OSX. 

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

>Comment By: Just van Rossum (jvr)
Date: 2003-06-06 14:39

Message:
Logged In: YES 
user_id=92689

It appears to be a bug in CW8: the paths are correct in the 
generated XML, and they are correctly marked as formatted for 
MacOS.

However, if I manually tweak the paths in the XML file, I get lots 
of other errors, so I'm tempted to punt, and forget about distutils 
for CW 8 :-(. I'm so fedup with CW.

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

Comment By: Just van Rossum (jvr)
Date: 2003-06-06 12:11

Message:
Logged In: YES 
user_id=92689

I have attached a screenshot which illustrates the problem 
(access paths are OS9-style but with OSX separator). This 
is with OS9MacPython 2.2.3 as posted today. Do you have any 
tips on where to look? I'm not familiar with the distutils CW back 
end at all.

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

Comment By: Just van Rossum (jvr)
Date: 2003-05-23 16:31

Message:
Logged In: YES 
user_id=92689

I didn't do a _lot_ of testing, but it sure looked like it simply doesn't work at 
all.

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-05-23 16:11

Message:
Logged In: YES 
user_id=45365

Just: do you mean that *no* distutils-based packages build correctly with 
MacPython-OS9 on OSX with CW8 because of the incorrect pathnames?

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

Comment By: Just van Rossum (jvr)
Date: 2003-05-20 18:18

Message:
Logged In: YES 
user_id=92689

I've observed that (at least with CW8) _all_ pathnames are wrong: they do use 
/, but the paths are constructed as if they are OS9 paths, ie. the start with 
the volume name ( /MyHD/rest/of/path )

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 15:01:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 07:01:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-750092 ] exec documentation not updated
Message-ID: <E19OHms-0003tQ-00@sc8-sf-web1.sourceforge.net>

Bugs item #750092, was opened at 2003-06-06 10:01
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=750092&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michele Simionato (michele_s)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec documentation not updated

Initial Comment:
The 2.3b1 reference manual (last update april 25 2003)
still says 
that executable strings must end with a newline, but
this has
been fixed now (finally, it was very annoying :-).

                                                      
                       M.S.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750092&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 18:41:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 10:41:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-740026 ] re.finditer() listed as new in 2.2.?
Message-ID: <E19OLD9-0004xy-00@sc8-sf-web1.sourceforge.net>

Bugs item #740026, was opened at 2003-05-19 20:52
Message generated for change (Comment added) made by gradha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grzegorz Adam Hankiewicz (gradha)
Assigned to: Nobody/Anonymous (nobody)
Summary: re.finditer() listed as new in 2.2.?

Initial Comment:
Documentation says re.finditer() is new in 2.2
(http://www.python.org/doc/current/lib/node99.html),
but this is not totally correct:

[gradha@ws5:0] [~/cms_freeze]$ python
Python 2.2.1 (#1, Sep 10 2002, 17:49:17)
[GCC 3.2] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.finditer
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'finditer'

[0:arpa/g/gradha> /usr/pkg/bin/python2.2
Python 2.2.2 (#1, Mar 13 2003, 22:53:11)
[GCC 2.95.3 20010315 (release) (NetBSD nb3)] on netbsd1
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.finditer
<function finditer at 0x1201ed218>

The first log was produced on an 8.1 Suse default
distro. For a moment I wanted to blame Suse, but I
thought: "hey, let's blame the documentation!". Please
extend that version number to 2.2.2.

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

>Comment By: Grzegorz Adam Hankiewicz (gradha)
Date: 2003-06-06 19:41

Message:
Logged In: YES 
user_id=153159

Maybe SRE should make it to the final documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-20 07:19

Message:
Logged In: YES 
user_id=80475

I recommend leaving it listed as new in 2.2 since that it the 
first time that "from sre import *" would find it.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-20 03:37

Message:
Logged In: YES 
user_id=33168

This is a bit of a weird case.  From looking through CVS,
finditer is in sre, but due to a bug it was not exported
from re.  So  import sre ; sre.finditer should work, but
from sre import * doesn't.  I'm not sure how best to handle
this.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 20:05:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 12:05:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-749831 ] pickle raises SystemError when __getstate__ refers to class
Message-ID: <E19OMX8-0005wy-00@sc8-sf-web3.sourceforge.net>

Bugs item #749831, was opened at 2003-06-05 22:04
Message generated for change (Comment added) made by gerrit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle raises SystemError when __getstate__ refers to class

Initial Comment:
I'm sorry that I'm so far unable to track this down
better, but my app is quite complex I think. But if I'm
right cPickle should never raise a SystemError:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 265, in ?
    main()
  File "./brian.py", line 235, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 216, in save
    self.level.save(fp)
  File "level.py", line 113, in save
    cPickle.dump(self, f, -1)
SystemError: NULL object passed to Py_BuildValue
$ python -c 'import sys;print sys.version'
2.3b1+ (#2, Jun  4 2003, 17:16:59)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)]

When I use (Py)pickle instead of cPickle, the traceback
becomes:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 266, in ?
    main()
  File "./brian.py", line 236, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 217, in save
    self.level.save(fp)
  File "/home/gerrit/cvs/brian/level.py", line 114, in save
    cPickle.dump(self, f, -1)
  File "/usr/local/lib/python2.3/pickle.py", line 1382,
in dump
    Pickler(file, protocol, bin).dump(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 231,
in dump
    self.save(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 338,
in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/local/lib/python2.3/pickle.py", line 433,
in save_reduce
    save(state)
  File "/usr/local/lib/python2.3/pickle.py", line 293,
in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/local/lib/python2.3/pickle.py", line 663,
in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/local/lib/python2.3/pickle.py", line 695,
in _batch_setitems
    save(v)
  File "/usr/local/lib/python2.3/pickle.py", line 313,
in save
    rv = reduce(self.proto)
SystemError: NULL object passed to Py_BuildValue

'self' is an object whose __dict__ has 4 items. The
'data' item is a set (Sets.set) with approx. 450 items.
Those are all instances of a class Sprite or one of its
subclasses. This is where it goes wrong.

The interesting part is that if a reference to
__class__ in __getstate__ of this Sprite is commented
out, (line 200 of
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/basesprites.py?annotate=1.18)
this bug no longer occurs. The file then pickled is
attached (it is gzipped). Unfortunately, the
__getstate__ relies on some images available.

The full CVS tree of the app concerned is available via
SF:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/
When 'brian' is called without basesprites.py#200
commented out, this error occurs for Python 2.3.

I am going to try to track this down further tomorrow
and beyond, because I think that with the line in
getstate I am very far already.

Gerrit.

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

>Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:05

Message:
Logged In: YES 
user_id=13298

OK; one step further.
The __class__ does not exist in the dictionairy so it should
raise a KeyError. The above is true for any non-existing key
in this dictionairy.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 20:08:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 12:08:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-749831 ] pickle raises SystemError when __getstate__ gets error
Message-ID: <E19OMa4-0000Uv-00@sc8-sf-web1.sourceforge.net>

Bugs item #749831, was opened at 2003-06-05 22:04
Message generated for change (Comment added) made by gerrit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
>Summary: pickle raises SystemError when __getstate__ gets error

Initial Comment:
I'm sorry that I'm so far unable to track this down
better, but my app is quite complex I think. But if I'm
right cPickle should never raise a SystemError:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 265, in ?
    main()
  File "./brian.py", line 235, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 216, in save
    self.level.save(fp)
  File "level.py", line 113, in save
    cPickle.dump(self, f, -1)
SystemError: NULL object passed to Py_BuildValue
$ python -c 'import sys;print sys.version'
2.3b1+ (#2, Jun  4 2003, 17:16:59)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)]

When I use (Py)pickle instead of cPickle, the traceback
becomes:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 266, in ?
    main()
  File "./brian.py", line 236, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 217, in save
    self.level.save(fp)
  File "/home/gerrit/cvs/brian/level.py", line 114, in save
    cPickle.dump(self, f, -1)
  File "/usr/local/lib/python2.3/pickle.py", line 1382,
in dump
    Pickler(file, protocol, bin).dump(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 231,
in dump
    self.save(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 338,
in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/local/lib/python2.3/pickle.py", line 433,
in save_reduce
    save(state)
  File "/usr/local/lib/python2.3/pickle.py", line 293,
in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/local/lib/python2.3/pickle.py", line 663,
in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/local/lib/python2.3/pickle.py", line 695,
in _batch_setitems
    save(v)
  File "/usr/local/lib/python2.3/pickle.py", line 313,
in save
    rv = reduce(self.proto)
SystemError: NULL object passed to Py_BuildValue

'self' is an object whose __dict__ has 4 items. The
'data' item is a set (Sets.set) with approx. 450 items.
Those are all instances of a class Sprite or one of its
subclasses. This is where it goes wrong.

The interesting part is that if a reference to
__class__ in __getstate__ of this Sprite is commented
out, (line 200 of
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/basesprites.py?annotate=1.18)
this bug no longer occurs. The file then pickled is
attached (it is gzipped). Unfortunately, the
__getstate__ relies on some images available.

The full CVS tree of the app concerned is available via
SF:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/
When 'brian' is called without basesprites.py#200
commented out, this error occurs for Python 2.3.

I am going to try to track this down further tomorrow
and beyond, because I think that with the line in
getstate I am very far already.

Gerrit.

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

>Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:08

Message:
Logged In: YES 
user_id=13298

Heh, sorry for replying to my own post so soon, but this
problem occurs for any exception: 1/0 in the code of
__getstate__ yields the same result.

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:05

Message:
Logged In: YES 
user_id=13298

OK; one step further.
The __class__ does not exist in the dictionairy so it should
raise a KeyError. The above is true for any non-existing key
in this dictionairy.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 20:23:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 12:23:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-749831 ] copy raises SystemError when getstate raises exception
Message-ID: <E19OMnk-0007KO-00@sc8-sf-web2.sourceforge.net>

Bugs item #749831, was opened at 2003-06-05 22:04
Message generated for change (Comment added) made by gerrit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: copy raises SystemError when getstate raises exception

Initial Comment:
I'm sorry that I'm so far unable to track this down
better, but my app is quite complex I think. But if I'm
right cPickle should never raise a SystemError:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 265, in ?
    main()
  File "./brian.py", line 235, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 216, in save
    self.level.save(fp)
  File "level.py", line 113, in save
    cPickle.dump(self, f, -1)
SystemError: NULL object passed to Py_BuildValue
$ python -c 'import sys;print sys.version'
2.3b1+ (#2, Jun  4 2003, 17:16:59)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)]

When I use (Py)pickle instead of cPickle, the traceback
becomes:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 266, in ?
    main()
  File "./brian.py", line 236, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 217, in save
    self.level.save(fp)
  File "/home/gerrit/cvs/brian/level.py", line 114, in save
    cPickle.dump(self, f, -1)
  File "/usr/local/lib/python2.3/pickle.py", line 1382,
in dump
    Pickler(file, protocol, bin).dump(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 231,
in dump
    self.save(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 338,
in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/local/lib/python2.3/pickle.py", line 433,
in save_reduce
    save(state)
  File "/usr/local/lib/python2.3/pickle.py", line 293,
in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/local/lib/python2.3/pickle.py", line 663,
in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/local/lib/python2.3/pickle.py", line 695,
in _batch_setitems
    save(v)
  File "/usr/local/lib/python2.3/pickle.py", line 313,
in save
    rv = reduce(self.proto)
SystemError: NULL object passed to Py_BuildValue

'self' is an object whose __dict__ has 4 items. The
'data' item is a set (Sets.set) with approx. 450 items.
Those are all instances of a class Sprite or one of its
subclasses. This is where it goes wrong.

The interesting part is that if a reference to
__class__ in __getstate__ of this Sprite is commented
out, (line 200 of
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/basesprites.py?annotate=1.18)
this bug no longer occurs. The file then pickled is
attached (it is gzipped). Unfortunately, the
__getstate__ relies on some images available.

The full CVS tree of the app concerned is available via
SF:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/
When 'brian' is called without basesprites.py#200
commented out, this error occurs for Python 2.3.

I am going to try to track this down further tomorrow
and beyond, because I think that with the line in
getstate I am very far already.

Gerrit.

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

>Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:23

Message:
Logged In: YES 
user_id=13298

Python 2.2 does it right!

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:19

Message:
Logged In: YES 
user_id=13298

OK, I tracked it even further:

Copying an old-style class behaves as expected:
 47 >>> class Foo:
 47 ...  def __getstate__(self): 1/0
 47 ...
 48 >>> copy.copy(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/copy.py", line 75, in copy
    return copier(x)
  File "/usr/local/lib/python2.3/copy.py", line 148, in
_copy_inst
    state = x.__getstate__()
  File "<stdin>", line 2, in __getstate__
ZeroDivisionError: integer division or modulo by zero

However, copying a new-style class instance does not:

 49 >>> class Foo(object):
 49 ...  def __getstate__(self): 1/0
 49 ...
 50 >>> copy.copy(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/copy.py", line 87, in copy
    rv = reductor(2)
SystemError: NULL object passed to Py_BuildValue

...or even easier...

 51 >>> class Foo(object):
 51 ...  def __getstate__(self): raise
 51 ...
 52 >>> copy.copy(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/copy.py", line 87, in copy
    rv = reductor(2)
SystemError: NULL object passed to Py_BuildValue

That's as close as I can get.

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:08

Message:
Logged In: YES 
user_id=13298

Heh, sorry for replying to my own post so soon, but this
problem occurs for any exception: 1/0 in the code of
__getstate__ yields the same result.

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:05

Message:
Logged In: YES 
user_id=13298

OK; one step further.
The __class__ does not exist in the dictionairy so it should
raise a KeyError. The above is true for any non-existing key
in this dictionairy.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 20:19:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 12:19:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-749831 ] copy raises SystemError when getstate raises exception
Message-ID: <E19OMjt-0003vH-00@sc8-sf-web4.sourceforge.net>

Bugs item #749831, was opened at 2003-06-05 22:04
Message generated for change (Comment added) made by gerrit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470

>Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
>Summary: copy raises SystemError when getstate raises exception

Initial Comment:
I'm sorry that I'm so far unable to track this down
better, but my app is quite complex I think. But if I'm
right cPickle should never raise a SystemError:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 265, in ?
    main()
  File "./brian.py", line 235, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 216, in save
    self.level.save(fp)
  File "level.py", line 113, in save
    cPickle.dump(self, f, -1)
SystemError: NULL object passed to Py_BuildValue
$ python -c 'import sys;print sys.version'
2.3b1+ (#2, Jun  4 2003, 17:16:59)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)]

When I use (Py)pickle instead of cPickle, the traceback
becomes:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 266, in ?
    main()
  File "./brian.py", line 236, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 217, in save
    self.level.save(fp)
  File "/home/gerrit/cvs/brian/level.py", line 114, in save
    cPickle.dump(self, f, -1)
  File "/usr/local/lib/python2.3/pickle.py", line 1382,
in dump
    Pickler(file, protocol, bin).dump(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 231,
in dump
    self.save(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 338,
in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/local/lib/python2.3/pickle.py", line 433,
in save_reduce
    save(state)
  File "/usr/local/lib/python2.3/pickle.py", line 293,
in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/local/lib/python2.3/pickle.py", line 663,
in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/local/lib/python2.3/pickle.py", line 695,
in _batch_setitems
    save(v)
  File "/usr/local/lib/python2.3/pickle.py", line 313,
in save
    rv = reduce(self.proto)
SystemError: NULL object passed to Py_BuildValue

'self' is an object whose __dict__ has 4 items. The
'data' item is a set (Sets.set) with approx. 450 items.
Those are all instances of a class Sprite or one of its
subclasses. This is where it goes wrong.

The interesting part is that if a reference to
__class__ in __getstate__ of this Sprite is commented
out, (line 200 of
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/basesprites.py?annotate=1.18)
this bug no longer occurs. The file then pickled is
attached (it is gzipped). Unfortunately, the
__getstate__ relies on some images available.

The full CVS tree of the app concerned is available via
SF:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/
When 'brian' is called without basesprites.py#200
commented out, this error occurs for Python 2.3.

I am going to try to track this down further tomorrow
and beyond, because I think that with the line in
getstate I am very far already.

Gerrit.

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

>Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:19

Message:
Logged In: YES 
user_id=13298

OK, I tracked it even further:

Copying an old-style class behaves as expected:
 47 >>> class Foo:
 47 ...  def __getstate__(self): 1/0
 47 ...
 48 >>> copy.copy(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/copy.py", line 75, in copy
    return copier(x)
  File "/usr/local/lib/python2.3/copy.py", line 148, in
_copy_inst
    state = x.__getstate__()
  File "<stdin>", line 2, in __getstate__
ZeroDivisionError: integer division or modulo by zero

However, copying a new-style class instance does not:

 49 >>> class Foo(object):
 49 ...  def __getstate__(self): 1/0
 49 ...
 50 >>> copy.copy(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/copy.py", line 87, in copy
    rv = reductor(2)
SystemError: NULL object passed to Py_BuildValue

...or even easier...

 51 >>> class Foo(object):
 51 ...  def __getstate__(self): raise
 51 ...
 52 >>> copy.copy(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/copy.py", line 87, in copy
    rv = reductor(2)
SystemError: NULL object passed to Py_BuildValue

That's as close as I can get.

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:08

Message:
Logged In: YES 
user_id=13298

Heh, sorry for replying to my own post so soon, but this
problem occurs for any exception: 1/0 in the code of
__getstate__ yields the same result.

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 19:05

Message:
Logged In: YES 
user_id=13298

OK; one step further.
The __class__ does not exist in the dictionairy so it should
raise a KeyError. The above is true for any non-existing key
in this dictionairy.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470


From noreply@sourceforge.net  Fri Jun  6 22:13:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 14:13:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-750328 ] Pickle fails to restore new-style class instance in a cycle
Message-ID: <E19OOWb-0003Bn-00@sc8-sf-web2.sourceforge.net>

Bugs item #750328, was opened at 2003-06-06 21: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=750328&group_id=5470

Category: Type/class unification
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle fails to restore new-style class instance in a cycle

Initial Comment:
Here is code to demonstrate the problem.  All asserts
succeed except the last, showing that pickle and
cPickle both handle a "classic" cycle correctly, but
only cPickle handles new-style cycles correctly.  It
would appear that the problem is that the pure-Python
pickle isn't putting the object into its 'memo' until
*after* the object's state has been pickled.  Thus, the
identity is not preserved on unpickling.  This may be
true for other object types that use __reduce__, but I
have not verified this.


import pickle, cPickle

class X: pass

x = X()
x.x = x

x2 = cPickle.loads(cPickle.dumps(x))
assert x2.x is x2

x2 = pickle.loads(pickle.dumps(x))
assert x2.x is x2

class Y(object): pass

y = Y()
y.y = y

y2 = cPickle.loads(cPickle.dumps(y))
assert y2.y is y2

# this fails
y2 = pickle.loads(pickle.dumps(y))
assert y2.y is y2   


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470


From noreply@sourceforge.net  Sat Jun  7 03:58:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 06 Jun 2003 19:58:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-750423 ] event handling support
Message-ID: <E19OTv1-0004rc-00@sc8-sf-web3.sourceforge.net>

Bugs item #750423, was opened at 2003-06-06 19: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=750423&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Lila Chase (lchase)
Assigned to: Nobody/Anonymous (nobody)
Summary: event handling support

Initial Comment:
We are interested in a general solution to the problem
of getting
various Python packages that must deal with events to
cooperate.

Python currently provides a hook to readline
(PyOS_InputHook) that
packages use for event handling. However, we have found
so far that
the following Python packages conflict over use of
readline:

- Tkinter and PyGist
- PyMPI and PyGist

As Dave Munro explains below, the best solution to this
problem is
to add more general event handling capability to
Python.  We ask 
Python developers to seriously consider this important
change.

Thank you.
Lila Chase
lchase@llnl.gov
An explanation of the event handling problem is
provided in the 
following note from Dave Munro:

Date: Wed, 14 May 2003 12:11:16 -0700
From: "David H. Munro" <munro>
Reply-To: munro1@llnl.gov

Gist does not really care about readline, of course. 
There are only
two requirements:

(1) Gist must receive an idle event.  That is, whenever
all other events
have been processed (or during idle processing), gist
needs to be called
in order to process its own deferred tasks.  This is
where the apparent
readline dependence appears: When it has nothing left
to do, python calls
readline to wait for the next input line.  This is the
only hook I know
of in python for getting an idle event delivered. 
Unfortunately, it is
way overloaded (for example, tkinter steals the same
hook as well).  The
problem is that the python event loop is "inside out"
-- it needs to be
fixed such that readline is called only as the result
of input on stdin,
putting stdin on the same footing as any other input
source.

(2) The file descriptor for gist's X socket(s) must be
included in the
list of descriptors that will trigger python to "wake
up" when it is blocked
waiting for new input.  Technically, this means that
python must call
either poll() or select() when it goes idle, and that
gist's X socket must
be among the descriptors included in the list provided
for those routines.
Furthermore, when input actually arrives on that
socket, python must call
gist's event handler.  Python currently has no direct
support for asynchronous
input, which is why gist steals the readline hook. 
That approach will break
anyone else who needs such a callback, since the
current gist input hook only
wakes up for its own X socket(s) and stdin.  Gist does
have a full event model,
so other packages could register with gist if they
wanted to get event callbacks
of their own, but of course any package which did that
would itself become
dependent on gist.  The only correct place to do this
job is therefore in
python itself; it currently just does not support such
a notion.

Part of the technical problem with such support is that
things are quitedifferent under both Windows and MacOS
<=9.  It is quite challenging to find
an abstraction which covers all those cases.  For
example, (2) is not necessary
(for gist) at all under Windows, since the OS ensures
that events on gist window
s
generate gist event callbacks.

I hope this helps to clarify the problems gist has in
coexisting with python.
Neither of these problems is particularly difficult,
although the politics of
getting such changes into the python distribution is
probably very tricky.
The good news is that these are the only really serious
problems; everything
else is purely a pygist problem.  I don't know enough
about python to judge
the path of least resistance to get them implemented,
or to accomodate the
other packages that have gone after python's existing
input hooks, but I'm
sure there must be a fairly unobtrusive way to go about
it.

Dave

P.S.-There is a subtlety in the semantics of idle
events, which makes it impossible
for gist to rely on the Tcl/Tk model for handling
them.  If anyone undertakes
the addition of idle event machinery to python, they
should take care to avoid
the same pitfall: In Tcl/Tk, you can request an idle
event, and after this
request you will indeed get a callback just before
Tcl/Tk goes idle.  However,
with Tcl/Tk semantics, you only get one such callback,
and you need to renew
your request to get another idle callback.  This makes
the entire mechanism
worthless for gist, as it is currently implemented,
because gist does not
have hooks at the (many) points it might generate idle
tasks; it expects to
be able to permanently register an idle event handler,
and to have the caller
actually go idle when that returns.  Possibly gist
could be rewritten for the
Tcl/Tk semantics, but for a new implementation, it
would be better to support
the more inclusive semantics.  (The decision about
whether an idle callback is
necessary happens at a much higher level in the gist
design than its event
loop; I am not eager to mix the abstraction levels for
the sake of supporting
Tcl/Tk's idle event model.)






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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750423&group_id=5470


From noreply@sourceforge.net  Sat Jun  7 17:21:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 07 Jun 2003 09:21:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-595837 ] pickle_complex in copy_reg.py
Message-ID: <E19OgRD-00021X-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: pickle_complex in copy_reg.py

Initial Comment:
This code is in copy_reg.py from 1997:

def pickle_complex(c):
    return complex, (c.real, c.imag)

pickle(type(1j), pickle_complex, complex)

I'm not sure if the function pickle_complex() is
necessary, but it definitely seems that the line after
should be commented out or removed.  pickle_complex()
is not in the doc either.

(I was building WITHOUT_COMPLEX and found this problem.)

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

Comment By: Armin Rigo (arigo)
Date: 2003-06-07 16:21

Message:
Logged In: YES 
user_id=4771

proposed patch #750595.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 19:44

Message:
Logged In: YES 
user_id=6380

I'm rejecting this as invalid. Neal, if you disagree, just
reopen and assign to me.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-16 03:49

Message:
Logged In: YES 
user_id=6380

Without that line you can't pickle complex numbers. Maybe it
should fail gracefully if complex doesn't exist. Feel free
to check in a fix for that.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595837&group_id=5470


From noreply@sourceforge.net  Sat Jun  7 21:12:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 07 Jun 2003 13:12:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-595837 ] pickle_complex in copy_reg.py
Message-ID: <E19Ok2v-0000Ci-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: pickle_complex in copy_reg.py

Initial Comment:
This code is in copy_reg.py from 1997:

def pickle_complex(c):
    return complex, (c.real, c.imag)

pickle(type(1j), pickle_complex, complex)

I'm not sure if the function pickle_complex() is
necessary, but it definitely seems that the line after
should be commented out or removed.  pickle_complex()
is not in the doc either.

(I was building WITHOUT_COMPLEX and found this problem.)

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-07 22:12

Message:
Logged In: YES 
user_id=21627

I have committed the patch for 2.2 and 2.3, fixing this bug.

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

Comment By: Armin Rigo (arigo)
Date: 2003-06-07 18:21

Message:
Logged In: YES 
user_id=4771

proposed patch #750595.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 21:44

Message:
Logged In: YES 
user_id=6380

I'm rejecting this as invalid. Neal, if you disagree, just
reopen and assign to me.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-16 05:49

Message:
Logged In: YES 
user_id=6380

Without that line you can't pickle complex numbers. Maybe it
should fail gracefully if complex doesn't exist. Feel free
to check in a fix for that.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595837&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 14:20:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 06:20:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-749831 ] copy raises SystemError when getstate raises exception
Message-ID: <E19P05i-0007Jk-00@sc8-sf-web4.sourceforge.net>

Bugs item #749831, was opened at 2003-06-05 18:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Gerrit Holl (gerrit)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: copy raises SystemError when getstate raises exception

Initial Comment:
I'm sorry that I'm so far unable to track this down
better, but my app is quite complex I think. But if I'm
right cPickle should never raise a SystemError:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 265, in ?
    main()
  File "./brian.py", line 235, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 216, in save
    self.level.save(fp)
  File "level.py", line 113, in save
    cPickle.dump(self, f, -1)
SystemError: NULL object passed to Py_BuildValue
$ python -c 'import sys;print sys.version'
2.3b1+ (#2, Jun  4 2003, 17:16:59)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)]

When I use (Py)pickle instead of cPickle, the traceback
becomes:

$ ./brian.py
mcop warning: user defined signal handler found for
SIG_PIPE, overriding
Traceback (most recent call last):
  File "./brian.py", line 266, in ?
    main()
  File "./brian.py", line 236, in main
    game.mainloop()
  File "./brian.py", line 100, in mainloop
    self.save(self.savefile)
  File "./brian.py", line 217, in save
    self.level.save(fp)
  File "/home/gerrit/cvs/brian/level.py", line 114, in save
    cPickle.dump(self, f, -1)
  File "/usr/local/lib/python2.3/pickle.py", line 1382,
in dump
    Pickler(file, protocol, bin).dump(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 231,
in dump
    self.save(obj)
  File "/usr/local/lib/python2.3/pickle.py", line 338,
in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/local/lib/python2.3/pickle.py", line 433,
in save_reduce
    save(state)
  File "/usr/local/lib/python2.3/pickle.py", line 293,
in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/local/lib/python2.3/pickle.py", line 663,
in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/local/lib/python2.3/pickle.py", line 695,
in _batch_setitems
    save(v)
  File "/usr/local/lib/python2.3/pickle.py", line 313,
in save
    rv = reduce(self.proto)
SystemError: NULL object passed to Py_BuildValue

'self' is an object whose __dict__ has 4 items. The
'data' item is a set (Sets.set) with approx. 450 items.
Those are all instances of a class Sprite or one of its
subclasses. This is where it goes wrong.

The interesting part is that if a reference to
__class__ in __getstate__ of this Sprite is commented
out, (line 200 of
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/basesprites.py?annotate=1.18)
this bug no longer occurs. The file then pickled is
attached (it is gzipped). Unfortunately, the
__getstate__ relies on some images available.

The full CVS tree of the app concerned is available via
SF:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pybrian/brian/
When 'brian' is called without basesprites.py#200
commented out, this error occurs for Python 2.3.

I am going to try to track this down further tomorrow
and beyond, because I think that with the line in
getstate I am very far already.

Gerrit.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-08 09:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
 * Objects/typeobject.c 2.235
 * Lib/test/test_copy.py 1.9

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 15:23

Message:
Logged In: YES 
user_id=13298

Python 2.2 does it right!

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 15:19

Message:
Logged In: YES 
user_id=13298

OK, I tracked it even further:

Copying an old-style class behaves as expected:
 47 >>> class Foo:
 47 ...  def __getstate__(self): 1/0
 47 ...
 48 >>> copy.copy(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/copy.py", line 75, in copy
    return copier(x)
  File "/usr/local/lib/python2.3/copy.py", line 148, in
_copy_inst
    state = x.__getstate__()
  File "<stdin>", line 2, in __getstate__
ZeroDivisionError: integer division or modulo by zero

However, copying a new-style class instance does not:

 49 >>> class Foo(object):
 49 ...  def __getstate__(self): 1/0
 49 ...
 50 >>> copy.copy(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/copy.py", line 87, in copy
    rv = reductor(2)
SystemError: NULL object passed to Py_BuildValue

...or even easier...

 51 >>> class Foo(object):
 51 ...  def __getstate__(self): raise
 51 ...
 52 >>> copy.copy(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/copy.py", line 87, in copy
    rv = reductor(2)
SystemError: NULL object passed to Py_BuildValue

That's as close as I can get.

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 15:08

Message:
Logged In: YES 
user_id=13298

Heh, sorry for replying to my own post so soon, but this
problem occurs for any exception: 1/0 in the code of
__getstate__ yields the same result.

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-06 15:05

Message:
Logged In: YES 
user_id=13298

OK; one step further.
The __class__ does not exist in the dictionairy so it should
raise a KeyError. The above is true for any non-existing key
in this dictionairy.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749831&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 16:00:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 08:00:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-734695 ] Function for creating/extracting CoreFoundation types
Message-ID: <E19P1ev-0005uI-00@sc8-sf-web1.sourceforge.net>

Bugs item #734695, was opened at 2003-05-08 17:15
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470

Category: Macintosh
Group: Feature Request
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: Function for creating/extracting CoreFoundation types

Initial Comment:
pymactoolbox.h contains a number of functions for
converting from CoreFoundation references to Python
wrappers for those functions (e.g. CFTypeRefObj_New).
Simularly there are functions for extracting the
CoreFoundation reference from a wrapped Python object
(e.g. CFTypeRefObj_Convert).

It would be nice if CFTypeRefObj_New would automaticly
create a more specialized Python wrapper if you pass it
a CFArrayRef, this decreases the coupling between the
python core and 3th party extension modules.

Simularly CFTypeRefObj_Convert should "work" when
passed a CFArrayRefObj.

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2003-06-08 17:00

Message:
Logged In: YES 
user_id=580910

Yup, it works now. What I don't like is that the mutable
variations of datastructs (e.g. CFMutableArrayef) get mapped
onto wrappers for the immutable versions (e.g. CFArrayRef).
This seems to a limitation of CF.

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-01 00:09

Message:
Logged In: YES 
user_id=45365

Oops, sorry, I thought I had added it! It's in there now.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2003-05-29 22:55

Message:
Logged In: YES 
user_id=580910

My initial tests were a little too easy, now that I've
completely rebuild PyObjC I see:

ImportError: Module did not provide routine: Carbon.CF:
CFObj_New

Shouldn't there be code in _CFmodule.c to make sure that the
mactoolboxglue can find the two new functions?

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2003-05-29 21:55

Message:
Logged In: YES 
user_id=580910

The new functions seem to work just fine, and the
implementation looks OK too.

I think the current implementation is fine, automaticly
converting only some types to/from their python equivalent
would be confusing. Furthermore the current behaviour allows
me to get as close as possible to 'toll-free bridging' ,
which means it should be possible to translate code examples
that use this feature into Python without too many problems.

Thanks for implementing this!

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-05-27 23:43

Message:
Logged In: YES 
user_id=45365

Implemented in CVS, but I have called the new generalized functions 
CFObj_New() and CFObj_Convert().

One issue is open to discussion: currently CFObj_New() expects a CFTypeRef 
object for which a wrapper is available. An alternative would be to use 
PyCF_CF2Python() otherwise (so CFNumber would get mapped to a Python 
int, etc). Similarly for CFObj_Convert(), which expects an object of one of the 
classes Carbon.CF implements. It could also fall back to using 
PyCF_Python2CF(). Let me know which solution is better.

Also: the code is pretty much untested. Please test, and close this report 
when you're satisfied (and after answering the previous question).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 16:34:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 08:34:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-749261 ] os.path.split does not handle . & .. properly
Message-ID: <E19P2C3-00077A-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Curtis Siemens (csiemens)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.split does not handle . & .. properly

Initial Comment:
The os.path.split() & posixpath.split() functions in my
opinion do not handle '.' & '..' at the end of a path
properly which causes os.path.dirname() &
os.path.basename() to also return the wrong result
because they are directly based on os.path.split().

I'll demonstrate the Unix Python case (the Windows
ntpath.py case is just a close parallel variation).

Example:
>python
Python 2.1.1
>>> posixpath.split('.')
('', '.')
>>> posixpath.split('..')
('', '..')

Yet:
>>> posixpath.split('./')
('..', '')
>>> posixpath.split('../')
('..', '')

Now '.' really represents './', and '..' really
represents '../'
Since the split() function simply uses a string split
on '/' to
find directories, it goofs up on this one case.  The
'.' and
'..' are like the slash character in the sense that
they all
only refer to directories.
The '.' & '..' can never be files in Unix or Windows, so I
think that the split() function should treat paths like:
    .
    ..
    dir/.
    dir/..
    /dir1/dir2/.
    /dir1/dir2/..
as not having a file portion, just as if:
    ./
    ../
    dir/./
    dir/../
    /dir1/dir2/./
    /dir1/dir2/../
respectively were given instead.

The fix in posixpath.py for this is just to put a
little path
processing code at the beginning of the split() function
that looks for the follow cases:
    if p in ['.','..'] or p[-2:] == '/.' or p[-3:] ==
'/..':
        p = p+'/'
And then go into all the regular split() code.
In fix in ntpath.py is very similar.

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-08 10:34

Message:
Logged In: YES 
user_id=2772

I don't believe this behavior is a bug.  os.path.split's task is to split the last component of a path from the other components, regardless of whether any of the components actually names a directory.

Another property of os.path.split is that eventually this loop will terminate:
    while path != "": path = os.path.split(path)[0]
with your proposed change, this would not be true for paths that initially contain a "." or ".." component (since os.path.split("..") -> ('..', ''))

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749261&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 16:44:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 08:44:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-750423 ] event handling support
Message-ID: <E19P2LU-0007Ls-00@sc8-sf-web3.sourceforge.net>

Bugs item #750423, was opened at 2003-06-06 21:58
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750423&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Lila Chase (lchase)
Assigned to: Nobody/Anonymous (nobody)
Summary: event handling support

Initial Comment:
We are interested in a general solution to the problem
of getting
various Python packages that must deal with events to
cooperate.

Python currently provides a hook to readline
(PyOS_InputHook) that
packages use for event handling. However, we have found
so far that
the following Python packages conflict over use of
readline:

- Tkinter and PyGist
- PyMPI and PyGist

As Dave Munro explains below, the best solution to this
problem is
to add more general event handling capability to
Python.  We ask 
Python developers to seriously consider this important
change.

Thank you.
Lila Chase
lchase@llnl.gov
An explanation of the event handling problem is
provided in the 
following note from Dave Munro:

Date: Wed, 14 May 2003 12:11:16 -0700
From: "David H. Munro" <munro>
Reply-To: munro1@llnl.gov

Gist does not really care about readline, of course. 
There are only
two requirements:

(1) Gist must receive an idle event.  That is, whenever
all other events
have been processed (or during idle processing), gist
needs to be called
in order to process its own deferred tasks.  This is
where the apparent
readline dependence appears: When it has nothing left
to do, python calls
readline to wait for the next input line.  This is the
only hook I know
of in python for getting an idle event delivered. 
Unfortunately, it is
way overloaded (for example, tkinter steals the same
hook as well).  The
problem is that the python event loop is "inside out"
-- it needs to be
fixed such that readline is called only as the result
of input on stdin,
putting stdin on the same footing as any other input
source.

(2) The file descriptor for gist's X socket(s) must be
included in the
list of descriptors that will trigger python to "wake
up" when it is blocked
waiting for new input.  Technically, this means that
python must call
either poll() or select() when it goes idle, and that
gist's X socket must
be among the descriptors included in the list provided
for those routines.
Furthermore, when input actually arrives on that
socket, python must call
gist's event handler.  Python currently has no direct
support for asynchronous
input, which is why gist steals the readline hook. 
That approach will break
anyone else who needs such a callback, since the
current gist input hook only
wakes up for its own X socket(s) and stdin.  Gist does
have a full event model,
so other packages could register with gist if they
wanted to get event callbacks
of their own, but of course any package which did that
would itself become
dependent on gist.  The only correct place to do this
job is therefore in
python itself; it currently just does not support such
a notion.

Part of the technical problem with such support is that
things are quitedifferent under both Windows and MacOS
<=9.  It is quite challenging to find
an abstraction which covers all those cases.  For
example, (2) is not necessary
(for gist) at all under Windows, since the OS ensures
that events on gist window
s
generate gist event callbacks.

I hope this helps to clarify the problems gist has in
coexisting with python.
Neither of these problems is particularly difficult,
although the politics of
getting such changes into the python distribution is
probably very tricky.
The good news is that these are the only really serious
problems; everything
else is purely a pygist problem.  I don't know enough
about python to judge
the path of least resistance to get them implemented,
or to accomodate the
other packages that have gone after python's existing
input hooks, but I'm
sure there must be a fairly unobtrusive way to go about
it.

Dave

P.S.-There is a subtlety in the semantics of idle
events, which makes it impossible
for gist to rely on the Tcl/Tk model for handling
them.  If anyone undertakes
the addition of idle event machinery to python, they
should take care to avoid
the same pitfall: In Tcl/Tk, you can request an idle
event, and after this
request you will indeed get a callback just before
Tcl/Tk goes idle.  However,
with Tcl/Tk semantics, you only get one such callback,
and you need to renew
your request to get another idle callback.  This makes
the entire mechanism
worthless for gist, as it is currently implemented,
because gist does not
have hooks at the (many) points it might generate idle
tasks; it expects to
be able to permanently register an idle event handler,
and to have the caller
actually go idle when that returns.  Possibly gist
could be rewritten for the
Tcl/Tk semantics, but for a new implementation, it
would be better to support
the more inclusive semantics.  (The decision about
whether an idle callback is
necessary happens at a much higher level in the gist
design than its event
loop; I am not eager to mix the abstraction levels for
the sake of supporting
Tcl/Tk's idle event model.)






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

Comment By: Jeff Epler (jepler)
Date: 2003-06-08 10:44

Message:
Logged In: YES 
user_id=2772

Please see http://python.org/peps/ for information on submitting a python enhancement proposal.  This is probably a large and complex enough issue that it will have to go through the PEP process before it would be considered.

Another non-PEP or pre-PEP approach would be to develop this event-handling support separately from the three packages mentioned (Tkinter, PyMPI, and PyGist).  Presumably this new package would hook PyOS_InputHook and/or provide a "mainloop"-type function, providing the abstractions needed by Tkinter, PyMPI, and PyGist.

(Of course, you mention the "X socket" for one of the packages---for the solution to be acceptable in Python, I predict that it would need to at least work on Win32 as well, where event handling is a whole different kettle of monkeys, or whatever mixed and disturbing metaphor you care to use)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750423&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 19:51:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 11:51:47 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-635144 ] New UniDiffer class
Message-ID: <E19P5Gd-0005FZ-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #635144, was opened at 2002-11-07 14:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martijn Pieters (mjpieters)
Assigned to: Raymond Hettinger (rhettinger)
Summary: New UniDiffer class

Initial Comment:
Attached is a new UniDiffer module, based on the
difflib.Differ class, which outputs GNU diff unified
context format compatible lines.

The class includes doctest tests and is intended to be
merged directly into the difflib module.

Jim Fulton saiz this can be added to the Python Library
under the current Python license.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-08 13:51

Message:
Logged In: YES 
user_id=80475

I've added functionality for both unified and contexts diffs.  
They are separate functions rather than subclasses (primarily 
because they are implemented without knowledge of Differ).  
The interface changes the order of the parameters to allow 
filenames to be specified with modification dates and to 
provide an option for output without trailing newlines.

See Lib/difflib.py 1.12.

Thanks for the submission.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-12 22:49

Message:
Logged In: YES 
user_id=80475

Nope.  I have to blend this patch with another 
implementation and combine the best parts of each.  The 
SF is fine as it stands.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-12 21:58

Message:
Logged In: YES 
user_id=357491

Should this be made a patch instead of an RFE?

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

Comment By: Martijn Pieters (mjpieters)
Date: 2002-11-08 14:14

Message:
Logged In: YES 
user_id=116747

'Nother version. One bug fix, one new feature.

- When two hunks were between 2 * context + 1 and 3* context
lines aparart, the starting context for the second hunk
would be partially lost.

- Handle missing newline on the last line like GNU diff
does. This currently only supports UNIX-style lineendings.
Documentation reflects this.

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

Comment By: Martijn Pieters (mjpieters)
Date: 2002-11-08 11:18

Message:
Logged In: YES 
user_id=116747

And another little bug found: if set a is empty and set b is
not, resulting in all added lines,  an empty diff would be
returned. Attached latest version fixes this.

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

Comment By: Martijn Pieters (mjpieters)
Date: 2002-11-07 16:34

Message:
Logged In: YES 
user_id=116747

Another update: when there were more than [context] lines in
between two updates, but less than 2 * [context], the two
chunks should not be split. This version fixes that problem;
we look ahead an extra [context] lines before cutting the chunk.

Also, timestamps in headers are now show the seconds
fraction as well, just like GNU diff.

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

Comment By: Martijn Pieters (mjpieters)
Date: 2002-11-07 15:00

Message:
Logged In: YES 
user_id=116747

New version attached, fixing a context bug.

There was a small bug in the previous version where, if
context was set to 0, the all lines until the end of the
last chunk were shown.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 21:23:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 13:23:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-750328 ] Pickle fails to restore new-style class instance in a cycle
Message-ID: <E19P6hZ-0002lU-00@sc8-sf-web4.sourceforge.net>

Bugs item #750328, was opened at 2003-06-06 15:13
Message generated for change (Comment added) made by staschuk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470

Category: Type/class unification
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle fails to restore new-style class instance in a cycle

Initial Comment:
Here is code to demonstrate the problem.  All asserts
succeed except the last, showing that pickle and
cPickle both handle a "classic" cycle correctly, but
only cPickle handles new-style cycles correctly.  It
would appear that the problem is that the pure-Python
pickle isn't putting the object into its 'memo' until
*after* the object's state has been pickled.  Thus, the
identity is not preserved on unpickling.  This may be
true for other object types that use __reduce__, but I
have not verified this.


import pickle, cPickle

class X: pass

x = X()
x.x = x

x2 = cPickle.loads(cPickle.dumps(x))
assert x2.x is x2

x2 = pickle.loads(pickle.dumps(x))
assert x2.x is x2

class Y(object): pass

y = Y()
y.y = y

y2 = cPickle.loads(cPickle.dumps(y))
assert y2.y is y2

# this fails
y2 = pickle.loads(pickle.dumps(y))
assert y2.y is y2   


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

Comment By: Steven Taschuk (staschuk)
Date: 2003-06-08 14:23

Message:
Logged In: YES 
user_id=666873

Compare bug 702858, which observes the same behaviour for 
copy.deepcopy.

The common parts of pickle and copy really ought to be merged.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 21:29:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 13:29:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-750092 ] exec documentation not updated
Message-ID: <E19P6nD-0008Ep-00@sc8-sf-web2.sourceforge.net>

Bugs item #750092, was opened at 2003-06-06 08:01
Message generated for change (Comment added) made by staschuk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750092&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michele Simionato (michele_s)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec documentation not updated

Initial Comment:
The 2.3b1 reference manual (last update april 25 2003)
still says 
that executable strings must end with a newline, but
this has
been fixed now (finally, it was very annoying :-).

                                                      
                       M.S.

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

Comment By: Steven Taschuk (staschuk)
Date: 2003-06-08 14:29

Message:
Logged In: YES 
user_id=666873

Patch 751038.

http://www.python.org/sf/751038

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750092&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 22:18:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 14:18:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-699079 ] HTMLParser crash on glued tag attributes
Message-ID: <E19P7YM-0001MZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #699079, was opened at 2003-03-06 15:49
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699079&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 1
Submitted By: Artur de Sousa Rocha (adsr)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTMLParser crash on glued tag attributes

Initial Comment:
HTMLParser.HTMLParser and derived classes crash when
two tag attributes are glued like:

WIDTH="512"HEIGHT="83"

Example from IDLE:

>>> import HTMLParser
>>> BUGTEXT = """
<table CELLSPACING="0" CELLPADDING="0" BORDER="0"
WIDTH="100%">
<tr><td align="center">
<table CELLSPACING="0" CELLPADDING="0" BORDER="0"
WIDTH="600" BGCOLOR="white">
<tr><td WIDTH="512">
<img SRC="/pict/img83.jpg" WIDTH="512"HEIGHT="83"
BORDER="0" VSPACE="0" HSPACE="0">
</td><td WIDTH="2"></td>
</tr></table></td></tr></table>
"""
>>> parser = HTMLParser.HTMLParser()
>>> parser.feed(BUGTEXT)
>>> parser.close()
Traceback (most recent call last):
  File "<pyshell#19>", line 1, in ?
    parser.close()
  File "C:\Python22\lib\HTMLParser.py", line 112, in close
    self.goahead(1)
  File "C:\Python22\lib\HTMLParser.py", line 166, in
goahead
    self.error("EOF in middle of construct")
  File "C:\Python22\lib\HTMLParser.py", line 115, in error
    raise HTMLParseError(message, self.getpos())
HTMLParseError: EOF in middle of construct, at line 6,
column 1


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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 14:18

Message:
Logged In: YES 
user_id=357491

Raising an exception for this seems reasonable to me.  It is not 
valid HTML or XML to my knowledge so I don't see the problem 
here.  If there still is one please enlighten me.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699079&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 22:26:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 14:26:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-700055 ] site.py should ignore trailing CRs in .pth files
Message-ID: <E19P7g1-0004gL-00@sc8-sf-web4.sourceforge.net>

Bugs item #700055, was opened at 2003-03-08 11:39
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700055&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Everhart (d_everhart)
Assigned to: Nobody/Anonymous (nobody)
Summary: site.py should ignore trailing CRs in .pth files

Initial Comment:
When site.addpackage(), running on a posix (e.g. 
cygwin or linux) system, reads lines from a .pth file that 
have '\r\n' line terminators, the carriage return character 
interferes with both the import operation and the 
directory appending operation.

The situation can arise, for example, when .pth files 
reside on a network directory that is shared between 
Windows and Posix installations and accessed by 
python interpreters running in both environments.

Suggested change:
replace site.py line 146:
        dir = f.readline()
with
        dir = f.readline().rstrip()
This change also eliminates the need for removing the 
newline at lines 154-155




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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 14:26

Message:
Logged In: YES 
user_id=357491

Would opening the file with universal newlines solve the issue?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700055&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 22:30:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 14:30:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-700827 ] Compiler Limits (indentation)
Message-ID: <E19P7kf-0004oZ-00@sc8-sf-web4.sourceforge.net>

Bugs item #700827, was opened at 2003-03-10 05:43
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Two Inches (twoinches)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler Limits (indentation)

Initial Comment:
The reference manual does not mention the indentation
limits of compiler implementations.

Suggestion: In section 2.1.7 Indentation add the
following at the end of the section:

Implementations may explicity limit the maximum
indentation level. 

For CPython check tokenizer.h for build specifics
(default value is set to 100). 
For Jython check
org.python.parser.PythonGrammerTokenManager (default
value is set to 20).

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 14:30

Message:
Logged In: YES 
user_id=357491

I have no issue adding a comment that the indentation level is 
not infinite, but I don't think it should be mentioned where to 
find it since the reference manual is for the language and not 
any specific implementation.

Anyone else agree?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 22:45:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 14:45:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug
Message-ID: <E19P7yr-0005Ha-00@sc8-sf-web4.sourceforge.net>

Bugs item #702775, was opened at 2003-03-12 22:27
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jane Austine (janeaustine50)
Assigned to: Nobody/Anonymous (nobody)
Summary: dumbdbm __del__ bug

Initial Comment:
I used shelve.py and it falls back on dumbdbm when no
possible alternatives are found on the system.

I found this error, which is recurrent and deterministic:

Exception exceptions.AttributeError: "'NoneType' object 
has no
attribute 'error'" in <bound method _Database.__del__ of
<dumbdbm._Database instance at 0x820c71c>> ignored

The problem seems to reside in the __del__ of 
dumbdbm._Database:

class _Database:
...
    def __del__(self):
        if self._index is not None:
            self._commit()
...
    def _commit(self):
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        f = _open(self._dirfile, 'w', self._mode)
        for key, (pos, siz) in self._index.items():
            f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`))
        f.close()

My investigation showed that the error was from 
_commit. When
it was called, _os or _open was both None. And the 
exception
catch didn't work quite safely cause its in the "except" 
clause.

The reason I suspect is when the time that 
_Database.__del__ was
called the os module(which is imported as _os) is 
already removed out.

I changed the code as:

    def _commit(self):
        global _os
        if _os is None:
            import os as _os
            import __builtin__
            _open = __builtin__.open
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        ......

Now it works without any problems, AFAIK.



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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 14:45

Message:
Logged In: YES 
user_id=357491

OK, so according to Tim all the accessing of _os should be 
removed and instead call instance or class attributes that are 
storing what __del__ is going to need when it is cleaning up by 
calling them off of self since the namespace might be in the 
process of being cleared.  Right?  So 
``_os.unlink(self._bakfile)`` should be something more like 
``self._delattrs['unlink'](self._bakfile)`` where self._delattrs 
stores everything __del__ is going to need.  Or should it just 
store a reference to the os module at self._os since that might be 
a little cleaner looking?

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-25 20:09

Message:
Logged In: YES 
user_id=31435

Neal, this is actually a common problem in __del__ 
methods, and the OP's analysis is on target.  When Python 
is shutting down, it tries to tear down module dicts in a 
safe-as-possible order, but modules are full of reference 
cycles and there is no *wholly* safe order.

In general, a __del__ method should never reference 
globals because of this.  The usual solution can be seen in 
tempfile.py:  store the global objects __del__ will need as 
class attributes when the class is created, and refer to 
these bindings in __del__ via self.attrname 
(ClassName.attrname is also no good, because it refers to 
the global ClassName!  that may also become None).

Reimporting a module instead may not be effective (if it's in 
a partially torn-doiwn state but its name is still a key in 
sys.modules, importing again will just retrieve the partially 
torn-down module object).  The class-attr trick is robust.

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

Comment By: Jane Austine (janeaustine50)
Date: 2003-03-25 20:08

Message:
Logged In: YES 
user_id=732903

Tested on linux and windows xp with Python2.2.2 and 
Python2.3a2. 

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

Comment By: Jane Austine (janeaustine50)
Date: 2003-03-25 20:04

Message:
Logged In: YES 
user_id=732903

Run the main.py in Python 2.3+ putting the two files in the 
same place.

For Python 2.2+, put the two files in the same package and 
make a new file that imports main.py and run it as follows:

=======
from <packagename> import main
=======

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

Comment By: Jane Austine (janeaustine50)
Date: 2003-03-25 19:55

Message:
Logged In: YES 
user_id=732903

A test case that triggers this problem:

#foobar.py
def open(filename, flag='c'):
    import dumbdbm
    return dumbdbm.open(filename,flag)

c=open('test.dbm')

#main.py
import foobar

$ python main.py
>>> 
Exception exceptions.TypeError: "'NoneType' object is not 
callable" in <bound method _Database.__del__ of 
<dumbdbm._Database instance at 0x401e482c>> ignored

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 17:06

Message:
Logged In: YES 
user_id=33168

Can you provide a test case which triggers this problem?  I
can't see how _os becomes None.  Also I would like to add a
test.  Thanks.

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

Comment By: June Kim (juneaftn)
Date: 2003-03-13 09:02

Message:
Logged In: YES 
user_id=116941

see the thread at http://groups.google.com/groups?
selm=ba1e306f.0303111337.72a696c7%
40posting.google.com , esp. by my name.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 22:48:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 14:48:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-704194 ] Problems printing and sleep
Message-ID: <E19P81Z-0002Jt-00@sc8-sf-web3.sourceforge.net>

Bugs item #704194, was opened at 2003-03-15 09:19
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704194&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: ross (zepplin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems printing and sleep

Initial Comment:
When I do the following:

gui = input("Whats your name?")
print gui
Sleep(1000)

I can input my name, but the program then closes.  
Are there any includes or return 0's like in C++?  
Could the above code be my entire program?  It 
seems like I need to start or end the program 
somehow...  Well thanks, sorry if the answer to this is 
already here.  I didn't see anything like it.  And where 
are the forums?

Thanks again.

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 14:48

Message:
Logged In: YES 
user_id=357491

Closing as invalid since the OP never responded to Neal's 
question as to whether this was an actual bug or just not 
understanding how 
something worked.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 16:55

Message:
Logged In: YES 
user_id=33168

This doesn't appear to be a bug, but that you don't
understand how python works.  Is that correct?  If so, there
are several places to ask for help, including the
comp.lang.python newsgroup, python-help@python.org or
tutor@python.org.  You may also want to visit 
http://python.org/doc/Newbies.html

You can "include" other modules with the import statement. 
There is a return statement similar to C.  The code above
can be your entire program in python.
If this is truly a bug, I'm sorry I misunderstood.  Please
close this bug report if it's not a bug though.  Thanks, and
welcome to Python! :-)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704194&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 22:51:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 14:51:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-700827 ] Compiler Limits (indentation)
Message-ID: <E19P84E-0002SV-00@sc8-sf-web1.sourceforge.net>

Bugs item #700827, was opened at 2003-03-10 14:43
Message generated for change (Comment added) made by twoinches
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Two Inches (twoinches)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler Limits (indentation)

Initial Comment:
The reference manual does not mention the indentation
limits of compiler implementations.

Suggestion: In section 2.1.7 Indentation add the
following at the end of the section:

Implementations may explicity limit the maximum
indentation level. 

For CPython check tokenizer.h for build specifics
(default value is set to 100). 
For Jython check
org.python.parser.PythonGrammerTokenManager (default
value is set to 20).

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

>Comment By: Two Inches (twoinches)
Date: 2003-06-08 23:51

Message:
Logged In: YES 
user_id=730363

Agreed. 

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 23:30

Message:
Logged In: YES 
user_id=357491

I have no issue adding a comment that the indentation level is 
not infinite, but I don't think it should be mentioned where to 
find it since the reference manual is for the language and not 
any specific implementation.

Anyone else agree?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 23:19:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 15:19:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-706253 ] python accepts illegal "import mod.sub as name" syntax
Message-ID: <E19P8VW-0006AC-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Nobody/Anonymous (nobody)
Summary: python accepts illegal "import mod.sub as name" syntax

Initial Comment:
http://python.org/doc/current/ref/import.html
"To avoid confusion, you cannot import modules with
dotted names as a different local name. So import
module as m is legal, but import module.submod as s is
not."

sadly the interpreter accepts the illegal form without
comment which makes it "semi-legal".
packages that rely on this illegal form may cause
trouble with costum import implementations (i.e.
importing from zip file or similar)

tested with 2.2.2 and 2.3a2

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 15:19

Message:
Logged In: YES 
user_id=357491

That line seems to have been removed from the 2.3 
documentation as of revision 1.60 but it was not backported.  
Need to find out from Martin v. Lowis whether there is a reason 
he didn't backport it.

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

Comment By: logistix (logistix)
Date: 2003-03-25 14:21

Message:
Logged In: YES 
user_id=699438

Here's a case where I think the documentation should be 
fixed instead of the bug.  Every COM project I do starts 
with 'import win32com.client as client'.  I also don't see how 
one syntax is any more confusing than the other.  And even if 
the above syntax was illegal, you could still do something like:

>>> import win32com.client
>>> server = win32com.client

If you really wanted to be confusing.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706253&group_id=5470


From noreply@sourceforge.net  Sun Jun  8 23:38:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 15:38:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-706450 ] test_socket fails when not connected
Message-ID: <E19P8nm-0003lt-00@sc8-sf-web1.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: Open
Resolution: None
Priority: 5
Submitted By: Michael Stone (mbrierst)
Assigned to: Nobody/Anonymous (nobody)
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: 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@sourceforge.net  Sun Jun  8 23:54:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 15:54:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-713601 ] site.py breaks if prefix is empty
Message-ID: <E19P93N-00049o-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lalo Martins (lalo)
Assigned to: Nobody/Anonymous (nobody)
Summary: site.py breaks if prefix is empty

Initial Comment:
verified in 2.3a1 and 2.2.2:

prefixes = [sys.prefix]
if sys.exec_prefix != sys.prefix:
    prefixes.append(sys.exec_prefix)
for prefix in prefixes:
    if prefix:
        # do stuff - in particular, define the
"sitedir" variable
        # and add site-packages to the path
del prefix, sitedir

if sys.prefix == sys.exec_prefix and both are empty
(which is the case if you compile with --prefix=/ as
for the
Gnu OS for example), this will have two unfortunate
results:

1. site-packages will not be added to the path.

2. site.py will abort with a NameError (it tries to del
sitedir
which isn't defined)

The fix seems to be as simple as removing the "if prefix"
line.  From mailing list archives, it seems to have been
added to cope with unusual loading environments related
to windows and COM - in this case, there is probably a
safer way to check for this condition.  If the prefix is
empty, this just means it's the root, and no further
assumptions should be made.

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 15:54

Message:
Logged In: YES 
user_id=357491

Why is sys.prefix == '' if it is set to '/' as the command-line 
argument?  Checking Modules/getpath.c there appears a few 
places where things could go awry if an enviroment variable is 
set that causes the code to think it has already found the 
location before it reaches what the Makefile set PREFIX and 
EXEC_PREFIX to.  The steps used are in the initial comment of 
the file.  Any of those a possible reason for your problem?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 03:19:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 08 Jun 2003 19:19:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-751124 ] Enhancements to pdb.py when invoked as script
Message-ID: <E19PCFu-0001TN-00@sc8-sf-web3.sourceforge.net>

Bugs item #751124, was opened at 2003-06-08 19: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=751124&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Stork (cst)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhancements to pdb.py when invoked as script

Initial Comment:
Three little enhancements/mini-bugs:

1) Adding the following lines to the "main part" of pdb.py 
gives it the ability to stay in pdb if the program crashes.  
Very handy!

    # Ensure that we end up in pdb if we crash
    def pdb_on_crash(type, value, tb):
        sys.__excepthook__(type, value, tb)
        post_mortem(tb)
    sys.excepthook = pdb_on_crash

2) There's also a problem in the last lines of pdb.py:

    # Insert script directory in front of module search path
    sys.path.insert(0, os.path.dirname(filename))

This leaves the directory path under which pdb.py was 
invoked in sys.path.  This is a problem if pdb.py was 
invoked e.g. via a link a la /usr/pdb.  This leads to the last 
and related suggestion.

3) It would be very convenient if a pyhon installation would 
also install a link /usr/pdb -> /usr/lib/python2.3/pdb.py.  
This provides for easy invocation and, for example, it's also 
the default command used by Emacs' pdb-mode.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751124&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 09:51:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 01:51:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-685773 ] 2 (more) bugs in turtle
Message-ID: <E19PINb-0003j6-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christopher Smith (smichr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: 2 (more) bugs in turtle

Initial Comment:
1) After initiating filling with the fill(1) command, the next fill 
command (e.g. fill(0)) does not cause the filling to take place.  
FIlling does not occur until the next draw statement occurs.

SOLUTION:
###
At the end of the IF block in fill(), put the following lines as 
delimited below with the #-- comment:

    def fill(self, flag):
        if self._filling:
 <cut>
                        self._items.append(item)
                        
                #--cps Addition to force filling.  Filling doesn't occur until 
                #--a move command is issued, so a "move" to the 
                #--present position is being issued to force the 
                #--filling to occur.
                x,y=self._position
                self._goto(x,y)
                #--
        self._path = []
###

2)  The last line of the goto() (not the _goto()) function incorrectly 
computes the x coordinate as x-x0.  You can verify this by issuing 
a goto(0,0) command as the first turtle command:  the turtle 
wanders off of the origin.

SOLUTION The coordinate should be computed as x0+x as shown 
below (again, this is the last line of the goto() function):

        self._goto(x0+x, y0-y)



/c

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-09 03:51

Message:
Logged In: YES 
user_id=80475

Fixed.  See Lib/lib-tk/turtle.py 1.11.

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

Comment By: Christopher Smith (smichr)
Date: 2003-03-01 18:27

Message:
Logged In: YES 
user_id=514525

Regarding #2, I don't know what I was looking at! :-(  I am looking again 
at the code and it is x0+x, y0-y as it should be.  Disregard #2.

/c

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

Comment By: Christopher Smith (smichr)
Date: 2003-02-26 03:21

Message:
Logged In: YES 
user_id=514525

Regarding #1, a better patch has been to name the fill() function as _fill() 
and create a new fill() function as follows:

def fill(self,n):
  self._fill(n)
  self.forward(0) #a null move 

The previous patch from #1 (as I learned) did not fill circles properly.

/c

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685773&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 11:16:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 03:16:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-751260 ] Thread in threading.py can only be started once
Message-ID: <E19PJhA-00073Y-00@sc8-sf-web2.sourceforge.net>

Bugs item #751260, was opened at 2003-06-09 12:16
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=751260&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Schuenzel (yahoo_alive)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread in threading.py can only be started once

Initial Comment:
class Thread doesn't reset self.__started after run() has terminated, so one cannot reuse 
the thread class and run start() again.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 12:13:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 04:13:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-751276 ] cPickle doesn't raise error, pickle does (recursiondepth)
Message-ID: <E19PKay-0000Ha-00@sc8-sf-web3.sourceforge.net>

Bugs item #751276, was opened at 2003-06-09 13: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=751276&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle doesn't raise error, pickle does (recursiondepth)

Initial Comment:
I have this object that causes a recursive call in the
__getattr__ method.

When I unpicke it using pickle, I get a runtimeerror
recursiondepth exceeded. When I unpickle it using
cPickle, everything appears to work -- no error is raised.
(tested on python 2.2.3 and 2.3b1)

The output of the attached python test file is:

***pickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
FAIL!!!  <exceptions.RuntimeError instance at
0x00951C68> maximum recursion depth exceeded
***cPickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
SUCCESS!!! name= myname


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 12:21:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 04:21:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-751279 ] cPickle doesn't raise error, pickle does (UnpicklingError)
Message-ID: <E19PKim-0000c8-00@sc8-sf-web3.sourceforge.net>

Bugs item #751279, was opened at 2003-06-09 13: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=751279&group_id=5470

Category: None
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle doesn't raise error, pickle does (UnpicklingError)

Initial Comment:
I have this object with a __getinitargs__ method. 
When I try to unpickle it using pickle, it raises an
UnpicklingError: not safe for unpickling.
When unpickling with cPickle, everything appears to
work (no error is raised).

Tested on Python 2.2.3.  This issue doesn't appear on
Python 2.3b1.

The output of the attached test script is:

***pickle***
Creating t...
Pickle t...
Restore t...
FAIL!!!  <pickle.UnpicklingError instance at
0x008A2D90> __main__.Thing is not safe for unpickling
***cPickle***
Creating t...
Pickle t...
Restore t...
SUCCESS!!! name= myname


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751279&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 14:33:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 06:33:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-751321 ] Classes inheritig from object are not class type.
Message-ID: <E19PMmH-0005iU-00@sc8-sf-web3.sourceforge.net>

Bugs item #751321, was opened at 2003-06-09 15:33
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=751321&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Wenham (e078120)
Assigned to: Nobody/Anonymous (nobody)
Summary: Classes inheritig from object are not class type. 

Initial Comment:
Isinstance(<classinstance>, types.ClassType) will
return false if the class inherits from object.

Here is a demo:

import types
 
class a:
        def test(self):
                pass
 
class b(object):
        def test(self):
                pass
  
if __name__ == '__main__':
        if isinstance(a, types.ClassType):
                print "a is a class"
        else:
                print "a is not a class"
 
        if isinstance(b, types.ClassType):
                print "b is a class"
        else:
                print "b is not a class"

The output look like this:


roger@linux_lap:~ > python demo.py
a is a class
b is not a class



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751321&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 21:00:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 13:00:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-699079 ] HTMLParser crash on glued tag attributes
Message-ID: <E19PSoN-0006WC-00@sc8-sf-web1.sourceforge.net>

Bugs item #699079, was opened at 2003-03-07 00:49
Message generated for change (Comment added) made by adsr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699079&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 1
Submitted By: Artur de Sousa Rocha (adsr)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTMLParser crash on glued tag attributes

Initial Comment:
HTMLParser.HTMLParser and derived classes crash when
two tag attributes are glued like:

WIDTH="512"HEIGHT="83"

Example from IDLE:

>>> import HTMLParser
>>> BUGTEXT = """
<table CELLSPACING="0" CELLPADDING="0" BORDER="0"
WIDTH="100%">
<tr><td align="center">
<table CELLSPACING="0" CELLPADDING="0" BORDER="0"
WIDTH="600" BGCOLOR="white">
<tr><td WIDTH="512">
<img SRC="/pict/img83.jpg" WIDTH="512"HEIGHT="83"
BORDER="0" VSPACE="0" HSPACE="0">
</td><td WIDTH="2"></td>
</tr></table></td></tr></table>
"""
>>> parser = HTMLParser.HTMLParser()
>>> parser.feed(BUGTEXT)
>>> parser.close()
Traceback (most recent call last):
  File "<pyshell#19>", line 1, in ?
    parser.close()
  File "C:\Python22\lib\HTMLParser.py", line 112, in close
    self.goahead(1)
  File "C:\Python22\lib\HTMLParser.py", line 166, in
goahead
    self.error("EOF in middle of construct")
  File "C:\Python22\lib\HTMLParser.py", line 115, in error
    raise HTMLParseError(message, self.getpos())
HTMLParseError: EOF in middle of construct, at line 6,
column 1


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

>Comment By: Artur de Sousa Rocha (adsr)
Date: 2003-06-09 22:00

Message:
Logged In: YES 
user_id=728207

I agree with bcannon. Tagging as "Not a bug".

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 23:18

Message:
Logged In: YES 
user_id=357491

Raising an exception for this seems reasonable to me.  It is not 
valid HTML or XML to my knowledge so I don't see the problem 
here.  If there still is one please enlighten me.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699079&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 23:44:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 15:44:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19PVMy-0004C8-00@sc8-sf-web3.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 22: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=751612&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 23:51:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 15:51:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19PVTt-0004Pn-00@sc8-sf-web3.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 18:44
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

>Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-09 18:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Mon Jun  9 23:54:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 15:54:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-751260 ] Thread in threading.py can only be started once
Message-ID: <E19PVX6-0004YH-00@sc8-sf-web3.sourceforge.net>

Bugs item #751260, was opened at 2003-06-09 06:16
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Schuenzel (yahoo_alive)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread in threading.py can only be started once

Initial Comment:
class Thread doesn't reset self.__started after run() has terminated, so one cannot reuse 
the thread class and run start() again.


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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-09 18:54

Message:
Logged In: YES 
user_id=31435

It's true that Thread instances can't be restarted, but you 
haven't made a case for calling that "a bug".  Python's 
threading model is fashioned loosely on Java's, and, like 
Java's, limits thread instances to one invocation by design.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 00:25:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 16:25:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19PW0p-0001NB-00@sc8-sf-web4.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 22:44
Message generated for change (Comment added) made by netytan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

>Comment By: mark lee smith (netytan)
Date: 2003-06-09 23:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 22:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 00:39:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 16:39:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19PWEt-0006nU-00@sc8-sf-web1.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 18:44
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-09 19:39

Message:
Logged In: YES 
user_id=31435

I don't understand.  If you're not running an SMTP server on 
localhost, I expect that example to die with

socket.error: (10061, 'Connection refused')

And indeed, that's what it does when I try it on Win98SE.  So 
I conclude you must have changed the example in some way.  
If so, the solution to your problem will be found in the details 
of you changed it.  Nobody can guess that, so please attach 
the code you actually ran.

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

Comment By: mark lee smith (netytan)
Date: 2003-06-09 19:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 18:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 00:45:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 16:45:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19PWKJ-0006wK-00@sc8-sf-web1.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 18:44
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-09 19:45

Message:
Logged In: YES 
user_id=31435

I'll show you what I'm looking for:  attached is the exact code 
I just ran, in smtpex.py, and a screen dump from running it, in 
tcap.txt.  I changed the example to use comcast.net's SMTP 
server.  It worked fine for me on Win98SE.  I was using 
Python 2.2.3, and don't know whether that makes a 
difference.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 19:39

Message:
Logged In: YES 
user_id=31435

I don't understand.  If you're not running an SMTP server on 
localhost, I expect that example to die with

socket.error: (10061, 'Connection refused')

And indeed, that's what it does when I try it on Win98SE.  So 
I conclude you must have changed the example in some way.  
If so, the solution to your problem will be found in the details 
of you changed it.  Nobody can guess that, so please attach 
the code you actually ran.

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

Comment By: mark lee smith (netytan)
Date: 2003-06-09 19:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 18:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 00:47:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 16:47:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19PWLv-0006zG-00@sc8-sf-web1.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 18:44
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-09 19:47

Message:
Logged In: YES 
user_id=31435

Just attaching tcap.txt.  Note that on Windows, you have to 
end the msg with Ctrl-Z (not the Unixish Ctrl-D in the example 
comments).

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 19:45

Message:
Logged In: YES 
user_id=31435

I'll show you what I'm looking for:  attached is the exact code 
I just ran, in smtpex.py, and a screen dump from running it, in 
tcap.txt.  I changed the example to use comcast.net's SMTP 
server.  It worked fine for me on Win98SE.  I was using 
Python 2.2.3, and don't know whether that makes a 
difference.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 19:39

Message:
Logged In: YES 
user_id=31435

I don't understand.  If you're not running an SMTP server on 
localhost, I expect that example to die with

socket.error: (10061, 'Connection refused')

And indeed, that's what it does when I try it on Win98SE.  So 
I conclude you must have changed the example in some way.  
If so, the solution to your problem will be found in the details 
of you changed it.  Nobody can guess that, so please attach 
the code you actually ran.

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

Comment By: mark lee smith (netytan)
Date: 2003-06-09 19:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 18:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 07:51:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 09 Jun 2003 23:51:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-751758 ] ftplib.retrbinary fails when called from retrlines callback
Message-ID: <E19PcyL-0003TL-00@sc8-sf-web2.sourceforge.net>

Bugs item #751758, was opened at 2003-06-10 01: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=751758&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Long (christianmlong)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib.retrbinary fails when called from retrlines callback

Initial Comment:

Subject: ftplib.retrbinary() fails when called from
inside retrlines() callback function

I'm using ftplib to backup files from a Linux server to
a Windows 2000 worksation. 


Client:  
Windows 2000 Pro
ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on
Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit
(Intel)] on win32
Komodo IDE

Server:
ProFTP server (ProFTPd version 1.25) 
Mandrake Linux 9.0


Summary:

When I use it like this it works fine.

# Build a list of files that are on the remote server
f.retrlines('NLST', makeListOfFiles)

--then--
# Iterate over the list, retrieving each file
for remoteFileName in listOfFiles:
    --snip--
    f.retrbinary('RETR %s' % remoteFileName,
localFile.write)
    --snip--


But it fails if I try to do the retrieve directly in my
callback function.

def transferFile(listLine):
    --snip--
    f.retrbinary('RETR %s' % remoteFileName,
localFile.write)  <--fails here on first time through
    --snip--

# get list of files from server, adn transfer each file
as it gets listed
f.retrlines('LIST', transferFile)

--snip--
  File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
45, in ?
    f.retrlines('LIST', transferFile)
  File "C:\Python22\lib\ftplib.py", line 413, in retrlines
    callback(line)
  File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
36, in transferFile
    f.retrbinary('RETR mra.py', localFile.write)
--snip--
  File "C:\Python22\lib\ftplib.py", line 300, in makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python22\lib\ftplib.py", line 572, in parse227
    raise error_reply, resp
error_reply: 200 Type set to I.


It looks like the server is returning a 200 instead of
a 227 when retrbinary() is called inside a callback
function for retrlines().



Files:

2 Files are included:  a broken version and a version
that works

This One Is Broken -  retrbinary() called from inside a
callback function for retrlines().
===================================================
import ftplib
import os
import time

REMOTE_DIR = "/home/mydir"
LOCAL_DIR = "C:\My Documents"
TIME_FORMAT = "%y%m%d"    # YYMMDD, like 030522

def transferFile(listLine):
    # Strips the file name from a line of a
    # directory listing, and gets it from the
    # server.  Depends on filenames
    # with no embedded spaces or extra dots.
    if listLine.endswith('.py'):
        #Split file name on the dot
        splitFileName=remoteFileName.split('.')
        # Add a timestamp
        localFileName="%s_%s.%s" % (splitFileName[0],
                                   
time.strftime(TIME_FORMAT),
                                    splitFileName[1])
        # Open a local file for (over)writing, in
binary mode.
        # print os.path.join(LOCAL_DIR,localFileName)
       
localFile=file(os.path.join(LOCAL_DIR,localFileName), 'wb')
        print remoteFileName
        print localFile
        # Execute the FTP retrieve command, calling
        # the write() function of the local file
        # for each block retrieved from the FTP server
        # BUG: This should work, but I get the
following traceback
        f.retrbinary('RETR %s' % remoteFileName,
localFile.write)    #<--- Fails
                                                      
              #     Here

#        mra.py
#<open file 'D:\My
Documents\Work\IA\Miller\MRA\Dev\Backup of remote
files\mra_030610.py', mode 'wb' at 0x00886B70>
#Traceback (most recent call last):
#  File "C:\Program Files\ActiveState Komodo
2.3\callkomodo\kdb.py", line 430, in _do_start
#    self.kdb.run(code_ob, locals, locals)
#  File "C:\Python22\lib\bdb.py", line 349, in run
#    exec cmd in globals, locals
#  File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
45, in ?
#    f.retrlines('LIST', transferFile)
#  File "C:\Python22\lib\ftplib.py", line 413, in retrlines
#    callback(line)
#  File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
36, in transferFile
#    f.retrbinary('RETR mra.py', localFile.write)
#  File "C:\Python22\lib\ftplib.py", line 385, in
retrbinary
#    conn = self.transfercmd(cmd, rest)
#  File "C:\Python22\lib\ftplib.py", line 346, in
transfercmd
#    return self.ntransfercmd(cmd, rest)[0]
#  File "C:\Python22\lib\ftplib.py", line 322, in
ntransfercmd
#    host, port = self.makepasv()
#  File "C:\Python22\lib\ftplib.py", line 300, in makepasv
#    host, port = parse227(self.sendcmd('PASV'))
#  File "C:\Python22\lib\ftplib.py", line 572, in parse227
#    raise error_reply, resp
#error_reply: 200 Type set to I.

# The problem is that the self.sendcmd('PASV') call is
not getting a 227
# reply from the server.  Rather, it is getting a 200
reply, confirming
# that the type was set to I (Image).


        localFile.flush()
        localFile.close()

f=ftplib.FTP('server', 'user', 'password')
f.cwd(REMOTE_DIR)
# List directory contents, and call the transferFile
# function on each line in the listing
f.retrlines('LIST', transferFile)

f.close()




===================================================



This One Works - retlines() builds a list, and then
files are transferred by iterating over
that list and calling retrbinary() for each.
===================================================
import ftplib
import os
import time

REMOTE_DIR = "/home/mydir"
LOCAL_DIR = "C:\My Documents"
TIME_FORMAT = "%y%m%d"    # YYMMDD, like 030522

listOfFiles = []

def makeListOfFiles(remoteFileName):
    # Strips the file name from a line of a
    # directory listing, and gets file from the
    # server.  Depends on filenames
    # with no embedded spaces or extra dots.
    if remoteFileName.endswith('.py'):
        listOfFiles.append(remoteFileName)

f=ftplib.FTP('server', 'user', 'password')
f.cwd(REMOTE_DIR)
# List directory contents, and call the transferFile
# function on each line in the listing
f.retrlines('NLST', makeListOfFiles)
print listOfFiles

for remoteFileName in listOfFiles:
    #Split file name on the dot
    splitFileName=remoteFileName.split('.')
    # Add a timestamp
    localFileName="%s_%s.%s" % (splitFileName[0],
                                time.strftime(TIME_FORMAT),
                                splitFileName[1])
    # Open a local file for (over)writing, in binary mode.
    # print os.path.join(LOCAL_DIR,localFileName)
   
localFile=file(os.path.join(LOCAL_DIR,localFileName), 'wb')

    # Execute the FTP retrieve command, calling
    # the write() function of the local file
    # for each block retrieved from the FTP server
    f.retrbinary('RETR %s' % remoteFileName,
localFile.write)
    localFile.flush()
    localFile.close()

f.close()





===================================================

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751758&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 08:56:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 00:56:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-751793 ] Re module cannot be loaded in restricted mode
Message-ID: <E19PdzG-0005pB-00@sc8-sf-web2.sourceforge.net>

Bugs item #751793, was opened at 2003-06-10 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=751793&group_id=5470

Category: Regular Expressions
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Fredrik Lundh (effbot)
Summary: Re module cannot be loaded in restricted mode

Initial Comment:
If you try to use regular expressions in restricted mode, 
you get the error "'module' object has no 
attribute 'hexversion'". Try with:

import rexec
rexec.RExec().r_exec("import re")

Suggestion: Add 'hexversion' to allowed sys attributes 
in /usr/lib/python/rexec.py:

    ok_sys_names = 
('ps1', 'ps2', 'copyright', 'version', 'hexversion',
                    'platform', 'exit', 'maxint')


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751793&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 13:48:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 05:48:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-751894 ] int()
Message-ID: <E19PiYC-0007YB-00@sc8-sf-web3.sourceforge.net>

Bugs item #751894, was opened at 2003-06-10 14: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=751894&group_id=5470

Category: None
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hartmut Fröls (froels)
Assigned to: Nobody/Anonymous (nobody)
Summary: int()

Initial Comment:
Seems to me like an error in int():

Python 2.2.3 (#1, Jun  5 2003, 21:12:33)
ÄGCC 3.2.3Ü on aix4
Type "help", "copyright", "credits" or "license" for
more information.

>>> print int((4.3 % 1)*10)
2
>>> print 4.3 % 1
0.3
>>> print 4.3 % 1 * 10
3.0
>>> print int(4.3 % 1 * 10)
2

Is this a bug ???

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751894&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 15:13:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 07:13:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-751933 ] 2.2.3 Latex documentation missing from web page?
Message-ID: <E19PjsH-0000gY-00@sc8-sf-web4.sourceforge.net>

Bugs item #751933, was opened at 2003-06-10 14: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=751933&group_id=5470

Category: Documentation
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.2.3 Latex documentation missing from web page?

Initial Comment:
The files named latex-2.2.3.tgz and latex-2.2.3.tar.bz2 in
ftp://python.org/pub/python/doc/2.2.3 appear to contain
documentation for Python 2.3b1 and not for Python 2.2.3.
Is the LaTeX version of the Python 2.2.3 documentation
available elsewhere?

Thanks,

Mark

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751933&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 15:14:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 07:14:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-751894 ] int()
Message-ID: <E19PjtN-0006cX-00@sc8-sf-web2.sourceforge.net>

Bugs item #751894, was opened at 2003-06-10 08:48
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751894&group_id=5470

Category: None
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hartmut Fröls (froels)
Assigned to: Nobody/Anonymous (nobody)
Summary: int()

Initial Comment:
Seems to me like an error in int():

Python 2.2.3 (#1, Jun  5 2003, 21:12:33)
ÄGCC 3.2.3Ü on aix4
Type "help", "copyright", "credits" or "license" for
more information.

>>> print int((4.3 % 1)*10)
2
>>> print 4.3 % 1
0.3
>>> print 4.3 % 1 * 10
3.0
>>> print int(4.3 % 1 * 10)
2

Is this a bug ???

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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-10 10:14

Message:
Logged In: YES 
user_id=31435

Try displaying the penultimate result to full precision.  On my 
box I get this:

>>> 4.3 % 1 * 10
2.9999999999999982
>>>


int() of that is 2.  What do you get?  And have you read the 
Python Tutorial appendix on floating-point issues?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751894&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 15:27:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 07:27:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-751941 ] Invisible HTML tag
Message-ID: <E19Pk5q-00045d-00@sc8-sf-web3.sourceforge.net>

Bugs item #751941, was opened at 2003-06-10 10: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=751941&group_id=5470

Category: Documentation
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invisible HTML tag

Initial Comment:
In the current on-line documentation for the library,
in URL

http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-9

It says under classmethod(), 2nd to last sentence, "If
you want those, see ."  The HTML source has the tag
<tex2html_cross_ref_visible_mark> which doesn't display
in my browser (Mozilla 1.0.1 for Linux).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751941&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 15:47:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 07:47:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-751956 ] graminit.[ch] don't build on windows
Message-ID: <E19PkPM-0006uF-00@sc8-sf-web1.sourceforge.net>

Bugs item #751956, was opened at 2003-06-10 14: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=751956&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Booth (duncanb)
Assigned to: Nobody/Anonymous (nobody)
Summary: graminit.[ch] don't build on windows

Initial Comment:
Using grammar.mak to build new graminit.c and 
graminit.h files doesn't currently work on windows.

The line in grammar.mak:

CFLAGS= /I ..\Include /I ..\PC /D 
MS_NO_COREDLL  /MD

needs to be changed to:

CFLAGS= /I ..\Include /I ..\PC /D 
MS_NO_COREDLL /D PGEN /MD

otherwise you get an undefined symbol when 
attempting to link caused by a reference to 
PyExc_DeprecationWarning in tokenizer.c.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751956&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 16:55:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 08:55:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19PlSh-0000F6-00@sc8-sf-web3.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 10: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=751998&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 18:05:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 10:05:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete
Message-ID: <E19PmYr-0007A7-00@sc8-sf-web2.sourceforge.net>

Bugs item #742911, was opened at 2003-05-24 17:29
Message generated for change (Comment added) made by jacobs99
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Memory fault on complex weakref/weakkeydict delete

Initial Comment:
Attached find two modules which together form a
test-case.  The cache.py file is ripped out of a
production system (OpenGLContext), and I am seeing
memory faults under both Python 2.2.2 and 2.2.3 when I
run the code.  Under 2.2.2 while single-stepping
through the code I was able to provoke an error-message:

Fatal Python error: GC object already in linked list

The error message doesn't show up under 2.2.3, but the
memory-fault does.

Modules here don't use any extension modules, so there
shouldn't be any loose memory references or the like. 
Note, you'll likely need to make weakkeydictionary's
__delitem__ use keys instead of iterkeys to even get to
the crashing.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 12:05

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve this problem causes a potentially 
more serious one in Bug 751998.  In short, it seems that 
data descriptors become unavailable in __del__  methods,
preventing finalization from completing.  I have yet to figure 
out why, though I have isolated the problem to revision 2.234
of typeobject.c.  I've not looked to see if this also affects
Python 2.2.3, though I wouldn't be too suprised if it does.


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

Comment By: Tim Peters (tim_one)
Date: 2003-06-01 00:21

Message:
Logged In: YES 
user_id=31435

Which service pack <wink>?  Thanks for reporting this in 
time for 2.2.3, Mike.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-05-31 14:21

Message:
Logged In: YES 
user_id=34901

2.2.3 fixes the original problem on Win2k.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-29 16:35

Message:
Logged In: YES 
user_id=33168

2.3 works for me with the original, but didn't before. 
Redhat 9.

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

Comment By: Jeff Epler (jepler)
Date: 2003-05-29 15:47

Message:
Logged In: YES 
user_id=2772

Just one question: does the final test-case cover the
original bug?  I have a redhat 9 system with Python 2.2.2,
and temp2.py runs just fine:
$ python2 temp2.py 
<__main__.Oops object at 0x8162ecc>
$

The Python version is:
Python 2.2.2 (#1, Feb 24 2003, 19:13:11) 
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2

I have not tried any other version of the test-case.  I also
didn't try a non-redhat version, so it's barely possible
that some patch they apply affected this issue.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-29 09:53

Message:
Logged In: YES 
user_id=31435

Just changed Resolution to Fixed.  Thanks everyone!

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-29 09:35

Message:
Logged In: YES 
user_id=6380

Thanks to Tim for the analysis, to Neal for the simplified
test, and to Mike for the bug report! The fix was actually
simple: clear the weak ref list *before* calling __del__ or
clearing __dict__. This is the same order as used by classic
classes, so can't be wrong. Applied to 2.2.3 branch and 2.3
trunk, with test case.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-05-28 20:16

Message:
Logged In: YES 
user_id=34901

To give timeline: This is from real-life code (PyOpenGL's
OpenGLContext demo/teaching module).  It's currently about
to go beta, with a release date target of end-of-summer. 
I've worked around the problem for the most common case w/in
the system (exiting from the VRML browser), but that
work-around's not usable for end-user long-running projects
until the users can deallocate the scenegraph to load
another (i.e. go from world to world within a single run of
the application).

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-28 18:26

Message:
Logged In: YES 
user_id=31435

That's cool.  The analysis is much easier to follow if you run 
Neal's little program, which crashes right away in a debug 
build.  Then the analysis just follows the call stack, and it's 
instantly obvious (if you know to look for it <wink>) that 
we're trying to deallocate a single object twice.

One thing subtype_delloc does that instance_dealloc 
doesn't is clear the instance dict before clearing the 
weakrefs.  Clearing the instance dict can end up executing 
anything, and in this case does, in particular materializing a 
strong reference to the object we're in the middle of 
deallocating (via a weakref that hasn't been cleared).  That 
seems to be the key point.

Mike found the problem in 2.2.2, I believe in his real-life 
OpenGL code.  That's why I'm keen to see it fixed for 2.2.3.

I'll be in the office Thursday, BTW.

Ah, here, I'll attach a simpler program that has the same 
kind of problem (temp2.py).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-28 17:16

Message:
Logged In: YES 
user_id=6380

Tim, let's look at this when you're back in the office. My
head spins from just reading the analysis below.

Note that this is a 2.2 and 2.3 bug. I don't necessarily
want to hold up the 2.2.3 release until this is fixed,
unless we have a quick breakthrough.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-24 23:49

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I suspect the problem lies in 
the order subtype_dealloc does things.

With reference to Neal's whittled-down case:  when 
makeSome() ends, we decref i and then decref item.  item's 
refcount hits 0 then.  There's a weakref remaining to item 
(in CacheHolder.client), but subtype_dealloc doesn't clear 
the weakref at this point.  First it clears item's instance 
dict.  That contains the last strong reference to i.  
subtype_dealloc is inovked again, and clears i's instance 
dict, and then deals with the weak reference to i.  The 
weakref to i has a callback associated with it, and 
CacheHolder.__call__() is invoked.  That invokes self.client
(), still a weakref to item, and because item's weakrefs still 
haven't been dealt with, self.client() returns item.

Now we're hosed.  item *had* a refcount of 0 at this point, 
and is still in the process of getting cleaned out by the first 
call to subtype_dealloc (it still thinks it's clearing item's 
instance dict).  We already called _Py_ForgetReference on 
item when its refcount fell to 0.  Its refcount gets boosted 
back to 1 by virtue of item getting returned by the 
self.client() weakref call.  Cleaning out the frame for 
CacheHolder.__call__() knocks the refcount down to 0 
again, and the second attempt to call _Py_ForgetReference 
on it blows up.

In a release build, nothing visibly bad happens when I try 
it.  It crashes if I add

        print client.items

at the end of __call__ in a release-build run, though.  Looks 
like that's just the luck of the draw after things have gone 
insane.

I note that instance_dealloc deals with weakrefs much 
earlier in the process, so that when Neal makes Items a 
classic class instead, the eventual call to self.client() 
returns None (instead of items), and nothing bad happens.. 

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-24 21:53

Message:
Logged In: YES 
user_id=31435

Outstanding, Neal -- thanks!  I can confirm that this crashes 
in a current 2.3 debug build on Windows too.  I'm feeling 
sick and won't pursue it now, though.  When cleaning up 
from the call to makeSome() (the body of makeSome() has 
completed, and we're cleaning up its execution frame, 
decref'ing the locals), we're dying in _Py_ForgetReference 
with a NULL-pointer derefernce.  The refcount on an Items 
object has just fallen to 0, and the code is trying to verify 
that the object is in the debug-build "list of all objects".  But 
its prev and next pointers are both NULL -- it's not in the 
list, and simply trying to check that it is blows up.

I don't have a theory for what's causing this, but it's 
probably not a good thing <heh>.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-24 18:31

Message:
Logged In: YES 
user_id=33168

I cut out a lot of stuff from the test.  The new file is
much more minimal, but still crashes for me in a 2.3 debug
build.  You only need the one file too (not both files).

There is an issue with new style classes.  If Items doesn't
derive from object, I don't get a crash.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 18:07:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 10:07:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19PmaP-0005Wo-00@sc8-sf-web1.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 10:55
Message generated for change (Comment added) made by jacobs99
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


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

>Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 12:07

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve Bug 751998 is the cause of this
potentially more serious one bug.  I have yet to figure 
out why, though I have isolated the problem to revision
2.234 of typeobject.c.  I've not looked to see if this also 
affects Python 2.2.3, though I wouldn't be too suprised if it 
does.

More soon, hopefully.  Maybe...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 19:07:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 11:07:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-751321 ] Classes inheritig from object are not class type.
Message-ID: <E19PnWn-0001mu-00@sc8-sf-web2.sourceforge.net>

Bugs item #751321, was opened at 2003-06-09 15:33
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751321&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Wenham (e078120)
Assigned to: Nobody/Anonymous (nobody)
Summary: Classes inheritig from object are not class type. 

Initial Comment:
Isinstance(<classinstance>, types.ClassType) will
return false if the class inherits from object.

Here is a demo:

import types
 
class a:
        def test(self):
                pass
 
class b(object):
        def test(self):
                pass
  
if __name__ == '__main__':
        if isinstance(a, types.ClassType):
                print "a is a class"
        else:
                print "a is not a class"
 
        if isinstance(b, types.ClassType):
                print "b is a class"
        else:
                print "b is not a class"

The output look like this:


roger@linux_lap:~ > python demo.py
a is a class
b is not a class



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

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-10 20:07

Message:
Logged In: YES 
user_id=89016

The reason for this is that new style classes have a
different meta class than classic classes. This is
documented in http://www.python.org/2.2.3/descrintro.html:
"""The built-in 'type' is the most common metaclass; it is
the metaclass of all built-in types. Classic classes use a
different metaclass: the type known as types.ClassType."""

Why do you think this is a bug?


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751321&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 19:09:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 11:09:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19PnYd-0008Ui-00@sc8-sf-web1.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 11:55
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 6
Submitted By: Kevin Jacobs (jacobs99)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:07

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve Bug 751998 is the cause of this
potentially more serious one bug.  I have yet to figure 
out why, though I have isolated the problem to revision
2.234 of typeobject.c.  I've not looked to see if this also 
affects Python 2.2.3, though I wouldn't be too suprised if it 
does.

More soon, hopefully.  Maybe...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 19:19:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 11:19:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19PniL-0006uo-00@sc8-sf-web3.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 10:55
Message generated for change (Comment added) made by jacobs99
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


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

>Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:19

Message:
Logged In: YES 
user_id=459565

Okay, I had a few minutes free.  The problem is that
slots are being deallocated too early -- before tp_dealloc.
I'm attaching a patch that corrects this at the expense of
having to travel up the path of base class tp_dealloc
entries twice.  Here is the new sequence of actions:

1) Find the nearest base with a different tp_dealloc
2) Clear weakrefs
3) Call finalizer
4) Check to see if object was resurrected, if so stop
5) Clear all slots up to nearest base with a different 
    tp_dealloc
6) DECREF dict pointer, if necessary
7) proceed as usual... (call basedealloc, DECREF type, etc.)

Without my patch, step number 5  is done as part of step
1, and bad things happen.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 12:07

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve Bug 751998 is the cause of this
potentially more serious one bug.  I have yet to figure 
out why, though I have isolated the problem to revision
2.234 of typeobject.c.  I've not looked to see if this also 
affects Python 2.2.3, though I wouldn't be too suprised if it 
does.

More soon, hopefully.  Maybe...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 19:21:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 11:21:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19Pnjx-00070H-00@sc8-sf-web3.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 10:55
Message generated for change (Comment added) made by jacobs99
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


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

>Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:21

Message:
Logged In: YES 
user_id=459565

Oh, and with the patch, 'make test' completes without
any new errors, my attached test case works, as does
the minimal test case associated with Bug 751998.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:19

Message:
Logged In: YES 
user_id=459565

Okay, I had a few minutes free.  The problem is that
slots are being deallocated too early -- before tp_dealloc.
I'm attaching a patch that corrects this at the expense of
having to travel up the path of base class tp_dealloc
entries twice.  Here is the new sequence of actions:

1) Find the nearest base with a different tp_dealloc
2) Clear weakrefs
3) Call finalizer
4) Check to see if object was resurrected, if so stop
5) Clear all slots up to nearest base with a different 
    tp_dealloc
6) DECREF dict pointer, if necessary
7) proceed as usual... (call basedealloc, DECREF type, etc.)

Without my patch, step number 5  is done as part of step
1, and bad things happen.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 12:07

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve Bug 751998 is the cause of this
potentially more serious one bug.  I have yet to figure 
out why, though I have isolated the problem to revision
2.234 of typeobject.c.  I've not looked to see if this also 
affects Python 2.2.3, though I wouldn't be too suprised if it 
does.

More soon, hopefully.  Maybe...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 19:24:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 11:24:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19PnnG-0000ox-00@sc8-sf-web1.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 10:55
Message generated for change (Comment added) made by jacobs99
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


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

>Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:24

Message:
Logged In: YES 
user_id=459565

er, see Bug 742911 instead.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:21

Message:
Logged In: YES 
user_id=459565

Oh, and with the patch, 'make test' completes without
any new errors, my attached test case works, as does
the minimal test case associated with Bug 751998.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:19

Message:
Logged In: YES 
user_id=459565

Okay, I had a few minutes free.  The problem is that
slots are being deallocated too early -- before tp_dealloc.
I'm attaching a patch that corrects this at the expense of
having to travel up the path of base class tp_dealloc
entries twice.  Here is the new sequence of actions:

1) Find the nearest base with a different tp_dealloc
2) Clear weakrefs
3) Call finalizer
4) Check to see if object was resurrected, if so stop
5) Clear all slots up to nearest base with a different 
    tp_dealloc
6) DECREF dict pointer, if necessary
7) proceed as usual... (call basedealloc, DECREF type, etc.)

Without my patch, step number 5  is done as part of step
1, and bad things happen.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 12:07

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve Bug 751998 is the cause of this
potentially more serious one bug.  I have yet to figure 
out why, though I have isolated the problem to revision
2.234 of typeobject.c.  I've not looked to see if this also 
affects Python 2.2.3, though I wouldn't be too suprised if it 
does.

More soon, hopefully.  Maybe...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 19:25:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 11:25:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete
Message-ID: <E19PnoM-0007DE-00@sc8-sf-web3.sourceforge.net>

Bugs item #742911, was opened at 2003-05-24 17:29
Message generated for change (Comment added) made by jacobs99
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Memory fault on complex weakref/weakkeydict delete

Initial Comment:
Attached find two modules which together form a
test-case.  The cache.py file is ripped out of a
production system (OpenGLContext), and I am seeing
memory faults under both Python 2.2.2 and 2.2.3 when I
run the code.  Under 2.2.2 while single-stepping
through the code I was able to provoke an error-message:

Fatal Python error: GC object already in linked list

The error message doesn't show up under 2.2.3, but the
memory-fault does.

Modules here don't use any extension modules, so there
shouldn't be any loose memory references or the like. 
Note, you'll likely need to make weakkeydictionary's
__delitem__ use keys instead of iterkeys to even get to
the crashing.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:25

Message:
Logged In: YES 
user_id=459565

See patch attached to bug 751998 for an alternative,
friendlier fix for this bug.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 12:05

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve this problem causes a potentially 
more serious one in Bug 751998.  In short, it seems that 
data descriptors become unavailable in __del__  methods,
preventing finalization from completing.  I have yet to figure 
out why, though I have isolated the problem to revision 2.234
of typeobject.c.  I've not looked to see if this also affects
Python 2.2.3, though I wouldn't be too suprised if it does.


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

Comment By: Tim Peters (tim_one)
Date: 2003-06-01 00:21

Message:
Logged In: YES 
user_id=31435

Which service pack <wink>?  Thanks for reporting this in 
time for 2.2.3, Mike.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-05-31 14:21

Message:
Logged In: YES 
user_id=34901

2.2.3 fixes the original problem on Win2k.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-29 16:35

Message:
Logged In: YES 
user_id=33168

2.3 works for me with the original, but didn't before. 
Redhat 9.

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

Comment By: Jeff Epler (jepler)
Date: 2003-05-29 15:47

Message:
Logged In: YES 
user_id=2772

Just one question: does the final test-case cover the
original bug?  I have a redhat 9 system with Python 2.2.2,
and temp2.py runs just fine:
$ python2 temp2.py 
<__main__.Oops object at 0x8162ecc>
$

The Python version is:
Python 2.2.2 (#1, Feb 24 2003, 19:13:11) 
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2

I have not tried any other version of the test-case.  I also
didn't try a non-redhat version, so it's barely possible
that some patch they apply affected this issue.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-29 09:53

Message:
Logged In: YES 
user_id=31435

Just changed Resolution to Fixed.  Thanks everyone!

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-29 09:35

Message:
Logged In: YES 
user_id=6380

Thanks to Tim for the analysis, to Neal for the simplified
test, and to Mike for the bug report! The fix was actually
simple: clear the weak ref list *before* calling __del__ or
clearing __dict__. This is the same order as used by classic
classes, so can't be wrong. Applied to 2.2.3 branch and 2.3
trunk, with test case.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-05-28 20:16

Message:
Logged In: YES 
user_id=34901

To give timeline: This is from real-life code (PyOpenGL's
OpenGLContext demo/teaching module).  It's currently about
to go beta, with a release date target of end-of-summer. 
I've worked around the problem for the most common case w/in
the system (exiting from the VRML browser), but that
work-around's not usable for end-user long-running projects
until the users can deallocate the scenegraph to load
another (i.e. go from world to world within a single run of
the application).

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-28 18:26

Message:
Logged In: YES 
user_id=31435

That's cool.  The analysis is much easier to follow if you run 
Neal's little program, which crashes right away in a debug 
build.  Then the analysis just follows the call stack, and it's 
instantly obvious (if you know to look for it <wink>) that 
we're trying to deallocate a single object twice.

One thing subtype_delloc does that instance_dealloc 
doesn't is clear the instance dict before clearing the 
weakrefs.  Clearing the instance dict can end up executing 
anything, and in this case does, in particular materializing a 
strong reference to the object we're in the middle of 
deallocating (via a weakref that hasn't been cleared).  That 
seems to be the key point.

Mike found the problem in 2.2.2, I believe in his real-life 
OpenGL code.  That's why I'm keen to see it fixed for 2.2.3.

I'll be in the office Thursday, BTW.

Ah, here, I'll attach a simpler program that has the same 
kind of problem (temp2.py).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-28 17:16

Message:
Logged In: YES 
user_id=6380

Tim, let's look at this when you're back in the office. My
head spins from just reading the analysis below.

Note that this is a 2.2 and 2.3 bug. I don't necessarily
want to hold up the 2.2.3 release until this is fixed,
unless we have a quick breakthrough.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-24 23:49

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I suspect the problem lies in 
the order subtype_dealloc does things.

With reference to Neal's whittled-down case:  when 
makeSome() ends, we decref i and then decref item.  item's 
refcount hits 0 then.  There's a weakref remaining to item 
(in CacheHolder.client), but subtype_dealloc doesn't clear 
the weakref at this point.  First it clears item's instance 
dict.  That contains the last strong reference to i.  
subtype_dealloc is inovked again, and clears i's instance 
dict, and then deals with the weak reference to i.  The 
weakref to i has a callback associated with it, and 
CacheHolder.__call__() is invoked.  That invokes self.client
(), still a weakref to item, and because item's weakrefs still 
haven't been dealt with, self.client() returns item.

Now we're hosed.  item *had* a refcount of 0 at this point, 
and is still in the process of getting cleaned out by the first 
call to subtype_dealloc (it still thinks it's clearing item's 
instance dict).  We already called _Py_ForgetReference on 
item when its refcount fell to 0.  Its refcount gets boosted 
back to 1 by virtue of item getting returned by the 
self.client() weakref call.  Cleaning out the frame for 
CacheHolder.__call__() knocks the refcount down to 0 
again, and the second attempt to call _Py_ForgetReference 
on it blows up.

In a release build, nothing visibly bad happens when I try 
it.  It crashes if I add

        print client.items

at the end of __call__ in a release-build run, though.  Looks 
like that's just the luck of the draw after things have gone 
insane.

I note that instance_dealloc deals with weakrefs much 
earlier in the process, so that when Neal makes Items a 
classic class instead, the eventual call to self.client() 
returns None (instead of items), and nothing bad happens.. 

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-24 21:53

Message:
Logged In: YES 
user_id=31435

Outstanding, Neal -- thanks!  I can confirm that this crashes 
in a current 2.3 debug build on Windows too.  I'm feeling 
sick and won't pursue it now, though.  When cleaning up 
from the call to makeSome() (the body of makeSome() has 
completed, and we're cleaning up its execution frame, 
decref'ing the locals), we're dying in _Py_ForgetReference 
with a NULL-pointer derefernce.  The refcount on an Items 
object has just fallen to 0, and the code is trying to verify 
that the object is in the debug-build "list of all objects".  But 
its prev and next pointers are both NULL -- it's not in the 
list, and simply trying to check that it is blows up.

I don't have a theory for what's causing this, but it's 
probably not a good thing <heh>.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-24 18:31

Message:
Logged In: YES 
user_id=33168

I cut out a lot of stuff from the test.  The new file is
much more minimal, but still crashes for me in a 2.3 debug
build.  You only need the one file too (not both files).

There is an issue with new style classes.  If Items doesn't
derive from object, I don't get a crash.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 22:34:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 14:34:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-723540 ] __slots__ broken in 2.3a with ("__dict__", )
Message-ID: <E19Pql4-0005ms-00@sc8-sf-web4.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Douglas Napoleone (derivin)
Assigned to: Nobody/Anonymous (nobody)
Summary: __slots__ broken in 2.3a with ("__dict__", )

Initial Comment:
I LOVE using __slots__. I love using properties.
I made my own extension and metaclass so I could 
define type safe properties in classes. I could stick 
properties on a class and have them accessed 
seperatly from slots (because they are properties and 
not attributes). The properties call setter/getters and 
store the data in __dict__ (a cheezy means of making 
pickle still work with no effort). thus I had __slots__ = 
('__dict__', ) in my base class. this worked great in 2.2 
and 2.2.2.  Im migrating all my modules to 2.3. I just 
fixed a bug in my code that was due to a typo. Thats 
when I realized that __slots__ was no longer working in 
2.3a. I cant find anything on this change in behavior.

if slots contains "__dict__" slots is turned OFF!!!
simplified version of the bug:

$ python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class foo(object):
...   __slots__ = ("__dict__", )
...
>>> a = foo()
>>> a.bad = 3
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'foo' object has no attribute 'bad'
>>> ^Z

$ python23
Python 2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC 
v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class foo(object):
...   __slots__ = ("__dict__", )
...
>>> a = foo()
>>> a.bad = 3
>>> dir(a)
['__class__', '__delattr__', '__dict__', '__doc__', '__getattr
ibute__', '__hash_
_', '__init__', '__module__', '__new__', '__reduce__', '__re
duce_ex__', '__repr_
_', '__setattr__', '__slots__', '__str__', 'bad']
>>> ^Z



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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 14:34

Message:
Logged In: YES 
user_id=357491

pje is right that 2.3 allows '__dict__' to be defined in __slots__ 
and that will allow you to have arbitrary instance attributes.  This 
isn't going to be backported since it might break code (like 
yours), but 2.3 is going to stay the way it is.

I am closing this bug.

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

Comment By: Phillip J. Eby (pje)
Date: 2003-05-25 06:40

Message:
Logged In: YES 
user_id=56214

>From discussion on Python-Dev, this behavior is a feature,
not a bug.  Or to be precise, the 2.2 behavior of __slots__
is a bug, or at least a misfeature.  If an object has a
__dict__, it is supposed to allow setting arbitrary
attributes.  The behavior was fixed in 2.3 (see
http://www.python.org/2.2.3/descrintro.html).

A backward-compatible solution to your problem is to create
a slot with a different name than __dict__, store a
dictionary in it, and add __setstate__/__getstate__ methods
to your base class that operate on it.  This should work
correctly for both 2.2 and 2.3, and preserve the fixed
namespace behavior you're looking for, as long as all
subclasses set __slots__ to an empty list.  (You can always
have your metaclass do that in its __new__ method, if you
don't want to have to remember to do it manually.  Just be
sure not to overwrite __slots__ if present, since your base
class will need to set up the slot for the "hidden" dictionary.)

Hmm.  I just read all the followups in more detail and
noticed you are already using a __fakedict__ slot, but refer
to the pickle handling as "yuck"; note that this:

class MyBase(object):

    __slots__ = '__fakedict__'

    def __getstate__(self):
        return self.__fakedict__

    def __setstate__(self,state):
        self.__fakedict__ = state

...should be all you need to get pickling working correctly
under 2.2, assuming that you already have an __init__ that
sets __fakedict__ to a dictionary.  Since in 2.2, a __dict__
slot was not set to a dictionary automatically, I presume
you must have this code already.

For Python 2.3, the __getstate__/__setstate__ methods are
*not* required, as long as you use the new pickling protocol
(protocol #2) See the 2.3 pickle module docs.  Note that the
new protocol is also more space-efficient for new-style
classes, so you may want to upgrade to using it, anyway.



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

Comment By: Douglas Napoleone (derivin)
Date: 2003-04-21 11:31

Message:
Logged In: YES 
user_id=541557

from that followup of mine, you can clearly see why I use 
__slots__; sorry for the bad spelling and worse grammar.

I *think* I have a solution, but I an not really sure if it is the 
proper behavior for __slots__.

I can not find any documentation, PEP, bug, request, or 
discussion on how __slots__ should behave in boundry 
cases such as "__dict__", "__weakref__", etc. 

Should these be an error if used?
Are they assumed?
what behavior does having __dict__ as an allowed attribute 
have? (Does it allow access to the proxy __dict__ and use 
proper __slots__ conventions and attribute checking? does it 
circumvent __slots__, i.e. a back door?)

__slots__ and inheritance is not clearly specified either.
If these things are documented, please flame me with the 
links.


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

Comment By: Douglas Napoleone (derivin)
Date: 2003-04-18 11:44

Message:
Logged In: YES 
user_id=541557

Well looking deeper at the problem, is seems that __dict__ 
and __weakref__ are called out as special in 
Objects/typeobject.c at some point after the 2.2.2 release.

looking at teh code, I would expect the followint ot be 
triggered:

   if (!may_add_dict || add_dict) { 
          PyErr_SetString(PyExc_TypeError, 
                                    "__dict__ slot disallowed: " 
                                    "we already got one"); 
          goto bad_slots; 
    }

Ignoring the attrocious goto logic in this section of code, I 
would have expected to see this triggered.
I can understand the IDEA behind always having __slots__ 
on all classes/types and setting it to contain "__dict__" as 
teh equivolent of not having slots... But the code does not 
look like it implements this, and I dont see how this is even 
working that way yet. Has anyone heard anything about 
this???

(for now in my code I am having to use __fakedict__ and 
override all the pickle handling (yuck).



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723540&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 22:42:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 14:42:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-751941 ] Invisible HTML tag
Message-ID: <E19PqtC-0006CT-00@sc8-sf-web4.sourceforge.net>

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

Category: Documentation
Group: Python 2.2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invisible HTML tag

Initial Comment:
In the current on-line documentation for the library,
in URL

http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-9

It says under classmethod(), 2nd to last sentence, "If
you want those, see ."  The HTML source has the tag
<tex2html_cross_ref_visible_mark> which doesn't display
in my browser (Mozilla 1.0.1 for Linux).

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 16:42

Message:
Logged In: YES 
user_id=80475

Added the missing \label{staticmethod} and \label
{classmethod} so there will be valid jump targets.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751941&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 22:45:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 14:45:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-723806 ] overintelligent slice() behavior on integers
Message-ID: <E19PqwJ-0006Na-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Thompson (russt)
Assigned to: Nobody/Anonymous (nobody)
Summary: overintelligent slice() behavior on integers

Initial Comment:

slices such as a[:7] give a key of slice(0,7,None)
whereas a[:7.1] gives a key of slice(None,7.1,None)

Slices should not assume that the object indices
begin at zero, since that is actually a characteristic of 
the object.  The current behavior cripples an object that 
wants, say, to start its indices with negative numbers.

a[:7] should pass a key of slice(None,7,None).

Thanks!
russt@agilityfund.com


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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 14:45

Message:
Logged In: YES 
user_id=357491

How does having 'slice' not round its arguments have anything 
to do with assuming indices start at zero?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 22:58:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 14:58:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-752221 ] print in __getattr__ causes seg fault
Message-ID: <E19Pr8m-0000Ph-00@sc8-sf-web3.sourceforge.net>

Bugs item #752221, was opened at 2003-06-10 21: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=752221&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher K. Paulicka (paulicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: print in __getattr__ causes seg fault

Initial Comment:
[~/site-packages/WorldPlay/] paulicka@Sliver-14:56:32
$ python
Python 2.3a2+ (#4, Mar  2 2003, 17:13:46) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class A:
...     def __getattr__(self,name):
...             return 3
... 
>>> a=A()
>>> a.c
3
>>> class B:
...     def __getattr__(self,name):
...             print self, name
...             return 3
... 
>>> b=B()
>>> b.c
Segmentation fault
[~/site-packages/WorldPlay/] paulicka@Sliver-14:57:14
$ 

$ uname -a
Darwin Sliver.local. 6.6 Darwin Kernel Version 6.6: Thu 
May  1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/
RELEASE_PPC  Power Macintosh powerpc


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 23:01:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 15:01:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-726150 ] Broken links for grammar in docs
Message-ID: <E19PrBJ-0005Ay-00@sc8-sf-web2.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Broken links for grammar in docs

Initial Comment:
The "test" and "testlist" links at
http://www.python.org/dev/doc/devel/ref/lists.html#tok-
listmaker point
into space.


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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 15:01

Message:
Logged In: YES 
user_id=357491

OK, so it appears test and testlist in the grammar are purely for 
the compiler and not needed for any documentation explicitly.  
They basically cover how to create a chain of tests.  I have no 
clue where they would be put if they were to be documented.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726150&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 23:04:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 15:04:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball
Message-ID: <E19PrEL-0000e8-00@sc8-sf-web3.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Test failures on Linux, Python 2.3b1 tarball

Initial Comment:
"make test" resulted in:

test test_tempfile failed -- Traceback (most recent
call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports
failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
264, in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

test test_time failed -- Traceback (most recent call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_time.py", line
107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST


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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 15:04

Message:
Logged In: YES 
user_id=357491

How about the test_tempfile failure?  Does that occur when you 
run the test on its own?

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

Comment By: Phillip J. Eby (pje)
Date: 2003-05-25 06:21

Message:
Logged In: YES 
user_id=56214

Here's the tz info; I'll email you the 'man tzset' separately.

[admin@pilot Python-2.3a1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[admin@pilot Python-2.3a1]$ cd ../Python-2.3b1
[admin@pilot Python-2.3b1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-05-21 17:41

Message:
Logged In: YES 
user_id=46639

This is from my patch.

Phillip - can you please upload a copy of 'man tzset' on that Redhat box
or email it to zen@shangri-la.dropbear.id.au.

I'd also like to see the output of:
    python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='US/Eastern' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='Australia/Melbourne' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'

I'm thinking that tzset(3) and the time libraries are not fully functional on 
this earlier version of Redhat, possibly by not handling southern hemisphere 
daylight savings. If so, it needs to be detected during configuration.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 08:00

Message:
Logged In: YES 
user_id=21627

Neal, it appears you have checked in the test for the AEST
zone. Can you analyse the test_time failure in more detail?

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

Comment By: Phillip J. Eby (pje)
Date: 2003-05-04 06:19

Message:
Logged In: YES 
user_id=56214

It's an ISP-supplied variant of RedHat 6.2.  I see
'libc-2.1.3.so' in the /lib directory, so I assume that's
the version. Running 'strings' on it, I find:

GNU C Library stable release version 2.1.3, by Roland
McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software
Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release).
Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07.
Available extensions:
        GNU libio by Per Bothner
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        BIND-4.9.7-REL
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton 
        linuxthreads-0.8 by Xavier Leroy
        libthread_db work sponsored by Alpha Processor Inc


Python identifies itself as:

Python 2.3b1 (#1, Apr 26 2003, 10:02:40) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I just tested 2.3a1 andr 2.3a2 to confirm where the errors
began.  2.3a1 doesn't show either error.  2.3a2 has the
tempfile problem, but not the time problem.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 05:42

Message:
Logged In: YES 
user_id=21627

What operating system distribution specifically did you use?
What C library does this system use?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 23:23:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 15:23:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-723806 ] overintelligent slice() behavior on integers
Message-ID: <E19PrWM-0001Mq-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Thompson (russt)
Assigned to: Nobody/Anonymous (nobody)
Summary: overintelligent slice() behavior on integers

Initial Comment:

slices such as a[:7] give a key of slice(0,7,None)
whereas a[:7.1] gives a key of slice(None,7.1,None)

Slices should not assume that the object indices
begin at zero, since that is actually a characteristic of 
the object.  The current behavior cripples an object that 
wants, say, to start its indices with negative numbers.

a[:7] should pass a key of slice(None,7,None).

Thanks!
russt@agilityfund.com


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

>Comment By: Russ Thompson (russt)
Date: 2003-06-10 15:23

Message:
Logged In: YES 
user_id=760126


'slice' doesn't round its arguments.  The difference
is whether you pass an integer or a float as part
of the slice.  Thus:
a[:7] gives a key of slice(0,7,None)
while
a[:7.0] gives a key of slice(None,7.0,None)

What's going on I suspect is that the python
has two different behaviours for __getitem__.
The first handles slices with integer only
components, and defaults to starting at zero.
The second handles anything else.  This is
probably done in order to accomodate old 
'list' and 'tuple' implementation code that doesn't
accept starting indices of None.  But the best
solution would be to eliminate the dual behavior
of slice and revise the list and tuple code to 
accept the more general behavior.


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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 14:45

Message:
Logged In: YES 
user_id=357491

How does having 'slice' not round its arguments have anything 
to do with assuming indices start at zero?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470


From noreply@sourceforge.net  Tue Jun 10 23:56:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 15:56:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball
Message-ID: <E19Ps2t-0002dB-00@sc8-sf-web3.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Test failures on Linux, Python 2.3b1 tarball

Initial Comment:
"make test" resulted in:

test test_tempfile failed -- Traceback (most recent
call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports
failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
264, in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

test test_time failed -- Traceback (most recent call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_time.py", line
107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST


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

>Comment By: Phillip J. Eby (pje)
Date: 2003-06-10 22:56

Message:
Logged In: YES 
user_id=56214

I don't know.  Tell me how to run the test on its own, and
I'll tell you.  :)


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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 22:04

Message:
Logged In: YES 
user_id=357491

How about the test_tempfile failure?  Does that occur when you 
run the test on its own?

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

Comment By: Phillip J. Eby (pje)
Date: 2003-05-25 13:21

Message:
Logged In: YES 
user_id=56214

Here's the tz info; I'll email you the 'man tzset' separately.

[admin@pilot Python-2.3a1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[admin@pilot Python-2.3a1]$ cd ../Python-2.3b1
[admin@pilot Python-2.3b1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-05-22 00:41

Message:
Logged In: YES 
user_id=46639

This is from my patch.

Phillip - can you please upload a copy of 'man tzset' on that Redhat box
or email it to zen@shangri-la.dropbear.id.au.

I'd also like to see the output of:
    python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='US/Eastern' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='Australia/Melbourne' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'

I'm thinking that tzset(3) and the time libraries are not fully functional on 
this earlier version of Redhat, possibly by not handling southern hemisphere 
daylight savings. If so, it needs to be detected during configuration.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 15:00

Message:
Logged In: YES 
user_id=21627

Neal, it appears you have checked in the test for the AEST
zone. Can you analyse the test_time failure in more detail?

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

Comment By: Phillip J. Eby (pje)
Date: 2003-05-04 13:19

Message:
Logged In: YES 
user_id=56214

It's an ISP-supplied variant of RedHat 6.2.  I see
'libc-2.1.3.so' in the /lib directory, so I assume that's
the version. Running 'strings' on it, I find:

GNU C Library stable release version 2.1.3, by Roland
McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software
Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release).
Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07.
Available extensions:
        GNU libio by Per Bothner
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        BIND-4.9.7-REL
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton 
        linuxthreads-0.8 by Xavier Leroy
        libthread_db work sponsored by Alpha Processor Inc


Python identifies itself as:

Python 2.3b1 (#1, Apr 26 2003, 10:02:40) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I just tested 2.3a1 andr 2.3a2 to confirm where the errors
began.  2.3a1 doesn't show either error.  2.3a2 has the
tempfile problem, but not the time problem.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 12:42

Message:
Logged In: YES 
user_id=21627

What operating system distribution specifically did you use?
What C library does this system use?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 00:44:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 16:44:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-729103 ] Cannot retrieve name of super object
Message-ID: <E19Psn4-0000ph-00@sc8-sf-web2.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michele Simionato (michele_s)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot retrieve name of super object

Initial Comment:
I see that in Python 2.3b1 many problems of super
have been fixed, but this one is still there:
I cannot retrieve the __name__ of a super object.
This generates problems with pydoc, for instance:

>>> class C(B):
...     sup=super(B)
>>> help(C)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/site.py", line 293, in
__call__
    return pydoc.help(*args, **kwds)
  File "/usr/local/lib/python2.3/pydoc.py", line 1539,
in __call__
    self.help(request)
  File "/usr/local/lib/python2.3/pydoc.py", line 1575,
in help
    else: doc(request, 'Help on %s:')
  File "/usr/local/lib/python2.3/pydoc.py", line 1368,
in doc
    pager(title % desc + '\n\n' + text.document(object,
name))
  File "/usr/local/lib/python2.3/pydoc.py", line 279,
in document
    if inspect.isclass(object): return
self.docclass(*args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1122,
in docclass
    lambda t: t[1] == 'method')
  File "/usr/local/lib/python2.3/pydoc.py", line 1057,
in spill
    name, mod, object))
  File "/usr/local/lib/python2.3/pydoc.py", line 280,
in document
    if inspect.isroutine(object): return
self.docroutine(*args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1145,
in docroutine
    realname = object.__name__
AttributeError: 'super' object has no attribute
'__name__'

P.S. I seem to remember I already submitted this
bug (or feature request, as you wish ;) but I don't
find it in bugtracker and I had no feedback; maybe
it wasn't sent at all due to some connection problem.
If not, please accept my apologies.

    Michele Simionato

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 16:44

Message:
Logged In: YES 
user_id=357491

The issue is inspect.isroutine is saying that the instance is a 
callable object since it is also a non-data descriptor.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 00:57:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 16:57:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-731403 ] test_tarfile writes in Lib/test directory
Message-ID: <E19Psza-0004Ui-00@sc8-sf-web3.sourceforge.net>

Bugs item #731403, was opened at 2003-05-02 08:20
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731403&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Brett Cannon (bcannon)
Summary: test_tarfile writes in Lib/test directory

Initial Comment:
Test_tarfile writes a file in the Lib/test directory, which fails if Python 
has been installed read-only. It would be better if it used 
test_support.TESTFN as the basis for a filename to write to.

Here's the message for a binary install on MacOSX (framework 
Python):

test test_tarfile crashed -- exceptions.IOError: [Errno 13] Permission 
denied: '/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/test/testtar.tar.gz'


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731403&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 01:20:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 17:20:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-737291 ] os.symlink docstring is ambiguous.
Message-ID: <E19PtLr-0007fL-00@sc8-sf-web1.sourceforge.net>

Bugs item #737291, was opened at 2003-05-13 13:53
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737291&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.symlink docstring is ambiguous.

Initial Comment:
>>> print os.symlink.__doc__
symlink(src, dst)

Create a symbolic link.

I find that to be ambiguous -- personally, when I read
it, I picture the symlink as the source pointing to the
destination, but apparently Python considers the
symlink to be the "destination" file pointing at the
source (the file).

I propose simply changing "src" in the docstring to be
"filename" and "dst" in the docstring to be "linkname."
 That would cut out the ambiguity.

(It's unfortunate, btw, that os.symlink takes its
arguments in the opposite order of the UNIX ln command.)

Jeremy

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 17:20

Message:
Logged In: YES 
user_id=357491

Made the docstring match the official docs: "Create a symbolic 
link pointing to src named dst."  Applied as revision 2.300  for 
2.3 and revision 2.216.4.11 for the 2.2 branch.

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

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-05-13 14:13

Message:
Logged In: YES 
user_id=99508

(ignore that last comment...brain fart...)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737291&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 01:23:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 17:23:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-734844 ] pyxml setup error on Mac OS X
Message-ID: <E19PtOU-0001xh-00@sc8-sf-web2.sourceforge.net>

Bugs item #734844, was opened at 2003-05-08 13:35
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734844&group_id=5470

Category: XML
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Gene Chow (genechow)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyxml setup error on Mac OS X

Initial Comment:
Error when installing pyxml 0.8.2 on Mac OS 10.2.6 using the 
command: python2.1 setup.py install

The following change in setup.py fixes the problem:
59c59
<    distutils.sysconfig.get_config_var("LDSHARED").find("-
flat_namespace") == -1:
---
>    get_config_vars("LDSHARED")[0].find("-flat_namespace") == 
-1:


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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 17:23

Message:
Logged In: YES 
user_id=357491

It's been a month since Martin asked for clarification on this bug 
report from the OP on why he thinks this is a Python issue and 
not a PyXML issue.  Closing it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-09 00:45

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug in Python? The PyXML project
is at sf.net/projects/pyxml.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734844&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 01:29:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 17:29:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-740026 ] re.finditer() listed as new in 2.2.?
Message-ID: <E19PtUa-0005OL-00@sc8-sf-web3.sourceforge.net>

Bugs item #740026, was opened at 2003-05-19 11:52
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grzegorz Adam Hankiewicz (gradha)
Assigned to: Nobody/Anonymous (nobody)
Summary: re.finditer() listed as new in 2.2.?

Initial Comment:
Documentation says re.finditer() is new in 2.2
(http://www.python.org/doc/current/lib/node99.html),
but this is not totally correct:

[gradha@ws5:0] [~/cms_freeze]$ python
Python 2.2.1 (#1, Sep 10 2002, 17:49:17)
[GCC 3.2] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.finditer
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'finditer'

[0:arpa/g/gradha> /usr/pkg/bin/python2.2
Python 2.2.2 (#1, Mar 13 2003, 22:53:11)
[GCC 2.95.3 20010315 (release) (NetBSD nb3)] on netbsd1
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.finditer
<function finditer at 0x1201ed218>

The first log was produced on an 8.1 Suse default
distro. For a moment I wanted to blame Suse, but I
thought: "hey, let's blame the documentation!". Please
extend that version number to 2.2.2.

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 17:29

Message:
Logged In: YES 
user_id=357491

re is the front-end for sre so it shouldn't be documented 
specifically.  I also don't know of a single instance of where 
something is documented in the standard lib with a revision 
number and I doubt we will start now.

Since the docs are correct for the most recent version of the 2.2 
branch (you can check what version the docs apply to at the 
bottom of every page) I am inclined to say this bug should be 
closed.  Any objections?

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

Comment By: Grzegorz Adam Hankiewicz (gradha)
Date: 2003-06-06 10:41

Message:
Logged In: YES 
user_id=153159

Maybe SRE should make it to the final documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-19 22:19

Message:
Logged In: YES 
user_id=80475

I recommend leaving it listed as new in 2.2 since that it the 
first time that "from sre import *" would find it.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-19 18:37

Message:
Logged In: YES 
user_id=33168

This is a bit of a weird case.  From looking through CVS,
finditer is in sre, but due to a bug it was not exported
from re.  So  import sre ; sre.finditer should work, but
from sre import * doesn't.  I'm not sure how best to handle
this.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 01:42:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 17:42:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball
Message-ID: <E19Ptgg-0002Xa-00@sc8-sf-web2.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Test failures on Linux, Python 2.3b1 tarball

Initial Comment:
"make test" resulted in:

test test_tempfile failed -- Traceback (most recent
call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports
failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
264, in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

test test_time failed -- Traceback (most recent call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_time.py", line
107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST


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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 17:42

Message:
Logged In: YES 
user_id=357491

Sure thing.  =)  Execute this line from a terminal:

python2.3 -c "from test import test_tempfile; 
test_tempfile.test_main()"

All it is doing is importing the test_tempfile module from the test 
package and then executing test_tempfile.test_main() which 
runs all the tests.

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

Comment By: Phillip J. Eby (pje)
Date: 2003-06-10 15:56

Message:
Logged In: YES 
user_id=56214

I don't know.  Tell me how to run the test on its own, and
I'll tell you.  :)


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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 15:04

Message:
Logged In: YES 
user_id=357491

How about the test_tempfile failure?  Does that occur when you 
run the test on its own?

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

Comment By: Phillip J. Eby (pje)
Date: 2003-05-25 06:21

Message:
Logged In: YES 
user_id=56214

Here's the tz info; I'll email you the 'man tzset' separately.

[admin@pilot Python-2.3a1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[admin@pilot Python-2.3a1]$ cd ../Python-2.3b1
[admin@pilot Python-2.3b1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-05-21 17:41

Message:
Logged In: YES 
user_id=46639

This is from my patch.

Phillip - can you please upload a copy of 'man tzset' on that Redhat box
or email it to zen@shangri-la.dropbear.id.au.

I'd also like to see the output of:
    python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='US/Eastern' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='Australia/Melbourne' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'

I'm thinking that tzset(3) and the time libraries are not fully functional on 
this earlier version of Redhat, possibly by not handling southern hemisphere 
daylight savings. If so, it needs to be detected during configuration.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 08:00

Message:
Logged In: YES 
user_id=21627

Neal, it appears you have checked in the test for the AEST
zone. Can you analyse the test_time failure in more detail?

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

Comment By: Phillip J. Eby (pje)
Date: 2003-05-04 06:19

Message:
Logged In: YES 
user_id=56214

It's an ISP-supplied variant of RedHat 6.2.  I see
'libc-2.1.3.so' in the /lib directory, so I assume that's
the version. Running 'strings' on it, I find:

GNU C Library stable release version 2.1.3, by Roland
McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software
Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release).
Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07.
Available extensions:
        GNU libio by Per Bothner
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        BIND-4.9.7-REL
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton 
        linuxthreads-0.8 by Xavier Leroy
        libthread_db work sponsored by Alpha Processor Inc


Python identifies itself as:

Python 2.3b1 (#1, Apr 26 2003, 10:02:40) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I just tested 2.3a1 andr 2.3a2 to confirm where the errors
began.  2.3a1 doesn't show either error.  2.3a2 has the
tempfile problem, but not the time problem.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 05:42

Message:
Logged In: YES 
user_id=21627

What operating system distribution specifically did you use?
What C library does this system use?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 02:30:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 18:30:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-740026 ] re.finditer() listed as new in 2.2.?
Message-ID: <E19PuRB-00045h-00@sc8-sf-web2.sourceforge.net>

Bugs item #740026, was opened at 2003-05-19 13:52
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Grzegorz Adam Hankiewicz (gradha)
Assigned to: Nobody/Anonymous (nobody)
Summary: re.finditer() listed as new in 2.2.?

Initial Comment:
Documentation says re.finditer() is new in 2.2
(http://www.python.org/doc/current/lib/node99.html),
but this is not totally correct:

[gradha@ws5:0] [~/cms_freeze]$ python
Python 2.2.1 (#1, Sep 10 2002, 17:49:17)
[GCC 3.2] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.finditer
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'finditer'

[0:arpa/g/gradha> /usr/pkg/bin/python2.2
Python 2.2.2 (#1, Mar 13 2003, 22:53:11)
[GCC 2.95.3 20010315 (release) (NetBSD nb3)] on netbsd1
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.finditer
<function finditer at 0x1201ed218>

The first log was produced on an 8.1 Suse default
distro. For a moment I wanted to blame Suse, but I
thought: "hey, let's blame the documentation!". Please
extend that version number to 2.2.2.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 20:30

Message:
Logged In: YES 
user_id=80475

2.2.2 is the most current release of 2.2.
The docs are fine and the export bug was fixed.
Closing this one.


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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 19:29

Message:
Logged In: YES 
user_id=357491

re is the front-end for sre so it shouldn't be documented 
specifically.  I also don't know of a single instance of where 
something is documented in the standard lib with a revision 
number and I doubt we will start now.

Since the docs are correct for the most recent version of the 2.2 
branch (you can check what version the docs apply to at the 
bottom of every page) I am inclined to say this bug should be 
closed.  Any objections?

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

Comment By: Grzegorz Adam Hankiewicz (gradha)
Date: 2003-06-06 12:41

Message:
Logged In: YES 
user_id=153159

Maybe SRE should make it to the final documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-20 00:19

Message:
Logged In: YES 
user_id=80475

I recommend leaving it listed as new in 2.2 since that it the 
first time that "from sre import *" would find it.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-19 20:37

Message:
Logged In: YES 
user_id=33168

This is a bit of a weird case.  From looking through CVS,
finditer is in sre, but due to a bug it was not exported
from re.  So  import sre ; sre.finditer should work, but
from sre import * doesn't.  I'm not sure how best to handle
this.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 04:09:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 20:09:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-752221 ] print in __getattr__ causes seg fault
Message-ID: <E19Pvzd-0001RV-00@sc8-sf-web3.sourceforge.net>

Bugs item #752221, was opened at 2003-06-10 16:58
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher K. Paulicka (paulicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: print in __getattr__ causes seg fault

Initial Comment:
[~/site-packages/WorldPlay/] paulicka@Sliver-14:56:32
$ python
Python 2.3a2+ (#4, Mar  2 2003, 17:13:46) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class A:
...     def __getattr__(self,name):
...             return 3
... 
>>> a=A()
>>> a.c
3
>>> class B:
...     def __getattr__(self,name):
...             print self, name
...             return 3
... 
>>> b=B()
>>> b.c
Segmentation fault
[~/site-packages/WorldPlay/] paulicka@Sliver-14:57:14
$ 

$ uname -a
Darwin Sliver.local. 6.6 Darwin Kernel Version 6.6: Thu 
May  1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/
RELEASE_PPC  Power Macintosh powerpc


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 22:09

Message:
Logged In: YES 
user_id=80475

Can you try this one on the beta release to see if it is still a 
problem.  I cannot reproduce the segfault on a Windows 
build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 04:12:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 20:12:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-751894 ] int()
Message-ID: <E19Pw2T-0001YI-00@sc8-sf-web3.sourceforge.net>

Bugs item #751894, was opened at 2003-06-10 07:48
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751894&group_id=5470

Category: None
Group: Python 2.2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Hartmut Fröls (froels)
Assigned to: Nobody/Anonymous (nobody)
Summary: int()

Initial Comment:
Seems to me like an error in int():

Python 2.2.3 (#1, Jun  5 2003, 21:12:33)
ÄGCC 3.2.3Ü on aix4
Type "help", "copyright", "credits" or "license" for
more information.

>>> print int((4.3 % 1)*10)
2
>>> print 4.3 % 1
0.3
>>> print 4.3 % 1 * 10
3.0
>>> print int(4.3 % 1 * 10)
2

Is this a bug ???

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 22:12

Message:
Logged In: YES 
user_id=80475

Ah, the joys of floating point.
Closing the bug as invalid.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-10 09:14

Message:
Logged In: YES 
user_id=31435

Try displaying the penultimate result to full precision.  On my 
box I get this:

>>> 4.3 % 1 * 10
2.9999999999999982
>>>


int() of that is 2.  What do you get?  And have you read the 
Python Tutorial appendix on floating-point issues?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751894&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 05:20:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 21:20:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-723806 ] overintelligent slice() behavior on integers
Message-ID: <E19Px6G-0002YY-00@sc8-sf-web4.sourceforge.net>

Bugs item #723806, was opened at 2003-04-18 13:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Thompson (russt)
Assigned to: Nobody/Anonymous (nobody)
Summary: overintelligent slice() behavior on integers

Initial Comment:

slices such as a[:7] give a key of slice(0,7,None)
whereas a[:7.1] gives a key of slice(None,7.1,None)

Slices should not assume that the object indices
begin at zero, since that is actually a characteristic of 
the object.  The current behavior cripples an object that 
wants, say, to start its indices with negative numbers.

a[:7] should pass a key of slice(None,7,None).

Thanks!
russt@agilityfund.com


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 23:20

Message:
Logged In: YES 
user_id=80475

Russ, you're right about there being two behaviors for the 
implementation of the slice notation(see apply_slice() in 
Python/ceval.c).  This occurs in the bytecode interpreter 
rather than some object's implementation of __getitem__.

While it is unfortunate, it can't be fixed without breaking 
code which defines __getitem__ but doesn't provide a None-
to-zero converter.

Factiod of the day, interpreter doesn't just assume 0 for 
None, it clamps the values in a range of 0<= value <= 
sys.maxint:

>>> class C:
        def __getitem__(self, i):
            return i

>>> c = C()
>>> c[10000000000000000000L:]
slice(2147483647, 2147483647, None)


I recommend you close the bug as Won't Fix.

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

Comment By: Russ Thompson (russt)
Date: 2003-06-10 17:23

Message:
Logged In: YES 
user_id=760126


'slice' doesn't round its arguments.  The difference
is whether you pass an integer or a float as part
of the slice.  Thus:
a[:7] gives a key of slice(0,7,None)
while
a[:7.0] gives a key of slice(None,7.0,None)

What's going on I suspect is that the python
has two different behaviours for __getitem__.
The first handles slices with integer only
components, and defaults to starting at zero.
The second handles anything else.  This is
probably done in order to accomodate old 
'list' and 'tuple' implementation code that doesn't
accept starting indices of None.  But the best
solution would be to eliminate the dual behavior
of slice and revise the list and tuple code to 
accept the more general behavior.


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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 16:45

Message:
Logged In: YES 
user_id=357491

How does having 'slice' not round its arguments have anything 
to do with assuming indices start at zero?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 06:29:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 10 Jun 2003 22:29:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-751321 ] Classes inheritig from object are not class type.
Message-ID: <E19PyB6-0004Vu-00@sc8-sf-web4.sourceforge.net>

Bugs item #751321, was opened at 2003-06-09 15:33
Message generated for change (Comment added) made by e078120
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751321&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Wenham (e078120)
Assigned to: Nobody/Anonymous (nobody)
Summary: Classes inheritig from object are not class type. 

Initial Comment:
Isinstance(<classinstance>, types.ClassType) will
return false if the class inherits from object.

Here is a demo:

import types
 
class a:
        def test(self):
                pass
 
class b(object):
        def test(self):
                pass
  
if __name__ == '__main__':
        if isinstance(a, types.ClassType):
                print "a is a class"
        else:
                print "a is not a class"
 
        if isinstance(b, types.ClassType):
                print "b is a class"
        else:
                print "b is not a class"

The output look like this:


roger@linux_lap:~ > python demo.py
a is a class
b is not a class



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

>Comment By: Roger Wenham (e078120)
Date: 2003-06-11 07:29

Message:
Logged In: YES 
user_id=240941

Maybe I'm missing something, but to me a class is a class
and should allways be a ClassType. For instance if I have
pickled
some objects, when unpickling, how else can I identify that
it was a class that I pickled, and that I can take an
instance of it?

With the old style classes, a class was class type and if i
take an instance, it's type is instance, logical.

With new style classes, an class is type 'type', and an
instance of it is type class.

Is it not logical that a class is a class and an istance is
an instance?  

 





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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-10 20:07

Message:
Logged In: YES 
user_id=89016

The reason for this is that new style classes have a
different meta class than classic classes. This is
documented in http://www.python.org/2.2.3/descrintro.html:
"""The built-in 'type' is the most common metaclass; it is
the metaclass of all built-in types. Classic classes use a
different metaclass: the type known as types.ClassType."""

Why do you think this is a bug?


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751321&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 09:16:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 01:16:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-660022 ] parameters for int(), str(), etc.
Message-ID: <E19Q0mr-0003Xs-00@sc8-sf-web3.sourceforge.net>

Bugs item #660022, was opened at 2002-12-30 10:47
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Aahz (aahz)
Assigned to: Raymond Hettinger (rhettinger)
Summary: parameters for int(), str(), etc.

Initial Comment:
The built-in functions int(), str(), float(), long() are documented as
requiring a parameter, but the type/class unification has changed them
so that they return a false object without a parameter:

>>> int()
0
>>> str()
''
>>> float()
0.0
>>> long()
0L


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-11 03:16

Message:
Logged In: YES 
user_id=80475

Fixed.  See Doc/lib/libfuncs.tex 1.135


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-01 23:31

Message:
Logged In: YES 
user_id=80475

There are a lot of these:
[(0, False), (0.0, False), (0j, False), (0L, False), ((), False), 
([], False), ({}, False), ('', False), (u'', False)]

See attached doc patch. Also, consider adding a 
\versionchanged tag and changing the doc strings.

BTW, I think it is more complete and accurate to say that 
the contructors return an empty container or zero than it 
is to just say that bool(constructor()) is False.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 09:21:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 01:21:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-705792 ] test_atexit fails in directories with spaces
Message-ID: <E19Q0ra-0003pc-00@sc8-sf-web3.sourceforge.net>

Bugs item #705792, was opened at 2003-03-18 14:33
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470

Category: None
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Hutchings (wom-work)
>Assigned to: Nobody/Anonymous (nobody)
Summary: test_atexit fails in directories with spaces

Initial Comment:
The regression test program test_atexit.py constructs a
command line without doing any quoting of arguments. If
the name of the build directory contains spaces, the
command doesn't work and the test fails. Here's what
happens in Windows:

H:\benh\My
Documents\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d
test_atexit.py
Adding parser accelerators ...
Done.
Traceback (most recent call last):
  File "test_atexit.py", line 33, in ?
    """)
  File "test_support.py", line 122, in vereq
    raise TestFailed, "%r == %r" % (a, b)
test_support.TestFailed: '' == "handler2 (7,) {'kw':
'abc'}\nhandler2 () {}\nhandler1\n"
[5168 refs]

If I change the current directory to use a
compatibility name without a space in it:

H:\benh\My Documents\python\Python-2.2.2\Lib\test>cd
h:\benh\mydocu~1\python\python-2.2.2\lib\test

H:\benh\MYDOCU~1\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d
test_atexit.py
Adding parser accelerators ...
Done.
[5168 refs]


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 19:42

Message:
Logged In: YES 
user_id=33168

Directories with spaces should work with current CVS.  The
fix needs to be backported.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 12:39:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 04:39:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-752543 ] error with __getattr__
Message-ID: <E19Q3xA-0000Re-00@sc8-sf-web2.sourceforge.net>

Bugs item #752543, was opened at 2003-06-11 13: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=752543&group_id=5470

Category: Windows
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Uwe Matthaeus (cptncrunch)
Assigned to: Tim Peters (tim_one)
Summary: error with __getattr__

Initial Comment:
This is the design pattern proxy:

class Implementierung2:

    def a(self): print 'a';
    def b(self): print 'b';
    def c(self): print 'c';

class Proxy:

    def __init__(self):
        self.__impl = Implementierung2();

    def __getattr__(self,name):
        return getattr(self.__imp,name);

if __name__ == '__main__':

    p = Proxy();
    p.a();

error message(s):

File "f:\python\proxy.py", line 17, in __getattr__
    return getattr(self.__imp,name);

RuntimeError: maximum recursion depth exceeded

See Bruce Eckel: 'Thinking in python'

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752543&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 13:31:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 05:31:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-752543 ] error with __getattr__
Message-ID: <E19Q4lE-0004AT-00@sc8-sf-web4.sourceforge.net>

Bugs item #752543, was opened at 2003-06-11 13:39
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752543&group_id=5470

Category: Windows
Group: Python 2.2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Uwe Matthaeus (cptncrunch)
Assigned to: Tim Peters (tim_one)
Summary: error with __getattr__

Initial Comment:
This is the design pattern proxy:

class Implementierung2:

    def a(self): print 'a';
    def b(self): print 'b';
    def c(self): print 'c';

class Proxy:

    def __init__(self):
        self.__impl = Implementierung2();

    def __getattr__(self,name):
        return getattr(self.__imp,name);

if __name__ == '__main__':

    p = Proxy();
    p.a();

error message(s):

File "f:\python\proxy.py", line 17, in __getattr__
    return getattr(self.__imp,name);

RuntimeError: maximum recursion depth exceeded

See Bruce Eckel: 'Thinking in python'

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-11 14:31

Message:
Logged In: YES 
user_id=89016

This is caused by a typo in your constructor: Instead of
self.__impl = Implementierung2()
use
self.__imp = Implementierung2()
and it will work.

BTW, you should drop the semicolons, they are useless.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752543&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 13:47:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 05:47:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current
Message-ID: <E19Q50y-0007Nz-00@sc8-sf-web1.sourceforge.net>

Bugs item #740234, was opened at 2003-05-20 13:50
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Till Plewe (tpx)
Assigned to: Nobody/Anonymous (nobody)
Summary: test/build-failures on FreeBSD stable/current

Initial Comment:
Using snapshot: python_2003-05-19_230000.tar.gz
STABLE (FreeBSD 4.8-STABLE #14: Mon Apr  7)
CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue
May 20)

BUILDFAILURE
curses does not build; neither on CURRENT nor on STABLE
(compiler complaint:

/usr/include/ncurses.h:289: conflicting types for `wchar_t'
/usr/include/stdlib.h:57: previous declaration of `wchar_t'
/usr/include/ncurses.h:292: conflicting types for `wint_t'
/usr/include/wchar.h:96: previous declaration of `wint_t'

if lines /usr/include/ncurses.h:288-293 

#ifndef __wchar_t
typedef unsigned long wchar_t;
#endif /* __wchar_t */
#ifndef __wint_t
typedef long int wint_t;
#endif /* __wint_t */

are deleted then curses builds)

TESTFAILURES
test_re fails on both CURRENT and STABLE
 
test_long
test_pow 
and many more (probably related) tests 

fail on current

See attached file for details


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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-11 22:47

Message:
Logged In: YES 
user_id=250749

The _sre recursion limit was tweaked in _sre.c revision
2.98, which should deal with the bus error in test_re - at
least until thestack consumption per recursion increases again.

gcc 2.95 (FreeBSD 4.x) is set to 7500, gcc 3.x (FreeBSD 5.x)
is set to 6500 (tested on 4.8R).

The curses build problem should be addressed by revision 1.7
of Include/py_curses.h (tested on 4.8R)

Please let me know if the above fixes are satisfactory on
5.x. Is there anything else still needing attention?

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-01 17:47

Message:
Logged In: YES 
user_id=250749

Sigh...

Stacksize is indeed the problem with the test_re failure.

In the pthreads case, on FreeBSD prior to 5.x (I have no
info about 5.x, but from what you say it looks the same),
linking to libc_r causes the "initial" thread to get a hard
coded 1MB stack.  The stack size cannot be changed
(currently) without rebuilding libc_r :-(

As all these regression tests are running on the "initial"
thread, by virtue of not having been explicitly started in a
thread.

The problem is worse with gcc 3.x than 2.95, as gcc 3.x (I
tested with 3.2.2) seems to the stack  more aggressively.

I plan to post a patch to _sre.c extending the FreeBSD/gcc
specific #ifdef'ery (which was put in just before 2.3b1, and
was broken again by _sre commits shortly after 2.3b1).

configure --without-threads doesn't have a problem.

building a threaded interpreter with the Linuxthreads port
also doesn't suffer this problem.

I will be looking into preparing a FreeBSD patch to try and
allow a way to vary the "initial" thread stack size at
compile time, rather than libc_r build time.

This problem has been giving me the irrits since it first
appeared at the beginning of April.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-27 12:37

Message:
Logged In: YES 
user_id=782552

I forgot to mention that stack size is probably not the problem
(FreeBSD 5.1 and 4.8 behave identical with respect to
test_re.py) 
====================================
FreeBSD 4.8-STABLE FreeBSD 4.8-STABLE #14: Mon Apr  7
17:43:45 JST 2003  i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  524288
stack size              (kbytes, -s)  65536
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  896
open files                      (-n)  1792
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited

================================================================
FreeBSD 5.1-BETA FreeBSD 5.1-BETA #25: Thu May 22 09:10:55
JST 2003 i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  1572864
stack size              (kbytes, -s)  1572864
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  5547
open files                      (-n)  11095
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited


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

Comment By: Till Plewe (tpx)
Date: 2003-05-27 11:59

Message:
Logged In: YES 
user_id=782552

it seems that test_stack_overflow is the culprit

...
    def test_stack_overflow(self):
        # nasty case that overflows the straightforward
recursive
        # implementation of repeated groups.
        self.assertRaises(RuntimeError, re.match, '(x)*',
50000*'x')
        self.assertRaises(RuntimeError, re.match, '(x)*y',
50000*'x'+'y')
        self.assertRaises(RuntimeError, re.match, '(x)*?y',
50000*'x'+'y')
...

>>> A.test_stack_overflow()

Process Python bus error (core dumped)

Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*', 5000*'x')
<_sre.SRE_Match object at 0x81d2b20>
>>> re.match('(x)*', 50000*'x')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*y', 50000*'x'+'y')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*?y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*?y', 50000*'x'+'y')

Process Python bus error (core dumped)


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-25 09:40

Message:
Logged In: YES 
user_id=33168

Can you determine what the conflict in the header files
which prevents curses from building?

My guess is that test_bug_418626() is causing the core dump
(from test_re.py).  Can you verify the problem is in that
function?  If so, can you test each of the
re.match/re.search in the interpreter to determine which
line is failling?

My guess is that it's related to the recursion limit (likely
the last line).  Your stack size limit may be too small for
the python recursion limit.  You can try doing a ulimit -a
to see all the limits.  ulimit -s 8192 is what my stack size
is set to (but on Linux).  Doing that command may work for
you.  But this is all conjecture until you investigate further.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-22 15:04

Message:
Logged In: YES 
user_id=782552

Most of the test failures on FreeBSD CURRENT seem to be gcc
bugs.
(I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release))
Rebuilding world with the additional compiler flag 
  -mno-sse2
got rid of most test failures.

Now only the curses build failure and the test_re failure
remain.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-22 14:57

Message:
Logged In: YES 
user_id=782552

I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release).

Most of the test failures seem to be gcc-bugs.
Rebuilding world with the extra compiler flag 

   -mno-sse2

got rid of most test failures. Now only the test_re failure and
the curses build failure remain.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 08:34

Message:
Logged In: YES 
user_id=33168

I think many of the failures are due to the test_long
failure.  If that problem is fixed, my guess is several
other tests will start working.

What compiler are you using?  Can you try to debug the
test_long failure?  I don't think any python developers have
access to a freebsd box.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 17:16:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 09:16:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-749210 ] bdist --formats=zip,wininst and bdist --formats=wininst,zip
Message-ID: <E19Q8Go-0007jv-00@sc8-sf-web4.sourceforge.net>

Bugs item #749210, was opened at 2003-06-05 00:47
Message generated for change (Settings changed) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Dubner (dubnerm)
>Assigned to: Thomas Heller (theller)
Summary: bdist --formats=zip,wininst and bdist --formats=wininst,zip

Initial Comment:
Commands
setup.py bdist --formats=zip,wininst
and
setup.py bdist --formats=wininst,zip
should create the same two archives, but in my config
first version (zip,wininst) creates broken .exe file -
no SCRIPTS and DATA directories - only PURELIB.
I'm using ActiveState Python 2.2.2 with included
distutils 1.0.3 under WinXP.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 17:21:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 09:21:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-749210 ] bdist --formats=zip,wininst and bdist --formats=wininst,zip
Message-ID: <E19Q8MG-0006LA-00@sc8-sf-web2.sourceforge.net>

Bugs item #749210, was opened at 2003-06-05 00:47
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Dubner (dubnerm)
>Assigned to: Nobody/Anonymous (nobody)
Summary: bdist --formats=zip,wininst and bdist --formats=wininst,zip

Initial Comment:
Commands
setup.py bdist --formats=zip,wininst
and
setup.py bdist --formats=wininst,zip
should create the same two archives, but in my config
first version (zip,wininst) creates broken .exe file -
no SCRIPTS and DATA directories - only PURELIB.
I'm using ActiveState Python 2.2.2 with included
distutils 1.0.3 under WinXP.

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

>Comment By: Thomas Heller (theller)
Date: 2003-06-11 18:21

Message:
Logged In: YES 
user_id=11105

Michael, can you please try the following patch and report
if it fixes your problem?

In the file distutils/command/bdist_wininst.py, replace the line
        install = self.reinitialize_command('install')
with this one:
        install = self.reinitialize_command('install',
reinit_subcommands=1)

This code is near line 103, just near the top of the 'def
run(self):' method.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 17:30:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 09:30:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-749210 ] bdist --formats=zip,wininst and bdist --formats=wininst,zip
Message-ID: <E19Q8U7-0006ms-00@sc8-sf-web2.sourceforge.net>

Bugs item #749210, was opened at 2003-06-05 00:47
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Dubner (dubnerm)
>Assigned to: Thomas Heller (theller)
Summary: bdist --formats=zip,wininst and bdist --formats=wininst,zip

Initial Comment:
Commands
setup.py bdist --formats=zip,wininst
and
setup.py bdist --formats=wininst,zip
should create the same two archives, but in my config
first version (zip,wininst) creates broken .exe file -
no SCRIPTS and DATA directories - only PURELIB.
I'm using ActiveState Python 2.2.2 with included
distutils 1.0.3 under WinXP.

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

>Comment By: Thomas Heller (theller)
Date: 2003-06-11 18:30

Message:
Logged In: YES 
user_id=11105

Oops, I didn't want to unassign it!

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

Comment By: Thomas Heller (theller)
Date: 2003-06-11 18:21

Message:
Logged In: YES 
user_id=11105

Michael, can you please try the following patch and report
if it fixes your problem?

In the file distutils/command/bdist_wininst.py, replace the line
        install = self.reinitialize_command('install')
with this one:
        install = self.reinitialize_command('install',
reinit_subcommands=1)

This code is near line 103, just near the top of the 'def
run(self):' method.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 21:53:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 13:53:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19QCap-0008Ku-00@sc8-sf-web2.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 22:44
Message generated for change (Comment added) made by netytan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

>Comment By: mark lee smith (netytan)
Date: 2003-06-11 20:53

Message:
Logged In: YES 
user_id=797196

Hi, I've replicated what had before exactly, the win32 Kernal 
still crashes but the mail is delivered :S, don't ask me why it 
sends now and didn't before, nothing has changed to my 
knowlage.. Anyway if I've done this right it should be 
attached to this.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:47

Message:
Logged In: YES 
user_id=31435

Just attaching tcap.txt.  Note that on Windows, you have to 
end the msg with Ctrl-Z (not the Unixish Ctrl-D in the example 
comments).

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:45

Message:
Logged In: YES 
user_id=31435

I'll show you what I'm looking for:  attached is the exact code 
I just ran, in smtpex.py, and a screen dump from running it, in 
tcap.txt.  I changed the example to use comcast.net's SMTP 
server.  It worked fine for me on Win98SE.  I was using 
Python 2.2.3, and don't know whether that makes a 
difference.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:39

Message:
Logged In: YES 
user_id=31435

I don't understand.  If you're not running an SMTP server on 
localhost, I expect that example to die with

socket.error: (10061, 'Connection refused')

And indeed, that's what it does when I try it on Win98SE.  So 
I conclude you must have changed the example in some way.  
If so, the solution to your problem will be found in the details 
of you changed it.  Nobody can guess that, so please attach 
the code you actually ran.

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

Comment By: mark lee smith (netytan)
Date: 2003-06-09 23:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 22:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 22:22:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 14:22:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19QD2x-0005UC-00@sc8-sf-web4.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 22:44
Message generated for change (Comment added) made by netytan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

>Comment By: mark lee smith (netytan)
Date: 2003-06-11 21:22

Message:
Logged In: YES 
user_id=797196

Ok, I ran your file and it returned the same as when I ran 
mine,  both crashed the Kernal. I think the reason that the 
mail wasn't being sent before was that I forgot to finish the 
message with "^D" although the main problem remains, what 
is the Kernal crashing out :S..  

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

Comment By: mark lee smith (netytan)
Date: 2003-06-11 20:53

Message:
Logged In: YES 
user_id=797196

Hi, I've replicated what had before exactly, the win32 Kernal 
still crashes but the mail is delivered :S, don't ask me why it 
sends now and didn't before, nothing has changed to my 
knowlage.. Anyway if I've done this right it should be 
attached to this.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:47

Message:
Logged In: YES 
user_id=31435

Just attaching tcap.txt.  Note that on Windows, you have to 
end the msg with Ctrl-Z (not the Unixish Ctrl-D in the example 
comments).

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:45

Message:
Logged In: YES 
user_id=31435

I'll show you what I'm looking for:  attached is the exact code 
I just ran, in smtpex.py, and a screen dump from running it, in 
tcap.txt.  I changed the example to use comcast.net's SMTP 
server.  It worked fine for me on Win98SE.  I was using 
Python 2.2.3, and don't know whether that makes a 
difference.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:39

Message:
Logged In: YES 
user_id=31435

I don't understand.  If you're not running an SMTP server on 
localhost, I expect that example to die with

socket.error: (10061, 'Connection refused')

And indeed, that's what it does when I try it on Win98SE.  So 
I conclude you must have changed the example in some way.  
If so, the solution to your problem will be found in the details 
of you changed it.  Nobody can guess that, so please attach 
the code you actually ran.

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

Comment By: mark lee smith (netytan)
Date: 2003-06-09 23:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 22:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 22:36:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 14:36:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19QDH8-0008UT-00@sc8-sf-web3.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 18:44
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-11 17:36

Message:
Logged In: YES 
user_id=31435

I don't hold out much hope that this will get resolved.  
Windows has tons of bugs (a lot more than Python!), and it's 
not uncommon to find a program (Python-based or otherwise) 
that fails on only one specific Windows box in the world.  For 
example, you could have a corrupted bit in any of the 
thousand Windows DLLs on your box, or you may simply be 
behind in running Windows Update.  Other possibilities include 
that you're running a virus checker (those often interfere with 
normal program operations), or are behind an improperly 
written firewall.

So long as your report is the only one of this nature, there's 
really no hope for resolving it short you digging into it.  I don't 
see any evidence of a bug in Python here (worse, a crash in a 
core OS DLL is prima facia evidence of a bug in the OS!).

If you can, try running the same thing on a friend's Windows 
box.  I bet you won't have any problem there.

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

Comment By: mark lee smith (netytan)
Date: 2003-06-11 17:22

Message:
Logged In: YES 
user_id=797196

Ok, I ran your file and it returned the same as when I ran 
mine,  both crashed the Kernal. I think the reason that the 
mail wasn't being sent before was that I forgot to finish the 
message with "^D" although the main problem remains, what 
is the Kernal crashing out :S..  

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

Comment By: mark lee smith (netytan)
Date: 2003-06-11 16:53

Message:
Logged In: YES 
user_id=797196

Hi, I've replicated what had before exactly, the win32 Kernal 
still crashes but the mail is delivered :S, don't ask me why it 
sends now and didn't before, nothing has changed to my 
knowlage.. Anyway if I've done this right it should be 
attached to this.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 19:47

Message:
Logged In: YES 
user_id=31435

Just attaching tcap.txt.  Note that on Windows, you have to 
end the msg with Ctrl-Z (not the Unixish Ctrl-D in the example 
comments).

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 19:45

Message:
Logged In: YES 
user_id=31435

I'll show you what I'm looking for:  attached is the exact code 
I just ran, in smtpex.py, and a screen dump from running it, in 
tcap.txt.  I changed the example to use comcast.net's SMTP 
server.  It worked fine for me on Win98SE.  I was using 
Python 2.2.3, and don't know whether that makes a 
difference.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 19:39

Message:
Logged In: YES 
user_id=31435

I don't understand.  If you're not running an SMTP server on 
localhost, I expect that example to die with

socket.error: (10061, 'Connection refused')

And indeed, that's what it does when I try it on Win98SE.  So 
I conclude you must have changed the example in some way.  
If so, the solution to your problem will be found in the details 
of you changed it.  Nobody can guess that, so please attach 
the code you actually ran.

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

Comment By: mark lee smith (netytan)
Date: 2003-06-09 19:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 18:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 23:16:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 15:16:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-749210 ] bdist --formats=zip,wininst and bdist --formats=wininst,zip
Message-ID: <E19QDtJ-0007uz-00@sc8-sf-web4.sourceforge.net>

Bugs item #749210, was opened at 2003-06-05 02:47
Message generated for change (Comment added) made by dubnerm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470

Category: Distutils
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Michael Dubner (dubnerm)
Assigned to: Thomas Heller (theller)
Summary: bdist --formats=zip,wininst and bdist --formats=wininst,zip

Initial Comment:
Commands
setup.py bdist --formats=zip,wininst
and
setup.py bdist --formats=wininst,zip
should create the same two archives, but in my config
first version (zip,wininst) creates broken .exe file -
no SCRIPTS and DATA directories - only PURELIB.
I'm using ActiveState Python 2.2.2 with included
distutils 1.0.3 under WinXP.

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

>Comment By: Michael Dubner (dubnerm)
Date: 2003-06-12 02:16

Message:
Logged In: YES 
user_id=39274

Yes, it fixes the problem.

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

Comment By: Thomas Heller (theller)
Date: 2003-06-11 20:30

Message:
Logged In: YES 
user_id=11105

Oops, I didn't want to unassign it!

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

Comment By: Thomas Heller (theller)
Date: 2003-06-11 20:21

Message:
Logged In: YES 
user_id=11105

Michael, can you please try the following patch and report
if it fixes your problem?

In the file distutils/command/bdist_wininst.py, replace the line
        install = self.reinitialize_command('install')
with this one:
        install = self.reinitialize_command('install',
reinit_subcommands=1)

This code is near line 103, just near the top of the 'def
run(self):' method.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470


From noreply@sourceforge.net  Wed Jun 11 23:36:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 15:36:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19QED8-0002bQ-00@sc8-sf-web3.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 22:44
Message generated for change (Comment added) made by netytan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

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

>Comment By: mark lee smith (netytan)
Date: 2003-06-11 22:36

Message:
Logged In: YES 
user_id=797196

Will do, I'll try run the script from my box upstairs and one at 
work. Thanks for all your help, at least it's sending email, be it 
you need to send "^D" in that example but with a little 
reworking it should be a problem. Thank's again.

P.S let's blame Microsoft, never did like them, so dodgy lol. If 
I could get away from Windows I would but unfortunatly it's a 
commercial standard.. Ta

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-11 21:36

Message:
Logged In: YES 
user_id=31435

I don't hold out much hope that this will get resolved.  
Windows has tons of bugs (a lot more than Python!), and it's 
not uncommon to find a program (Python-based or otherwise) 
that fails on only one specific Windows box in the world.  For 
example, you could have a corrupted bit in any of the 
thousand Windows DLLs on your box, or you may simply be 
behind in running Windows Update.  Other possibilities include 
that you're running a virus checker (those often interfere with 
normal program operations), or are behind an improperly 
written firewall.

So long as your report is the only one of this nature, there's 
really no hope for resolving it short you digging into it.  I don't 
see any evidence of a bug in Python here (worse, a crash in a 
core OS DLL is prima facia evidence of a bug in the OS!).

If you can, try running the same thing on a friend's Windows 
box.  I bet you won't have any problem there.

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

Comment By: mark lee smith (netytan)
Date: 2003-06-11 21:22

Message:
Logged In: YES 
user_id=797196

Ok, I ran your file and it returned the same as when I ran 
mine,  both crashed the Kernal. I think the reason that the 
mail wasn't being sent before was that I forgot to finish the 
message with "^D" although the main problem remains, what 
is the Kernal crashing out :S..  

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

Comment By: mark lee smith (netytan)
Date: 2003-06-11 20:53

Message:
Logged In: YES 
user_id=797196

Hi, I've replicated what had before exactly, the win32 Kernal 
still crashes but the mail is delivered :S, don't ask me why it 
sends now and didn't before, nothing has changed to my 
knowlage.. Anyway if I've done this right it should be 
attached to this.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:47

Message:
Logged In: YES 
user_id=31435

Just attaching tcap.txt.  Note that on Windows, you have to 
end the msg with Ctrl-Z (not the Unixish Ctrl-D in the example 
comments).

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:45

Message:
Logged In: YES 
user_id=31435

I'll show you what I'm looking for:  attached is the exact code 
I just ran, in smtpex.py, and a screen dump from running it, in 
tcap.txt.  I changed the example to use comcast.net's SMTP 
server.  It worked fine for me on Win98SE.  I was using 
Python 2.2.3, and don't know whether that makes a 
difference.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:39

Message:
Logged In: YES 
user_id=31435

I don't understand.  If you're not running an SMTP server on 
localhost, I expect that example to die with

socket.error: (10061, 'Connection refused')

And indeed, that's what it does when I try it on Win98SE.  So 
I conclude you must have changed the example in some way.  
If so, the solution to your problem will be found in the details 
of you changed it.  Nobody can guess that, so please attach 
the code you actually ran.

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

Comment By: mark lee smith (netytan)
Date: 2003-06-09 23:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 22:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 00:39:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 16:39:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-729103 ] Cannot retrieve name of super object
Message-ID: <E19QFCB-0004jY-00@sc8-sf-web3.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michele Simionato (michele_s)
>Assigned to: Brett Cannon (bcannon)
Summary: Cannot retrieve name of super object

Initial Comment:
I see that in Python 2.3b1 many problems of super
have been fixed, but this one is still there:
I cannot retrieve the __name__ of a super object.
This generates problems with pydoc, for instance:

>>> class C(B):
...     sup=super(B)
>>> help(C)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/site.py", line 293, in
__call__
    return pydoc.help(*args, **kwds)
  File "/usr/local/lib/python2.3/pydoc.py", line 1539,
in __call__
    self.help(request)
  File "/usr/local/lib/python2.3/pydoc.py", line 1575,
in help
    else: doc(request, 'Help on %s:')
  File "/usr/local/lib/python2.3/pydoc.py", line 1368,
in doc
    pager(title % desc + '\n\n' + text.document(object,
name))
  File "/usr/local/lib/python2.3/pydoc.py", line 279,
in document
    if inspect.isclass(object): return
self.docclass(*args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1122,
in docclass
    lambda t: t[1] == 'method')
  File "/usr/local/lib/python2.3/pydoc.py", line 1057,
in spill
    name, mod, object))
  File "/usr/local/lib/python2.3/pydoc.py", line 280,
in document
    if inspect.isroutine(object): return
self.docroutine(*args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1145,
in docroutine
    realname = object.__name__
AttributeError: 'super' object has no attribute
'__name__'

P.S. I seem to remember I already submitted this
bug (or feature request, as you wish ;) but I don't
find it in bugtracker and I had no feedback; maybe
it wasn't sent at all due to some connection problem.
If not, please accept my apologies.

    Michele Simionato

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-11 16:39

Message:
Logged In: YES 
user_id=357491

Patched pydoc (revision 1.84) to try an object as "other" if what 
inspect identifies it as does not work based on its assumptions.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 16:44

Message:
Logged In: YES 
user_id=357491

The issue is inspect.isroutine is saying that the instance is a 
callable object since it is also a non-data descriptor.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 00:56:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 16:56:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-723806 ] overintelligent slice() behavior on integers
Message-ID: <E19QFRh-0007BV-00@sc8-sf-web2.sourceforge.net>

Bugs item #723806, was opened at 2003-04-18 11:17
Message generated for change (Settings changed) made by russt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
>Resolution: Wont Fix
Priority: 5
Submitted By: Russ Thompson (russt)
Assigned to: Nobody/Anonymous (nobody)
Summary: overintelligent slice() behavior on integers

Initial Comment:

slices such as a[:7] give a key of slice(0,7,None)
whereas a[:7.1] gives a key of slice(None,7.1,None)

Slices should not assume that the object indices
begin at zero, since that is actually a characteristic of 
the object.  The current behavior cripples an object that 
wants, say, to start its indices with negative numbers.

a[:7] should pass a key of slice(None,7,None).

Thanks!
russt@agilityfund.com


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 21:20

Message:
Logged In: YES 
user_id=80475

Russ, you're right about there being two behaviors for the 
implementation of the slice notation(see apply_slice() in 
Python/ceval.c).  This occurs in the bytecode interpreter 
rather than some object's implementation of __getitem__.

While it is unfortunate, it can't be fixed without breaking 
code which defines __getitem__ but doesn't provide a None-
to-zero converter.

Factiod of the day, interpreter doesn't just assume 0 for 
None, it clamps the values in a range of 0<= value <= 
sys.maxint:

>>> class C:
        def __getitem__(self, i):
            return i

>>> c = C()
>>> c[10000000000000000000L:]
slice(2147483647, 2147483647, None)


I recommend you close the bug as Won't Fix.

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

Comment By: Russ Thompson (russt)
Date: 2003-06-10 15:23

Message:
Logged In: YES 
user_id=760126


'slice' doesn't round its arguments.  The difference
is whether you pass an integer or a float as part
of the slice.  Thus:
a[:7] gives a key of slice(0,7,None)
while
a[:7.0] gives a key of slice(None,7.0,None)

What's going on I suspect is that the python
has two different behaviours for __getitem__.
The first handles slices with integer only
components, and defaults to starting at zero.
The second handles anything else.  This is
probably done in order to accomodate old 
'list' and 'tuple' implementation code that doesn't
accept starting indices of None.  But the best
solution would be to eliminate the dual behavior
of slice and revise the list and tuple code to 
accept the more general behavior.


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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 14:45

Message:
Logged In: YES 
user_id=357491

How does having 'slice' not round its arguments have anything 
to do with assuming indices start at zero?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 02:03:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 18:03:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-723806 ] overintelligent slice() behavior on integers
Message-ID: <E19QGV7-00050U-00@sc8-sf-web4.sourceforge.net>

Bugs item #723806, was opened at 2003-04-18 11:17
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Russ Thompson (russt)
Assigned to: Nobody/Anonymous (nobody)
Summary: overintelligent slice() behavior on integers

Initial Comment:

slices such as a[:7] give a key of slice(0,7,None)
whereas a[:7.1] gives a key of slice(None,7.1,None)

Slices should not assume that the object indices
begin at zero, since that is actually a characteristic of 
the object.  The current behavior cripples an object that 
wants, say, to start its indices with negative numbers.

a[:7] should pass a key of slice(None,7,None).

Thanks!
russt@agilityfund.com


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 21:20

Message:
Logged In: YES 
user_id=80475

Russ, you're right about there being two behaviors for the 
implementation of the slice notation(see apply_slice() in 
Python/ceval.c).  This occurs in the bytecode interpreter 
rather than some object's implementation of __getitem__.

While it is unfortunate, it can't be fixed without breaking 
code which defines __getitem__ but doesn't provide a None-
to-zero converter.

Factiod of the day, interpreter doesn't just assume 0 for 
None, it clamps the values in a range of 0<= value <= 
sys.maxint:

>>> class C:
        def __getitem__(self, i):
            return i

>>> c = C()
>>> c[10000000000000000000L:]
slice(2147483647, 2147483647, None)


I recommend you close the bug as Won't Fix.

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

Comment By: Russ Thompson (russt)
Date: 2003-06-10 15:23

Message:
Logged In: YES 
user_id=760126


'slice' doesn't round its arguments.  The difference
is whether you pass an integer or a float as part
of the slice.  Thus:
a[:7] gives a key of slice(0,7,None)
while
a[:7.0] gives a key of slice(None,7.0,None)

What's going on I suspect is that the python
has two different behaviours for __getitem__.
The first handles slices with integer only
components, and defaults to starting at zero.
The second handles anything else.  This is
probably done in order to accomodate old 
'list' and 'tuple' implementation code that doesn't
accept starting indices of None.  But the best
solution would be to eliminate the dual behavior
of slice and revise the list and tuple code to 
accept the more general behavior.


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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 14:45

Message:
Logged In: YES 
user_id=357491

How does having 'slice' not round its arguments have anything 
to do with assuming indices start at zero?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 07:06:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 11 Jun 2003 23:06:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current
Message-ID: <E19QLEf-0000ae-00@sc8-sf-web2.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Till Plewe (tpx)
Assigned to: Nobody/Anonymous (nobody)
Summary: test/build-failures on FreeBSD stable/current

Initial Comment:
Using snapshot: python_2003-05-19_230000.tar.gz
STABLE (FreeBSD 4.8-STABLE #14: Mon Apr  7)
CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue
May 20)

BUILDFAILURE
curses does not build; neither on CURRENT nor on STABLE
(compiler complaint:

/usr/include/ncurses.h:289: conflicting types for `wchar_t'
/usr/include/stdlib.h:57: previous declaration of `wchar_t'
/usr/include/ncurses.h:292: conflicting types for `wint_t'
/usr/include/wchar.h:96: previous declaration of `wint_t'

if lines /usr/include/ncurses.h:288-293 

#ifndef __wchar_t
typedef unsigned long wchar_t;
#endif /* __wchar_t */
#ifndef __wint_t
typedef long int wint_t;
#endif /* __wint_t */

are deleted then curses builds)

TESTFAILURES
test_re fails on both CURRENT and STABLE
 
test_long
test_pow 
and many more (probably related) tests 

fail on current

See attached file for details


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

>Comment By: Till Plewe (tpx)
Date: 2003-06-12 06:06

Message:
Logged In: YES 
user_id=782552

The good news first: test_re works on STABLE/CURRENT and curses
builds on STABLE. 

curses still fails to build on CURRENT but this (as well as
for STABLE)  is really a FreeBSD problem (too many unrelated
guards). I am waiting for answers from various FreeBSD
mailing lists.
In the meantime I patched /usr/include/ncurses.h

Your patch for py_curses.h works for FreeBSD4 but for FreeBSD5 
you would also have to add 

#ifndef __wchar_t
#define __wchar_t
#endif
#ifndef __wint_t
#define __wint_t
#endif

All these guards should be replaced in ncurses.h by
_W{CHAR,INT}_T_DECLARED I believe (on CURRENT)

However I hope that eventually somebody from FreeBSD
will respond and that this problem will be dealt with from 
the FreeBSD side.   
 
The most recent test failure is test_signal. It boils down to
import signal

def handler(signum,frame):
    raise Exception

signal.signal(signal.SIGALRM,handler)
signal.alarm(5)
signal.pause()
signal.alarm(0)

hanging and not raising an exception on CURRENT with 
python2.3. However any of the following work: replacing
i) CURRENT by STABLE, or i) python2.3 by python2.2, or 
iii) SIGALRM by SIGVTALRM


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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-11 12:47

Message:
Logged In: YES 
user_id=250749

The _sre recursion limit was tweaked in _sre.c revision
2.98, which should deal with the bus error in test_re - at
least until thestack consumption per recursion increases again.

gcc 2.95 (FreeBSD 4.x) is set to 7500, gcc 3.x (FreeBSD 5.x)
is set to 6500 (tested on 4.8R).

The curses build problem should be addressed by revision 1.7
of Include/py_curses.h (tested on 4.8R)

Please let me know if the above fixes are satisfactory on
5.x. Is there anything else still needing attention?

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-01 07:47

Message:
Logged In: YES 
user_id=250749

Sigh...

Stacksize is indeed the problem with the test_re failure.

In the pthreads case, on FreeBSD prior to 5.x (I have no
info about 5.x, but from what you say it looks the same),
linking to libc_r causes the "initial" thread to get a hard
coded 1MB stack.  The stack size cannot be changed
(currently) without rebuilding libc_r :-(

As all these regression tests are running on the "initial"
thread, by virtue of not having been explicitly started in a
thread.

The problem is worse with gcc 3.x than 2.95, as gcc 3.x (I
tested with 3.2.2) seems to the stack  more aggressively.

I plan to post a patch to _sre.c extending the FreeBSD/gcc
specific #ifdef'ery (which was put in just before 2.3b1, and
was broken again by _sre commits shortly after 2.3b1).

configure --without-threads doesn't have a problem.

building a threaded interpreter with the Linuxthreads port
also doesn't suffer this problem.

I will be looking into preparing a FreeBSD patch to try and
allow a way to vary the "initial" thread stack size at
compile time, rather than libc_r build time.

This problem has been giving me the irrits since it first
appeared at the beginning of April.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-27 02:37

Message:
Logged In: YES 
user_id=782552

I forgot to mention that stack size is probably not the problem
(FreeBSD 5.1 and 4.8 behave identical with respect to
test_re.py) 
====================================
FreeBSD 4.8-STABLE FreeBSD 4.8-STABLE #14: Mon Apr  7
17:43:45 JST 2003  i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  524288
stack size              (kbytes, -s)  65536
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  896
open files                      (-n)  1792
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited

================================================================
FreeBSD 5.1-BETA FreeBSD 5.1-BETA #25: Thu May 22 09:10:55
JST 2003 i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  1572864
stack size              (kbytes, -s)  1572864
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  5547
open files                      (-n)  11095
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited


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

Comment By: Till Plewe (tpx)
Date: 2003-05-27 01:59

Message:
Logged In: YES 
user_id=782552

it seems that test_stack_overflow is the culprit

...
    def test_stack_overflow(self):
        # nasty case that overflows the straightforward
recursive
        # implementation of repeated groups.
        self.assertRaises(RuntimeError, re.match, '(x)*',
50000*'x')
        self.assertRaises(RuntimeError, re.match, '(x)*y',
50000*'x'+'y')
        self.assertRaises(RuntimeError, re.match, '(x)*?y',
50000*'x'+'y')
...

>>> A.test_stack_overflow()

Process Python bus error (core dumped)

Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*', 5000*'x')
<_sre.SRE_Match object at 0x81d2b20>
>>> re.match('(x)*', 50000*'x')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*y', 50000*'x'+'y')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*?y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*?y', 50000*'x'+'y')

Process Python bus error (core dumped)


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-24 23:40

Message:
Logged In: YES 
user_id=33168

Can you determine what the conflict in the header files
which prevents curses from building?

My guess is that test_bug_418626() is causing the core dump
(from test_re.py).  Can you verify the problem is in that
function?  If so, can you test each of the
re.match/re.search in the interpreter to determine which
line is failling?

My guess is that it's related to the recursion limit (likely
the last line).  Your stack size limit may be too small for
the python recursion limit.  You can try doing a ulimit -a
to see all the limits.  ulimit -s 8192 is what my stack size
is set to (but on Linux).  Doing that command may work for
you.  But this is all conjecture until you investigate further.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-22 05:04

Message:
Logged In: YES 
user_id=782552

Most of the test failures on FreeBSD CURRENT seem to be gcc
bugs.
(I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release))
Rebuilding world with the additional compiler flag 
  -mno-sse2
got rid of most test failures.

Now only the curses build failure and the test_re failure
remain.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-22 04:57

Message:
Logged In: YES 
user_id=782552

I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release).

Most of the test failures seem to be gcc-bugs.
Rebuilding world with the extra compiler flag 

   -mno-sse2

got rid of most test failures. Now only the test_re failure and
the curses build failure remain.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-21 22:34

Message:
Logged In: YES 
user_id=33168

I think many of the failures are due to the test_long
failure.  If that problem is fixed, my guess is several
other tests will start working.

What compiler are you using?  Can you try to debug the
test_long failure?  I don't think any python developers have
access to a freebsd box.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 08:24:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 00:24:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-450225 ] urljoin fails RFC tests
Message-ID: <E19QMSB-0006iQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #450225, was opened at 2001-08-11 22:10
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470

Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Brett Cannon (bcannon)
Summary: urljoin fails RFC tests

Initial Comment:
I've put together a test suite for Python's URLparse 
module, based on the tests in Appendix C of 
RFC2396 (the URI RFC). They're available at:

http://lists.w3.org/Archives/Public/uri/2001Aug/
0013.html

The major problem seems to be that it treats 
queries and parameters as special components 
(not just normal parts of the path), making this 
related to:

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

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-12 00:24

Message:
Logged In: YES 
user_id=357491

Since there is the random possibility that this might break code 
that depends on this to act like RFC 1808 instead of 2396 and 
2.3 has hit beta I am going to wait for 2.4 before I deal with this.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-11 17:35

Message:
Logged In: YES 
user_id=357491

mbrierst is right.  From C.1 of RFC 2396 (with http://a/b/c/d;p?q as the 
base):

    ?y            =  http://a/b/c/?y
    ;x            =  http://a/b/c/;x

And notice how this contradicts RFC 1808 ( with <URL:http://a/b/c/
d;p?q#f> as the base):

    ?y         = <URL:http://a/b/c/d;p?y>
    ;x         = <URL:http://a/b/c/d;x>

So obviously there is a conflict here.  And since RFC 2396 says "it revises and 
replaces the generic definitions in RFC 1738 and RFC 1808" (of which 
"generic" just means the actual syntax) this means that RFC 2396's solution 
should override.

Now the issue is whether the patch for this is the right thing to do (I am 
ignoring if the patch is correct; have not tested it yet).  This shouldn't break 
anything since the whole point of urlparse.urljoin is to have an abstracted 
way to create URIs without the user having to worry about all of these rules.  
So I say that it should be changed.

Fred, do you mind if I reassign this patch to myself and deal with it?

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

Comment By: Michael Stone (mbrierst)
Date: 2003-02-03 13:02

Message:
Logged In: YES 
user_id=670441

The two failing tests could not pass because RFC 1808 and RFC 2396 seem to conflict when a relative URI is given as just ;y or just ?y.

RFC 2396 claims to update RFC 1808, so presumably it describes the correct behavior.  The patch in this message (I can't upload it on sourceforge here for some reason) brings urljoin's behavior in line with RFC 2396, and changes the appropriate test cases.  I think if you apply this patch this bug can be closed.  Let me know what you think


Index: python/dist/src/Lib/urlparse.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/urlparse.py,v
retrieving revision 1.39
diff -c -r1.39 urlparse.py
*** python/dist/src/Lib/urlparse.py	7 Jan 2003 02:09:16 -0000	1.39
--- python/dist/src/Lib/urlparse.py	3 Feb 2003 20:51:08 -0000
***************
*** 157,169 ****
      if path[:1] == '/':
          return urlunparse((scheme, netloc, path,
                             params, query, fragment))
!     if not path:
!         if not params:
!             params = bparams
!             if not query:
!                 query = bquery
          return urlunparse((scheme, netloc, bpath,
!                            params, query, fragment))
      segments = bpath.split('/')[:-1] + path.split('/')
      # XXX The stuff below is bogus in various ways...
      if segments[-1] == '.':
--- 157,165 ----
      if path[:1] == '/':
          return urlunparse((scheme, netloc, path,
                             params, query, fragment))
!     if not (path or params or query):
          return urlunparse((scheme, netloc, bpath,
!                            bparams, bquery, fragment))
      segments = bpath.split('/')[:-1] + path.split('/')
      # XXX The stuff below is bogus in various ways...
      if segments[-1] == '.':
Index: python/dist/src/Lib/test/test_urlparse.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_urlparse.py,v
retrieving revision 1.11
diff -c -r1.11 test_urlparse.py
*** python/dist/src/Lib/test/test_urlparse.py	6 Jan 2003 20:27:03 -0000	1.11
--- python/dist/src/Lib/test/test_urlparse.py	3 Feb 2003 20:51:12 -0000
***************
*** 54,59 ****
--- 54,63 ----
              self.assertEqual(urlparse.urlunparse(urlparse.urlparse(u)), u)
  
      def test_RFC1808(self):
+         # updated by RFC 2396
+ #        self.checkJoin(RFC1808_BASE, '?y', 'http://a/b/c/d;p?y')
+ #        self.checkJoin(RFC1808_BASE, ';x', 'http://a/b/c/d;x')
+ 
          # "normal" cases from RFC 1808:
          self.checkJoin(RFC1808_BASE, 'g:h', 'g:h')
          self.checkJoin(RFC1808_BASE, 'g', 'http://a/b/c/g')
***************
*** 61,74 ****
          self.checkJoin(RFC1808_BASE, 'g/', 'http://a/b/c/g/')
          self.checkJoin(RFC1808_BASE, '/g', 'http://a/g')
          self.checkJoin(RFC1808_BASE, '//g', 'http://g')
-         self.checkJoin(RFC1808_BASE, '?y', 'http://a/b/c/d;p?y')
          self.checkJoin(RFC1808_BASE, 'g?y', 'http://a/b/c/g?y')
          self.checkJoin(RFC1808_BASE, 'g?y/./x', 'http://a/b/c/g?y/./x')
          self.checkJoin(RFC1808_BASE, '#s', 'http://a/b/c/d;p?q#s')
          self.checkJoin(RFC1808_BASE, 'g#s', 'http://a/b/c/g#s')
          self.checkJoin(RFC1808_BASE, 'g#s/./x', 'http://a/b/c/g#s/./x')
          self.checkJoin(RFC1808_BASE, 'g?y#s', 'http://a/b/c/g?y#s')
-         self.checkJoin(RFC1808_BASE, ';x', 'http://a/b/c/d;x')
          self.checkJoin(RFC1808_BASE, 'g;x', 'http://a/b/c/g;x')
          self.checkJoin(RFC1808_BASE, 'g;x?y#s', 'http://a/b/c/g;x?y#s')
          self.checkJoin(RFC1808_BASE, '.', 'http://a/b/c/')
--- 65,76 ----
***************
*** 103,111 ****
      def test_RFC2396(self):
          # cases from RFC 2396
  
!         ### urlparse.py as of v 1.32 fails on these two
!         #self.checkJoin(RFC2396_BASE, '?y', 'http://a/b/c/?y')
!         #self.checkJoin(RFC2396_BASE, ';x', 'http://a/b/c/;x')
  
          self.checkJoin(RFC2396_BASE, 'g:h', 'g:h')
          self.checkJoin(RFC2396_BASE, 'g', 'http://a/b/c/g')
--- 105,113 ----
      def test_RFC2396(self):
          # cases from RFC 2396
  
!         # conflict with RFC 1808, tests commented out there
!         self.checkJoin(RFC2396_BASE, '?y', 'http://a/b/c/?y')
!         self.checkJoin(RFC2396_BASE, ';x', 'http://a/b/c/;x')
  
          self.checkJoin(RFC2396_BASE, 'g:h', 'g:h')
          self.checkJoin(RFC2396_BASE, 'g', 'http://a/b/c/g')


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

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 21:34

Message:
Logged In: YES 
user_id=44345

added Aaron's RFC 2396 tests to test_urlparse.py
version 1.4 - the two failing tests are commented out



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

Comment By: Jon Ribbens (jribbens)
Date: 2002-03-18 06:22

Message:
Logged In: YES 
user_id=76089

I think it would be better btw if '..' components taking 
you 'off the top' were stripped. RFC 2396 says this is 
valid behaviour, and it's what 'real' browsers do.

i.e.
  http://a/b/ + ../../../d == http://a/d


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

Comment By: Aaron Swartz (aaronsw)
Date: 2001-11-05 10:34

Message:
Logged In: YES 
user_id=122141

Oops, meant to attach it...

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

Comment By: Aaron Swartz (aaronsw)
Date: 2001-11-05 10:30

Message:
Logged In: YES 
user_id=122141

Sure, here they are:



import urlparse

base = 'http://a/b/c/d;p?q'

assert urlparse.urljoin(base, 'g:h') == 'g:h'
assert urlparse.urljoin(base, 'g') ==   'http://a/b/c/g'
assert urlparse.urljoin(base, './g') == 'http://a/b/c/g'
assert urlparse.urljoin(base, 'g/') ==  'http://a/b/c/g/'
assert urlparse.urljoin(base, '/g') ==  'http://a/g'
assert urlparse.urljoin(base, '//g') == 'http://g'
assert urlparse.urljoin(base, '?y') ==  'http://a/b/c/?y'
assert urlparse.urljoin(base, 'g?y') == 'http://a/b/c/g?y'
assert urlparse.urljoin(base, '#s') ==  'http://a/b/c/
d;p?q#s'
assert urlparse.urljoin(base, 'g#s') == 'http://a/b/c/g#s'
assert urlparse.urljoin(base, 'g?y#s') == 'http://a/b/c/
g?y#s'
assert urlparse.urljoin(base, ';x') == 'http://a/b/c/;x'
assert urlparse.urljoin(base, 'g;x') ==  'http://a/b/c/g;x'
assert urlparse.urljoin(base, 'g;x?y#s') == 'http://a/b/c/
g;x?y#s'
assert urlparse.urljoin(base, '.') ==  'http://a/b/c/'
assert urlparse.urljoin(base, './') ==  'http://a/b/c/'
assert urlparse.urljoin(base, '..') ==  'http://a/b/'
assert urlparse.urljoin(base, '../') ==  'http://a/b/'
assert urlparse.urljoin(base, '../g') ==  'http://a/b/g'
assert urlparse.urljoin(base, '../..') ==  'http://a/'
assert urlparse.urljoin(base, '../../') ==  'http://a/'
assert urlparse.urljoin(base, '../../g') ==  'http://a/g'

assert urlparse.urljoin(base, '') == base

assert urlparse.urljoin(base, '../../../g')    ==  'http://a/../g'
assert urlparse.urljoin(base, '../../../../g') ==  'http://a/../../g'

assert urlparse.urljoin(base, '/./g') ==  'http://a/./g'
assert urlparse.urljoin(base, '/../g')         ==  'http://a/../g'
assert urlparse.urljoin(base, 'g.')            ==  'http://a/b/c/
g.'
assert urlparse.urljoin(base, '.g')            ==  'http://a/b/c/
.g'
assert urlparse.urljoin(base, 'g..')           == 'http://a/b/c/
g..'
assert urlparse.urljoin(base, '..g')           == 'http://a/b/c/
..g'

assert urlparse.urljoin(base, './../g')        ==  'http://a/b/g'
assert urlparse.urljoin(base, './g/.')         ==  'http://a/b/c/
g/'
assert urlparse.urljoin(base, 'g/./h')         ==  'http://a/b/c/
g/h'
assert urlparse.urljoin(base, 'g/../h')        ==  'http://a/b/c/
h'
assert urlparse.urljoin(base, 'g;x=1/./y')     ==  
'http://a/b/c/g;x=1/y'
assert urlparse.urljoin(base, 'g;x=1/../y')    ==  'http://a/b/
c/y'

assert urlparse.urljoin(base, 'g?y/./x')       ==  
'http://a/b/c/g?y/./x'
assert urlparse.urljoin(base, 'g?y/../x')      == 
'http://a/b/c/g?y/../x'
assert urlparse.urljoin(base, 'g#s/./x')       ==  'http://a/b/
c/g#s/./x'
assert urlparse.urljoin(base, 'g#s/../x')      ==  'http://a/b/
c/g#s/../x'



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-11-05 10:05

Message:
Logged In: YES 
user_id=3066

This looks like its probably related to #478038; I'll try to
tackle them together.  Can you attach your tests to the bug
report on SF?  Thanks!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 09:03:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 01:03:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-731403 ] test_tarfile writes in Lib/test directory
Message-ID: <E19QN3H-0002Q1-00@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Brett Cannon (bcannon)
Summary: test_tarfile writes in Lib/test directory

Initial Comment:
Test_tarfile writes a file in the Lib/test directory, which fails if Python 
has been installed read-only. It would be better if it used 
test_support.TESTFN as the basis for a filename to write to.

Here's the message for a binary install on MacOSX (framework 
Python):

test test_tarfile crashed -- exceptions.IOError: [Errno 13] Permission 
denied: '/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/test/testtar.tar.gz'


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

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-12 01:03

Message:
Logged In: YES 
user_id=357491

Fixed the temp file name to use test_support.TESTFN and the 
temp directory to use tempfile.gettempdir .  Also fixed the 
fetching of path names to use the functions used in the file 
instead of getting it from the global variables.

Changed filename to be absolute for testar.tar instead of using 
os.extsep since name is locked in since it is in CVS.

All checked in as revision 1.10 .

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731403&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 18:32:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 10:32:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-749210 ] bdist --formats=zip,wininst and bdist --formats=wininst,zip
Message-ID: <E19QVvt-0003BD-00@sc8-sf-web1.sourceforge.net>

Bugs item #749210, was opened at 2003-06-05 00:47
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470

Category: Distutils
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael Dubner (dubnerm)
Assigned to: Thomas Heller (theller)
Summary: bdist --formats=zip,wininst and bdist --formats=wininst,zip

Initial Comment:
Commands
setup.py bdist --formats=zip,wininst
and
setup.py bdist --formats=wininst,zip
should create the same two archives, but in my config
first version (zip,wininst) creates broken .exe file -
no SCRIPTS and DATA directories - only PURELIB.
I'm using ActiveState Python 2.2.2 with included
distutils 1.0.3 under WinXP.

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

>Comment By: Thomas Heller (theller)
Date: 2003-06-12 19:32

Message:
Logged In: YES 
user_id=11105

Checked in as bdist_wininst.py rev 1.46, and rev 1.27.4.4

Thanks for the clear bug report!

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

Comment By: Michael Dubner (dubnerm)
Date: 2003-06-12 00:16

Message:
Logged In: YES 
user_id=39274

Yes, it fixes the problem.

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

Comment By: Thomas Heller (theller)
Date: 2003-06-11 18:30

Message:
Logged In: YES 
user_id=11105

Oops, I didn't want to unassign it!

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

Comment By: Thomas Heller (theller)
Date: 2003-06-11 18:21

Message:
Logged In: YES 
user_id=11105

Michael, can you please try the following patch and report
if it fixes your problem?

In the file distutils/command/bdist_wininst.py, replace the line
        install = self.reinitialize_command('install')
with this one:
        install = self.reinitialize_command('install',
reinit_subcommands=1)

This code is near line 103, just near the top of the 'def
run(self):' method.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749210&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 19:09:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 11:09:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-753451 ] classmethod abuse --> SystemError
Message-ID: <E19QWWE-0004Xp-00@sc8-sf-web1.sourceforge.net>

Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"

Bugs item #753451, was opened at 2003-06-12 19: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=753451&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: classmethod abuse --> SystemError


Initial Comment:
This is obviously a silly thing to do:

>>> classmethod(1).__get__(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: ../Objects/classobject.c:2102: bad
argument to internal function

but I think that's still a bug.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753451&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 20:51:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 12:51:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-753518 ] Installing idle from new location
Message-ID: <E19QY6w-00024y-00@sc8-sf-web2.sourceforge.net>

Bugs item #753518, was opened at 2003-06-12 21: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=753518&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installing idle from new location

Initial Comment:
Makefile.pre.in and Mac/OSX/Makefile still use Tools/idle as 
the source from which they install idle in stead of the new 
Lib/idletools.

I'm mainly putting this bug report in the database so we 
don't forget to fix this before 2.3b2.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 22:55:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 14:55:52 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-697985 ] Move gmtime function from calendar to time module
Message-ID: <E19Qa2y-0001lg-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #697985, was opened at 2003-03-05 05:40
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erland Lewin (erl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Move gmtime function from calendar to time module

Initial Comment:
The gmtime function in the calendar module would be
much more logical to have in the time module, since it
manipulates tm tuples and unix timestamps, which the
other functions in time do, but no other functions in
calendar.

Related to bug #697983


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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-29 09:22

Message:
Logged In: YES 
user_id=357491

Well then, is there any desire to bother to make this happen?  Or is this just 
a "I hope someone likes this idea enough to implement it" instance in which 
case this should probably be made an RFE.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-28 19:59

Message:
Logged In: YES 
user_id=31435

mktime() interprets its argument as local time; timegm() as 
UTC.  Generally speaking,

time.mktime(time.localtime())

returns int(time.time()), and so does

calendar.timegm(time.gmtime())

The OP appears to be right that the time module doesn't 
have an "inverse" for time.gmtime() in this sense.  Then 
again, the time functions inherited from C are generally a 
twisted thicket.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-28 18:50

Message:
Logged In: YES 
user_id=357491

OK, assuming the OP meant calendar.timegm , doesn't time.mktime provide 
the same functionality?  Or is the desire to have it because  it specifies the 
epoch as 1970-01-01?

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-22 21:47

Message:
Logged In: YES 
user_id=31435

I expect the OP meant the calendar.timegm() function.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 14:46

Message:
Logged In: YES 
user_id=33168

The gmtime function is in time, not calendar.  Did you mean
the opposite that you believe gmtime should be in calendar?
  gmtime comes from the C version which is the purpose of
time, to expose C functions.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 23:00:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 15:00:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-753592 ] websucker bug
Message-ID: <E19Qa78-0007a0-00@sc8-sf-web2.sourceforge.net>

Bugs item #753592, was opened at 2003-06-12 16: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=753592&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: websucker bug

Initial Comment:
from c.l.py poster Anton Vredegoor who doesn't like that 
SF has a "must login to post bugs" barrier, and whose IE 
has problems handling the SF bugs page.

On Win98Se, Python23:
>
>>d:\python23\pythonw -u wsgui.py
>Exception in Tkinter callback
>Traceback (most recent call last):
>  File "D:\PYTHON23\lib\lib-tk\Tkinter.py", line 1337, in 
__call__
>    return self.func(*args)
>  File "wsgui.py", line 163, in go
>    self.sucker.rootdir = os.path.dirname(
>TypeError: unbound method savefilename() must be 
called with Sucker
>instance as first argument (got App instance instead)
>>Exit code: 0

My bug-fix:

change only 1 line (164):
                websucker.Sucker.savefilename(self, url))
into:
                websucker.Sucker.savefilename(self.sucker, 
url))

I've tested it and now it works as expected. Can we get 
this in
Python23 final? 



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753592&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 23:16:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 15:16:40 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-753600 ] why should += produce name binding?
Message-ID: <E19QaN6-0002cL-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #753600, was opened at 2003-06-12 18:16
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=753600&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: why should += produce name binding?

Initial Comment:

Currently, in

def x():
     foo += 1

... 'foo' is a local variable. Why should it be?
If the semantics are changed so that augmented
assignment is not a name-binding operation,
then only broken code will be affected.

This would allow you to use simple things
like   'EventCount += 1' without having to
use 'global EventCount'. After all, I can do
'EventList.append(...)' without the global decl.

For another (better) example, see 
http://mail.python.org/pipermail/edu-sig/2001-June/001329.html

In the response to the above, the poster is referred
to PEP227 which lists 'assignment' as a name-binding
operation. There is no clear-cut implication that this
includes augmented assignment, and in the Python
ref manual, one can only infer this behaviour from
the statement that x += y is almost equivalent
to x = x+y, which is pretty weak. In any case, since
an augmented assignment to a name always requires the
a-priori existence of that name in
an accessible namespace,  IMHO it should not
produce a binding.


















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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 23:18:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 15:18:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-753602 ] random.sample not properly documented
Message-ID: <E19QaOq-0002el-00@sc8-sf-web4.sourceforge.net>

Bugs item #753602, was opened at 2003-06-12 22: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=753602&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample not properly documented

Initial Comment:
random.sample seems to take a third argument:

 38 >>> random.sample(seq, 10, 'bla')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/random.py", line 247,
in sample
    j = int(random() * (n-i))
TypeError: 'str' object is not callable

However, the docs don't mention it.
I will try to patch it tomorrow (need to find out what
it does first ;)

Gerrit.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753602&group_id=5470


From noreply@sourceforge.net  Thu Jun 12 23:59:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 15:59:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-749261 ] os.path.split does not handle . & .. properly
Message-ID: <E19Qb31-0007wC-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Curtis Siemens (csiemens)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.split does not handle . & .. properly

Initial Comment:
The os.path.split() & posixpath.split() functions in my
opinion do not handle '.' & '..' at the end of a path
properly which causes os.path.dirname() &
os.path.basename() to also return the wrong result
because they are directly based on os.path.split().

I'll demonstrate the Unix Python case (the Windows
ntpath.py case is just a close parallel variation).

Example:
>python
Python 2.1.1
>>> posixpath.split('.')
('', '.')
>>> posixpath.split('..')
('', '..')

Yet:
>>> posixpath.split('./')
('..', '')
>>> posixpath.split('../')
('..', '')

Now '.' really represents './', and '..' really
represents '../'
Since the split() function simply uses a string split
on '/' to
find directories, it goofs up on this one case.  The
'.' and
'..' are like the slash character in the sense that
they all
only refer to directories.
The '.' & '..' can never be files in Unix or Windows, so I
think that the split() function should treat paths like:
    .
    ..
    dir/.
    dir/..
    /dir1/dir2/.
    /dir1/dir2/..
as not having a file portion, just as if:
    ./
    ../
    dir/./
    dir/../
    /dir1/dir2/./
    /dir1/dir2/../
respectively were given instead.

The fix in posixpath.py for this is just to put a
little path
processing code at the beginning of the split() function
that looks for the follow cases:
    if p in ['.','..'] or p[-2:] == '/.' or p[-3:] ==
'/..':
        p = p+'/'
And then go into all the regular split() code.
In fix in ntpath.py is very similar.

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

>Comment By: Curtis Siemens (csiemens)
Date: 2003-06-12 15:59

Message:
Logged In: YES 
user_id=794244

Ok, I see your points, but I have 2 points.

Point 1:
Your loop 'while path != "": path = os.path.split(path)[0]'
won't stop with an absolute path because it will get down
to '/' and go into infinite spin.
OK, so you can modify it to be:
  while path != "" and path != '/':path =os.path.split(path)[0]
But this too will spin if start with an absolute path that has
more than 2 slashes - like '//dir1/dir2' or '///dir1/dir2'
at the
front of the path.
OK, you can fix that up to by doing something like:
   old_path = ''
   while path != old_path:
       old_path = path
       path = os.path.split(path)[0]
But that final loop will work with my new os.path.split
proposal - which makes me wonder if your assertion that
split should have the 'terminate loop' property.

Point 2:
You may be right about os.path.split's slated task/job.
So maybe the change shouldn't be done to os.path.split(),
but rather os.path.dirname() & os.path.basename() should
be changed to not just simply return the 1st and 2nd
components of split(), but rather try to be as "smart" as
possible and dirname's intention is to return the directory
portion, and basename's intention is to return the (end)
filename portion - if possible.  With paths like /abc/xyz
you have no idea if xyz is a file or dir, so the default should
be 'file'.  Currently /abc/xyz/ knows that xyz is a dir and
returns /abc/xyz for the dirname and '' for the basename.
My point is that currently basename/dirname are "smart"
and not just returning the last component that is a file or
is a directory, otherwise it would return /abc for the dirname
and xyz/ for the basename.
So given the current behavior of dirname/basename, they
should be smart in ALL "we can tell its a directory" cases
such as:
  .
  ..
  dir/.
  dir/..
  /dir1/dir2/.
  /dir1/dir2/..

So do I have a good Point #1, and more importantly do I have
a good Point #2 - and if I do I could change this bug's title
to be os.path.dirname/basename related.

Curtis Siemens

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-08 08:34

Message:
Logged In: YES 
user_id=2772

I don't believe this behavior is a bug.  os.path.split's task is to split the last component of a path from the other components, regardless of whether any of the components actually names a directory.

Another property of os.path.split is that eventually this loop will terminate:
    while path != "": path = os.path.split(path)[0]
with your proposed change, this would not be true for paths that initially contain a "." or ".." component (since os.path.split("..") -> ('..', ''))

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749261&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 00:12:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 16:12:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-753617 ] dump_address_pair in email._parseaddr appears to be missing
Message-ID: <E19QbEu-0001Vx-00@sc8-sf-web2.sourceforge.net>

Bugs item #753617, was opened at 2003-06-12 16:12
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=753617&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: dump_address_pair in email._parseaddr appears to be missing

Initial Comment:
The _parseaddr module in the email module references a 
function called dump_address_pair on line 445.  This 
function lives in Utils.py and is not imported.  Thus if you 
try to do a str() of an AddressList object, it fails with a 
NameError.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753617&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 01:06:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 17:06:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-753602 ] random.sample not properly documented
Message-ID: <E19Qc52-0000zE-00@sc8-sf-web3.sourceforge.net>

Bugs item #753602, was opened at 2003-06-12 18: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=753602&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: random.sample not properly documented

Initial Comment:
random.sample seems to take a third argument:

 38 >>> random.sample(seq, 10, 'bla')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/random.py", line 247,
in sample
    j = int(random() * (n-i))
TypeError: 'str' object is not callable

However, the docs don't mention it.
I will try to patch it tomorrow (need to find out what
it does first ;)

Gerrit.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-12 20:06

Message:
Logged In: YES 
user_id=31435

It's documented correctly.  The third argument is

int=int

and is simply a speed trick to avoid the expense of looking up 
the builtin name "int" in the function body every time the 
function is called.  Lots of speed-intensive functions do that, 
alas.  Since you're calling function with three arguments 
that's documented as taking two, your code is in error.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753602&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 01:49:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 17:49:29 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-697985 ] Move gmtime function from calendar to time module
Message-ID: <E19Qckz-0006vP-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #697985, was opened at 2003-03-05 08:40
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erland Lewin (erl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Move gmtime function from calendar to time module

Initial Comment:
The gmtime function in the calendar module would be
much more logical to have in the time module, since it
manipulates tm tuples and unix timestamps, which the
other functions in time do, but no other functions in
calendar.

Related to bug #697983


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

>Comment By: Tim Peters (tim_one)
Date: 2003-06-12 20:49

Message:
Logged In: YES 
user_id=31435

Sorry, I don't have time to give to this.  It's certainly not a 
bug report <wink>.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-29 12:22

Message:
Logged In: YES 
user_id=357491

Well then, is there any desire to bother to make this happen?  Or is this just 
a "I hope someone likes this idea enough to implement it" instance in which 
case this should probably be made an RFE.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-28 22:59

Message:
Logged In: YES 
user_id=31435

mktime() interprets its argument as local time; timegm() as 
UTC.  Generally speaking,

time.mktime(time.localtime())

returns int(time.time()), and so does

calendar.timegm(time.gmtime())

The OP appears to be right that the time module doesn't 
have an "inverse" for time.gmtime() in this sense.  Then 
again, the time functions inherited from C are generally a 
twisted thicket.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-28 21:50

Message:
Logged In: YES 
user_id=357491

OK, assuming the OP meant calendar.timegm , doesn't time.mktime provide 
the same functionality?  Or is the desire to have it because  it specifies the 
epoch as 1970-01-01?

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-23 00:47

Message:
Logged In: YES 
user_id=31435

I expect the OP meant the calendar.timegm() function.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 17:46

Message:
Logged In: YES 
user_id=33168

The gmtime function is in time, not calendar.  Did you mean
the opposite that you believe gmtime should be in calendar?
  gmtime comes from the C version which is the purpose of
time, to expose C functions.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 02:14:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 18:14:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-753592 ] websucker bug
Message-ID: <E19Qd9Q-0003cn-00@sc8-sf-web1.sourceforge.net>

Bugs item #753592, was opened at 2003-06-12 18:00
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753592&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: websucker bug

Initial Comment:
from c.l.py poster Anton Vredegoor who doesn't like that 
SF has a "must login to post bugs" barrier, and whose IE 
has problems handling the SF bugs page.

On Win98Se, Python23:
>
>>d:\python23\pythonw -u wsgui.py
>Exception in Tkinter callback
>Traceback (most recent call last):
>  File "D:\PYTHON23\lib\lib-tk\Tkinter.py", line 1337, in 
__call__
>    return self.func(*args)
>  File "wsgui.py", line 163, in go
>    self.sucker.rootdir = os.path.dirname(
>TypeError: unbound method savefilename() must be 
called with Sucker
>instance as first argument (got App instance instead)
>>Exit code: 0

My bug-fix:

change only 1 line (164):
                websucker.Sucker.savefilename(self, url))
into:
                websucker.Sucker.savefilename(self.sucker, 
url))

I've tested it and now it works as expected. Can we get 
this in
Python23 final? 



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-12 21:14

Message:
Logged In: YES 
user_id=33168

Why wouldn't you want to do self.sucker.savefilename(url)?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753592&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 02:15:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 18:15:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-753518 ] Installing idle from new location
Message-ID: <E19QdAT-0002xM-00@sc8-sf-web3.sourceforge.net>

Bugs item #753518, was opened at 2003-06-12 15:51
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Installing idle from new location

Initial Comment:
Makefile.pre.in and Mac/OSX/Makefile still use Tools/idle as 
the source from which they install idle in stead of the new 
Lib/idletools.

I'm mainly putting this bug report in the database so we 
don't forget to fix this before 2.3b2.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-12 21:15

Message:
Logged In: YES 
user_id=33168

Kurt, can you take a look at this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 04:27:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 12 Jun 2003 20:27:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-753711 ] Infinite Loop in RE
Message-ID: <E19QfEK-0007hb-00@sc8-sf-web1.sourceforge.net>

Bugs item #753711, was opened at 2003-06-12 20: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=753711&group_id=5470

Category: Regular Expressions
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Bogosian (mbogosian)
Assigned to: Fredrik Lundh (effbot)
Summary: Infinite Loop in RE

Initial Comment:
This *may* be similar to
<http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=439997>,
but I don't think the current behavior (infinite
loop/unbound execution) is correct.

Here's the python version:

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

#!/usr/bin/python

import re

pattern =
'^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,'

# This won't match (missing ',' at end
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

re.search(pattern, str, re.I)

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

When run, this script just pegs the CPU and hangs (I'm
running RedHat 8.0). Note: if I change the pattern
slightly it still doesn't work:

pattern = '^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*([^
=,]+\s*)+,'

It's not until the pattern actually matches that things
get better (with both the original and modified patterns):

# Pattern now matches (added a ',' at the end)
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP),'

I tried doing the same thing in Perl:

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

#!/usr/bin/perl

'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)' =~
'/UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,/i';

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

This of course runs just fine. Any ideas?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 08:01:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 00:01:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-753602 ] random.sample not properly documented
Message-ID: <E19QiZJ-0000AX-00@sc8-sf-web4.sourceforge.net>

Bugs item #753602, was opened at 2003-06-12 17:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753602&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.sample not properly documented

Initial Comment:
random.sample seems to take a third argument:

 38 >>> random.sample(seq, 10, 'bla')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/random.py", line 247,
in sample
    j = int(random() * (n-i))
TypeError: 'str' object is not callable

However, the docs don't mention it.
I will try to patch it tomorrow (need to find out what
it does first ;)

Gerrit.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-13 02:01

Message:
Logged In: YES 
user_id=80475

Moved the int() optimization out of the definition to prevent 
future misunderstandings.  See Lib/random.py 

BTW, is Gerritt Holl your real name?  Just curious.

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

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

Message:
Logged In: YES 
user_id=31435

It's documented correctly.  The third argument is

int=int

and is simply a speed trick to avoid the expense of looking up 
the builtin name "int" in the function body every time the 
function is called.  Lots of speed-intensive functions do that, 
alas.  Since you're calling function with three arguments 
that's documented as taking two, your code is in error.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753602&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 09:25:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 01:25:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-753518 ] Installing idle from new location
Message-ID: <E19Qjru-0001De-00@sc8-sf-web2.sourceforge.net>

Bugs item #753518, was opened at 2003-06-12 21:51
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Installing idle from new location

Initial Comment:
Makefile.pre.in and Mac/OSX/Makefile still use Tools/idle as 
the source from which they install idle in stead of the new 
Lib/idletools.

I'm mainly putting this bug report in the database so we 
don't forget to fix this before 2.3b2.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-13 10:25

Message:
Logged In: YES 
user_id=45365

And, Kurt, could you please assign to me when Makefile.pre.in is 
done, so I can fix Mac/OSX/Makefile? (unless you want to give 
that a go too:-)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-13 03:15

Message:
Logged In: YES 
user_id=33168

Kurt, can you take a look at this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 09:50:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 01:50:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-753602 ] random.sample not properly documented
Message-ID: <E19QkGP-0001UY-00@sc8-sf-web2.sourceforge.net>

Bugs item #753602, was opened at 2003-06-13 00:18
Message generated for change (Comment added) made by gerrit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753602&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.sample not properly documented

Initial Comment:
random.sample seems to take a third argument:

 38 >>> random.sample(seq, 10, 'bla')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/random.py", line 247,
in sample
    j = int(random() * (n-i))
TypeError: 'str' object is not callable

However, the docs don't mention it.
I will try to patch it tomorrow (need to find out what
it does first ;)

Gerrit.

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

>Comment By: Gerrit Holl (gerrit)
Date: 2003-06-13 10:50

Message:
Logged In: YES 
user_id=13298

Ah... thanks.

[Rest of comment offtopic]

Yes, Gerrit Holl is my real name. Gerrit is a quite
traditional Dutch name (we have a right-wing minister called
Gerrit and there is a song called "Ik ben Gerrit" (I am
Gerrit)) and Holl is a surname, I think it was originally
German... This is the first time this question was ever
asked to me :)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-13 09:01

Message:
Logged In: YES 
user_id=80475

Moved the int() optimization out of the definition to prevent 
future misunderstandings.  See Lib/random.py 

BTW, is Gerritt Holl your real name?  Just curious.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-13 02:06

Message:
Logged In: YES 
user_id=31435

It's documented correctly.  The third argument is

int=int

and is simply a speed trick to avoid the expense of looking up 
the builtin name "int" in the function body every time the 
function is called.  Lots of speed-intensive functions do that, 
alas.  Since you're calling function with three arguments 
that's documented as taking two, your code is in error.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753602&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 11:16:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 03:16:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-753863 ] Broken reference for static/class method in docs
Message-ID: <E19Qlc8-0003sp-00@sc8-sf-web3.sourceforge.net>

Bugs item #753863, was opened at 2003-06-13 19:16
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=753863&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: Broken reference for static/class method in docs

Initial Comment:
In the ``Python Library Reference'', 2.1 Built-in 
Functions,
the documentation for staticmethod and classmethod 
breaks
in the middle of the sentence.
It looks like the \ref tag doesn't work well.

This is an excerpt from the html file, Doc/lib/built-in-
funcs.html.

  classmethod
    If you want those, see . New in version 2.2. 

  staticmethod
    For a more advanced concept, see . New in version 
2.2.

And here is an excerpt from the original tex file, 
Doc/lib/libfuncs.tex.

  classmethod
    If you want those, see \ref{staticmethod}.

  staticmethod
    For a more advanced concept, see \ref{classmethod}.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753863&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 12:33:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 04:33:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-753863 ] Broken reference for static/class method in docs
Message-ID: <E19QmoO-0007XE-00@sc8-sf-web1.sourceforge.net>

Bugs item #753863, was opened at 2003-06-13 06:16
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753863&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: Broken reference for static/class method in docs

Initial Comment:
In the ``Python Library Reference'', 2.1 Built-in 
Functions,
the documentation for staticmethod and classmethod 
breaks
in the middle of the sentence.
It looks like the \ref tag doesn't work well.

This is an excerpt from the html file, Doc/lib/built-in-
funcs.html.

  classmethod
    If you want those, see . New in version 2.2. 

  staticmethod
    For a more advanced concept, see . New in version 
2.2.

And here is an excerpt from the original tex file, 
Doc/lib/libfuncs.tex.

  classmethod
    If you want those, see \ref{staticmethod}.

  staticmethod
    For a more advanced concept, see \ref{classmethod}.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-13 07:33

Message:
Logged In: YES 
user_id=33168

This was fixed in bug 751941.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753863&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 13:03:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 05:03:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-749261 ] os.path.split does not handle . & .. properly
Message-ID: <E19QnHM-0007yr-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Curtis Siemens (csiemens)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.split does not handle . & .. properly

Initial Comment:
The os.path.split() & posixpath.split() functions in my
opinion do not handle '.' & '..' at the end of a path
properly which causes os.path.dirname() &
os.path.basename() to also return the wrong result
because they are directly based on os.path.split().

I'll demonstrate the Unix Python case (the Windows
ntpath.py case is just a close parallel variation).

Example:
>python
Python 2.1.1
>>> posixpath.split('.')
('', '.')
>>> posixpath.split('..')
('', '..')

Yet:
>>> posixpath.split('./')
('..', '')
>>> posixpath.split('../')
('..', '')

Now '.' really represents './', and '..' really
represents '../'
Since the split() function simply uses a string split
on '/' to
find directories, it goofs up on this one case.  The
'.' and
'..' are like the slash character in the sense that
they all
only refer to directories.
The '.' & '..' can never be files in Unix or Windows, so I
think that the split() function should treat paths like:
    .
    ..
    dir/.
    dir/..
    /dir1/dir2/.
    /dir1/dir2/..
as not having a file portion, just as if:
    ./
    ../
    dir/./
    dir/../
    /dir1/dir2/./
    /dir1/dir2/../
respectively were given instead.

The fix in posixpath.py for this is just to put a
little path
processing code at the beginning of the split() function
that looks for the follow cases:
    if p in ['.','..'] or p[-2:] == '/.' or p[-3:] ==
'/..':
        p = p+'/'
And then go into all the regular split() code.
In fix in ntpath.py is very similar.

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-13 07:03

Message:
Logged In: YES 
user_id=2772

OK-- so my statement of the "important property" of split
was only correct in the case of a non-absolute path.

The important point is that split shortens the path whenever
it contains more than one component.  You propose that of
the values given by repeated splits of "/foo/.."  or
"foo/..", you'll never see the one-component return "foo" or
"/foo".  Why do you believe that in the loop
    while 1:
        p = os.path.split(p)[0]
that p should never have one those values?  To me this seems
obviously incorrect.

You didn't respond to my point that os.path.split is about
components, not about whether those components name
directories.  For instance, because "/usr/local/bin" names a
directory on my system, shouldn't
os.path.split("/usr/local/bin") -> ('/usr/local/bin', '') if
your test really is about whether the final component names
a directory?  To me this seems obviously incorrect.

Let me also address your claim that because of this split
behavior, basename and dirname behave improperly.  This is
also wrong.  In "/tmp/.." and "/usr/local/bin", the first
names an entry ".." in the directory "/tmp", and the second
names an entry "bin" in the directory "/usr/local", just
like "/bin/sh" names an entry "sh" in the directory "/bin".

I strongly believe this bug should be marked closed,
resolution: invalid.

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

Comment By: Curtis Siemens (csiemens)
Date: 2003-06-12 17:59

Message:
Logged In: YES 
user_id=794244

Ok, I see your points, but I have 2 points.

Point 1:
Your loop 'while path != "": path = os.path.split(path)[0]'
won't stop with an absolute path because it will get down
to '/' and go into infinite spin.
OK, so you can modify it to be:
  while path != "" and path != '/':path =os.path.split(path)[0]
But this too will spin if start with an absolute path that has
more than 2 slashes - like '//dir1/dir2' or '///dir1/dir2'
at the
front of the path.
OK, you can fix that up to by doing something like:
   old_path = ''
   while path != old_path:
       old_path = path
       path = os.path.split(path)[0]
But that final loop will work with my new os.path.split
proposal - which makes me wonder if your assertion that
split should have the 'terminate loop' property.

Point 2:
You may be right about os.path.split's slated task/job.
So maybe the change shouldn't be done to os.path.split(),
but rather os.path.dirname() & os.path.basename() should
be changed to not just simply return the 1st and 2nd
components of split(), but rather try to be as "smart" as
possible and dirname's intention is to return the directory
portion, and basename's intention is to return the (end)
filename portion - if possible.  With paths like /abc/xyz
you have no idea if xyz is a file or dir, so the default should
be 'file'.  Currently /abc/xyz/ knows that xyz is a dir and
returns /abc/xyz for the dirname and '' for the basename.
My point is that currently basename/dirname are "smart"
and not just returning the last component that is a file or
is a directory, otherwise it would return /abc for the dirname
and xyz/ for the basename.
So given the current behavior of dirname/basename, they
should be smart in ALL "we can tell its a directory" cases
such as:
  .
  ..
  dir/.
  dir/..
  /dir1/dir2/.
  /dir1/dir2/..

So do I have a good Point #1, and more importantly do I have
a good Point #2 - and if I do I could change this bug's title
to be os.path.dirname/basename related.

Curtis Siemens

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-08 10:34

Message:
Logged In: YES 
user_id=2772

I don't believe this behavior is a bug.  os.path.split's task is to split the last component of a path from the other components, regardless of whether any of the components actually names a directory.

Another property of os.path.split is that eventually this loop will terminate:
    while path != "": path = os.path.split(path)[0]
with your proposed change, this would not be true for paths that initially contain a "." or ".." component (since os.path.split("..") -> ('..', ''))

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749261&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 13:15:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 05:15:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-753711 ] Infinite Loop in RE
Message-ID: <E19QnSo-00015f-00@sc8-sf-web1.sourceforge.net>

Bugs item #753711, was opened at 2003-06-12 22:27
Message generated for change (Comment added) made by sjones
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470

Category: Regular Expressions
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Bogosian (mbogosian)
Assigned to: Fredrik Lundh (effbot)
Summary: Infinite Loop in RE

Initial Comment:
This *may* be similar to
<http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=439997>,
but I don't think the current behavior (infinite
loop/unbound execution) is correct.

Here's the python version:

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

#!/usr/bin/python

import re

pattern =
'^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,'

# This won't match (missing ',' at end
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

re.search(pattern, str, re.I)

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

When run, this script just pegs the CPU and hangs (I'm
running RedHat 8.0). Note: if I change the pattern
slightly it still doesn't work:

pattern = '^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*([^
=,]+\s*)+,'

It's not until the pattern actually matches that things
get better (with both the original and modified patterns):

# Pattern now matches (added a ',' at the end)
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP),'

I tried doing the same thing in Perl:

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

#!/usr/bin/perl

'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)' =~
'/UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,/i';

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

This of course runs just fine. Any ideas?

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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 07:15

Message:
Logged In: YES 
user_id=589306

If you change your regex and sample data to the following
simpler forms, you get the same problem:

pattern = '(\S+\s*)+,'
str = 'CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

If you remove some letters from str, the search does finish
but it takes several seconds. I believe the problem is that
your regex takes exponential time to execute based on the
length of str. Here is a recent python-dev post that talks
about the problem:

http://mail.python.org/pipermail/python-dev/2003-May/035916.html

The link you provided in the bug report talks about this as
well. You can also do a web search for "regular expression
exponential" to see more information. I believe that any
regex engine (that has similar features to Python's engine)
will have some regular expressions that take exponential
time or space. Perl has some cases as well (search for
"exponential" in perldoc perlre).  This is just how regular
expressions are and IMHO does not indicate a bug in Python.

As far as how to fix the regular expression, I can't say.
I'm sure there is a way to "rephrase" what you want to get
it to work. Maybe try asking in the comp.lang.python newsgroup.

Good luck!


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 13:32:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 05:32:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-753925 ] OSA handling of toplevel properties is weird
Message-ID: <E19Qnj0-0001QM-00@sc8-sf-web2.sourceforge.net>

Bugs item #753925, was opened at 2003-06-13 14: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=753925&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: OSA handling of toplevel properties is weird

Initial Comment:
Handling toplevel properties (i.e. properties of the 
application) in Python is strange. In applescript you can say
"get player state" to iTunes and it will tell you whether it is 
playing or not.

In Python you have to do 
xx.get(iTunes.iTunes_Suite._Prop_player_state()), which I 
actually found by accident:-)

Why you have to use the funny name I know (and can fix), 
but the strange call of the property object is a mystery to 
me. "get name of window 1" translates to 
"xx.get(iTunes.window(1).name)", but even 
"xx.get(iTunes.application(0).name)" doesn't.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753925&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 15:30:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 07:30:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-753925 ] OSA handling of toplevel properties is weird
Message-ID: <E19QpZY-0005tC-00@sc8-sf-web3.sourceforge.net>

Bugs item #753925, was opened at 2003-06-13 14:32
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753925&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: OSA handling of toplevel properties is weird

Initial Comment:
Handling toplevel properties (i.e. properties of the 
application) in Python is strange. In applescript you can say
"get player state" to iTunes and it will tell you whether it is 
playing or not.

In Python you have to do 
xx.get(iTunes.iTunes_Suite._Prop_player_state()), which I 
actually found by accident:-)

Why you have to use the funny name I know (and can fix), 
but the strange call of the property object is a mystery to 
me. "get name of window 1" translates to 
"xx.get(iTunes.window(1).name)", but even 
"xx.get(iTunes.application(0).name)" doesn't.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-13 16:30

Message:
Logged In: YES 
user_id=45365

The strange behaviour was logical, and easy to fix, the magic 
that allows you to say "window(0).name" is in the __getattr__ 
of the window object, so we do that manually for properties.

In addition the main class of the scripting packages now also 
mimicks the OSA "application" class.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753925&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 16:13:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 08:13:07 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-754014 ] list.index() should accept optional start, end arguments
Message-ID: <E19QqEl-00031T-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #754014, was opened at 2003-06-13 10:13
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=754014&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: list.index() should accept optional start, end arguments

Initial Comment:
As with the .index() method on strings, which allows 
scanning only a subset of the string by specifying 
optional start and end arguments, the list type's index() 
method should do the same.

The use case comes from the thread started here: 
http://mail.python.org/pipermail/python-list/2003-
June/168225.html .  

A later posting shows a list-comprehension-based 
solution which is fairly clean, but relies on generating a 
temporary utility list using range() (or xrange()).  
Another easy alternative would be to manually create 
subsets of the list using slicing, but that would involve a 
lot of overhead compared to including it in the index() 
method itself.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=754014&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 16:15:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 08:15:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-754016 ] urlparse goes wrong with IP:port without scheme
Message-ID: <E19QqH8-00037i-00@sc8-sf-web4.sourceforge.net>

Bugs item #754016, was opened at 2003-06-13 17: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=754016&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Krüger (kruegi)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse goes wrong with IP:port without scheme

Initial Comment:
urlparse doesnt work if IP and port are given without 
scheme:

>>> urlparse.urlparse('1.2.3.4:80','http')
('1.2.3.4', '', '80', '', '', '')

should be:

>>> urlparse.urlparse('1.2.3.4:80','http')
('http', '1.2.3.4', '80', '', '', '')

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 18:33:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 10:33:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-753518 ] Installing idle from new location
Message-ID: <E19QsQF-0006dz-00@sc8-sf-web2.sourceforge.net>

Bugs item #753518, was opened at 2003-06-12 14:51
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470

>Category: Installation
>Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Installing idle from new location

Initial Comment:
Makefile.pre.in and Mac/OSX/Makefile still use Tools/idle as 
the source from which they install idle in stead of the new 
Lib/idletools.

I'm mainly putting this bug report in the database so we 
don't forget to fix this before 2.3b2.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-06-13 12:33

Message:
Logged In: YES 
user_id=149084

Jack, I've got Makefile.pre.in mostly done,
(there's a problem installing the icons).  I was 
going to do exactly what you suggest: look at
Mac/OSX/Makefile and /maybe/ make a first try,
then assign this to you.

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-13 03:25

Message:
Logged In: YES 
user_id=45365

And, Kurt, could you please assign to me when Makefile.pre.in is 
done, so I can fix Mac/OSX/Makefile? (unless you want to give 
that a go too:-)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-12 20:15

Message:
Logged In: YES 
user_id=33168

Kurt, can you take a look at this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 19:43:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 11:43:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-749261 ] os.path.split does not handle . & .. properly
Message-ID: <E19QtWc-0001QN-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Curtis Siemens (csiemens)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.split does not handle . & .. properly

Initial Comment:
The os.path.split() & posixpath.split() functions in my
opinion do not handle '.' & '..' at the end of a path
properly which causes os.path.dirname() &
os.path.basename() to also return the wrong result
because they are directly based on os.path.split().

I'll demonstrate the Unix Python case (the Windows
ntpath.py case is just a close parallel variation).

Example:
>python
Python 2.1.1
>>> posixpath.split('.')
('', '.')
>>> posixpath.split('..')
('', '..')

Yet:
>>> posixpath.split('./')
('..', '')
>>> posixpath.split('../')
('..', '')

Now '.' really represents './', and '..' really
represents '../'
Since the split() function simply uses a string split
on '/' to
find directories, it goofs up on this one case.  The
'.' and
'..' are like the slash character in the sense that
they all
only refer to directories.
The '.' & '..' can never be files in Unix or Windows, so I
think that the split() function should treat paths like:
    .
    ..
    dir/.
    dir/..
    /dir1/dir2/.
    /dir1/dir2/..
as not having a file portion, just as if:
    ./
    ../
    dir/./
    dir/../
    /dir1/dir2/./
    /dir1/dir2/../
respectively were given instead.

The fix in posixpath.py for this is just to put a
little path
processing code at the beginning of the split() function
that looks for the follow cases:
    if p in ['.','..'] or p[-2:] == '/.' or p[-3:] ==
'/..':
        p = p+'/'
And then go into all the regular split() code.
In fix in ntpath.py is very similar.

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

>Comment By: Curtis Siemens (csiemens)
Date: 2003-06-13 11:43

Message:
Logged In: YES 
user_id=794244

Ok, I like the statment,
  "split shortens the path whenever it contains more than one
   component"
I can go with that definition of os.path.split()
because that's consistent for all paths, absolute or relative,
and given that definition I'll agree that split is about
components.

Ok, onto dirname/basename which are really the source of my
concern.  I looked at the python documentation for basename()
and I think that it points out a problem that has been
tolerated.
It states:
    Note that the result of this function is different from the
    Unix basename program; where basename for '/foo/bar/'
    returns 'bar', the basename() function returns an empty
    string ('').
You state that the final component of a path should be
returned for basename() irregardless if it is a file or
directory.
I can get behind that, but then I think that statement supports
the Unix basename function implementation where /foo/bar/
has 'bar' (or 'bar/') returned for basename because /foo/bar
and /foo/bar/ are the same path, and to me 'bar' or 'bar/' is
the same single component since the trailing slash (and only
the trailing slash(es) case) is redundant.  Am I way off on
this?

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-13 05:03

Message:
Logged In: YES 
user_id=2772

OK-- so my statement of the "important property" of split
was only correct in the case of a non-absolute path.

The important point is that split shortens the path whenever
it contains more than one component.  You propose that of
the values given by repeated splits of "/foo/.."  or
"foo/..", you'll never see the one-component return "foo" or
"/foo".  Why do you believe that in the loop
    while 1:
        p = os.path.split(p)[0]
that p should never have one those values?  To me this seems
obviously incorrect.

You didn't respond to my point that os.path.split is about
components, not about whether those components name
directories.  For instance, because "/usr/local/bin" names a
directory on my system, shouldn't
os.path.split("/usr/local/bin") -> ('/usr/local/bin', '') if
your test really is about whether the final component names
a directory?  To me this seems obviously incorrect.

Let me also address your claim that because of this split
behavior, basename and dirname behave improperly.  This is
also wrong.  In "/tmp/.." and "/usr/local/bin", the first
names an entry ".." in the directory "/tmp", and the second
names an entry "bin" in the directory "/usr/local", just
like "/bin/sh" names an entry "sh" in the directory "/bin".

I strongly believe this bug should be marked closed,
resolution: invalid.

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

Comment By: Curtis Siemens (csiemens)
Date: 2003-06-12 15:59

Message:
Logged In: YES 
user_id=794244

Ok, I see your points, but I have 2 points.

Point 1:
Your loop 'while path != "": path = os.path.split(path)[0]'
won't stop with an absolute path because it will get down
to '/' and go into infinite spin.
OK, so you can modify it to be:
  while path != "" and path != '/':path =os.path.split(path)[0]
But this too will spin if start with an absolute path that has
more than 2 slashes - like '//dir1/dir2' or '///dir1/dir2'
at the
front of the path.
OK, you can fix that up to by doing something like:
   old_path = ''
   while path != old_path:
       old_path = path
       path = os.path.split(path)[0]
But that final loop will work with my new os.path.split
proposal - which makes me wonder if your assertion that
split should have the 'terminate loop' property.

Point 2:
You may be right about os.path.split's slated task/job.
So maybe the change shouldn't be done to os.path.split(),
but rather os.path.dirname() & os.path.basename() should
be changed to not just simply return the 1st and 2nd
components of split(), but rather try to be as "smart" as
possible and dirname's intention is to return the directory
portion, and basename's intention is to return the (end)
filename portion - if possible.  With paths like /abc/xyz
you have no idea if xyz is a file or dir, so the default should
be 'file'.  Currently /abc/xyz/ knows that xyz is a dir and
returns /abc/xyz for the dirname and '' for the basename.
My point is that currently basename/dirname are "smart"
and not just returning the last component that is a file or
is a directory, otherwise it would return /abc for the dirname
and xyz/ for the basename.
So given the current behavior of dirname/basename, they
should be smart in ALL "we can tell its a directory" cases
such as:
  .
  ..
  dir/.
  dir/..
  /dir1/dir2/.
  /dir1/dir2/..

So do I have a good Point #1, and more importantly do I have
a good Point #2 - and if I do I could change this bug's title
to be os.path.dirname/basename related.

Curtis Siemens

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-08 08:34

Message:
Logged In: YES 
user_id=2772

I don't believe this behavior is a bug.  os.path.split's task is to split the last component of a path from the other components, regardless of whether any of the components actually names a directory.

Another property of os.path.split is that eventually this loop will terminate:
    while path != "": path = os.path.split(path)[0]
with your proposed change, this would not be true for paths that initially contain a "." or ".." component (since os.path.split("..") -> ('..', ''))

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749261&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 20:27:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 12:27:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-702858 ] deepcopy can't copy self-referential new-style classes
Message-ID: <E19QuD4-0005by-00@sc8-sf-web4.sourceforge.net>

Bugs item #702858, was opened at 2003-03-13 05:14
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702858&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Stephen C Phillips (scp93ch)
Assigned to: Nobody/Anonymous (nobody)
Summary: deepcopy can't copy self-referential new-style classes

Initial Comment:
Given this code:

import copy
class Foo(object):
    pass
f = Foo()
f.bar = f
g = copy.deepcopy(f)

You will find with Python 2.3a2 and 2.2.2:

f is f.bar   ->  True
g is g.bar   ->  False
g is not f   -> True
g.bar is not f   -> True

Obviously, all the statements should be True.



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-13 15:27

Message:
Logged In: YES 
user_id=6380

Fixed using that patch.

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

Comment By: Steven Taschuk (staschuk)
Date: 2003-03-30 06:10

Message:
Logged In: YES 
user_id=666873

See patch 707900.

http://www.python.org/sf/707900

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702858&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 20:42:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 12:42:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19QuRN-00051k-00@sc8-sf-web1.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 11:55
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.2.3
Status: Open
>Resolution: Fixed
Priority: 6
Submitted By: Kevin Jacobs (jacobs99)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-13 15:42

Message:
Logged In: YES 
user_id=6380

Thanks! Fixed in CVS for 2.3. This should be backported to
2.2 too; assiged to Neal Norwitz for that purpose.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:24

Message:
Logged In: YES 
user_id=459565

er, see Bug 742911 instead.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:21

Message:
Logged In: YES 
user_id=459565

Oh, and with the patch, 'make test' completes without
any new errors, my attached test case works, as does
the minimal test case associated with Bug 751998.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:19

Message:
Logged In: YES 
user_id=459565

Okay, I had a few minutes free.  The problem is that
slots are being deallocated too early -- before tp_dealloc.
I'm attaching a patch that corrects this at the expense of
having to travel up the path of base class tp_dealloc
entries twice.  Here is the new sequence of actions:

1) Find the nearest base with a different tp_dealloc
2) Clear weakrefs
3) Call finalizer
4) Check to see if object was resurrected, if so stop
5) Clear all slots up to nearest base with a different 
    tp_dealloc
6) DECREF dict pointer, if necessary
7) proceed as usual... (call basedealloc, DECREF type, etc.)

Without my patch, step number 5  is done as part of step
1, and bad things happen.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:07

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve Bug 751998 is the cause of this
potentially more serious one bug.  I have yet to figure 
out why, though I have isolated the problem to revision
2.234 of typeobject.c.  I've not looked to see if this also 
affects Python 2.2.3, though I wouldn't be too suprised if it 
does.

More soon, hopefully.  Maybe...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 20:44:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 12:44:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-749261 ] os.path.split does not handle . & .. properly
Message-ID: <E19QuTm-00058o-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Curtis Siemens (csiemens)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.split does not handle . & .. properly

Initial Comment:
The os.path.split() & posixpath.split() functions in my
opinion do not handle '.' & '..' at the end of a path
properly which causes os.path.dirname() &
os.path.basename() to also return the wrong result
because they are directly based on os.path.split().

I'll demonstrate the Unix Python case (the Windows
ntpath.py case is just a close parallel variation).

Example:
>python
Python 2.1.1
>>> posixpath.split('.')
('', '.')
>>> posixpath.split('..')
('', '..')

Yet:
>>> posixpath.split('./')
('..', '')
>>> posixpath.split('../')
('..', '')

Now '.' really represents './', and '..' really
represents '../'
Since the split() function simply uses a string split
on '/' to
find directories, it goofs up on this one case.  The
'.' and
'..' are like the slash character in the sense that
they all
only refer to directories.
The '.' & '..' can never be files in Unix or Windows, so I
think that the split() function should treat paths like:
    .
    ..
    dir/.
    dir/..
    /dir1/dir2/.
    /dir1/dir2/..
as not having a file portion, just as if:
    ./
    ../
    dir/./
    dir/../
    /dir1/dir2/./
    /dir1/dir2/../
respectively were given instead.

The fix in posixpath.py for this is just to put a
little path
processing code at the beginning of the split() function
that looks for the follow cases:
    if p in ['.','..'] or p[-2:] == '/.' or p[-3:] ==
'/..':
        p = p+'/'
And then go into all the regular split() code.
In fix in ntpath.py is very similar.

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-13 14:44

Message:
Logged In: YES 
user_id=2772

Interestingly, it appears that back in Python version 1.2,
os.path.split may have behaved in the way you described.
From
http://www.via.ecp.fr/python-doc/python-lib/posixpath.html :
split (p) -- function of module posixpath
    Split the pathname p in a pair (head, tail), where tail
is the last pathname component and head is everything
leading up to that. If p ends in a slash (except if it is
the root), the trailing slash is removed and the operation
applied to the result; otherwise, join(head, tail) equals p.
The tail part never contains a slash. Some boundary cases:
if p is the root, head equals p and tail is empty; if p is
empty, both head and tail are empty; if p contains no slash,
head is empty and tail equals p.

By version 1.4, the behavior had
changed:http://www.python.org/doc/1.4/lib/node75.html
split(p)
    Split the pathname p in a pair (head, tail), where tail
is the last pathname component and head is everything
leading up to that. The tail part will never contain a
slash; if p ends in a slash, tail will be empty. If there is
no slash in p, head will be empty. If p is empty, both head
and tail are empty. Trailing slashes are stripped from head
unless it is the root (one or more slashes only). In nearly
all cases, join(head, tail) equals p (the only exception
being when there were multiple slashes separating head from
tail).

This change in the Python CVS was made by Guido himself,
between the 1.2 and 1.3 releases:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/posixpath.py.diff?r1=1.15&r2=1.16

Since the behavior you are now proposing was one that Guido
explicitly got rid of, it seems like an uphill battle to ask
for it back, especially since the current behavior has been
clearly documented for the 1.3, 1.4, 1.5, 1.6, 2.0, 2.1, and
2.2 releases (the last 7 major releases, spanning  something
like 8 years---or about the time of the introduction of
keyword arguments, according to 1.3's Misc/NEWS)

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

Comment By: Curtis Siemens (csiemens)
Date: 2003-06-13 13:43

Message:
Logged In: YES 
user_id=794244

Ok, I like the statment,
  "split shortens the path whenever it contains more than one
   component"
I can go with that definition of os.path.split()
because that's consistent for all paths, absolute or relative,
and given that definition I'll agree that split is about
components.

Ok, onto dirname/basename which are really the source of my
concern.  I looked at the python documentation for basename()
and I think that it points out a problem that has been
tolerated.
It states:
    Note that the result of this function is different from the
    Unix basename program; where basename for '/foo/bar/'
    returns 'bar', the basename() function returns an empty
    string ('').
You state that the final component of a path should be
returned for basename() irregardless if it is a file or
directory.
I can get behind that, but then I think that statement supports
the Unix basename function implementation where /foo/bar/
has 'bar' (or 'bar/') returned for basename because /foo/bar
and /foo/bar/ are the same path, and to me 'bar' or 'bar/' is
the same single component since the trailing slash (and only
the trailing slash(es) case) is redundant.  Am I way off on
this?

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-13 07:03

Message:
Logged In: YES 
user_id=2772

OK-- so my statement of the "important property" of split
was only correct in the case of a non-absolute path.

The important point is that split shortens the path whenever
it contains more than one component.  You propose that of
the values given by repeated splits of "/foo/.."  or
"foo/..", you'll never see the one-component return "foo" or
"/foo".  Why do you believe that in the loop
    while 1:
        p = os.path.split(p)[0]
that p should never have one those values?  To me this seems
obviously incorrect.

You didn't respond to my point that os.path.split is about
components, not about whether those components name
directories.  For instance, because "/usr/local/bin" names a
directory on my system, shouldn't
os.path.split("/usr/local/bin") -> ('/usr/local/bin', '') if
your test really is about whether the final component names
a directory?  To me this seems obviously incorrect.

Let me also address your claim that because of this split
behavior, basename and dirname behave improperly.  This is
also wrong.  In "/tmp/.." and "/usr/local/bin", the first
names an entry ".." in the directory "/tmp", and the second
names an entry "bin" in the directory "/usr/local", just
like "/bin/sh" names an entry "sh" in the directory "/bin".

I strongly believe this bug should be marked closed,
resolution: invalid.

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

Comment By: Curtis Siemens (csiemens)
Date: 2003-06-12 17:59

Message:
Logged In: YES 
user_id=794244

Ok, I see your points, but I have 2 points.

Point 1:
Your loop 'while path != "": path = os.path.split(path)[0]'
won't stop with an absolute path because it will get down
to '/' and go into infinite spin.
OK, so you can modify it to be:
  while path != "" and path != '/':path =os.path.split(path)[0]
But this too will spin if start with an absolute path that has
more than 2 slashes - like '//dir1/dir2' or '///dir1/dir2'
at the
front of the path.
OK, you can fix that up to by doing something like:
   old_path = ''
   while path != old_path:
       old_path = path
       path = os.path.split(path)[0]
But that final loop will work with my new os.path.split
proposal - which makes me wonder if your assertion that
split should have the 'terminate loop' property.

Point 2:
You may be right about os.path.split's slated task/job.
So maybe the change shouldn't be done to os.path.split(),
but rather os.path.dirname() & os.path.basename() should
be changed to not just simply return the 1st and 2nd
components of split(), but rather try to be as "smart" as
possible and dirname's intention is to return the directory
portion, and basename's intention is to return the (end)
filename portion - if possible.  With paths like /abc/xyz
you have no idea if xyz is a file or dir, so the default should
be 'file'.  Currently /abc/xyz/ knows that xyz is a dir and
returns /abc/xyz for the dirname and '' for the basename.
My point is that currently basename/dirname are "smart"
and not just returning the last component that is a file or
is a directory, otherwise it would return /abc for the dirname
and xyz/ for the basename.
So given the current behavior of dirname/basename, they
should be smart in ALL "we can tell its a directory" cases
such as:
  .
  ..
  dir/.
  dir/..
  /dir1/dir2/.
  /dir1/dir2/..

So do I have a good Point #1, and more importantly do I have
a good Point #2 - and if I do I could change this bug's title
to be os.path.dirname/basename related.

Curtis Siemens

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-08 10:34

Message:
Logged In: YES 
user_id=2772

I don't believe this behavior is a bug.  os.path.split's task is to split the last component of a path from the other components, regardless of whether any of the components actually names a directory.

Another property of os.path.split is that eventually this loop will terminate:
    while path != "": path = os.path.split(path)[0]
with your proposed change, this would not be true for paths that initially contain a "." or ".." component (since os.path.split("..") -> ('..', ''))

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749261&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 21:41:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 13:41:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19QvMb-0007TR-00@sc8-sf-web1.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 11:55
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: Fixed
Priority: 6
Submitted By: Kevin Jacobs (jacobs99)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-13 16:41

Message:
Logged In: YES 
user_id=33168

Hmm, did you check anything in?  The report says it's broken
in CVS, but works in 2.3b1.  It is still broken for me
without the patch.  Did you want me to test the patch and
then backport?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-13 15:42

Message:
Logged In: YES 
user_id=6380

Thanks! Fixed in CVS for 2.3. This should be backported to
2.2 too; assiged to Neal Norwitz for that purpose.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:24

Message:
Logged In: YES 
user_id=459565

er, see Bug 742911 instead.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:21

Message:
Logged In: YES 
user_id=459565

Oh, and with the patch, 'make test' completes without
any new errors, my attached test case works, as does
the minimal test case associated with Bug 751998.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:19

Message:
Logged In: YES 
user_id=459565

Okay, I had a few minutes free.  The problem is that
slots are being deallocated too early -- before tp_dealloc.
I'm attaching a patch that corrects this at the expense of
having to travel up the path of base class tp_dealloc
entries twice.  Here is the new sequence of actions:

1) Find the nearest base with a different tp_dealloc
2) Clear weakrefs
3) Call finalizer
4) Check to see if object was resurrected, if so stop
5) Clear all slots up to nearest base with a different 
    tp_dealloc
6) DECREF dict pointer, if necessary
7) proceed as usual... (call basedealloc, DECREF type, etc.)

Without my patch, step number 5  is done as part of step
1, and bad things happen.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:07

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve Bug 751998 is the cause of this
potentially more serious one bug.  I have yet to figure 
out why, though I have isolated the problem to revision
2.234 of typeobject.c.  I've not looked to see if this also 
affects Python 2.2.3, though I wouldn't be too suprised if it 
does.

More soon, hopefully.  Maybe...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 21:57:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 13:57:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19QvcA-0006ha-00@sc8-sf-web2.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 11:55
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: Fixed
Priority: 6
Submitted By: Kevin Jacobs (jacobs99)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-13 16:57

Message:
Logged In: YES 
user_id=6380

Sorry, the checkin barfed and I didn't notice. Try again now.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-13 16:41

Message:
Logged In: YES 
user_id=33168

Hmm, did you check anything in?  The report says it's broken
in CVS, but works in 2.3b1.  It is still broken for me
without the patch.  Did you want me to test the patch and
then backport?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-13 15:42

Message:
Logged In: YES 
user_id=6380

Thanks! Fixed in CVS for 2.3. This should be backported to
2.2 too; assiged to Neal Norwitz for that purpose.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:24

Message:
Logged In: YES 
user_id=459565

er, see Bug 742911 instead.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:21

Message:
Logged In: YES 
user_id=459565

Oh, and with the patch, 'make test' completes without
any new errors, my attached test case works, as does
the minimal test case associated with Bug 751998.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:19

Message:
Logged In: YES 
user_id=459565

Okay, I had a few minutes free.  The problem is that
slots are being deallocated too early -- before tp_dealloc.
I'm attaching a patch that corrects this at the expense of
having to travel up the path of base class tp_dealloc
entries twice.  Here is the new sequence of actions:

1) Find the nearest base with a different tp_dealloc
2) Clear weakrefs
3) Call finalizer
4) Check to see if object was resurrected, if so stop
5) Clear all slots up to nearest base with a different 
    tp_dealloc
6) DECREF dict pointer, if necessary
7) proceed as usual... (call basedealloc, DECREF type, etc.)

Without my patch, step number 5  is done as part of step
1, and bad things happen.


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

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:07

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve Bug 751998 is the cause of this
potentially more serious one bug.  I have yet to figure 
out why, though I have isolated the problem to revision
2.234 of typeobject.c.  I've not looked to see if this also 
affects Python 2.2.3, though I wouldn't be too suprised if it 
does.

More soon, hopefully.  Maybe...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 22:04:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 14:04:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-753617 ] dump_address_pair in email._parseaddr appears to be missing
Message-ID: <E19Qvj7-0000uX-00@sc8-sf-web4.sourceforge.net>

Bugs item #753617, was opened at 2003-06-12 19:12
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753617&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: dump_address_pair in email._parseaddr appears to be missing

Initial Comment:
The _parseaddr module in the email module references a 
function called dump_address_pair on line 445.  This 
function lives in Utils.py and is not imported.  Thus if you 
try to do a str() of an AddressList object, it fails with a 
NameError.


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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-06-13 17:04

Message:
Logged In: YES 
user_id=12800

Can you explain how you're getting an AddressList instance
from _parseaddr?  Both the _parseaddr module nor the
AddressList class should be considered private to the email
package. 

I'm more inclined to remove AddressList.__str__() since it
isn't used anywhere.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753617&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 22:08:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 14:08:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-753617 ] dump_address_pair in email._parseaddr appears to be missing
Message-ID: <E19QvmM-0007Go-00@sc8-sf-web3.sourceforge.net>

Bugs item #753617, was opened at 2003-06-12 16:12
Message generated for change (Comment added) made by ehuss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753617&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: dump_address_pair in email._parseaddr appears to be missing

Initial Comment:
The _parseaddr module in the email module references a 
function called dump_address_pair on line 445.  This 
function lives in Utils.py and is not imported.  Thus if you 
try to do a str() of an AddressList object, it fails with a 
NameError.


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

>Comment By: Eric Huss (ehuss)
Date: 2003-06-13 14:08

Message:
Logged In: YES 
user_id=393416

I was just checking/reviewing the code and noticed it.  
Getting rid of __str__ sounds fine to me...I wasn't using it for 
anything.



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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-06-13 14:04

Message:
Logged In: YES 
user_id=12800

Can you explain how you're getting an AddressList instance
from _parseaddr?  Both the _parseaddr module nor the
AddressList class should be considered private to the email
package. 

I'm more inclined to remove AddressList.__str__() since it
isn't used anywhere.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753617&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 22:16:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 14:16:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-753617 ] dump_address_pair in email._parseaddr appears to be missing
Message-ID: <E19Qvun-0007fi-00@sc8-sf-web3.sourceforge.net>

Bugs item #753617, was opened at 2003-06-12 19:12
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753617&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: dump_address_pair in email._parseaddr appears to be missing

Initial Comment:
The _parseaddr module in the email module references a 
function called dump_address_pair on line 445.  This 
function lives in Utils.py and is not imported.  Thus if you 
try to do a str() of an AddressList object, it fails with a 
NameError.


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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-06-13 17:16

Message:
Logged In: YES 
user_id=12800

Done in Python 2.3.

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

Comment By: Eric Huss (ehuss)
Date: 2003-06-13 17:08

Message:
Logged In: YES 
user_id=393416

I was just checking/reviewing the code and noticed it.  
Getting rid of __str__ sounds fine to me...I wasn't using it for 
anything.



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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-06-13 17:04

Message:
Logged In: YES 
user_id=12800

Can you explain how you're getting an AddressList instance
from _parseaddr?  Both the _parseaddr module nor the
AddressList class should be considered private to the email
package. 

I'm more inclined to remove AddressList.__str__() since it
isn't used anywhere.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753617&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 22:15:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 14:15:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-749261 ] os.path.split does not handle . & .. properly
Message-ID: <E19QvtS-0007cX-00@sc8-sf-web3.sourceforge.net>

Bugs item #749261, was opened at 2003-06-04 18:03
Message generated for change (Settings changed) made by csiemens
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749261&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Curtis Siemens (csiemens)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.split does not handle . & .. properly

Initial Comment:
The os.path.split() & posixpath.split() functions in my
opinion do not handle '.' & '..' at the end of a path
properly which causes os.path.dirname() &
os.path.basename() to also return the wrong result
because they are directly based on os.path.split().

I'll demonstrate the Unix Python case (the Windows
ntpath.py case is just a close parallel variation).

Example:
>python
Python 2.1.1
>>> posixpath.split('.')
('', '.')
>>> posixpath.split('..')
('', '..')

Yet:
>>> posixpath.split('./')
('..', '')
>>> posixpath.split('../')
('..', '')

Now '.' really represents './', and '..' really
represents '../'
Since the split() function simply uses a string split
on '/' to
find directories, it goofs up on this one case.  The
'.' and
'..' are like the slash character in the sense that
they all
only refer to directories.
The '.' & '..' can never be files in Unix or Windows, so I
think that the split() function should treat paths like:
    .
    ..
    dir/.
    dir/..
    /dir1/dir2/.
    /dir1/dir2/..
as not having a file portion, just as if:
    ./
    ../
    dir/./
    dir/../
    /dir1/dir2/./
    /dir1/dir2/../
respectively were given instead.

The fix in posixpath.py for this is just to put a
little path
processing code at the beginning of the split() function
that looks for the follow cases:
    if p in ['.','..'] or p[-2:] == '/.' or p[-3:] ==
'/..':
        p = p+'/'
And then go into all the regular split() code.
In fix in ntpath.py is very similar.

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-13 12:44

Message:
Logged In: YES 
user_id=2772

Interestingly, it appears that back in Python version 1.2,
os.path.split may have behaved in the way you described.
From
http://www.via.ecp.fr/python-doc/python-lib/posixpath.html :
split (p) -- function of module posixpath
    Split the pathname p in a pair (head, tail), where tail
is the last pathname component and head is everything
leading up to that. If p ends in a slash (except if it is
the root), the trailing slash is removed and the operation
applied to the result; otherwise, join(head, tail) equals p.
The tail part never contains a slash. Some boundary cases:
if p is the root, head equals p and tail is empty; if p is
empty, both head and tail are empty; if p contains no slash,
head is empty and tail equals p.

By version 1.4, the behavior had
changed:http://www.python.org/doc/1.4/lib/node75.html
split(p)
    Split the pathname p in a pair (head, tail), where tail
is the last pathname component and head is everything
leading up to that. The tail part will never contain a
slash; if p ends in a slash, tail will be empty. If there is
no slash in p, head will be empty. If p is empty, both head
and tail are empty. Trailing slashes are stripped from head
unless it is the root (one or more slashes only). In nearly
all cases, join(head, tail) equals p (the only exception
being when there were multiple slashes separating head from
tail).

This change in the Python CVS was made by Guido himself,
between the 1.2 and 1.3 releases:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/posixpath.py.diff?r1=1.15&r2=1.16

Since the behavior you are now proposing was one that Guido
explicitly got rid of, it seems like an uphill battle to ask
for it back, especially since the current behavior has been
clearly documented for the 1.3, 1.4, 1.5, 1.6, 2.0, 2.1, and
2.2 releases (the last 7 major releases, spanning  something
like 8 years---or about the time of the introduction of
keyword arguments, according to 1.3's Misc/NEWS)

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

Comment By: Curtis Siemens (csiemens)
Date: 2003-06-13 11:43

Message:
Logged In: YES 
user_id=794244

Ok, I like the statment,
  "split shortens the path whenever it contains more than one
   component"
I can go with that definition of os.path.split()
because that's consistent for all paths, absolute or relative,
and given that definition I'll agree that split is about
components.

Ok, onto dirname/basename which are really the source of my
concern.  I looked at the python documentation for basename()
and I think that it points out a problem that has been
tolerated.
It states:
    Note that the result of this function is different from the
    Unix basename program; where basename for '/foo/bar/'
    returns 'bar', the basename() function returns an empty
    string ('').
You state that the final component of a path should be
returned for basename() irregardless if it is a file or
directory.
I can get behind that, but then I think that statement supports
the Unix basename function implementation where /foo/bar/
has 'bar' (or 'bar/') returned for basename because /foo/bar
and /foo/bar/ are the same path, and to me 'bar' or 'bar/' is
the same single component since the trailing slash (and only
the trailing slash(es) case) is redundant.  Am I way off on
this?

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-13 05:03

Message:
Logged In: YES 
user_id=2772

OK-- so my statement of the "important property" of split
was only correct in the case of a non-absolute path.

The important point is that split shortens the path whenever
it contains more than one component.  You propose that of
the values given by repeated splits of "/foo/.."  or
"foo/..", you'll never see the one-component return "foo" or
"/foo".  Why do you believe that in the loop
    while 1:
        p = os.path.split(p)[0]
that p should never have one those values?  To me this seems
obviously incorrect.

You didn't respond to my point that os.path.split is about
components, not about whether those components name
directories.  For instance, because "/usr/local/bin" names a
directory on my system, shouldn't
os.path.split("/usr/local/bin") -> ('/usr/local/bin', '') if
your test really is about whether the final component names
a directory?  To me this seems obviously incorrect.

Let me also address your claim that because of this split
behavior, basename and dirname behave improperly.  This is
also wrong.  In "/tmp/.." and "/usr/local/bin", the first
names an entry ".." in the directory "/tmp", and the second
names an entry "bin" in the directory "/usr/local", just
like "/bin/sh" names an entry "sh" in the directory "/bin".

I strongly believe this bug should be marked closed,
resolution: invalid.

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

Comment By: Curtis Siemens (csiemens)
Date: 2003-06-12 15:59

Message:
Logged In: YES 
user_id=794244

Ok, I see your points, but I have 2 points.

Point 1:
Your loop 'while path != "": path = os.path.split(path)[0]'
won't stop with an absolute path because it will get down
to '/' and go into infinite spin.
OK, so you can modify it to be:
  while path != "" and path != '/':path =os.path.split(path)[0]
But this too will spin if start with an absolute path that has
more than 2 slashes - like '//dir1/dir2' or '///dir1/dir2'
at the
front of the path.
OK, you can fix that up to by doing something like:
   old_path = ''
   while path != old_path:
       old_path = path
       path = os.path.split(path)[0]
But that final loop will work with my new os.path.split
proposal - which makes me wonder if your assertion that
split should have the 'terminate loop' property.

Point 2:
You may be right about os.path.split's slated task/job.
So maybe the change shouldn't be done to os.path.split(),
but rather os.path.dirname() & os.path.basename() should
be changed to not just simply return the 1st and 2nd
components of split(), but rather try to be as "smart" as
possible and dirname's intention is to return the directory
portion, and basename's intention is to return the (end)
filename portion - if possible.  With paths like /abc/xyz
you have no idea if xyz is a file or dir, so the default should
be 'file'.  Currently /abc/xyz/ knows that xyz is a dir and
returns /abc/xyz for the dirname and '' for the basename.
My point is that currently basename/dirname are "smart"
and not just returning the last component that is a file or
is a directory, otherwise it would return /abc for the dirname
and xyz/ for the basename.
So given the current behavior of dirname/basename, they
should be smart in ALL "we can tell its a directory" cases
such as:
  .
  ..
  dir/.
  dir/..
  /dir1/dir2/.
  /dir1/dir2/..

So do I have a good Point #1, and more importantly do I have
a good Point #2 - and if I do I could change this bug's title
to be os.path.dirname/basename related.

Curtis Siemens

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

Comment By: Jeff Epler (jepler)
Date: 2003-06-08 08:34

Message:
Logged In: YES 
user_id=2772

I don't believe this behavior is a bug.  os.path.split's task is to split the last component of a path from the other components, regardless of whether any of the components actually names a directory.

Another property of os.path.split is that eventually this loop will terminate:
    while path != "": path = os.path.split(path)[0]
with your proposed change, this would not be true for paths that initially contain a "." or ".." component (since os.path.split("..") -> ('..', ''))

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749261&group_id=5470


From noreply@sourceforge.net  Fri Jun 13 22:42:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 14:42:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-753711 ] Infinite Loop in RE
Message-ID: <E19QwJt-0000HZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #753711, was opened at 2003-06-12 22:27
Message generated for change (Comment added) made by sjones
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470

Category: Regular Expressions
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Bogosian (mbogosian)
Assigned to: Fredrik Lundh (effbot)
Summary: Infinite Loop in RE

Initial Comment:
This *may* be similar to
<http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=439997>,
but I don't think the current behavior (infinite
loop/unbound execution) is correct.

Here's the python version:

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

#!/usr/bin/python

import re

pattern =
'^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,'

# This won't match (missing ',' at end
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

re.search(pattern, str, re.I)

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

When run, this script just pegs the CPU and hangs (I'm
running RedHat 8.0). Note: if I change the pattern
slightly it still doesn't work:

pattern = '^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*([^
=,]+\s*)+,'

It's not until the pattern actually matches that things
get better (with both the original and modified patterns):

# Pattern now matches (added a ',' at the end)
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP),'

I tried doing the same thing in Perl:

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

#!/usr/bin/perl

'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)' =~
'/UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,/i';

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

This of course runs just fine. Any ideas?

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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 16:42

Message:
Logged In: YES 
user_id=589306

If you change your regex and sample data to the following
simpler forms, you get the same problem:

pattern = '(\S+\s*)+,'
str = 'CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

If you remove some letters from str, the search does finish
but it takes several seconds. I believe the problem is that
your regex takes exponential time to execute based on the
length of str. Here is a recent python-dev post that talks
about the problem:

http://mail.python.org/pipermail/python-dev/2003-May/035916.html

The link you provided in the bug report talks about this as
well. You can also do a web search for "regular expression
exponential" to see more information. I believe that any
regex engine (that has similar features to Python's engine)
will have some regular expressions that take exponential
time or space. Perl has some cases as well (search for
"exponential" in perldoc perlre).  This is just how regular
expressions are and IMHO does not indicate a bug in Python.

As far as how to fix the regular expression, I can't say.
I'm sure there is a way to "rephrase" what you want to get
it to work. Maybe try asking in the comp.lang.python newsgroup.

Good luck!


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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 07:15

Message:
Logged In: YES 
user_id=589306

If you change your regex and sample data to the following
simpler forms, you get the same problem:

pattern = '(\S+\s*)+,'
str = 'CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

If you remove some letters from str, the search does finish
but it takes several seconds. I believe the problem is that
your regex takes exponential time to execute based on the
length of str. Here is a recent python-dev post that talks
about the problem:

http://mail.python.org/pipermail/python-dev/2003-May/035916.html

The link you provided in the bug report talks about this as
well. You can also do a web search for "regular expression
exponential" to see more information. I believe that any
regex engine (that has similar features to Python's engine)
will have some regular expressions that take exponential
time or space. Perl has some cases as well (search for
"exponential" in perldoc perlre).  This is just how regular
expressions are and IMHO does not indicate a bug in Python.

As far as how to fix the regular expression, I can't say.
I'm sure there is a way to "rephrase" what you want to get
it to work. Maybe try asking in the comp.lang.python newsgroup.

Good luck!


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 01:20:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 17:20:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-752221 ] print in __getattr__ causes seg fault
Message-ID: <E19Qymb-0005HV-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher K. Paulicka (paulicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: print in __getattr__ causes seg fault

Initial Comment:
[~/site-packages/WorldPlay/] paulicka@Sliver-14:56:32
$ python
Python 2.3a2+ (#4, Mar  2 2003, 17:13:46) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class A:
...     def __getattr__(self,name):
...             return 3
... 
>>> a=A()
>>> a.c
3
>>> class B:
...     def __getattr__(self,name):
...             print self, name
...             return 3
... 
>>> b=B()
>>> b.c
Segmentation fault
[~/site-packages/WorldPlay/] paulicka@Sliver-14:57:14
$ 

$ uname -a
Darwin Sliver.local. 6.6 Darwin Kernel Version 6.6: Thu 
May  1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/
RELEASE_PPC  Power Macintosh powerpc


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

>Comment By: Christopher K. Paulicka (paulicka)
Date: 2003-06-14 00:20

Message:
Logged In: YES 
user_id=45461

Actually, I can't use the beta, because I used the MacOS Kitchen 
Sink combination of Framework Python, Pygame and PyOpenGL.

I tried building from the CVS repository, but had problems, so 
just moved on...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-11 03:09

Message:
Logged In: YES 
user_id=80475

Can you try this one on the beta release to see if it is still a 
problem.  I cannot reproduce the segfault on a Windows 
build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 02:57:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 18:57:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-752221 ] print in __getattr__ causes seg fault
Message-ID: <E19R0II-0000UM-00@sc8-sf-web1.sourceforge.net>

Bugs item #752221, was opened at 2003-06-10 16:58
Message generated for change (Comment added) made by sjones
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher K. Paulicka (paulicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: print in __getattr__ causes seg fault

Initial Comment:
[~/site-packages/WorldPlay/] paulicka@Sliver-14:56:32
$ python
Python 2.3a2+ (#4, Mar  2 2003, 17:13:46) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class A:
...     def __getattr__(self,name):
...             return 3
... 
>>> a=A()
>>> a.c
3
>>> class B:
...     def __getattr__(self,name):
...             print self, name
...             return 3
... 
>>> b=B()
>>> b.c
Segmentation fault
[~/site-packages/WorldPlay/] paulicka@Sliver-14:57:14
$ 

$ uname -a
Darwin Sliver.local. 6.6 Darwin Kernel Version 6.6: Thu 
May  1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/
RELEASE_PPC  Power Macintosh powerpc


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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 20:57

Message:
Logged In: YES 
user_id=589306

I tried running with current CVS and got the following
results on Linux:

Python 2.3b1+ (#3, Jun 13 2003, 07:56:14)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> class A:
...     def __getattr__(self, name):
...             return 3
...
>>> a = A()
>>> a.c
3
>>> class B:
...     def __getattr__(self, name):
...             print self, name
...             return 3
...
>>> b = B()
>>> b.c
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
[Repeats lots of times]
  File "<stdin>", line 3, in __getattr__
RuntimeError: maximum recursion depth exceeded
>>> class C:
...     def __init__(self):
...             self.x = 5
...     def __getattr__(self, name):
...             print self.x
...             return 3
...
>>> c = C()
>>> c.c
5
3

$ uname -a
Linux localhost 2.4.20-18.9 #1 Thu May 29 06:54:41 EDT 2003
i686 athlon i386 GNU/Linux

-------------------------------------------------
Note that I can print things from getattr, it is just
printing self that gets me in trouble.


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

Comment By: Christopher K. Paulicka (paulicka)
Date: 2003-06-13 19:20

Message:
Logged In: YES 
user_id=45461

Actually, I can't use the beta, because I used the MacOS Kitchen 
Sink combination of Framework Python, Pygame and PyOpenGL.

I tried building from the CVS repository, but had problems, so 
just moved on...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 22:09

Message:
Logged In: YES 
user_id=80475

Can you try this one on the beta release to see if it is still a 
problem.  I cannot reproduce the segfault on a Windows 
build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 03:26:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 19:26:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-754016 ] urlparse goes wrong with IP:port without scheme
Message-ID: <E19R0kh-0001E0-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Krüger (kruegi)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse goes wrong with IP:port without scheme

Initial Comment:
urlparse doesnt work if IP and port are given without 
scheme:

>>> urlparse.urlparse('1.2.3.4:80','http')
('1.2.3.4', '', '80', '', '', '')

should be:

>>> urlparse.urlparse('1.2.3.4:80','http')
('http', '1.2.3.4', '80', '', '', '')

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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 21:26

Message:
Logged In: YES 
user_id=589306

urlparse.urlparse takes a url of the format:
    <scheme>://<netloc>/<path>;<params>?<query>#<fragment>

And returns a 6-tuple of the format:
    (scheme, netloc, path, params, query, fragment).

An example from the library refrence takes:


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 03:39:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 19:39:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-754016 ] urlparse goes wrong with IP:port without scheme
Message-ID: <E19R0wb-0000Nu-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Krüger (kruegi)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse goes wrong with IP:port without scheme

Initial Comment:
urlparse doesnt work if IP and port are given without 
scheme:

>>> urlparse.urlparse('1.2.3.4:80','http')
('1.2.3.4', '', '80', '', '', '')

should be:

>>> urlparse.urlparse('1.2.3.4:80','http')
('http', '1.2.3.4', '80', '', '', '')

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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 21:39

Message:
Logged In: YES 
user_id=589306

Sorry, previous comment got cut off...

urlparse.urlparse takes a url of the format:
    <scheme>://<netloc>/<path>;<params>?<query>#<fragment>

And returns a 6-tuple of the format:
    (scheme, netloc, path, params, query, fragment).

An example from the library refrence takes:
    urlparse('http://www.cwi.nl:80/%7Eguido/Python.html')

And produces:
    ('http', 'www.cwi.nl:80', '/%7Eguido/Python.html', '',
'', '')

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

Note that there isn't a field for the port number in the
6-tuple. Instead, it is included in the netloc. Urlparse
should handle your example as:

>>> urlparse.urlparse('1.2.3.4:80','http') 
('http', '1.2.3.4:80', '', '', '', '')

Instead, it gives the incorrect output as you indicated.


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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 21:26

Message:
Logged In: YES 
user_id=589306

urlparse.urlparse takes a url of the format:
    <scheme>://<netloc>/<path>;<params>?<query>#<fragment>

And returns a 6-tuple of the format:
    (scheme, netloc, path, params, query, fragment).

An example from the library refrence takes:


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 05:18:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 21:18:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-754016 ] urlparse goes wrong with IP:port without scheme
Message-ID: <E19R2UV-0003FP-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Krüger (kruegi)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse goes wrong with IP:port without scheme

Initial Comment:
urlparse doesnt work if IP and port are given without 
scheme:

>>> urlparse.urlparse('1.2.3.4:80','http')
('1.2.3.4', '', '80', '', '', '')

should be:

>>> urlparse.urlparse('1.2.3.4:80','http')
('http', '1.2.3.4', '80', '', '', '')

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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 23:18

Message:
Logged In: YES 
user_id=589306

Ok, I researched this a bit, and the situation isn't as
simple as it first appears. The RFC that urlparse tries to
follow is at http://www.faqs.org/rfcs/rfc1808.html and
notice specifically sections 2.1 and 2.2.

It seems to me that the source code follows rfc1808
religiously, and in that sense it does the correct thing.
According to the RFC, the netloc should begin with a '//',
and since your example didn't include one then it technical
was an invalid URL. Here is another example where it seems
Python fails to do the right thing:

>>> urlparse.urlparse('python.org')
('', '', 'python.org', '', '', '')
>>> urlparse.urlparse('python.org', 'http')
('http', '', 'python.org', '', '', '')

Note that it is putting 'python.org' as the path and not the
netloc. So the problem isn't limited to just when you use a
scheme parameter and/or a port number. Now if we put '//' at
the beginning, we get:

>>> urlparse.urlparse('//python.org')
('', 'python.org', '', '', '', '')
>>> urlparse.urlparse('//python.org', 'http')
('http', 'python.org', '', '', '', '')

So here it does the correct thing.

There are two problems though. First, it is common for
browsers and other software to just take a URL without a
scheme and '://' and assume it is http for the user. While
the URL is technically not correct, it is still common
usage. Also, urlparse does take a scheme parameter. It seems
as though this parameter should be used with a scheme-less
URL to give it a default one like web browsers do.

So somebody needs to make a decision. Should urlparse follow
the RFC religiously and require '//' in front of netlocs? If
so, I think the documentation should give an example showing
this and showing how to use the 'scheme' parameter. Or
should urlparse use the more commonly used form of a URL
where '//' is omitted when the scheme is omitted? If so,
urlparse.py will need to be changed. Or maybe another
fuction should be added to cover whichever behaviour
urlparse doesn't cover.

In any case, you can temporarily solve your problem by
making sure that URL's without a scheme have '//' at the
front. So your example becomes:

>>> urlparse.urlparse('//1.2.3.4:80', 'http')
('http', '1.2.3.4:80', '', '', '', '')



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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 21:39

Message:
Logged In: YES 
user_id=589306

Sorry, previous comment got cut off...

urlparse.urlparse takes a url of the format:
    <scheme>://<netloc>/<path>;<params>?<query>#<fragment>

And returns a 6-tuple of the format:
    (scheme, netloc, path, params, query, fragment).

An example from the library refrence takes:
    urlparse('http://www.cwi.nl:80/%7Eguido/Python.html')

And produces:
    ('http', 'www.cwi.nl:80', '/%7Eguido/Python.html', '',
'', '')

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

Note that there isn't a field for the port number in the
6-tuple. Instead, it is included in the netloc. Urlparse
should handle your example as:

>>> urlparse.urlparse('1.2.3.4:80','http') 
('http', '1.2.3.4:80', '', '', '', '')

Instead, it gives the incorrect output as you indicated.


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

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 21:26

Message:
Logged In: YES 
user_id=589306

urlparse.urlparse takes a url of the format:
    <scheme>://<netloc>/<path>;<params>?<query>#<fragment>

And returns a 6-tuple of the format:
    (scheme, netloc, path, params, query, fragment).

An example from the library refrence takes:


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 07:13:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 23:13:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-751321 ] Classes inheritig from object are not class type.
Message-ID: <E19R4IS-0005Wh-00@sc8-sf-web3.sourceforge.net>

Bugs item #751321, was opened at 2003-06-09 15:33
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751321&group_id=5470

Category: Extension Modules
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Roger Wenham (e078120)
Assigned to: Nobody/Anonymous (nobody)
Summary: Classes inheritig from object are not class type. 

Initial Comment:
Isinstance(<classinstance>, types.ClassType) will
return false if the class inherits from object.

Here is a demo:

import types
 
class a:
        def test(self):
                pass
 
class b(object):
        def test(self):
                pass
  
if __name__ == '__main__':
        if isinstance(a, types.ClassType):
                print "a is a class"
        else:
                print "a is not a class"
 
        if isinstance(b, types.ClassType):
                print "b is a class"
        else:
                print "b is not a class"

The output look like this:


roger@linux_lap:~ > python demo.py
a is a class
b is not a class



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:13

Message:
Logged In: YES 
user_id=21627

You *are* missing something. It is not logical that 'foo'
has a type of string, whereas UserString.UserString('foo')
has a type of instance - why doesn't it have UserString as
its type?

In general: It is illogical that for some objects, you use
the type to find out what kind of object it is, and for
other objects, you use __class__, as type() only tells you
"yes, it is an instance" (of course it is an instance;
"instance" and "object" ought to be synonyms). This is known
as the "class/type dichotomy", see

http://www.amk.ca/python/writing/warts.html

The newstyle classes intend to fix this problem, unifying
classes and types. As a result, any object should have a
type() which is identical to its __class__. Unfortunately,
for backwards compatibility, old-style classes need to be
preserved for a foreseeable future, however, it is them who
get it wrong, not the newstyle classes.

If you are pickling objects of any type, you will have to
find a mechanism for unpickling them. Fortunately, the
pickle module provides plenty of hooks to perform proper
unpickling, and automatic pickling/unpickling in most cases.

Closing as not-a-bug.

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

Comment By: Roger Wenham (e078120)
Date: 2003-06-11 07:29

Message:
Logged In: YES 
user_id=240941

Maybe I'm missing something, but to me a class is a class
and should allways be a ClassType. For instance if I have
pickled
some objects, when unpickling, how else can I identify that
it was a class that I pickled, and that I can take an
instance of it?

With the old style classes, a class was class type and if i
take an instance, it's type is instance, logical.

With new style classes, an class is type 'type', and an
instance of it is type class.

Is it not logical that a class is a class and an istance is
an instance?  

 





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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-10 20:07

Message:
Logged In: YES 
user_id=89016

The reason for this is that new style classes have a
different meta class than classic classes. This is
documented in http://www.python.org/2.2.3/descrintro.html:
"""The built-in 'type' is the most common metaclass; it is
the metaclass of all built-in types. Classic classes use a
different metaclass: the type known as types.ClassType."""

Why do you think this is a bug?


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751321&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 07:36:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 23:36:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19R4ef-00081L-00@sc8-sf-web4.sourceforge.net>

Bugs item #749911, was opened at 2003-06-06 03:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Reed (dr2048)
Assigned to: Nobody/Anonymous (nobody)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:36

Message:
Logged In: YES 
user_id=21627

Please try the attached patch and report whether this solves
the problem.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 07:37:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 23:37:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19R4f7-000828-00@sc8-sf-web4.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Reed (dr2048)
>Assigned to: Martin v. Löwis (loewis)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:36

Message:
Logged In: YES 
user_id=21627

Please try the attached patch and report whether this solves
the problem.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 07:40:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 23:40:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-748928 ] last threads fixes broke linker
Message-ID: <E19R4i7-00069a-00@sc8-sf-web3.sourceforge.net>

Bugs item #748928, was opened at 2003-06-04 17:25
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: last threads fixes broke linker

Initial Comment:
In current cvs, -pthread and -ieee is properly set for
OSF1/Tru64Unix. Unfortunately, -ieee is somewhat passed
to linker:

building '_curses' extension
cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/mnt/python/dist/src/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/python/dist/src/Include -I/mnt/python/dist/src
-c /mnt/python/dist/src/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved * -ieee -std -Olimit 1500
-DNDEBUG -O -I. -I./Include
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
ld:
-ieee: Unknown flag
ld: Usage: ld [options] file [...]
building '_curses_panel' extension


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:40

Message:
Logged In: YES 
user_id=21627

Is it not the case that cc(1) supports -ieee? If so, why
does it then pass the option to ld?

Perhaps it depends on the cc version whether -ieee is
supported? Perhaps the compiler should be invoked with a
different name?

Please don't make us guess as to how your operating system
works. If you can contribute to a solution, that would be
much appreciated.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 07:50:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 23:50:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs a last distribution
Message-ID: <E19R4sB-0006wf-00@sc8-sf-web2.sourceforge.net>

Bugs item #748926, was opened at 2003-06-04 17:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken ncurses support in current cvs a last distribution

Initial Comment:
I found configure looks for ncurses.h instead of
ncurses/ncurses.h. Please note that newer version of
ncurses have moved ncurses.h to a subdirectory ncurses/.

Even after fixing configure and
Modules/_curses_panel.c, I get:

cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 506: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addch (const chtype);      
                 /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 507: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchnstr (const chtype *,
int);             /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 508: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchstr (const chtype *); 
                 /* generated */
---------------------------^

Any ideas?

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:50

Message:
Logged In: YES 
user_id=21627

Can you report how NCURSES_EXPORT is defined on your system?


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 07:55:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 23:55:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-746895 ] socket.sendto(SOCK_DGRAM) very slow on OSX!
Message-ID: <E19R4wu-00074f-00@sc8-sf-web2.sourceforge.net>

Bugs item #746895, was opened at 2003-06-01 08:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Kangas (mkangas)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.sendto(SOCK_DGRAM) very slow on OSX!

Initial Comment:
I'm trying to send UDP packets using socket.sendto().
With Python 2.2 on Linux, this works like a champ. On
Mac OS X, something's terribly wrong.

Time to send 100 UDP packets using test code + Python
2.2.1:
- Linux 2.4.18 (RedHat 8): 0.009 sec
- MacOS X 10.2.6: > 1 sec, sometimes > 2 sec.

I've tried the following Python builds on OS X, all
with the same results:
- Stock 2.2 build that comes with OS X 10.2
- 2.2.1 provided by Fink
- built-from-scratch 2.2.3: "./configure; make"

provided are sample programs in Python and C.
ktrace/kdump seem to indicate that both programs make
the same sequence of syscalls. the C program runs
blazingly fast on OS X, while the Python one seems to
stall on every call to socket.sendto().

why does socket.sendto() perform so poorly on OS X?

----------------- python sample ----------------
 
#
# UDP socket test: how fast can we write?
# (5/2003 kangas)
#
# time to run with python 2.2.1:
# - Linux 2.4.18:     0.009 sec
# - Mac OS x 10.2.6:  1.272 sec (!!!)

import socket, time, sys

PORT = 9999
DEST_ADDR = ("192.168.1.60", PORT)

def run():
    maxcount = 100
    data = "pingme pingme pingme pingme pingme..."
    dest = DEST_ADDR

    print "opening socket"
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    
    print "Sending %i packets" % maxcount
    t0 = time.time()
    for i in xrange(0, maxcount):
        s.sendto(data, dest)
    t1 = time.time() - t0
    print "%0.4f secs elapsed" % t1

    s.close()

if __name__=="__main__":
    run()
    

----------------- C sample ----------------

/*
 * UDP socket test: how fast can we write?
 * (5/2003 kangas)
 *
 * Tested on Mac OS X 10.2.6 and Linux 2.4
 */

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>

static const int MAXCOUNT = 100;
static const char DATA[] = "pingme pingme pingme pingme
pingme...";
    
int main(void) {
    int s, i, err;
    struct sockaddr_in serverAddr;

    bzero(&serverAddr, sizeof(serverAddr));
    serverAddr.sin_family = AF_INET;
    serverAddr.sin_port = htons(9999);
    
    inet_pton(AF_INET, "192.168.1.60",
&serverAddr.sin_addr);
    
    printf("opening socket\n");
    if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
	perror("socket");
	exit(1);
    }

    printf("sending %i packets\n", MAXCOUNT);
    for (i=0; i<MAXCOUNT; i++) {
	err = sendto(s, DATA, strlen(DATA), 0,
		     (struct sockaddr *)&serverAddr, sizeof(serverAddr));
	if (err < 0) {
	    perror("sendto");
	    break;
	}
	printf(".");
     };
    printf("\n");

    printf("closing...\n");
    close(s);
    printf("done!\n");
    return 0;
}


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:55

Message:
Logged In: YES 
user_id=21627

Can you try to link your C program with the same libraries
that python is linked with, and compile it with the same
command line options that socketmodule is compiled with?

My first guess is that enabling pthreads may have an effect.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 07:59:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 13 Jun 2003 23:59:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-746366 ] 2.2.3c1 install-sh out of date
Message-ID: <E19R50i-0006dW-00@sc8-sf-web3.sourceforge.net>

Bugs item #746366, was opened at 2003-05-31 00:01
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746366&group_id=5470

Category: Build
Group: Python 2.2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Paul Eggert (eggert)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.2.3c1 install-sh out of date

Initial Comment:
The install-sh shipped with Python 2.2.3c1 is out of
date with respect
to the canonical install-sh shipped with Automake.  The
Automake version has fixed a few portability bugs
having to do with spaces in directory names, the
unportable use of "[ ... -o ... ]", and the like.

The simplest fix is to copy automake/lib/install-sh
into Python.  I'll also try to attach a patch below.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:59

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as install-sh 2.5 and 2.4.24.1.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-31 00:07

Message:
Logged In: YES 
user_id=12800

Sorry, its too late to fix this for Python 2.2.3.  Setting
resolution to Later for consideration in 2.2.4.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746366&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 08:21:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 00:21:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-746304 ] TypeError raised when deepcopying built-in functions
Message-ID: <E19R5Lc-0007mJ-00@sc8-sf-web2.sourceforge.net>

Bugs item #746304, was opened at 2003-05-30 21:59
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746304&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Oktay Safak (oktaysafak)
Assigned to: Nobody/Anonymous (nobody)
Summary: TypeError raised when deepcopying built-in functions

Initial Comment:
>>> import copy
>>> copy.deepcopy(max)

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in ?
    copy.deepcopy(max)
  File "C:\PYTHON23\lib\copy.py", line 205, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "C:\PYTHON23\lib\copy.py", line 336, in _reconstruct
    y = callable(*args)
  File "C:\PYTHON23\Lib\copy_reg.py", line 84, in __newobj__
    return cls.__new__(cls, *args)
TypeError: object.__new__(builtin_function_or_method) is not 
safe, use builtin_function_or_method.__new__()

Steven Taschuk's guess is that all things pickleable should be 
copyable since copy uses the same protocol as pickle. (He is 
not sure though) He demonstrates this idea with the following 
example:

>>> import pickle
>>> pickle.loads(pickle.dumps(max))
<built-in function max>

which succeeds unlike the first example.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 09:21

Message:
Logged In: YES 
user_id=21627

Thanks for the bugreport. This is now fixed in 

copy.py 1.42
test_copy.py 1.11
NEWS 1.782
copy.py 1.22.10.6
NEWS 1.337.2.4.2.88


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746304&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 08:49:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 00:49:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-746012 ] PACKAGE_*  in pyconfig.h
Message-ID: <E19R5mZ-0000tL-00@sc8-sf-web1.sourceforge.net>

Bugs item #746012, was opened at 2003-05-30 13:02
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746012&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: PACKAGE_*  in pyconfig.h

Initial Comment:
Is it intentional that in 2.3 pyconfig.h includes
PACKAGE_* definitions? It causes lot of warnings when
building modules (and maybe some other problems).

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 09:49

Message:
Logged In: YES 
user_id=21627

This is fixed in

configure.in 1.415
configure 1.404

by explicitly removing the PACKAGE_* definitions.
Unfortunately, autoconf has no API for this, so we need a
hack here.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-31 16:17

Message:
Logged In: YES 
user_id=33168

These seem to have been added when upgrading to autoconf 2.53.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746012&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 08:56:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 00:56:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-745145 ] xml.sax Contenthandler passes truncated data
Message-ID: <E19R5tz-00017C-00@sc8-sf-web1.sourceforge.net>

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

Category: XML
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Guido Treutwein (gtreutwein)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax Contenthandler passes truncated data

Initial Comment:
Error-Message in Python xml.sax module

writeXml_1 generates a xml file ('testOut.xml' )containing 
random strings and checksums
'readXml_2 testOut.xml' reads the file and verifies the 
checksums

Observation: readXml_2 reports checksum errors. The 
error occurs on all tried combinations of (Win2000, Win98 
and OpenBSD 3.2) with (Python 2.2.2 and 2.3a1).
The corrupted strings reported are located shortly before 
64kByte boundaries in the file.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 09:56

Message:
Logged In: YES 
user_id=21627

This is a bug in your code. There is no guarantee that, for
a chunk of PCDATA text, there will only be one .characters
callback; the parser may split this up into multiple calls. 

With the attached modified readXml_2.py, the data validate
just fine.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745145&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 08:58:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 00:58:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-745002 ] <> in attrs in sgmllib not handled
Message-ID: <E19R5vq-00019z-00@sc8-sf-web1.sourceforge.net>

Bugs item #745002, was opened at 2003-05-28 18:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745002&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Samuel Bayer (sambayer)
Assigned to: Nobody/Anonymous (nobody)
Summary: <> in attrs in sgmllib not handled

Initial Comment:
Hi folks -

This bug is noted in the source code for sgmllib.py,
and it finally bit me. If you feed the SGMLParser class
text such as

<tag attr = "<attrtag> bar </attrtag>">foo</tag>

the <attrtag> will be processed as a tag, as well as
being recognized as part of the attribute. This is
because of the way the end index for the opening tag is
computed.

As far as I can tell from the HTML 4.01 specification,
this is legal. The case I encountered was in a value of
an "onmouseover" attribute, which was a Javascript call
which contained HTML text as one of its arguments.

The problem is in SGMLParser.parse_starttag, which
attempts to compute the end of the opening tag with a
simple regexp [<>], and uses this index even when the
attributes have passed it. There's no real need to
check this regexp in advance, as far as I can tell.
I've attached my proposed modification of
SGMLParser.parse_starttag; I've tested this change in
2.2.1, but there are no relevant differences between
2.2.1 and the head of the CVS tree for this method. No
guarantees of correctness, but it works on the examples
I've tested it on.

Cheers -
Sam Bayer

================================

w_endbracket = re.compile("\s*[<>]")

class SGMLParser:
    # Internal -- handle starttag, return length or -1
if not terminated
    def parse_starttag(self, i):
        self.__starttag_text = None
        start_pos = i
        rawdata = self.rawdata
        if shorttagopen.match(rawdata, i):
            # SGML shorthand: <tag/data/ == <tag>data</tag>
            # XXX Can data contain &... (entity or char
refs)?
            # XXX Can data contain < or > (tag characters)?
            # XXX Can there be whitespace before the
first /?
            match = shorttag.match(rawdata, i)
            if not match:
                return -1
            tag, data = match.group(1, 2)
            self.__starttag_text = '<%s/' % tag
            tag = tag.lower()
            k = match.end(0)
            self.finish_shorttag(tag, data)
            self.__starttag_text =
rawdata[start_pos:match.end(1) + 1]
            return k
        
        # Now parse the data between i+1 and the end of
the tag into a tag and attrs
        attrs = []
        if rawdata[i:i+2] == '<>':
            # SGML shorthand: <> == <last open tag seen>
            k = i + 1
            tag = self.lasttag
        else:
            match = tagfind.match(rawdata, i+1)
            if not match:
                self.error('unexpected call to
parse_starttag')
            k = match.end(0)
            tag = rawdata[i+1:k].lower()
            self.lasttag = tag
        while w_endbracket.match(rawdata, k) is None:
            match = attrfind.match(rawdata, k)
            if not match: break
            attrname, rest, attrvalue = match.group(1,
2, 3)
            if not rest:
                attrvalue = attrname
            elif attrvalue[:1] == '\'' ==
attrvalue[-1:] or \
                 attrvalue[:1] == '"' == attrvalue[-1:]:
                attrvalue = attrvalue[1:-1]
            attrs.append((attrname.lower(), attrvalue))
            k = match.end(0)
        match = endbracket.search(rawdata, k)
        if not match:
            return -1
        j = match.start(0)   
        if rawdata[j] == '>':
            j = j+1
        self.__starttag_text = rawdata[start_pos:j]
        self.finish_starttag(tag, attrs)
        return j


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 09:58

Message:
Logged In: YES 
user_id=21627

If this is a known bug, why are you reporting it?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745002&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 09:18:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 01:18:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-744687 ] anydbm and whichdb again
Message-ID: <E19R6FE-0001hS-00@sc8-sf-web1.sourceforge.net>

Bugs item #744687, was opened at 2003-05-28 05:07
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744687&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory Saunders (grerfy)
Assigned to: Nobody/Anonymous (nobody)
Summary: anydbm and whichdb again

Initial Comment:
There is an annoying inconsistency with the various dbm
modules that occurs when a database is created, left
empty, and then re-opened for writing later with
anydbm. Code to produce the bug appears below:

Python 2.2.2 (#1, Mar 21 2003, 23:01:54) 
[GCC 3.2.3 20030316 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import dbhash, gdbm, dumbdbm, anydbm
>>> a = dbhash.open('/tmp/a', 'c')
>>> a.close()
>>> a1 = anydbm.open('/tmp/a', 'w')
>>> a1.close()
>>> b = gdbm.open('/tmp/b', 'c')
>>> b.close()
>>> b1 = anydbm.open('/tmp/b', 'w')
>>> b1.close()
>>> c = dumbdbm.open('/tmp/c', 'c')
>>> c.close()
>>> c1 = anydbm.open('/tmp/c', 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/anydbm.py", line 80, in open
    raise error, "need 'c' or 'n' flag to open new db"
anydbm.error: need 'c' or 'n' flag to open new db
>>> 

I have also tried this on python2.3b1, and python2.1.3
- with the same results. The bug occurs apparently
because the whichdb module cannot properly identify an
empty dumbdbm file. So, the bug also occurs in this
example:

Python 2.2.2 (#1, Mar 21 2003, 23:01:54) 
[GCC 3.2.3 20030316 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import dumbdbm, anydbm
>>> a = dumbdbm.open('aaa', 'c')
>>> a['abc'] = 'def'
>>> a.close()
>>> b = anydbm.open('aaa', 'w')
>>> del b['abc']
>>> b.close()
>>> c = anydbm.open('aaa', 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/anydbm.py", line 80, in open
    raise error, "need 'c' or 'n' flag to open new db"
anydbm.error: need 'c' or 'n' flag to open new db
>>> 

One solution to this might be to place a warning in the
anydbm documentation that leaving a file empty is
invalid. Another possibility is to include some kind of
magic in dumbdbm so that whichdb can identify them. A
patch for the python2.2.2 dumbdbm.py file is attached.

regards
Greg


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 10:18

Message:
Logged In: YES 
user_id=21627

Thanks for the bugreport. A third approach is to treat empty
dir/dat files as dumbdbm. This approach has been implemented in

whichdb.py 1.15
test_whichdb.py 1.5
whichdb.py 1.12.8.1


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

Comment By: Gregory Saunders (grerfy)
Date: 2003-05-28 05:25

Message:
Logged In: YES 
user_id=788203

Incidentally, the patch I have attached is designed to work with
no modification to the whichdb module. The whichdb module could
be modified to check for the correct magic - but this could
break
backwards compatibility.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744687&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 09:20:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 01:20:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-744164 ] ipv6 addrinfo is bad
Message-ID: <E19R6Gz-0001jo-00@sc8-sf-web1.sourceforge.net>

Bugs item #744164, was opened at 2003-05-27 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=744164&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cypherpunks (cypherpunks)
Assigned to: Nobody/Anonymous (nobody)
Summary: ipv6 addrinfo is bad

Initial Comment:
ipv6 addrinfo becomes a 4-tuple in python, with
additional scope-id and flowinfo members that are never
used in practice by normal apps. scope id might be used
once in a blue moon by something like a dhcp server
(use link local addresses).

this difference causes a large portion of work involved
in porting python apps to suppot v6. i suggest it be
changed to just an address-port tuple, or add some kind
of hack to allow it ot be unpacked like "host, port =
addr".

  -- erno kuusela <erno@iki.fi>

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 10:20

Message:
Logged In: YES 
user_id=21627

Why is this a bug, and what kind of large portion of work is
involved to support IPv6? Please have a look at
httplib/ftplib, which both support IPv6, with minimum amount
of work.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744164&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 09:23:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 01:23:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-741843 ] _locale in Python-2.3b1/Tru64Unix 5.1A doesn't link
Message-ID: <E19R6KA-0001nR-00@sc8-sf-web1.sourceforge.net>

Bugs item #741843, was opened at 2003-05-22 18:25
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: _locale in Python-2.3b1/Tru64Unix 5.1A doesn't link

Initial Comment:
I have managed to compile python on Tru64Unix, but am
curious when I rerun "make", I get:

make
case $MAKEFLAGS in \
*-s*)  CC='cc -pthread' LDSHARED='ld -shared
-expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E
./setup.py -q build;; \
*)  CC='cc -pthread' LDSHARED='ld -shared
-expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E
./setup.py build;; \
esac
running build
running build_ext
building '_locale' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_localemodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -o
build/lib.osf1-V5.1-alpha-2.3/_locale.so
*** WARNING: renaming "_locale" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol
"libintl_gettext" unresolved
building '_curses' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
*** WARNING: renaming "_curses" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_curses.so: symbol
"_acs_map" unresolved
building '_curses_panel' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_curses_panel.c -o
build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o
cc: Severe: /mnt/Python-2.3b1/Modules/_curses_panel.c,
line 17: Cannot find file <panel.h> specified in
#include directive. (noinclfilef)
#include <panel.h>
-^
running build_scripts


This looks suspicious. I have ncurses available on the
system too, also termcap

I see that ncurses isn't found because newer version
are in $prefix/include/ncurses/ and not anymore in
$prefix/include/. There configure fails to detect them.
So, I have to configure as:

F77=f77 F90=f90 CC="cc -pthread" CXX="cxx -pthread"
CFLAGS="$CFLAGS -pthread -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses" CPPFLAGS=$CFLAGS
CXXFLAGS=$CFLAGS ./configure
--prefix=/software/@sys/usr --host=alphaev56-dec-osf5.1
--with-dec-threads --enable-large-file

But even in this case, CPPFLAGS weren't propagated to
Makefiles:
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_curses_panel.c -o
build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o
cc: Severe: /mnt/Python-2.3b1/./Include/py_curses.h,
line 16: Cannot find file <ncurses.h> specified in
#include directive. (noinclfilef)
#include <ncurses.h>
-^


Ooops! Not propagated, they are NOT USED! See
config.status:

s,@CXX@,cxx -pthread,;t t
s,@MAINOBJ@,python.o,;t t
s,@EXEEXT@,,;t t
s,@CC@,cc -pthread,;t t
s,@CFLAGS@,-O2 -arch ev56 -pthread
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses,;t t
s,@LDFLAGS@,,;t t
s,@CPPFLAGS@,-O2 -arch ev56 -pthread
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses,;t t
s,@ac_ct_CC@,,;t t
s,@OBJEXT@,o,;t t
s,@CPP@,cc -pthread -E,;t t

And during build I still see:

case $MAKEFLAGS in \
*-s*)  CC='cc -pthread -O2 -arch ev56
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses' LDSHARED='ld
-shared -expect_unresolved "*"' OPT='-DNDEBUG -O'
./python -E ./setup.py -q build;; \
*)  CC='cc -pthread -O2 -arch ev56
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses' LDSHARED='ld
-shared -expect_unresolved "*"' OPT='-DNDEBUG -O'
./python -E ./setup.py build;; \
esac
running build
running build_ext
building '_locale' extension
cc -pthread -O2 -arch ev56 -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses -DNDEBUG -O
-Olimit 1500 -I. -I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_localemodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -o
build/lib.osf1-V5.1-alpha-2.3/_locale.so
*** WARNING: renaming "_locale" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol
"libintl_gettext" unresolved
running build_scripts


I've reinstalled gettext/libiconv/ncurses, but no
difference. 



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 10:23

Message:
Logged In: YES 
user_id=21627

Please report one bug at a time. What is the bug you are
reporting here? In particular, what does ncurses.h have to
do with _locale?

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

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-04 17:16

Message:
Logged In: YES 
user_id=696559

I believe linking additionally against -lintl will solve the
problem.

I think configur ehas to be improved to detect cases when
-lintl and -lgettextlib might be needed.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 09:28:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 01:28:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-740407 ] Can't browse methods and Classes
Message-ID: <E19R6Oh-0000Rb-00@sc8-sf-web3.sourceforge.net>

Bugs item #740407, was opened at 2003-05-20 14:19
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740407&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: hoka (hoka)
Assigned to: Mark Hammond (mhammond)
Summary: Can't browse methods and Classes

Initial Comment:
If i want to show the method and classes under 
Browse Python Path i got every time this error:

  File "D:\Python23\lib\site-
packages\Pythonwin\pywin\tools\hierlist.py", line 
123, in OnTreeItemExpanding
    self.AddSubList(itemHandle, self.GetSubList
(item))
  File "D:\Python23\lib\site-
packages\Pythonwin\pywin\tools\hierlist.py", line 
137, in AddSubList
    self.AddItem(parentHandle, item)
  File "D:\Python23\lib\site-
packages\Pythonwin\pywin\tools\hierlist.py", line 
140, in AddItem
    text = self.GetText(item)
  File "D:\Python23\lib\site-
packages\Pythonwin\pywin\tools\hierlist.py", line 
266, in GetText
    return self.DelegateCall( item.GetText )
  File "D:\Python23\lib\site-
packages\Pythonwin\pywin\tools\hierlist.py", line 
255, in DelegateCall
    return fn()
  File "D:\Python23\lib\site-
packages\Pythonwin\pywin\tools\browseProjects.p
y", line 26, in GetText
    return self.name + self.suffix
TypeError: unsupported operand type(s) for 
+: 'instance' and 'str'
win32ui: Exception in OnNotify() handler

Greetings

Kai

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 10:28

Message:
Logged In: YES 
user_id=21627

Indeed it sounds like one. Closing it here; hoka, please
report it to Mark, as he is the PythonWin maintainer. I believe

https://sourceforge.net/projects/pywin32/

would be appropriate.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-05-21 23:08

Message:
Logged In: YES 
user_id=31392

I think this is a win32 bug, not a Python bug, right, Mark?


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740407&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 09:36:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 01:36:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current
Message-ID: <E19R6WG-00024Y-00@sc8-sf-web1.sourceforge.net>

Bugs item #740234, was opened at 2003-05-20 05:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Till Plewe (tpx)
Assigned to: Nobody/Anonymous (nobody)
Summary: test/build-failures on FreeBSD stable/current

Initial Comment:
Using snapshot: python_2003-05-19_230000.tar.gz
STABLE (FreeBSD 4.8-STABLE #14: Mon Apr  7)
CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue
May 20)

BUILDFAILURE
curses does not build; neither on CURRENT nor on STABLE
(compiler complaint:

/usr/include/ncurses.h:289: conflicting types for `wchar_t'
/usr/include/stdlib.h:57: previous declaration of `wchar_t'
/usr/include/ncurses.h:292: conflicting types for `wint_t'
/usr/include/wchar.h:96: previous declaration of `wint_t'

if lines /usr/include/ncurses.h:288-293 

#ifndef __wchar_t
typedef unsigned long wchar_t;
#endif /* __wchar_t */
#ifndef __wint_t
typedef long int wint_t;
#endif /* __wint_t */

are deleted then curses builds)

TESTFAILURES
test_re fails on both CURRENT and STABLE
 
test_long
test_pow 
and many more (probably related) tests 

fail on current

See attached file for details


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 10:36

Message:
Logged In: YES 
user_id=21627

Please, folks, one bug per bug report. I think the original
bugs reported in this bug report have been either fixed or
identified as third-party (i.e. OS) bug. So I'm closing it
as fixed.

If any issues remain, please submit a new bugreport. Feel
free to add a note here indicating the new bug report
number, and perhaps assign it right-away to aimacintyre, as
he'll most likely investigate it further (Andrew, if you
won't, feel free to unassign it).

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

Comment By: Till Plewe (tpx)
Date: 2003-06-12 08:06

Message:
Logged In: YES 
user_id=782552

The good news first: test_re works on STABLE/CURRENT and curses
builds on STABLE. 

curses still fails to build on CURRENT but this (as well as
for STABLE)  is really a FreeBSD problem (too many unrelated
guards). I am waiting for answers from various FreeBSD
mailing lists.
In the meantime I patched /usr/include/ncurses.h

Your patch for py_curses.h works for FreeBSD4 but for FreeBSD5 
you would also have to add 

#ifndef __wchar_t
#define __wchar_t
#endif
#ifndef __wint_t
#define __wint_t
#endif

All these guards should be replaced in ncurses.h by
_W{CHAR,INT}_T_DECLARED I believe (on CURRENT)

However I hope that eventually somebody from FreeBSD
will respond and that this problem will be dealt with from 
the FreeBSD side.   
 
The most recent test failure is test_signal. It boils down to
import signal

def handler(signum,frame):
    raise Exception

signal.signal(signal.SIGALRM,handler)
signal.alarm(5)
signal.pause()
signal.alarm(0)

hanging and not raising an exception on CURRENT with 
python2.3. However any of the following work: replacing
i) CURRENT by STABLE, or i) python2.3 by python2.2, or 
iii) SIGALRM by SIGVTALRM


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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-11 14:47

Message:
Logged In: YES 
user_id=250749

The _sre recursion limit was tweaked in _sre.c revision
2.98, which should deal with the bus error in test_re - at
least until thestack consumption per recursion increases again.

gcc 2.95 (FreeBSD 4.x) is set to 7500, gcc 3.x (FreeBSD 5.x)
is set to 6500 (tested on 4.8R).

The curses build problem should be addressed by revision 1.7
of Include/py_curses.h (tested on 4.8R)

Please let me know if the above fixes are satisfactory on
5.x. Is there anything else still needing attention?

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-01 09:47

Message:
Logged In: YES 
user_id=250749

Sigh...

Stacksize is indeed the problem with the test_re failure.

In the pthreads case, on FreeBSD prior to 5.x (I have no
info about 5.x, but from what you say it looks the same),
linking to libc_r causes the "initial" thread to get a hard
coded 1MB stack.  The stack size cannot be changed
(currently) without rebuilding libc_r :-(

As all these regression tests are running on the "initial"
thread, by virtue of not having been explicitly started in a
thread.

The problem is worse with gcc 3.x than 2.95, as gcc 3.x (I
tested with 3.2.2) seems to the stack  more aggressively.

I plan to post a patch to _sre.c extending the FreeBSD/gcc
specific #ifdef'ery (which was put in just before 2.3b1, and
was broken again by _sre commits shortly after 2.3b1).

configure --without-threads doesn't have a problem.

building a threaded interpreter with the Linuxthreads port
also doesn't suffer this problem.

I will be looking into preparing a FreeBSD patch to try and
allow a way to vary the "initial" thread stack size at
compile time, rather than libc_r build time.

This problem has been giving me the irrits since it first
appeared at the beginning of April.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-27 04:37

Message:
Logged In: YES 
user_id=782552

I forgot to mention that stack size is probably not the problem
(FreeBSD 5.1 and 4.8 behave identical with respect to
test_re.py) 
====================================
FreeBSD 4.8-STABLE FreeBSD 4.8-STABLE #14: Mon Apr  7
17:43:45 JST 2003  i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  524288
stack size              (kbytes, -s)  65536
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  896
open files                      (-n)  1792
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited

================================================================
FreeBSD 5.1-BETA FreeBSD 5.1-BETA #25: Thu May 22 09:10:55
JST 2003 i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  1572864
stack size              (kbytes, -s)  1572864
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  5547
open files                      (-n)  11095
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited


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

Comment By: Till Plewe (tpx)
Date: 2003-05-27 03:59

Message:
Logged In: YES 
user_id=782552

it seems that test_stack_overflow is the culprit

...
    def test_stack_overflow(self):
        # nasty case that overflows the straightforward
recursive
        # implementation of repeated groups.
        self.assertRaises(RuntimeError, re.match, '(x)*',
50000*'x')
        self.assertRaises(RuntimeError, re.match, '(x)*y',
50000*'x'+'y')
        self.assertRaises(RuntimeError, re.match, '(x)*?y',
50000*'x'+'y')
...

>>> A.test_stack_overflow()

Process Python bus error (core dumped)

Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*', 5000*'x')
<_sre.SRE_Match object at 0x81d2b20>
>>> re.match('(x)*', 50000*'x')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*y', 50000*'x'+'y')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*?y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*?y', 50000*'x'+'y')

Process Python bus error (core dumped)


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-25 01:40

Message:
Logged In: YES 
user_id=33168

Can you determine what the conflict in the header files
which prevents curses from building?

My guess is that test_bug_418626() is causing the core dump
(from test_re.py).  Can you verify the problem is in that
function?  If so, can you test each of the
re.match/re.search in the interpreter to determine which
line is failling?

My guess is that it's related to the recursion limit (likely
the last line).  Your stack size limit may be too small for
the python recursion limit.  You can try doing a ulimit -a
to see all the limits.  ulimit -s 8192 is what my stack size
is set to (but on Linux).  Doing that command may work for
you.  But this is all conjecture until you investigate further.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-22 07:04

Message:
Logged In: YES 
user_id=782552

Most of the test failures on FreeBSD CURRENT seem to be gcc
bugs.
(I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release))
Rebuilding world with the additional compiler flag 
  -mno-sse2
got rid of most test failures.

Now only the curses build failure and the test_re failure
remain.

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

Comment By: Till Plewe (tpx)
Date: 2003-05-22 06:57

Message:
Logged In: YES 
user_id=782552

I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release).

Most of the test failures seem to be gcc-bugs.
Rebuilding world with the extra compiler flag 

   -mno-sse2

got rid of most test failures. Now only the test_re failure and
the curses build failure remain.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 00:34

Message:
Logged In: YES 
user_id=33168

I think many of the failures are due to the test_long
failure.  If that problem is fixed, my guess is several
other tests will start working.

What compiler are you using?  Can you try to debug the
test_long failure?  I don't think any python developers have
access to a freebsd box.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 09:38:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 01:38:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-733231 ] Need an easy way to check the version
Message-ID: <E19R6Y7-00027w-00@sc8-sf-web1.sourceforge.net>

Bugs item #733231, was opened at 2003-05-06 14:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733231&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need an easy way to check the version

Initial Comment:
With MacPython's Package Manager being able to install the full HTML 
documentation on the users' machine it would be nice if it could 
check the version of the documentation. Something like a version.txt 
(or __version__.py?) should do the trick.
 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 10:38

Message:
Logged In: YES 
user_id=21627

As there are no follow-ups, I assume my proposal is
sufficient, so I'm closing this report as works-for-me.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-09 09:56

Message:
Logged In: YES 
user_id=21627

Looking for the string <strong>Release in lib.html is not
good enough?

If so, I could support adding a META tag into lib.html. I'm
-1 for an additional file.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733231&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 10:08:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 02:08:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-715782 ] pydoc support for keywords
Message-ID: <E19R71W-0002wG-00@sc8-sf-web1.sourceforge.net>

Bugs item #715782, was opened at 2003-04-05 13:36
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc support for keywords

Initial Comment:
[ from http://bugs.debian.org/186775 ]

If one uses $ man perl
one gets on a path that can lead one to eventually find
docs for the
most basic commands like 'while'

However for python one sees one is to use pydoc. But
running pydoc,
one just sees
  pydoc - the Python documentation tool

  /usr/bin/pydoc <name> ...

etc. no hint about how to learn about basics like 'while'.

BTW, I wish it would say pydoc, not /usr/bin/pydoc


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 11:08

Message:
Logged In: YES 
user_id=21627

This is fixed in

pydoc.py 1.85
NEWS 1.783

as far is Python proper is concerned. To get keyword help,
the Python HTML documentation must be found in the locations
in which it is searched for.

The "I wish it would say pydoc" wish will not be granted.
Printing the complete path is deliberate, so that users can
see where in the path pydoc was found.

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-24 16:29

Message:
Logged In: YES 
user_id=31435

Unassigned (I can't make time for this).

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

Comment By: Douglas Napoleone (derivin)
Date: 2003-04-19 06:06

Message:
Logged In: YES 
user_id=541557

Could you please include the OS, install, distro for python?

the distrobution from ActiveState has a very detailed 
manpage on linux. The cygwin distrobution (currently 
hosted/maintained by RedHat) has a poor man page (similar 
yet different from your example).

To be honest, I thought there was only a GNU info page, a 
quick find of the source tree didnt turn anything up, (but Im 
building on windows).


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

Comment By: Cherniavsky Beni (cben)
Date: 2003-04-06 10:33

Message:
Logged In: YES 
user_id=36166

It should suggest to run ``python`` and type ``help()``. 
Then one can type ``topics`` and access the language
documentation itself, e.g. ``LOOPING`` would tell one that
there is a ``while`` whose specific documentation is
accessible by typing the ``while`` keyword itself.  Also
some sentences about the usefulness of the Python prompt,
`dir()` and `help()` for learning might be in order...

BTW, it would be more consistent if pydoc would support the
special topics from the command line (it would require a
non-ambiguos option to avoid shadowing modules in current
directoy that happen to have one of the special name)...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 11:19:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 03:19:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-754447 ] socket.ssl fails when passed a _socketobj
Message-ID: <E19R88Y-0003Rm-00@sc8-sf-web3.sourceforge.net>

Bugs item #754447, was opened at 2003-06-14 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=754447&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.ssl fails when passed a _socketobj

Initial Comment:
[forwarded from http://bugs.debian.org/196082]

rechecked with 2.3 CVS 20030614

When trying to create a IMAP connection over SSL I'm
getting a failiure
with python2.3. You can recreate it with the following
simple script:

#!/usr/bin/python2.3

import imaplib
c = imaplib.IMAP4_SSL("localhost")

which dies with the following trace:
Traceback (most recent call last):
  File "./sslimaptest.py", line 4, in ?
    c = imaplib.IMAP4_SSL("localhost")
  File
"/home/andyh/projects/personal/webimap/imaplib.py",
line 1040, in __init__
    IMAP4.__init__(self, host, port)
  File
"/home/andyh/projects/personal/webimap/imaplib.py",
line 151, in __init__
    self.open(host, port)
  File
"/home/andyh/projects/personal/webimap/imaplib.py",
line 1053, in open
    self.sslobj = socket.ssl(self.sock, self.keyfile,
self.certfile)
TypeError: ssl() argument 1 must be _socket.socket, not
_socketobject


I simplified the code IMAP4_SSL calls to the following:
#!/usr/bin/python2.3

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("localhost", 993))
socket.ssl(sock, None, None)

which dies:
Traceback (most recent call last):
  File "./ssltest.py", line 7, in ?
    socket.ssl(sock, None, None)
TypeError: ssl() argument 1 must be _socket.socket, not
_socketobject

It appears that the socket.ssl() function doesn't like
taking the objects
the socket library is producing!

I noticed in the python2.3 changelog the following entry:
- The socket module now always uses the _socketobject
wrapper class, even 
on platforms which have dup(2). The makefile() method
is built directly on 
uop of the socket without duplicating the file
descriptor, allowing timeouts 
to work properly.

Not sure if its relevant. 



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754447&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 11:21:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 03:21:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-754447 ] socket.ssl fails when passed a _socketobj
Message-ID: <E19R8AH-0003V5-00@sc8-sf-web3.sourceforge.net>

Bugs item #754447, was opened at 2003-06-14 10:19
Message generated for change (Settings changed) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754447&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.ssl fails when passed a _socketobj

Initial Comment:
[forwarded from http://bugs.debian.org/196082]

rechecked with 2.3 CVS 20030614

When trying to create a IMAP connection over SSL I'm
getting a failiure
with python2.3. You can recreate it with the following
simple script:

#!/usr/bin/python2.3

import imaplib
c = imaplib.IMAP4_SSL("localhost")

which dies with the following trace:
Traceback (most recent call last):
  File "./sslimaptest.py", line 4, in ?
    c = imaplib.IMAP4_SSL("localhost")
  File
"/home/andyh/projects/personal/webimap/imaplib.py",
line 1040, in __init__
    IMAP4.__init__(self, host, port)
  File
"/home/andyh/projects/personal/webimap/imaplib.py",
line 151, in __init__
    self.open(host, port)
  File
"/home/andyh/projects/personal/webimap/imaplib.py",
line 1053, in open
    self.sslobj = socket.ssl(self.sock, self.keyfile,
self.certfile)
TypeError: ssl() argument 1 must be _socket.socket, not
_socketobject


I simplified the code IMAP4_SSL calls to the following:
#!/usr/bin/python2.3

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("localhost", 993))
socket.ssl(sock, None, None)

which dies:
Traceback (most recent call last):
  File "./ssltest.py", line 7, in ?
    socket.ssl(sock, None, None)
TypeError: ssl() argument 1 must be _socket.socket, not
_socketobject

It appears that the socket.ssl() function doesn't like
taking the objects
the socket library is producing!

I noticed in the python2.3 changelog the following entry:
- The socket module now always uses the _socketobject
wrapper class, even 
on platforms which have dup(2). The makefile() method
is built directly on 
uop of the socket without duplicating the file
descriptor, allowing timeouts 
to work properly.

Not sure if its relevant. 



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754447&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 11:32:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 03:32:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E19R8KL-0005si-00@sc8-sf-web4.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 10: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=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 11:51:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 03:51:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-754455 ] sigwinch crashes python with curses
Message-ID: <E19R8d3-0004P9-00@sc8-sf-web3.sourceforge.net>

Bugs item #754455, was opened at 2003-06-14 10: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=754455&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: sigwinch crashes python with curses

Initial Comment:
[forwarded from http://bugs.debian.org/178205]

I'm not able to reproduce this bug in current 2.1/2.2.
In 2.3 CVS 20030614, changing the window size of an
xterm results in the crash

The following code crashes. It does not occur when
getkey () is not used.

# Crash python

import curses, signal, time, sys

def sigwinch (signum, frame): return

win = curses.initscr ()

signal.signal(signal.SIGWINCH, sigwinch)

while 1: win.getkey ()

curses.endwin ()


Traceback (most recent call last):
File "curs.py", line 9, in ?
while 1: win.getkey ()
_curses.error: no input


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754455&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 13:25:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 05:25:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19RA69-0000CH-00@sc8-sf-web1.sourceforge.net>

Bugs item #749911, was opened at 2003-06-05 21:21
Message generated for change (Comment added) made by dr2048
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Reed (dr2048)
Assigned to: Martin v. Löwis (loewis)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


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

>Comment By: Dave Reed (dr2048)
Date: 2003-06-14 08:25

Message:
Logged In: YES 
user_id=795169

That gets past the first problem. Now during the initial
compile, I get:

c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib -L.
-lpython2.3 -lsocket -lnsl -lrt -ldl  -lpthread   -lm  
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


I can't find those flags in the Makefile to try removing one
of them.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 02:36

Message:
Logged In: YES 
user_id=21627

Please try the attached patch and report whether this solves
the problem.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 14:14:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 06:14:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19RAry-0001h0-00@sc8-sf-web1.sourceforge.net>

Bugs item #749911, was opened at 2003-06-06 03:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Reed (dr2048)
Assigned to: Martin v. Löwis (loewis)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 15:14

Message:
Logged In: YES 
user_id=21627

Committed as Makefile.pre.in 1.131.

Can you please add -v to the linker line, and report how the
linker is being invoked?

Can you also try to replace -rpath with -R?

This very line works fine on my copy of Solaris 9, so I'm
uncertain what the problem is.

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

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 14:25

Message:
Logged In: YES 
user_id=795169

That gets past the first problem. Now during the initial
compile, I get:

c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib -L.
-lpython2.3 -lsocket -lnsl -lrt -ldl  -lpthread   -lm  
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


I can't find those flags in the Makefile to try removing one
of them.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:36

Message:
Logged In: YES 
user_id=21627

Please try the attached patch and report whether this solves
the problem.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 14:29:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 06:29:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-754509 ] mod_python does't compile
Message-ID: <E19RB5s-0000ps-00@sc8-sf-web2.sourceforge.net>

Bugs item #754509, was opened at 2003-06-14 06: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=754509&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Hughes (fyl)
Assigned to: Nobody/Anonymous (nobody)
Summary: mod_python does't compile

Initial Comment:
When I attempt to build mod_python 3.0.3 on Linux (SuSE 8.2) it 
fails with 
 requestobject.c: In function `getreq_recmbr_off': 
 requestobject.c:1055: error: `LONG_LONG' undeclared (first use 
in this function) 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754509&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 14:31:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 06:31:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-754447 ] socket.ssl fails when passed a _socketobj
Message-ID: <E19RB7v-0002lL-00@sc8-sf-web4.sourceforge.net>

Bugs item #754447, was opened at 2003-06-14 12:19
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754447&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.ssl fails when passed a _socketobj

Initial Comment:
[forwarded from http://bugs.debian.org/196082]

rechecked with 2.3 CVS 20030614

When trying to create a IMAP connection over SSL I'm
getting a failiure
with python2.3. You can recreate it with the following
simple script:

#!/usr/bin/python2.3

import imaplib
c = imaplib.IMAP4_SSL("localhost")

which dies with the following trace:
Traceback (most recent call last):
  File "./sslimaptest.py", line 4, in ?
    c = imaplib.IMAP4_SSL("localhost")
  File
"/home/andyh/projects/personal/webimap/imaplib.py",
line 1040, in __init__
    IMAP4.__init__(self, host, port)
  File
"/home/andyh/projects/personal/webimap/imaplib.py",
line 151, in __init__
    self.open(host, port)
  File
"/home/andyh/projects/personal/webimap/imaplib.py",
line 1053, in open
    self.sslobj = socket.ssl(self.sock, self.keyfile,
self.certfile)
TypeError: ssl() argument 1 must be _socket.socket, not
_socketobject


I simplified the code IMAP4_SSL calls to the following:
#!/usr/bin/python2.3

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("localhost", 993))
socket.ssl(sock, None, None)

which dies:
Traceback (most recent call last):
  File "./ssltest.py", line 7, in ?
    socket.ssl(sock, None, None)
TypeError: ssl() argument 1 must be _socket.socket, not
_socketobject

It appears that the socket.ssl() function doesn't like
taking the objects
the socket library is producing!

I noticed in the python2.3 changelog the following entry:
- The socket module now always uses the _socketobject
wrapper class, even 
on platforms which have dup(2). The makefile() method
is built directly on 
uop of the socket without duplicating the file
descriptor, allowing timeouts 
to work properly.

Not sure if its relevant. 



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 15:31

Message:
Logged In: YES 
user_id=21627

This is fixed in

httplib.py 1.77
socket.py 1.42


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754447&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 14:35:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 06:35:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-745002 ] <> in attrs in sgmllib not handled
Message-ID: <E19RBBa-0000bb-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Samuel Bayer (sambayer)
Assigned to: Nobody/Anonymous (nobody)
Summary: <> in attrs in sgmllib not handled

Initial Comment:
Hi folks -

This bug is noted in the source code for sgmllib.py,
and it finally bit me. If you feed the SGMLParser class
text such as

<tag attr = "<attrtag> bar </attrtag>">foo</tag>

the <attrtag> will be processed as a tag, as well as
being recognized as part of the attribute. This is
because of the way the end index for the opening tag is
computed.

As far as I can tell from the HTML 4.01 specification,
this is legal. The case I encountered was in a value of
an "onmouseover" attribute, which was a Javascript call
which contained HTML text as one of its arguments.

The problem is in SGMLParser.parse_starttag, which
attempts to compute the end of the opening tag with a
simple regexp [<>], and uses this index even when the
attributes have passed it. There's no real need to
check this regexp in advance, as far as I can tell.
I've attached my proposed modification of
SGMLParser.parse_starttag; I've tested this change in
2.2.1, but there are no relevant differences between
2.2.1 and the head of the CVS tree for this method. No
guarantees of correctness, but it works on the examples
I've tested it on.

Cheers -
Sam Bayer

================================

w_endbracket = re.compile("\s*[<>]")

class SGMLParser:
    # Internal -- handle starttag, return length or -1
if not terminated
    def parse_starttag(self, i):
        self.__starttag_text = None
        start_pos = i
        rawdata = self.rawdata
        if shorttagopen.match(rawdata, i):
            # SGML shorthand: <tag/data/ == <tag>data</tag>
            # XXX Can data contain &... (entity or char
refs)?
            # XXX Can data contain < or > (tag characters)?
            # XXX Can there be whitespace before the
first /?
            match = shorttag.match(rawdata, i)
            if not match:
                return -1
            tag, data = match.group(1, 2)
            self.__starttag_text = '<%s/' % tag
            tag = tag.lower()
            k = match.end(0)
            self.finish_shorttag(tag, data)
            self.__starttag_text =
rawdata[start_pos:match.end(1) + 1]
            return k
        
        # Now parse the data between i+1 and the end of
the tag into a tag and attrs
        attrs = []
        if rawdata[i:i+2] == '<>':
            # SGML shorthand: <> == <last open tag seen>
            k = i + 1
            tag = self.lasttag
        else:
            match = tagfind.match(rawdata, i+1)
            if not match:
                self.error('unexpected call to
parse_starttag')
            k = match.end(0)
            tag = rawdata[i+1:k].lower()
            self.lasttag = tag
        while w_endbracket.match(rawdata, k) is None:
            match = attrfind.match(rawdata, k)
            if not match: break
            attrname, rest, attrvalue = match.group(1,
2, 3)
            if not rest:
                attrvalue = attrname
            elif attrvalue[:1] == '\'' ==
attrvalue[-1:] or \
                 attrvalue[:1] == '"' == attrvalue[-1:]:
                attrvalue = attrvalue[1:-1]
            attrs.append((attrname.lower(), attrvalue))
            k = match.end(0)
        match = endbracket.search(rawdata, k)
        if not match:
            return -1
        j = match.start(0)   
        if rawdata[j] == '>':
            j = j+1
        self.__starttag_text = rawdata[start_pos:j]
        self.finish_starttag(tag, attrs)
        return j


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

>Comment By: Samuel Bayer (sambayer)
Date: 2003-06-14 13:35

Message:
Logged In: YES 
user_id=40146

I'm reporting it because

(a) it's not in the bug queue, and
(b) it's broken

The fact that it's noted as a bug in the source code doesn't
strike me as relevant. Especially since I attached a fix.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 07:58

Message:
Logged In: YES 
user_id=21627

If this is a known bug, why are you reporting it?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745002&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 14:39:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 06:39:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19RBFw-00017I-00@sc8-sf-web2.sourceforge.net>

Bugs item #749911, was opened at 2003-06-05 21:21
Message generated for change (Comment added) made by dr2048
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Reed (dr2048)
Assigned to: Martin v. Löwis (loewis)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


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

>Comment By: Dave Reed (dr2048)
Date: 2003-06-14 09:39

Message:
Logged In: YES 
user_id=795169

I found the rpath line in the Makefile and replaced it with -R
I can't seem to find the ld line in the Makefile.

I noticed that I actually did get a libpython2.3.so file
created even though
I got the errors, but I couldn't complete a make install
because of the errors

I'm trying again now with the -R line.

If you want to contact me via email at "dreed at
capital.edu", it might
be easier to work through these problems using email or IM
at some time
that we're both available. Thanks!

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 09:14

Message:
Logged In: YES 
user_id=21627

Committed as Makefile.pre.in 1.131.

Can you please add -v to the linker line, and report how the
linker is being invoked?

Can you also try to replace -rpath with -R?

This very line works fine on my copy of Solaris 9, so I'm
uncertain what the problem is.

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

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 08:25

Message:
Logged In: YES 
user_id=795169

That gets past the first problem. Now during the initial
compile, I get:

c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib -L.
-lpython2.3 -lsocket -lnsl -lrt -ldl  -lpthread   -lm  
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


I can't find those flags in the Makefile to try removing one
of them.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 02:36

Message:
Logged In: YES 
user_id=21627

Please try the attached patch and report whether this solves
the problem.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 14:43:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 06:43:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-754455 ] sigwinch crashes python with curses
Message-ID: <E19RBJJ-0000qw-00@sc8-sf-web3.sourceforge.net>

Bugs item #754455, was opened at 2003-06-14 12:51
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754455&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: sigwinch crashes python with curses

Initial Comment:
[forwarded from http://bugs.debian.org/178205]

I'm not able to reproduce this bug in current 2.1/2.2.
In 2.3 CVS 20030614, changing the window size of an
xterm results in the crash

The following code crashes. It does not occur when
getkey () is not used.

# Crash python

import curses, signal, time, sys

def sigwinch (signum, frame): return

win = curses.initscr ()

signal.signal(signal.SIGWINCH, sigwinch)

while 1: win.getkey ()

curses.endwin ()


Traceback (most recent call last):
File "curs.py", line 9, in ?
while 1: win.getkey ()
_curses.error: no input


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 15:43

Message:
Logged In: YES 
user_id=21627

This is not a bug in Python. In _cursesmodule.c rev. 2.70,
Patch #633635 from David M. Cooke was implemented, which
makes the implementation match the documentation:

getch([x, y])
Get a character. Note that the integer returned does not
have to be in ASCII range: function keys, keypad keys and so
on return numbers higher than 256. In no-delay mode, an
exception is raised if there is no input. 

This exception is raised when the underlying wgetch returns
ERR, so if there is a bug here, it might be in ncurses, for
having wgetch return on window change.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754455&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 15:12:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 07:12:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-754509 ] mod_python does't compile
Message-ID: <E19RBlR-0001j5-00@sc8-sf-web3.sourceforge.net>

Bugs item #754509, was opened at 2003-06-14 15:29
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754509&group_id=5470

Category: Build
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Phil Hughes (fyl)
Assigned to: Nobody/Anonymous (nobody)
Summary: mod_python does't compile

Initial Comment:
When I attempt to build mod_python 3.0.3 on Linux (SuSE 8.2) it 
fails with 
 requestobject.c: In function `getreq_recmbr_off': 
 requestobject.c:1055: error: `LONG_LONG' undeclared (first use 
in this function) 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:12

Message:
Logged In: YES 
user_id=21627

This is not a bug in Python, but in mod_python. Please
report it to the mod_python maintainer.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754509&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 15:16:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 07:16:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19RBpU-0003Pz-00@sc8-sf-web1.sourceforge.net>

Bugs item #749911, was opened at 2003-06-05 21:21
Message generated for change (Comment added) made by dr2048
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Reed (dr2048)
Assigned to: Martin v. Löwis (loewis)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


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

>Comment By: Dave Reed (dr2048)
Date: 2003-06-14 10:16

Message:
Logged In: YES 
user_id=795169

The makefile patch and changing -rpath to -R got it to
compile, but
when I try to execute python I get:

python
ld.so.1: python: fatal: relocation error: file
./libpython2.3.so: symbol rl_complete: referenced symbol not
found
Killed

what version of gcc are you using to compile it on Solaris 9?

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

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 09:39

Message:
Logged In: YES 
user_id=795169

I found the rpath line in the Makefile and replaced it with -R
I can't seem to find the ld line in the Makefile.

I noticed that I actually did get a libpython2.3.so file
created even though
I got the errors, but I couldn't complete a make install
because of the errors

I'm trying again now with the -R line.

If you want to contact me via email at "dreed at
capital.edu", it might
be easier to work through these problems using email or IM
at some time
that we're both available. Thanks!

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 09:14

Message:
Logged In: YES 
user_id=21627

Committed as Makefile.pre.in 1.131.

Can you please add -v to the linker line, and report how the
linker is being invoked?

Can you also try to replace -rpath with -R?

This very line works fine on my copy of Solaris 9, so I'm
uncertain what the problem is.

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

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 08:25

Message:
Logged In: YES 
user_id=795169

That gets past the first problem. Now during the initial
compile, I get:

c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib -L.
-lpython2.3 -lsocket -lnsl -lrt -ldl  -lpthread   -lm  
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


I can't find those flags in the Makefile to try removing one
of them.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 02:36

Message:
Logged In: YES 
user_id=21627

Please try the attached patch and report whether this solves
the problem.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 15:17:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 07:17:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-751933 ] 2.2.3 Latex documentation missing from web page?
Message-ID: <E19RBq6-0001ts-00@sc8-sf-web3.sourceforge.net>

Bugs item #751933, was opened at 2003-06-10 16:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751933&group_id=5470

Category: Documentation
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Dickinson (marketdickinson)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 2.2.3 Latex documentation missing from web page?

Initial Comment:
The files named latex-2.2.3.tgz and latex-2.2.3.tar.bz2 in
ftp://python.org/pub/python/doc/2.2.3 appear to contain
documentation for Python 2.3b1 and not for Python 2.2.3.
Is the LaTeX version of the Python 2.2.3 documentation
available elsewhere?

Thanks,

Mark

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:17

Message:
Logged In: YES 
user_id=21627

Fred, any idea how that happened?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751933&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 15:20:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 07:20:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-751793 ] Re module cannot be loaded in restricted mode
Message-ID: <E19RBtn-0003Xd-00@sc8-sf-web1.sourceforge.net>

Bugs item #751793, was opened at 2003-06-10 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=751793&group_id=5470

Category: Regular Expressions
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Fredrik Lundh (effbot)
Summary: Re module cannot be loaded in restricted mode

Initial Comment:
If you try to use regular expressions in restricted mode, 
you get the error "'module' object has no 
attribute 'hexversion'". Try with:

import rexec
rexec.RExec().r_exec("import re")

Suggestion: Add 'hexversion' to allowed sys attributes 
in /usr/lib/python/rexec.py:

    ok_sys_names = 
('ps1', 'ps2', 'copyright', 'version', 'hexversion',
                    'platform', 'exit', 'maxint')


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:20

Message:
Logged In: YES 
user_id=21627

This is fixed in Python 2.2.3 and 2.3 (except that rexec
won't work in these versions, anyway).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751793&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 15:23:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 07:23:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-751276 ] cPickle doesn't raise error, pickle does (recursiondepth)
Message-ID: <E19RBwK-0004Mq-00@sc8-sf-web4.sourceforge.net>

Bugs item #751276, was opened at 2003-06-09 13:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle doesn't raise error, pickle does (recursiondepth)

Initial Comment:
I have this object that causes a recursive call in the
__getattr__ method.

When I unpicke it using pickle, I get a runtimeerror
recursiondepth exceeded. When I unpickle it using
cPickle, everything appears to work -- no error is raised.
(tested on python 2.2.3 and 2.3b1)

The output of the attached python test file is:

***pickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
FAIL!!!  <exceptions.RuntimeError instance at
0x00951C68> maximum recursion depth exceeded
***cPickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
SUCCESS!!! name= myname


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:23

Message:
Logged In: YES 
user_id=21627

This problem cannot be fixed. cPickle and pickle work
differently by nature; one is written in C, the other in
Python (as their names suggest).

You can try to sys.setrecursionlimit, to raise the nesting
level that pickle.py supports.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 15:28:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 07:28:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-749480 ] strange  __subclasses__ behaviour
Message-ID: <E19RC0k-0003op-00@sc8-sf-web1.sourceforge.net>

Bugs item #749480, was opened at 2003-06-05 13:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749480&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: strange  __subclasses__ behaviour

Initial Comment:
I am not entirely sure whether this is a bug, because I
can't find documentation on __subclasses__ and am
unable to read the source (don't know C). But the name
__subclasses__ implies that a collection of all
subclasses would be returned; however, it doesn't on my
system. It seems as if some subclasses are only listed
*after* they have been looked up in the subclasses'
__bases__, while others are included without that:

$ python
Python 2.3b1+ (#2, Jun  4 2003, 17:16:59)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> float in object.__subclasses__()
False
  1 >>> object in float.__bases__
True
  2 >>> float in object.__subclasses__()
True  3 >>> object.__subclasses__
<built-in method __subclasses__ of type object at
0x8107d60>
  4 >>> object.__subclasses__()
[<type 'type'>, <type 'int'>, <type 'basestring'>,
<type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>, <type
'zipimport.zipimporter'>, <type 'posix.stat_result'>,
<type 'posix.statvfs_result'>, <type 'dict'>, <type
'function'>, <type 'file'>, <type 'float'>, <type
'dictproxy'>]
  5 >>> long in object.__subclasses__()
False
  6 >>> long()
0L
  7 >>> long in object.__subclasses__()
False
  8 >>> long.__bases__
(<type 'object'>,)
  9 >>> long in object.__subclasses__()
True
$ python -c "print object.__subclasses__()"
[<type 'type'>, <type 'int'>, <type 'basestring'>,
<type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>, <type
'zipimport.zipimporter'>, <type 'posix.stat_result'>,
<type 'posix.statvfs_result'>, <type 'dict'>, <type
'function'>, <type 'file'>]
$ python -S -c "print object.__subclasses__()"
[<type 'type'>, <type 'int'>, <type 'basestring'>,
<type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>, <type
'zipimport.zipimporter'>, <type 'function'>, <type
'posix.stat_result'>, <type 'posix.statvfs_result'>,
<type 'dict'>]


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:28

Message:
Logged In: YES 
user_id=21627

This is not a bug. A type is added to __subclasses__ of its
base once it gets "readied". When and if that happens for a
certain type is implementation-defined.

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-06-05 13:36

Message:
Logged In: YES 
user_id=13298

I accidently pressed enter to early, here is some more
information:

$ python2.2 -S -c "print object.__subclasses__()"
[<type 'type'>, <type 'list'>, <type 'NoneType'>, <type
'NotImplementedType'>, <type 'module'>]

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749480&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 15:30:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 07:30:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-678723 ] ./configure fails w/error: cannot compute sizeof (wchar_t),
Message-ID: <E19RC30-0003th-00@sc8-sf-web1.sourceforge.net>

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

Category: Installation
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jeff Stephens (jeffste)
Assigned to: Nobody/Anonymous (nobody)
Summary: ./configure fails w/error: cannot compute sizeof (wchar_t), 

Initial Comment:
 I am running RH 7.3, kernel  2.4.18-19.7.x, and gcc-2.96-113.    
I attempted to configure python-2.3a1 as follows:   
   
./configure  --enable-shared --with-threads --with-pth  
  
Got the following error:  
  
checking size of wchar_t... configure: error: cannot compute 
sizeof (wchar_t), 77 
 
  

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:30

Message:
Logged In: YES 
user_id=21627

Apparently not. Closing as invalid.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 23:50

Message:
Logged In: YES 
user_id=33168

Is this still a problem with the current beta?

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-15 14:24

Message:
Logged In: YES 
user_id=21627

Feel free to put a note into the README. However, I think
this is a pilot error: If the user specifies --with-pth, but
does not have pth properly installed, then configure is
entitled to fail in strange ways. If --with or --enable is
specified, it should be taken as overriding whatever
configure thinks is right, so those command options must be
followed blindly.

Perhaps a general note "read config.log if configure fails"
would be appropriate.

It would be good if Jeff could report whether he ran into
the same problem (pth not properly installed).

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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-03-15 14:11

Message:
Logged In: YES 
user_id=11375

Good suggestion; installing libpth-dev lets configure run without problems.

So the simplest fix for this bug is probably just adding a note to the README warning people to have the appropriate .so installed.   Or should configure
check for a linkable libfoo.so? 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-14 22:33

Message:
Logged In: YES 
user_id=21627

Can you give the precise name of the .so file you have in
/usr/lib? If it is usr/lib/libpth.so.14, then it is
irrelevant that ldconfig finds it: /usr/bin/ld won't use
that file for linking. You probably need to install libpth-dev.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-03-14 17:04

Message:
Logged In: YES 
user_id=11375

I can replicate this problem on my Debian machine.  config.log attached.

'gcc -o conftest -g -O2   config.c  -lpth -lrt -ldl'  reports the following error: '/usr/bin/ld: cannot find -lpth'.  This is very odd, because 
I've got the libpth14 package installed, there's a .so in /usr/lib,
ldconfig find it, etc.  


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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-03-14 17:04

Message:
Logged In: YES 
user_id=11375

Let's try that attachment again.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-05 16:42

Message:
Logged In: YES 
user_id=21627

It would be good if you could attach the config.log that you
got when it failed.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-02 02:46

Message:
Logged In: YES 
user_id=33168

Jeff, I think we should try to fix this.  It looks like a
duplicate of 662840.  It would be great if you can help
debug this further.

The problem seems to be related to redhat 7.3.  The other
bug which fails exactly the same way is using gcc 3.2 and
doesn't mention config options (although they may be used).

----------------------------------------------------------------------

Comment By: Jeff Stephens (jeffste)
Date: 2003-02-01 19:33

Message:
Logged In: YES 
user_id=702289

I reran ./configure several times, varying the options, and found  
that this error only occurs when the option "--with-pth" is  
included.  For example: 
 
./configure --enable-shared --with-pth   #error occurs 
./configure --enable-shared --with-threads  #error does NOT occur 
 
I don't know whether this is a bug or not, so I am leaving it to 
the experts to say yea or nay.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 15:47:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 07:47:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-610332 ] SO name is too short!  Python 2.2.1
Message-ID: <E19RCJy-00030R-00@sc8-sf-web3.sourceforge.net>

Bugs item #610332, was opened at 2002-09-17 05:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610332&group_id=5470

Category: Build
Group: Not a Bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: eschasi (eschasi)
Assigned to: Nobody/Anonymous (nobody)
Summary: SO name is too short!  Python 2.2.1

Initial Comment:
I had various odd problems building python 2.2.1 under the 
FreeBSD ports, but have finally resolved it. 
 
It turns out that my standard system setup includes two 
environment variables which are used in shell scripts to 
generate inverse video.  They are SO and SE, for 
standout and standend, as per the classic termcap/termlib 
variables. 
 
Unfortunately, the ./configure script uses SO as the 
extension for shared libraries.  If it is previously defined, 
the value is retained rather than developed by test.  Thus 
my python builds were looking for shared libraries with 
the name foo.<ESC>[7m rather than foo.so. 
 
I found two fixes which worked.  One was to undefine SO. 
The other was to rummage thru configure, configure.in and 
Makefile.pre.in at the top dir and change SO to SHLIBEXT. 
After either, the configure/builds ran fine. 
 
I notice in those files that SO is pretty much the *only* 
two-character variable name used that is not already 
strongly associated with a 'standard' name for builds 
via make (CC, LD, etc).  I have not encounted any other 
use of SO except python's and mine. 
 
While I'm not presumptuous enough to suggest that pythons 
build should change to avoid my problems, I *will* note 
that long, meaningful variable names are alwas better than 
short, obscure, misleading ones.  While SO does reflect 
the UNIX shared library, it's a bit misleading for DLLs, etc. 

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:47

Message:
Logged In: YES 
user_id=21627

I think this should be solved by unsetting SO before
configuration. I have added a warning in

configure.in 1.416
configure 1.405

if SO is set, to allow the user to interrupt configure.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-17 19:57

Message:
Logged In: YES 
user_id=21627

I'm not confusing the two. I'm concerned that extensions
module build procedures read through the generated makefile,
try to extract SO from it, and make use of this. It appears
that your requested change would break such build procedures.

I'm not worried about the actual extension; I know it has to
be .so or .sl on Unix.

----------------------------------------------------------------------

Comment By: eschasi (eschasi)
Date: 2002-09-17 19:48

Message:
Logged In: YES 
user_id=161331

Sorry, you're confusing the variable name and the shared file 
extension name.  For UNIX systems, the extension has to be .so; 
it has to be .dll for Windows, etc.  The internal variable the 
build process uses to hold the extension is a separate item. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-17 17:33

Message:
Logged In: YES 
user_id=21627

When changing this, I'm concerned that third-party code may
break which relies on the extension being SO. I'd like to
hear other opinions on whether this should or should not be
changed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610332&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 15:52:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 07:52:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-614791 ] gethostbyname() blocks when threaded
Message-ID: <E19RCOG-0005aH-00@sc8-sf-web4.sourceforge.net>

Bugs item #614791, was opened at 2002-09-26 06:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614791&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rob Green (rbgrn)
Assigned to: Nobody/Anonymous (nobody)
Summary: gethostbyname() blocks when threaded

Initial Comment:
I know this is because it is simply a wrapper for the libc 
gethostbyname, but it really, really hurts my app to have 
it block like this. I am requesting that by any means 
necessary, gethostbyname() not block when multiple 
threads call it simultaneously. It seriously ruins the 
ability to write effective network daemons in python, as it 
can take a very, very long time to get through even a 
small list of hostnames if one or a few of them need to 
timeout to be resolved.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:52

Message:
Logged In: YES 
user_id=21627

This was fixed with patch #731644 for Python 2.3. Please
have a look at the implementation; FreeBSD is considered as
a system which does not have a thread-safe getaddrinfo. If
some release are thread-safe and some are not, patches
telling those apart would be appreciated.

----------------------------------------------------------------------

Comment By: Rob Green (rbgrn)
Date: 2002-09-30 19:22

Message:
Logged In: YES 
user_id=590105

Here is a response from one of the FreeBSD developers 
working on resolver functions:

Of course, HEAD branch has some newer implementation.  
However, basic facility of getaddrinfo(3) is same between 
branches.

getaddrinfo(3) is expected as thead-safe from begining. This 
requirement is described in RFC2553:

>   The official specification for this function will be the final 
POSIX
>   standard, with the following additional requirements:
>
>      -  getaddrinfo() (along with the getnameinfo() function 
described
>         in the next section) must be thread safe.

And, I believe getaddrinfo(3) itself is written in thread-safe 
manner. But, res_* functions is still not thread-safe.  Since no 
one tries to audit if getaddrinfo(3) in FreeBSD is thread-safe, 
yet, I dunno if it is actually thread-safe. In any way, if 
getaddrinfo(3) is not thread-safe, we should fix it.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-09-30 15:56

Message:
Logged In: YES 
user_id=31392

I should also take a look at the thread-safe implementation for 
FreeBSD.  Perhaps it can be mined to make the default 
implementation that ships with Python thread-safe.

----------------------------------------------------------------------

Comment By: Rob Green (rbgrn)
Date: 2002-09-30 10:40

Message:
Logged In: YES 
user_id=590105

Ok, well since it is confirmed fixed in FreeBSD 5.0, maybe 
the next release of python should consider it thread-safe.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-30 09:30

Message:
Logged In: YES 
user_id=21627

Thanks for the research. 

We'll leave the bug open until this is actually fixed. It
would be still possible to implement a patch that replaces
the GIL with a getaddrinfo lock on systems where getaddrinfo
is not thread-safe, but I feel no urge to implement such a
fix now. The only other system that would suffer is Win32,
on which getaddrinfo is thread-safe if you compile with VC.NET.

----------------------------------------------------------------------

Comment By: Rob Green (rbgrn)
Date: 2002-09-30 04:12

Message:
Logged In: YES 
user_id=590105

Here's what I found out. The thread-safe version is available in 
FreeBSD-Current, which will be Release and Stable in v5.0. 
So you can take out the lock for FreeBSD 5.0 and up, and 
that should be incorporated into the next Python release, as 
it has been available for FreeBSD-Current users for a year 
now.

----------------------------------------------------------------------

Comment By: Rob Green (rbgrn)
Date: 2002-09-30 01:45

Message:
Logged In: YES 
user_id=590105

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/net/name6.c

It appears as though this was made thread-safe in revision 
1.17 of the file which was Jan 24, 2001. Unfortunately there 
are two branches of code here, and I have no idea what's 
going on with them. I apparently have code from 2000 that 
doesn't appear to be thread-safe but the test worked so I'm 
gonna send around some emails and see if I can't clear 
anything up.

----------------------------------------------------------------------

Comment By: Rob Green (rbgrn)
Date: 2002-09-30 01:19

Message:
Logged In: YES 
user_id=590105

http://orange.kame.net/dev/query-pr.cgi?pr=277

There's the bug. It was submitted over 2 years ago, and I'm 
willing to bet it has been fixed but their bug database isn't up-
to-date. I ran the test code and it passed on my machine, 
meaning it's fixed in my version, so I emailed the author to 
find out what version this was fixed in. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-29 23:31

Message:
Logged In: YES 
user_id=21627

As for FreeBSD bugs: Please consult the BUGS section of
getaddrinfo(3). It may be that this man page is incorrect, I
don't know.

----------------------------------------------------------------------

Comment By: Rob Green (rbgrn)
Date: 2002-09-29 21:05

Message:
Logged In: YES 
user_id=590105

I've done some testing and I partially see what you are talking 
about. I wrote a test case in C using pthreads and in 
FreeBSD 4.5 I was able to resolve tens of hostnames 
simultaneously with no errors or problems. Python of course 
has the lock wrapped around the call, and Java appears to as 
well. Should I expect problems with this? Or might this be an 
indication that somewhere along the lines in freebsd 
development this issue was resolved but never 
tested/incorporated with Python/Java? If this is the case, then 
I suppose we would need to figure out at what version this 
changed and have the python lock act accordingly.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-26 20:14

Message:
Logged In: YES 
user_id=21627

socketmodule.c contains a number of calls to getaddrinfo and
getnameinfo. On systems where those calls are not
thread-safe, you should add a lock around them, see Python
2.1, socketmodule.c, gethostbyname_lock. On all systems, you
should use Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS;
again, see Python 2.1.

There probably should be a single lock around both
getaddrinfo and getnameinfo. By default, those should be
considered thread-safe, giving explicit exceptions: *BSD,
and the fallback implementations (i.e. if either
getaddrinfo.c or getnameinfo.c is included).

----------------------------------------------------------------------

Comment By: Rob Green (rbgrn)
Date: 2002-09-26 19:28

Message:
Logged In: YES 
user_id=590105

This is a little over my head, but I'll take a look to see what 
you mean. Could you give me any more info to point me in 
the right direction? Thanks

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-26 18:29

Message:
Logged In: YES 
user_id=21627

Bad choice of system :-) In general, it would be the easiest
modification of the interpreter to just release the GIL
before getaddrinfo (which gethostbyname uses); this is a
simple change and makes everything free running.

Unfortunately, on BSD, getaddrinfo is not thread-safe. So
for this system, a much more complicated change must be
implemented. I have semi-approved any change that releases
the GIL unconditionally on "good" systems (Solaris, Linux,
Tru64). That won't help you, though.

If you can contribute a patch that adds a getaddrinfo lock
for "bad" systems, and avoids this lock on "good" systems,
there is a small chance that this can get included in 2.2.2.
Without anybody acting quickly, this may or may not get
fixed in 2.3.

----------------------------------------------------------------------

Comment By: Rob Green (rbgrn)
Date: 2002-09-26 18:09

Message:
Logged In: YES 
user_id=590105

FreeBSD 4.5, although I don't think it's platform specific, as 
I've seen some messages from guido on certain mailing lists 
talking about this problem and how it will require a large 
rewrite to fix correctly. In all honesty, I'd be happy with a 
simple hack to make this work and then a rewrite of whatever 
needs it in the future to have it written correctly.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-26 18:06

Message:
Logged In: YES 
user_id=21627

Can you please report what platform you are using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614791&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 16:07:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 08:07:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-553736 ] thread_pthread.h on FreeBSD
Message-ID: <E19RCcT-0003lV-00@sc8-sf-web3.sourceforge.net>

Bugs item #553736, was opened at 2002-05-08 17:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=553736&group_id=5470

Category: Threads
Group: Python 2.1.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrew Sawyers (zc_andrew)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_pthread.h on FreeBSD

Initial Comment:
The pthread setstacksize of 64K is too small for 
FreeBSD in some cases (i.e. specifically when running 
Zope/CMF).  The attached diff has worked on 3+ 
different production sites; though the setting of the 
stacksize to 128K was WAG.  It might be possible to 
still overflow the stacksize, though in all the sites 
using this change are no longer having problems.
I've spoken with Fred about this on a few occassions...
Thanks,
Andrew

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 17:07

Message:
Logged In: YES 
user_id=21627

I have now backported the 2.3 FreeBSD RECURSION_LIMIT code
to 2.2 as 2.77.6.2 and to 2.1 as 2.55.2.1. Closing this
report as fixed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-14 21:12

Message:
Logged In: YES 
user_id=6380

Oops, Casey didn't speak for everyone. Reopened as a 2.1.4
task.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-14 20:04

Message:
Logged In: YES 
user_id=6380

Casey Duncan says he can live with it for 2.1.x, so I'm
closing this as Won't Fix.

----------------------------------------------------------------------

Comment By: Andrew Sawyers (zc_andrew)
Date: 2002-05-13 19:34

Message:
Logged In: YES 
user_id=538986

Yes, I definately think it's useful to have the change in 
the 2.1.x branches; specifically anyone running Zope could 
be exposed to this bug.
Thanks,
Andrew

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 16:53

Message:
Logged In: YES 
user_id=6380

It looks like a similar change has already been applied to
2.2 and beyond. Does that work for you? Do you think it
would be useful to backport this change to the Python 2.1.x
series?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=553736&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 16:10:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 08:10:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-599377 ] re searches don't work with 4-byte unico
Message-ID: <E19RCfS-0003rs-00@sc8-sf-web3.sourceforge.net>

Bugs item #599377, was opened at 2002-08-23 21:16
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599377&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jim Fulton (dcjim)
>Assigned to: Martin v. Löwis (loewis)
Summary: re searches don't work with 4-byte unico

Initial Comment:
For Python 2.2.1 or the CVS head, as of this posting, 
with Python configured for 4-byte unicode
(--enable-unicode=ucs4)
searches against unicode regular expressions that use 
characters above \xff don't seem to work.

Here's an example:

  invalid_xml_char = re.compile(u'[\ud800-\udfff]')
  invalid_xml_char.search(u'\ud800')

returns None, rather than a match.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 17:10

Message:
Logged In: YES 
user_id=21627

This is now fixed for Python 2.3, with _sre.c 2.89.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-26 18:53

Message:
Logged In: YES 
user_id=21627

Added a work-around in sre_compile 1.44 and 1.41.14.2: it
disables big charsets for UCS-4 builds.

I leave this report open, so that a proper fix can be designed.


----------------------------------------------------------------------

Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 18:49

Message:
Logged In: YES 
user_id=14463

I could reproduce this behaviour exactly. No idea what is
causing it, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599377&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 16:21:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 08:21:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19RCq8-0006dM-00@sc8-sf-web4.sourceforge.net>

Bugs item #749911, was opened at 2003-06-06 03:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dave Reed (dr2048)
Assigned to: Martin v. Löwis (loewis)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 17:21

Message:
Logged In: YES 
user_id=21627

I use gcc 3.2.2. I don't see the problem with -rpath as I
use GNU ld, not /usr/ccs/bin/ld. I don't see the problem
with rl_complete because I don't have readline. To fix this
problem, invoke 

crle -u -l <directory where libreadline.so is located>

DO READ THE MAN PAGE OF crle BEFORE INVOKING THIS COMMAND.

I have committed the change from -rpath to -R as

configure 1.406
configure.in 1.417

Closing this report as fixed.

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 16:16

Message:
Logged In: YES 
user_id=795169

The makefile patch and changing -rpath to -R got it to
compile, but
when I try to execute python I get:

python
ld.so.1: python: fatal: relocation error: file
./libpython2.3.so: symbol rl_complete: referenced symbol not
found
Killed

what version of gcc are you using to compile it on Solaris 9?

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 15:39

Message:
Logged In: YES 
user_id=795169

I found the rpath line in the Makefile and replaced it with -R
I can't seem to find the ld line in the Makefile.

I noticed that I actually did get a libpython2.3.so file
created even though
I got the errors, but I couldn't complete a make install
because of the errors

I'm trying again now with the -R line.

If you want to contact me via email at "dreed at
capital.edu", it might
be easier to work through these problems using email or IM
at some time
that we're both available. Thanks!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 15:14

Message:
Logged In: YES 
user_id=21627

Committed as Makefile.pre.in 1.131.

Can you please add -v to the linker line, and report how the
linker is being invoked?

Can you also try to replace -rpath with -R?

This very line works fine on my copy of Solaris 9, so I'm
uncertain what the problem is.

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 14:25

Message:
Logged In: YES 
user_id=795169

That gets past the first problem. Now during the initial
compile, I get:

c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib -L.
-lpython2.3 -lsocket -lnsl -lrt -ldl  -lpthread   -lm  
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


I can't find those flags in the Makefile to try removing one
of them.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:36

Message:
Logged In: YES 
user_id=21627

Please try the attached patch and report whether this solves
the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 16:23:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 08:23:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-745002 ] <> in attrs in sgmllib not handled
Message-ID: <E19RCsI-0006hv-00@sc8-sf-web4.sourceforge.net>

Bugs item #745002, was opened at 2003-05-28 18:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745002&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Samuel Bayer (sambayer)
Assigned to: Nobody/Anonymous (nobody)
Summary: <> in attrs in sgmllib not handled

Initial Comment:
Hi folks -

This bug is noted in the source code for sgmllib.py,
and it finally bit me. If you feed the SGMLParser class
text such as

<tag attr = "<attrtag> bar </attrtag>">foo</tag>

the <attrtag> will be processed as a tag, as well as
being recognized as part of the attribute. This is
because of the way the end index for the opening tag is
computed.

As far as I can tell from the HTML 4.01 specification,
this is legal. The case I encountered was in a value of
an "onmouseover" attribute, which was a Javascript call
which contained HTML text as one of its arguments.

The problem is in SGMLParser.parse_starttag, which
attempts to compute the end of the opening tag with a
simple regexp [<>], and uses this index even when the
attributes have passed it. There's no real need to
check this regexp in advance, as far as I can tell.
I've attached my proposed modification of
SGMLParser.parse_starttag; I've tested this change in
2.2.1, but there are no relevant differences between
2.2.1 and the head of the CVS tree for this method. No
guarantees of correctness, but it works on the examples
I've tested it on.

Cheers -
Sam Bayer

================================

w_endbracket = re.compile("\s*[<>]")

class SGMLParser:
    # Internal -- handle starttag, return length or -1
if not terminated
    def parse_starttag(self, i):
        self.__starttag_text = None
        start_pos = i
        rawdata = self.rawdata
        if shorttagopen.match(rawdata, i):
            # SGML shorthand: <tag/data/ == <tag>data</tag>
            # XXX Can data contain &... (entity or char
refs)?
            # XXX Can data contain < or > (tag characters)?
            # XXX Can there be whitespace before the
first /?
            match = shorttag.match(rawdata, i)
            if not match:
                return -1
            tag, data = match.group(1, 2)
            self.__starttag_text = '<%s/' % tag
            tag = tag.lower()
            k = match.end(0)
            self.finish_shorttag(tag, data)
            self.__starttag_text =
rawdata[start_pos:match.end(1) + 1]
            return k
        
        # Now parse the data between i+1 and the end of
the tag into a tag and attrs
        attrs = []
        if rawdata[i:i+2] == '<>':
            # SGML shorthand: <> == <last open tag seen>
            k = i + 1
            tag = self.lasttag
        else:
            match = tagfind.match(rawdata, i+1)
            if not match:
                self.error('unexpected call to
parse_starttag')
            k = match.end(0)
            tag = rawdata[i+1:k].lower()
            self.lasttag = tag
        while w_endbracket.match(rawdata, k) is None:
            match = attrfind.match(rawdata, k)
            if not match: break
            attrname, rest, attrvalue = match.group(1,
2, 3)
            if not rest:
                attrvalue = attrname
            elif attrvalue[:1] == '\'' ==
attrvalue[-1:] or \
                 attrvalue[:1] == '"' == attrvalue[-1:]:
                attrvalue = attrvalue[1:-1]
            attrs.append((attrname.lower(), attrvalue))
            k = match.end(0)
        match = endbracket.search(rawdata, k)
        if not match:
            return -1
        j = match.start(0)   
        if rawdata[j] == '>':
            j = j+1
        self.__starttag_text = rawdata[start_pos:j]
        self.finish_starttag(tag, attrs)
        return j


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 17:23

Message:
Logged In: YES 
user_id=21627

I see. Can you please attach the fix as a context or unified
diff to this report? I can't follow your changes above at all.

----------------------------------------------------------------------

Comment By: Samuel Bayer (sambayer)
Date: 2003-06-14 15:35

Message:
Logged In: YES 
user_id=40146

I'm reporting it because

(a) it's not in the bug queue, and
(b) it's broken

The fact that it's noted as a bug in the source code doesn't
strike me as relevant. Especially since I attached a fix.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 09:58

Message:
Logged In: YES 
user_id=21627

If this is a known bug, why are you reporting it?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745002&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 16:36:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 08:36:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19RD4x-0004hN-00@sc8-sf-web3.sourceforge.net>

Bugs item #749911, was opened at 2003-06-05 21:21
Message generated for change (Comment added) made by dr2048
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dave Reed (dr2048)
Assigned to: Martin v. Löwis (loewis)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


----------------------------------------------------------------------

>Comment By: Dave Reed (dr2048)
Date: 2003-06-14 11:36

Message:
Logged In: YES 
user_id=795169

I don't have root access on this machine so I won't try the
crle command.

I just installed gcc 3.2 and am trying to get Python and
Postgresql compiled with it. readline is compiled with gcc
2.95 so I'll bet that's the problem. I'll recompile readline
or edit Modules/Setup or see if there's a configure option
to disable readline.

Thanks for all your help.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 11:21

Message:
Logged In: YES 
user_id=21627

I use gcc 3.2.2. I don't see the problem with -rpath as I
use GNU ld, not /usr/ccs/bin/ld. I don't see the problem
with rl_complete because I don't have readline. To fix this
problem, invoke 

crle -u -l <directory where libreadline.so is located>

DO READ THE MAN PAGE OF crle BEFORE INVOKING THIS COMMAND.

I have committed the change from -rpath to -R as

configure 1.406
configure.in 1.417

Closing this report as fixed.

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 10:16

Message:
Logged In: YES 
user_id=795169

The makefile patch and changing -rpath to -R got it to
compile, but
when I try to execute python I get:

python
ld.so.1: python: fatal: relocation error: file
./libpython2.3.so: symbol rl_complete: referenced symbol not
found
Killed

what version of gcc are you using to compile it on Solaris 9?

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 09:39

Message:
Logged In: YES 
user_id=795169

I found the rpath line in the Makefile and replaced it with -R
I can't seem to find the ld line in the Makefile.

I noticed that I actually did get a libpython2.3.so file
created even though
I got the errors, but I couldn't complete a make install
because of the errors

I'm trying again now with the -R line.

If you want to contact me via email at "dreed at
capital.edu", it might
be easier to work through these problems using email or IM
at some time
that we're both available. Thanks!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 09:14

Message:
Logged In: YES 
user_id=21627

Committed as Makefile.pre.in 1.131.

Can you please add -v to the linker line, and report how the
linker is being invoked?

Can you also try to replace -rpath with -R?

This very line works fine on my copy of Solaris 9, so I'm
uncertain what the problem is.

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 08:25

Message:
Logged In: YES 
user_id=795169

That gets past the first problem. Now during the initial
compile, I get:

c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib -L.
-lpython2.3 -lsocket -lnsl -lrt -ldl  -lpthread   -lm  
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


I can't find those flags in the Makefile to try removing one
of them.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 02:36

Message:
Logged In: YES 
user_id=21627

Please try the attached patch and report whether this solves
the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 16:47:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 08:47:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-749911 ] --enable-shared fails on Solaris 9 with gcc-3.2.3
Message-ID: <E19RDF7-0006gz-00@sc8-sf-web1.sourceforge.net>

Bugs item #749911, was opened at 2003-06-06 03:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dave Reed (dr2048)
Assigned to: Martin v. Löwis (loewis)
Summary: --enable-shared fails on Solaris 9 with gcc-3.2.3

Initial Comment:
./confgiure --enable-shared
make
fails on Solaris 9 with gcc 3.2.3

        gcc -shared -o libpython2.3.so
Modules/getbuildinfo.o
        Parser/acceler.o Parser/grammar1.o
Parser/listnode.o
        Parser/node.o Parser/parser.o Parser/parsetok.o
        Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
        Parser/grammar.o Parser/pgen.o Parser/myreadline.o
        Parser/tokenizer.o Objects/abstract.o
Objects/boolobject.o
        Objects/bufferobject.o Objects/cellobject.o
        Objects/classobject.o Objects/cobject.o
        Objects/complexobject.o Objects/descrobject.o
        Objects/enumobject.o Objects/fileobject.o
        Objects/floatobject.o Objects/frameobject.o
        Objects/funcobject.o Objects/intobject.o
Objects/iterobject.o
        Objects/listobject.o Objects/longobject.o
Objects/dictobject.o
        Objects/methodobject.o Objects/moduleobject.o
Objects/object.o
        Objects/obmalloc.o Objects/rangeobject.o
Objects/sliceobject.o
        Objects/stringobject.o Objects/structseq.o
        Objects/tupleobject.o Objects/typeobject.o
        Objects/weakrefobject.o Objects/unicodeobject.o
        Objects/unicodectype.o Python/bltinmodule.o
        Python/exceptions.o Python/ceval.o Python/compile.o
        Python/codecs.o Python/errors.o Python/frozen.o
        Python/frozenmain.o Python/future.o
Python/getargs.o
        Python/getcompiler.o Python/getcopyright.o
Python/getmtime.o
        Python/getplatform.o Python/getversion.o
Python/graminit.o
        Python/import.o Python/importdl.o Python/marshal.o
        Python/modsupport.o Python/mystrtoul.o
Python/mysnprintf.o
        Python/pyfpe.o Python/pystate.o Python/pythonrun.o
        Python/structmember.o Python/symtable.o
Python/sysmodule.o
        Python/traceback.o Python/getopt.o
Python/dynload_shlib.o
        Python/thread.o Modules/config.o Modules/getpath.o
        Modules/main.o Modules/gcmodule.o 
Modules/threadmodule.o
        Modules/signalmodule.o  Modules/posixmodule.o
        Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o
        Modules/zipimport.o  Modules/symtablemodule.o
        Modules/xxsubtype.o -lsocket -lnsl -lrt -ldl 
-lpthread  -lm;
        \
fi
ld: warning: option -o appears more than once, first
setting taken
ln: libpython2.3.so and libpython2.3.so are identical
make: *** [libpython2.3.so] Error 2

running make again produces:
c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib
        -L. -lpython2.3 -lsocket -lnsl -lrt -ldl 
-lpthread   -lm
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 17:47

Message:
Logged In: YES 
user_id=21627

You'll lose your bet :-)

The problem is not that readline is compiled with gcc, but
that it is in a location where ld.so.1 does not look. You can
a) set LD_RUN_PATH
b) set LD_LIBRARY_PATH
c) add more -R options to the linker
d) build readline statically, and link the readline module
statically through Modules/Setup.

See ld.so.1(1)

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 17:36

Message:
Logged In: YES 
user_id=795169

I don't have root access on this machine so I won't try the
crle command.

I just installed gcc 3.2 and am trying to get Python and
Postgresql compiled with it. readline is compiled with gcc
2.95 so I'll bet that's the problem. I'll recompile readline
or edit Modules/Setup or see if there's a configure option
to disable readline.

Thanks for all your help.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 17:21

Message:
Logged In: YES 
user_id=21627

I use gcc 3.2.2. I don't see the problem with -rpath as I
use GNU ld, not /usr/ccs/bin/ld. I don't see the problem
with rl_complete because I don't have readline. To fix this
problem, invoke 

crle -u -l <directory where libreadline.so is located>

DO READ THE MAN PAGE OF crle BEFORE INVOKING THIS COMMAND.

I have committed the change from -rpath to -R as

configure 1.406
configure.in 1.417

Closing this report as fixed.

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 16:16

Message:
Logged In: YES 
user_id=795169

The makefile patch and changing -rpath to -R got it to
compile, but
when I try to execute python I get:

python
ld.so.1: python: fatal: relocation error: file
./libpython2.3.so: symbol rl_complete: referenced symbol not
found
Killed

what version of gcc are you using to compile it on Solaris 9?

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 15:39

Message:
Logged In: YES 
user_id=795169

I found the rpath line in the Makefile and replaced it with -R
I can't seem to find the ld line in the Makefile.

I noticed that I actually did get a libpython2.3.so file
created even though
I got the errors, but I couldn't complete a make install
because of the errors

I'm trying again now with the -R line.

If you want to contact me via email at "dreed at
capital.edu", it might
be easier to work through these problems using email or IM
at some time
that we're both available. Thanks!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 15:14

Message:
Logged In: YES 
user_id=21627

Committed as Makefile.pre.in 1.131.

Can you please add -v to the linker line, and report how the
linker is being invoked?

Can you also try to replace -rpath with -R?

This very line works fine on my copy of Solaris 9, so I'm
uncertain what the problem is.

----------------------------------------------------------------------

Comment By: Dave Reed (dr2048)
Date: 2003-06-14 14:25

Message:
Logged In: YES 
user_id=795169

That gets past the first problem. Now during the initial
compile, I get:

c++   -o python \
                Modules/python.o \
               
-Wl,-rpath,/home/faculty/dreed/pub/Python-2.3/lib -L.
-lpython2.3 -lsocket -lnsl -lrt -ldl  -lpthread   -lm  
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [python] Error 1


I can't find those flags in the Makefile to try removing one
of them.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:36

Message:
Logged In: YES 
user_id=21627

Please try the attached patch and report whether this solves
the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=749911&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 17:24:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 09:24:43 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-753600 ] why should += produce name binding?
Message-ID: <E19RDpb-0000GB-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #753600, was opened at 2003-06-13 00:16
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: why should += produce name binding?

Initial Comment:

Currently, in

def x():
     foo += 1

... 'foo' is a local variable. Why should it be?
If the semantics are changed so that augmented
assignment is not a name-binding operation,
then only broken code will be affected.

This would allow you to use simple things
like   'EventCount += 1' without having to
use 'global EventCount'. After all, I can do
'EventList.append(...)' without the global decl.

For another (better) example, see 
http://mail.python.org/pipermail/edu-sig/2001-June/001329.html

In the response to the above, the poster is referred
to PEP227 which lists 'assignment' as a name-binding
operation. There is no clear-cut implication that this
includes augmented assignment, and in the Python
ref manual, one can only infer this behaviour from
the statement that x += y is almost equivalent
to x = x+y, which is pretty weak. In any case, since
an augmented assignment to a name always requires the
a-priori existence of that name in
an accessible namespace,  IMHO it should not
produce a binding.


















----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 18:24

Message:
Logged In: YES 
user_id=21627

Can you please explain, in detail, what semantics you
propose for += if the variable does not refer to a mutable
object?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 18:08:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 10:08:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-751276 ] cPickle doesn't raise error, pickle does (recursiondepth)
Message-ID: <E19REWL-0007mS-00@sc8-sf-web2.sourceforge.net>

Bugs item #751276, was opened at 2003-06-09 13:13
Message generated for change (Comment added) made by irmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle doesn't raise error, pickle does (recursiondepth)

Initial Comment:
I have this object that causes a recursive call in the
__getattr__ method.

When I unpicke it using pickle, I get a runtimeerror
recursiondepth exceeded. When I unpickle it using
cPickle, everything appears to work -- no error is raised.
(tested on python 2.2.3 and 2.3b1)

The output of the attached python test file is:

***pickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
FAIL!!!  <exceptions.RuntimeError instance at
0x00951C68> maximum recursion depth exceeded
***cPickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
SUCCESS!!! name= myname


----------------------------------------------------------------------

>Comment By: Irmen de Jong (irmen)
Date: 2003-06-14 19:08

Message:
Logged In: YES 
user_id=129426

I fail to understand why this cannot be fixed. Is the
cPickle implementation that different from the pickle one?
In this particular case: it doesn't use __getattr__ the same
way as pickle does, apparently. 

Increasing sys.setrecursionlimit won't help because the
recursion is  infinite.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:23

Message:
Logged In: YES 
user_id=21627

This problem cannot be fixed. cPickle and pickle work
differently by nature; one is written in C, the other in
Python (as their names suggest).

You can try to sys.setrecursionlimit, to raise the nesting
level that pickle.py supports.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 20:19:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 12:19:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-751276 ] cPickle doesn't raise error, pickle does (recursiondepth)
Message-ID: <E19RGYq-0005i1-00@sc8-sf-web4.sourceforge.net>

Bugs item #751276, was opened at 2003-06-09 13:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470

Category: Python Library
Group: None
>Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle doesn't raise error, pickle does (recursiondepth)

Initial Comment:
I have this object that causes a recursive call in the
__getattr__ method.

When I unpicke it using pickle, I get a runtimeerror
recursiondepth exceeded. When I unpickle it using
cPickle, everything appears to work -- no error is raised.
(tested on python 2.2.3 and 2.3b1)

The output of the attached python test file is:

***pickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
FAIL!!!  <exceptions.RuntimeError instance at
0x00951C68> maximum recursion depth exceeded
***cPickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
SUCCESS!!! name= myname


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 21:19

Message:
Logged In: YES 
user_id=21627

I see. The problem occurs when trying to find __setstate__.
pickle.py uses getattr("setstate", None), which only masks
AttributeError, passing RuntimeError through. cPickle masks
all exceptions. It would be indeed possible to have one
match the other.

Reopening the report. Notice that there are dozens such
inconsistencies, so it will be a sisyphus job to fix them all.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2003-06-14 19:08

Message:
Logged In: YES 
user_id=129426

I fail to understand why this cannot be fixed. Is the
cPickle implementation that different from the pickle one?
In this particular case: it doesn't use __getattr__ the same
way as pickle does, apparently. 

Increasing sys.setrecursionlimit won't help because the
recursion is  infinite.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 16:23

Message:
Logged In: YES 
user_id=21627

This problem cannot be fixed. cPickle and pickle work
differently by nature; one is written in C, the other in
Python (as their names suggest).

You can try to sys.setrecursionlimit, to raise the nesting
level that pickle.py supports.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470


From noreply@sourceforge.net  Sat Jun 14 23:21:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 15:21:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-746895 ] socket.sendto(SOCK_DGRAM) very slow on OSX!
Message-ID: <E19RJPK-0002iW-00@sc8-sf-web4.sourceforge.net>

Bugs item #746895, was opened at 2003-06-01 02:21
Message generated for change (Comment added) made by mkangas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Kangas (mkangas)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.sendto(SOCK_DGRAM) very slow on OSX!

Initial Comment:
I'm trying to send UDP packets using socket.sendto().
With Python 2.2 on Linux, this works like a champ. On
Mac OS X, something's terribly wrong.

Time to send 100 UDP packets using test code + Python
2.2.1:
- Linux 2.4.18 (RedHat 8): 0.009 sec
- MacOS X 10.2.6: > 1 sec, sometimes > 2 sec.

I've tried the following Python builds on OS X, all
with the same results:
- Stock 2.2 build that comes with OS X 10.2
- 2.2.1 provided by Fink
- built-from-scratch 2.2.3: "./configure; make"

provided are sample programs in Python and C.
ktrace/kdump seem to indicate that both programs make
the same sequence of syscalls. the C program runs
blazingly fast on OS X, while the Python one seems to
stall on every call to socket.sendto().

why does socket.sendto() perform so poorly on OS X?

----------------- python sample ----------------
 
#
# UDP socket test: how fast can we write?
# (5/2003 kangas)
#
# time to run with python 2.2.1:
# - Linux 2.4.18:     0.009 sec
# - Mac OS x 10.2.6:  1.272 sec (!!!)

import socket, time, sys

PORT = 9999
DEST_ADDR = ("192.168.1.60", PORT)

def run():
    maxcount = 100
    data = "pingme pingme pingme pingme pingme..."
    dest = DEST_ADDR

    print "opening socket"
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    
    print "Sending %i packets" % maxcount
    t0 = time.time()
    for i in xrange(0, maxcount):
        s.sendto(data, dest)
    t1 = time.time() - t0
    print "%0.4f secs elapsed" % t1

    s.close()

if __name__=="__main__":
    run()
    

----------------- C sample ----------------

/*
 * UDP socket test: how fast can we write?
 * (5/2003 kangas)
 *
 * Tested on Mac OS X 10.2.6 and Linux 2.4
 */

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>

static const int MAXCOUNT = 100;
static const char DATA[] = "pingme pingme pingme pingme
pingme...";
    
int main(void) {
    int s, i, err;
    struct sockaddr_in serverAddr;

    bzero(&serverAddr, sizeof(serverAddr));
    serverAddr.sin_family = AF_INET;
    serverAddr.sin_port = htons(9999);
    
    inet_pton(AF_INET, "192.168.1.60",
&serverAddr.sin_addr);
    
    printf("opening socket\n");
    if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
	perror("socket");
	exit(1);
    }

    printf("sending %i packets\n", MAXCOUNT);
    for (i=0; i<MAXCOUNT; i++) {
	err = sendto(s, DATA, strlen(DATA), 0,
		     (struct sockaddr *)&serverAddr, sizeof(serverAddr));
	if (err < 0) {
	    perror("sendto");
	    break;
	}
	printf(".");
     };
    printf("\n");

    printf("closing...\n");
    close(s);
    printf("done!\n");
    return 0;
}


----------------------------------------------------------------------

>Comment By: Matt Kangas (mkangas)
Date: 2003-06-14 18:21

Message:
Logged In: YES 
user_id=234623

"otool -L" (similar to Linux's ldd) shows the following for
my freshly-built Python 2.2.3 interpreter:

drinkycrow:Python-2.2.3$ otool -L python.exe
python.exe:
        /usr/lib/libSystem.B.dylib (compatibility version
1.0.0, current version 63.0.0)
       
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 14.0.0)
       
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 462.0.0)
drinkycrow:Python-2.2.3$ ./python.exe
Python 2.2.3 (#2, Jun 14 2003, 17:58:35)
[GCC 3.1 20020420 (prerelease)] on darwin

--------------------------------------

I added the following CFLAGS line to my makefile:

CFLAGS = -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-no-cpp-precomp -framework System -framework CoreServices
-framework Foundation

These are, AFAIK, all of the relevant options used when
building _socket.so and python.exe. (See attached
"build_notes.txt" for full details)

------------------------------------------

How does the C test-case perform now? Slower than before,
but still an order of magnitude faster than the Python code!

drinkycrow:udp_test_py$ make clean; make
rm socktest
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-no-cpp-precomp -framework System-framework CoreServices
-framework Foundation    socktest.c   -o socktest
socktest.c: In function `main':
socktest.c:21: warning: implicit declaration of function `bzero'
socktest.c:25: warning: implicit declaration of function
`inet_pton'
socktest.c:30: warning: implicit declaration of function `exit'
socktest.c:35: warning: implicit declaration of function
`strlen'
socktest.c:46: warning: implicit declaration of function `close'
drinkycrow:udp_test_py$ time ./socktest
opening socket
sending 100 packets
....................................................................................................
closing...
done!

real    0m0.164s
user    0m0.030s
sys     0m0.040s

drinkycrow:udp_test_py$ otool -L socktest
socktest:
        /usr/lib/libSystem.B.dylib (compatibility version
1.0.0, current version 63.0.0)
       
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 14.0.0)
       
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 462.0.0)


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 02:55

Message:
Logged In: YES 
user_id=21627

Can you try to link your C program with the same libraries
that python is linked with, and compile it with the same
command line options that socketmodule is compiled with?

My first guess is that enabling pthreads may have an effect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 01:45:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 17:45:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-751758 ] ftplib.retrbinary fails when called from retrlines callback
Message-ID: <E19RLdy-0003io-00@sc8-sf-web3.sourceforge.net>

Bugs item #751758, was opened at 2003-06-10 01:51
Message generated for change (Comment added) made by sjones
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751758&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Long (christianmlong)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib.retrbinary fails when called from retrlines callback

Initial Comment:

Subject: ftplib.retrbinary() fails when called from
inside retrlines() callback function

I'm using ftplib to backup files from a Linux server to
a Windows 2000 worksation. 


Client:  
Windows 2000 Pro
ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on
Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit
(Intel)] on win32
Komodo IDE

Server:
ProFTP server (ProFTPd version 1.25) 
Mandrake Linux 9.0


Summary:

When I use it like this it works fine.

# Build a list of files that are on the remote server
f.retrlines('NLST', makeListOfFiles)

--then--
# Iterate over the list, retrieving each file
for remoteFileName in listOfFiles:
    --snip--
    f.retrbinary('RETR %s' % remoteFileName,
localFile.write)
    --snip--


But it fails if I try to do the retrieve directly in my
callback function.

def transferFile(listLine):
    --snip--
    f.retrbinary('RETR %s' % remoteFileName,
localFile.write)  <--fails here on first time through
    --snip--

# get list of files from server, adn transfer each file
as it gets listed
f.retrlines('LIST', transferFile)

--snip--
  File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
45, in ?
    f.retrlines('LIST', transferFile)
  File "C:\Python22\lib\ftplib.py", line 413, in retrlines
    callback(line)
  File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
36, in transferFile
    f.retrbinary('RETR mra.py', localFile.write)
--snip--
  File "C:\Python22\lib\ftplib.py", line 300, in makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python22\lib\ftplib.py", line 572, in parse227
    raise error_reply, resp
error_reply: 200 Type set to I.


It looks like the server is returning a 200 instead of
a 227 when retrbinary() is called inside a callback
function for retrlines().



Files:

2 Files are included:  a broken version and a version
that works

This One Is Broken -  retrbinary() called from inside a
callback function for retrlines().
===================================================
import ftplib
import os
import time

REMOTE_DIR = "/home/mydir"
LOCAL_DIR = "C:\My Documents"
TIME_FORMAT = "%y%m%d"    # YYMMDD, like 030522

def transferFile(listLine):
    # Strips the file name from a line of a
    # directory listing, and gets it from the
    # server.  Depends on filenames
    # with no embedded spaces or extra dots.
    if listLine.endswith('.py'):
        #Split file name on the dot
        splitFileName=remoteFileName.split('.')
        # Add a timestamp
        localFileName="%s_%s.%s" % (splitFileName[0],
                                   
time.strftime(TIME_FORMAT),
                                    splitFileName[1])
        # Open a local file for (over)writing, in
binary mode.
        # print os.path.join(LOCAL_DIR,localFileName)
       
localFile=file(os.path.join(LOCAL_DIR,localFileName), 'wb')
        print remoteFileName
        print localFile
        # Execute the FTP retrieve command, calling
        # the write() function of the local file
        # for each block retrieved from the FTP server
        # BUG: This should work, but I get the
following traceback
        f.retrbinary('RETR %s' % remoteFileName,
localFile.write)    #<--- Fails
                                                      
              #     Here

#        mra.py
#<open file 'D:\My
Documents\Work\IA\Miller\MRA\Dev\Backup of remote
files\mra_030610.py', mode 'wb' at 0x00886B70>
#Traceback (most recent call last):
#  File "C:\Program Files\ActiveState Komodo
2.3\callkomodo\kdb.py", line 430, in _do_start
#    self.kdb.run(code_ob, locals, locals)
#  File "C:\Python22\lib\bdb.py", line 349, in run
#    exec cmd in globals, locals
#  File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
45, in ?
#    f.retrlines('LIST', transferFile)
#  File "C:\Python22\lib\ftplib.py", line 413, in retrlines
#    callback(line)
#  File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
36, in transferFile
#    f.retrbinary('RETR mra.py', localFile.write)
#  File "C:\Python22\lib\ftplib.py", line 385, in
retrbinary
#    conn = self.transfercmd(cmd, rest)
#  File "C:\Python22\lib\ftplib.py", line 346, in
transfercmd
#    return self.ntransfercmd(cmd, rest)[0]
#  File "C:\Python22\lib\ftplib.py", line 322, in
ntransfercmd
#    host, port = self.makepasv()
#  File "C:\Python22\lib\ftplib.py", line 300, in makepasv
#    host, port = parse227(self.sendcmd('PASV'))
#  File "C:\Python22\lib\ftplib.py", line 572, in parse227
#    raise error_reply, resp
#error_reply: 200 Type set to I.

# The problem is that the self.sendcmd('PASV') call is
not getting a 227
# reply from the server.  Rather, it is getting a 200
reply, confirming
# that the type was set to I (Image).


        localFile.flush()
        localFile.close()

f=ftplib.FTP('server', 'user', 'password')
f.cwd(REMOTE_DIR)
# List directory contents, and call the transferFile
# function on each line in the listing
f.retrlines('LIST', transferFile)

f.close()




===================================================



This One Works - retlines() builds a list, and then
files are transferred by iterating over
that list and calling retrbinary() for each.
===================================================
import ftplib
import os
import time

REMOTE_DIR = "/home/mydir"
LOCAL_DIR = "C:\My Documents"
TIME_FORMAT = "%y%m%d"    # YYMMDD, like 030522

listOfFiles = []

def makeListOfFiles(remoteFileName):
    # Strips the file name from a line of a
    # directory listing, and gets file from the
    # server.  Depends on filenames
    # with no embedded spaces or extra dots.
    if remoteFileName.endswith('.py'):
        listOfFiles.append(remoteFileName)

f=ftplib.FTP('server', 'user', 'password')
f.cwd(REMOTE_DIR)
# List directory contents, and call the transferFile
# function on each line in the listing
f.retrlines('NLST', makeListOfFiles)
print listOfFiles

for remoteFileName in listOfFiles:
    #Split file name on the dot
    splitFileName=remoteFileName.split('.')
    # Add a timestamp
    localFileName="%s_%s.%s" % (splitFileName[0],
                                time.strftime(TIME_FORMAT),
                                splitFileName[1])
    # Open a local file for (over)writing, in binary mode.
    # print os.path.join(LOCAL_DIR,localFileName)
   
localFile=file(os.path.join(LOCAL_DIR,localFileName), 'wb')

    # Execute the FTP retrieve command, calling
    # the write() function of the local file
    # for each block retrieved from the FTP server
    f.retrbinary('RETR %s' % remoteFileName,
localFile.write)
    localFile.flush()
    localFile.close()

f.close()





===================================================

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-14 19:45

Message:
Logged In: YES 
user_id=589306

The problem seems to happen when you use a callback within a
function that was called as a callback. Here is a much
simpler case that demonstrates the problem:

-----------------------------
import ftplib
 
def transferFile(listLine):
    filename = listLine.split()[-1]
    if filename == 'README':
        # Note that retrlines uses a default
        # callback that just prints the file
        f.retrlines('RETR README') # <-- Fails
 
f=ftplib.FTP('ftp.python.org', 'ftp', 'anon@')
f.cwd('/pub/python')
f.retrlines('LIST', transferFile)
f.close()
-----------------------------

This fails with the following:

Traceback (most recent call last):
  File "ftptest.py", line 10, in ?
    f.retrlines('LIST', transferFile)
  File "/home/sjones/src/python/dist/src/Lib/ftplib.py",
line 407, in retrlines
    callback(line)
  File "ftptest.py", line 6, in transferFile
    f.retrlines('RETR README') # <-- Fails
  File "/home/sjones/src/python/dist/src/Lib/ftplib.py",
line 396, in retrlines
    conn = self.transfercmd(cmd)
  File "/home/sjones/src/python/dist/src/Lib/ftplib.py",
line 345, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "/home/sjones/src/python/dist/src/Lib/ftplib.py",
line 321, in ntransfercmd
    host, port = self.makepasv()
  File "/home/sjones/src/python/dist/src/Lib/ftplib.py",
line 299, in makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "/home/sjones/src/python/dist/src/Lib/ftplib.py",
line 566, in parse227
    raise error_reply, resp
ftplib.error_reply: 200 Type set to A.


Note this is with the current CVS version on Redhat 9.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751758&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 04:54:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 20:54:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-744051 ] sum() should be renamed
Message-ID: <E19RObB-0007xM-00@sc8-sf-web3.sourceforge.net>

Bugs item #744051, was opened at 2003-05-26 22:51
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744051&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: David Albert Torpey (dtorp)
Assigned to: Nobody/Anonymous (nobody)
Summary: sum() should be renamed

Initial Comment:
1. "sum" is a commonly used name for variables and 
functions at both the global and local levels.

2.  from Numeric import * (as recommended by Alex 
Martelli in Python in a Nutshell) will shadow the new 
builtin resulting in changed behavior for any functions 
using it.

In theory, namespaces make the problem irrelevant.  
In practice, it creates hard-to-find errors.  The conflict 
between __builtin__.open and os.open has been a 
small disaster.  To a lesser degree, __builtin__.pow 
and math.pow have a conflict.

It is not too late to fix this by choosing a less 
commonly used name:  summation, addall, 
addsequence, sigma, sumsequence, addit or anything 
that isn't already being used.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-14 20:54

Message:
Logged In: YES 
user_id=357491

I really don't see the name as being a problem.  No one from 
Numeric spoke up when this was being discussed on python-dev.  
If you grep the Lib/ directory from CVS the only instance of sum 
being used as a variable name is in Bastion.py and that is an 
instance attribute so it is accessed as self.sum .

Without getting a following from c.l.p to back this up this is not 
going to happen.  I am going to close this as "won't fix", but it 
can be opened again if you can prove the community wants a 
renaming.

----------------------------------------------------------------------

Comment By: Samuel Bronson (sbronson)
Date: 2003-05-27 10:51

Message:
Logged In: YES 
user_id=237753

The locals are not a big problem, as long as functions are a
reasonable size. Is sum really that common at the global level?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744051&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 04:56:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 20:56:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-751260 ] Thread in threading.py can only be started once
Message-ID: <E19ROcy-0001tp-00@sc8-sf-web1.sourceforge.net>

Bugs item #751260, was opened at 2003-06-09 03:16
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Schuenzel (yahoo_alive)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread in threading.py can only be started once

Initial Comment:
class Thread doesn't reset self.__started after run() has terminated, so one cannot reuse 
the thread class and run start() again.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-14 20:56

Message:
Logged In: YES 
user_id=357491

I agree with Tim here.  I don't see a need for this anyway.  Once 
a thread has terminated it is done, period.  Having to 
reinstantiate a class to run another thread is perfectly 
reasonable.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 15:54

Message:
Logged In: YES 
user_id=31435

It's true that Thread instances can't be restarted, but you 
haven't made a case for calling that "a bug".  Python's 
threading model is fashioned loosely on Java's, and, like 
Java's, limits thread instances to one invocation by design.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 05:28:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 14 Jun 2003 21:28:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-753711 ] Infinite Loop in RE
Message-ID: <E19RP88-0000GH-00@sc8-sf-web3.sourceforge.net>

Bugs item #753711, was opened at 2003-06-12 20:27
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470

Category: Regular Expressions
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Bogosian (mbogosian)
Assigned to: Fredrik Lundh (effbot)
Summary: Infinite Loop in RE

Initial Comment:
This *may* be similar to
<http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=439997>,
but I don't think the current behavior (infinite
loop/unbound execution) is correct.

Here's the python version:

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - 

#!/usr/bin/python

import re

pattern =
'^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,'

# This won't match (missing ',' at end
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

re.search(pattern, str, re.I)

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - 

When run, this script just pegs the CPU and hangs (I'm
running RedHat 8.0). Note: if I change the pattern
slightly it still doesn't work:

pattern = '^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*([^
=,]+\s*)+,'

It's not until the pattern actually matches that things
get better (with both the original and modified patterns):

# Pattern now matches (added a ',' at the end)
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP),'

I tried doing the same thing in Perl:

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - 

#!/usr/bin/perl

'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)' =~
'/UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,/i';

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - 

This of course runs just fine. Any ideas?

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-14 21:28

Message:
Logged In: YES 
user_id=357491

sjones is right about it taking exponential time.  A regex engine 
works with greedy quantifiers by sucking up all that it can and 
then trying the next part of the regex and continues until it fails 
or succeeds.  If it fails, though, it backtracks one regex character, 
gives up a character it claimed, and tries again.  It does this for a 
long time.

How long did you wait for the regex to complete?  I bet if you left 
it for a *very* long time it would complete.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 14:42

Message:
Logged In: YES 
user_id=589306

If you change your regex and sample data to the following
simpler forms, you get the same problem:

pattern = '(\S+\s*)+,'
str = 'CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

If you remove some letters from str, the search does finish
but it takes several seconds. I believe the problem is that
your regex takes exponential time to execute based on the
length of str. Here is a recent python-dev post that talks
about the problem:

http://mail.python.org/pipermail/python-dev/2003-May/035916.html

The link you provided in the bug report talks about this as
well. You can also do a web search for "regular expression
exponential" to see more information. I believe that any
regex engine (that has similar features to Python's engine)
will have some regular expressions that take exponential
time or space. Perl has some cases as well (search for
"exponential" in perldoc perlre).  This is just how regular
expressions are and IMHO does not indicate a bug in Python.

As far as how to fix the regular expression, I can't say.
I'm sure there is a way to "rephrase" what you want to get
it to work. Maybe try asking in the comp.lang.python newsgroup.

Good luck!


----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 05:15

Message:
Logged In: YES 
user_id=589306

If you change your regex and sample data to the following
simpler forms, you get the same problem:

pattern = '(\S+\s*)+,'
str = 'CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

If you remove some letters from str, the search does finish
but it takes several seconds. I believe the problem is that
your regex takes exponential time to execute based on the
length of str. Here is a recent python-dev post that talks
about the problem:

http://mail.python.org/pipermail/python-dev/2003-May/035916.html

The link you provided in the bug report talks about this as
well. You can also do a web search for "regular expression
exponential" to see more information. I believe that any
regex engine (that has similar features to Python's engine)
will have some regular expressions that take exponential
time or space. Perl has some cases as well (search for
"exponential" in perldoc perlre).  This is just how regular
expressions are and IMHO does not indicate a bug in Python.

As far as how to fix the regular expression, I can't say.
I'm sure there is a way to "rephrase" what you want to get
it to work. Maybe try asking in the comp.lang.python newsgroup.

Good luck!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 08:48:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 00:48:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-752221 ] print in __getattr__ causes seg fault
Message-ID: <E19RSG1-0004LA-00@sc8-sf-web3.sourceforge.net>

Bugs item #752221, was opened at 2003-06-10 14:58
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher K. Paulicka (paulicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: print in __getattr__ causes seg fault

Initial Comment:
[~/site-packages/WorldPlay/] paulicka@Sliver-14:56:32
$ python
Python 2.3a2+ (#4, Mar  2 2003, 17:13:46) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class A:
...     def __getattr__(self,name):
...             return 3
... 
>>> a=A()
>>> a.c
3
>>> class B:
...     def __getattr__(self,name):
...             print self, name
...             return 3
... 
>>> b=B()
>>> b.c
Segmentation fault
[~/site-packages/WorldPlay/] paulicka@Sliver-14:57:14
$ 

$ uname -a
Darwin Sliver.local. 6.6 Darwin Kernel Version 6.6: Thu 
May  1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/
RELEASE_PPC  Power Macintosh powerpc


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 00:48

Message:
Logged In: YES 
user_id=357491

I get a RuntimeError under OS X just like sjones but only with a 
classic class.  What else that is interesting is that if I just type in 
the instance name and hit enter it also has the RuntimeError.

I checked the bytecode and both are the same so there isn't 
some funky difference there.  Must be some way that classic 
classes handle self compared to new-style and how __getattr__ 
is dealt with.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 18:57

Message:
Logged In: YES 
user_id=589306

I tried running with current CVS and got the following
results on Linux:

Python 2.3b1+ (#3, Jun 13 2003, 07:56:14)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> class A:
...     def __getattr__(self, name):
...             return 3
...
>>> a = A()
>>> a.c
3
>>> class B:
...     def __getattr__(self, name):
...             print self, name
...             return 3
...
>>> b = B()
>>> b.c
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
[Repeats lots of times]
  File "<stdin>", line 3, in __getattr__
RuntimeError: maximum recursion depth exceeded
>>> class C:
...     def __init__(self):
...             self.x = 5
...     def __getattr__(self, name):
...             print self.x
...             return 3
...
>>> c = C()
>>> c.c
5
3

$ uname -a
Linux localhost 2.4.20-18.9 #1 Thu May 29 06:54:41 EDT 2003
i686 athlon i386 GNU/Linux

-------------------------------------------------
Note that I can print things from getattr, it is just
printing self that gets me in trouble.


----------------------------------------------------------------------

Comment By: Christopher K. Paulicka (paulicka)
Date: 2003-06-13 17:20

Message:
Logged In: YES 
user_id=45461

Actually, I can't use the beta, because I used the MacOS Kitchen 
Sink combination of Framework Python, Pygame and PyOpenGL.

I tried building from the CVS repository, but had problems, so 
just moved on...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 20:09

Message:
Logged In: YES 
user_id=80475

Can you try this one on the beta release to see if it is still a 
problem.  I cannot reproduce the segfault on a Windows 
build.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 09:00:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 01:00:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-753451 ] classmethod abuse --> SystemError
Message-ID: <E19RSR1-0005lv-00@sc8-sf-web2.sourceforge.net>

Bugs item #753451, was opened at 2003-06-12 11:09
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753451&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
>Summary: classmethod abuse --> SystemError

Initial Comment:
This is obviously a silly thing to do:

>>> classmethod(1).__get__(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: ../Objects/classobject.c:2102: bad
argument to internal function

but I think that's still a bug.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:00

Message:
Logged In: YES 
user_id=357491

Well, couldn't we check if the argument is a non-data descriptor 
at least?  Since classmethod only works with new-style we know 
the method will be a non-data descriptor.  That should prevent 
allowing arguments like 1 being allowed through.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753451&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 09:19:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 01:19:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E19RSjN-00082C-00@sc8-sf-web4.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 09:44:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 01:44:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E19RT7e-0008J8-00@sc8-sf-web1.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 10:32
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2003-06-15 08:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 08:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 12:22:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 04:22:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-751260 ] Thread in threading.py can only be started once
Message-ID: <E19RVb6-0006EP-00@sc8-sf-web4.sourceforge.net>

Bugs item #751260, was opened at 2003-06-09 12:16
Message generated for change (Comment added) made by yahoo_alive
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Schuenzel (yahoo_alive)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread in threading.py can only be started once

Initial Comment:
class Thread doesn't reset self.__started after run() has terminated, so one cannot reuse 
the thread class and run start() again.


----------------------------------------------------------------------

>Comment By: Lars Schuenzel (yahoo_alive)
Date: 2003-06-15 13:22

Message:
Logged In: YES 
user_id=647640

Maybe I should state some reasons for adding this functionality:

Imagine, you wish your thread to do some background work
while normal execution goes on (e.g. parsing a website).
It's a small task doing execatly the same job over an over.
If that will happen often, the overhead of creating a new
object might be too hight, especially if your object holds a
lot of data. And sometime the garbage collector will kick in...
If you want to write a really small class build from several
mix-in classes and Thread that only seldom needs to run
start(), you could use all member functions and variables.
Nice and neat.
And last but not least it wouldn't break compatibility.
Programs using threadying.py needn't change a single line.
There are more pro's and con's to this. To my opinion it is
more a matter of coding style and design. I do not know
Java's threads but I agree now with time_one: maybe this
issue is more a feature request than a bug report.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 05:56

Message:
Logged In: YES 
user_id=357491

I agree with Tim here.  I don't see a need for this anyway.  Once 
a thread has terminated it is done, period.  Having to 
reinstantiate a class to run another thread is perfectly 
reasonable.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-10 00:54

Message:
Logged In: YES 
user_id=31435

It's true that Thread instances can't be restarted, but you 
haven't made a case for calling that "a bug".  Python's 
threading model is fashioned loosely on Java's, and, like 
Java's, limits thread instances to one invocation by design.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 13:35:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 05:35:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-751260 ] Thread in threading.py can only be started once
Message-ID: <E19RWjJ-0006X4-00@sc8-sf-web2.sourceforge.net>

Bugs item #751260, was opened at 2003-06-09 20:16
Message generated for change (Comment added) made by spiv
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Schuenzel (yahoo_alive)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread in threading.py can only be started once

Initial Comment:
class Thread doesn't reset self.__started after run() has terminated, so one cannot reuse 
the thread class and run start() again.


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2003-06-15 22:35

Message:
Logged In: YES 
user_id=50945

> Imagine, you wish your thread to do some background work
> while normal execution goes on (e.g. parsing a website).
> It's a small task doing execatly the same job over an over.
> If that will happen often, the overhead of creating a new
> object might be too hight, especially if your object holds a
> lot of data. And sometime the garbage collector will kick
in...

Asking for this feature on the basis of performance sounds
bogus to me.  I'd expect creating and finishing threads to
be more expensive than the usual way to do this, which is to
have the one thread process chunks of work delivered via a
Queue.Queue (as opposed to creating a short-lived thread for
each chunk of work).

If you really think performance is the issue here, do some
benchmarking of the way things work at the moment versus
your proposal, versus long-lived threads using Queues.  If
you have some compelling numbers, then you'll have more
chance of convincing people this needs to be done.  (But my
guess is you'll find long-lived threads are more efficient.)


----------------------------------------------------------------------

Comment By: Lars Schuenzel (yahoo_alive)
Date: 2003-06-15 21:22

Message:
Logged In: YES 
user_id=647640

Maybe I should state some reasons for adding this functionality:

Imagine, you wish your thread to do some background work
while normal execution goes on (e.g. parsing a website).
It's a small task doing execatly the same job over an over.
If that will happen often, the overhead of creating a new
object might be too hight, especially if your object holds a
lot of data. And sometime the garbage collector will kick in...
If you want to write a really small class build from several
mix-in classes and Thread that only seldom needs to run
start(), you could use all member functions and variables.
Nice and neat.
And last but not least it wouldn't break compatibility.
Programs using threadying.py needn't change a single line.
There are more pro's and con's to this. To my opinion it is
more a matter of coding style and design. I do not know
Java's threads but I agree now with time_one: maybe this
issue is more a feature request than a bug report.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 13:56

Message:
Logged In: YES 
user_id=357491

I agree with Tim here.  I don't see a need for this anyway.  Once 
a thread has terminated it is done, period.  Having to 
reinstantiate a class to run another thread is perfectly 
reasonable.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-10 08:54

Message:
Logged In: YES 
user_id=31435

It's true that Thread instances can't be restarted, but you 
haven't made a case for calling that "a bug".  Python's 
threading model is fashioned loosely on Java's, and, like 
Java's, limits thread instances to one invocation by design.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 13:40:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 05:40:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution
Message-ID: <E19RWnt-0005VQ-00@sc8-sf-web3.sourceforge.net>

Bugs item #474836, was opened at 2001-10-25 13:22
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Tix not included in windows distribution

Initial Comment:
Although there is a Tix.py available, there is no Tix
support in the precomiled 
Python-distribution for windows. So 

import Tix

works fine, but

root = Tix.Tk()

results in 

TclError: package not found. 

It is possible to circumvent this problem by installing
a regular Tcl/Tk distribution (e.g. in
c:\programme\tcl) and installing Tix in the regular
Tcl-path (i.e. tcl\lib).

Mathias

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-15 14:40

Message:
Logged In: YES 
user_id=21627

I found that the instructions need slight modification: In step 
2, use tk...\mkd.bat for mkdir. Apart from that, these 
instructions work fine for me, now. I have made a binary 
release of tix8.1 for Python 2.3 at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/tix8.1.zip

The tix8184.dll goes to DLLs, the tix8.1 subdirectory goes to 
tcl. It differs from the standard tix8.1 subdirectory only in 
fixing the path to the DLLs directory.

To test whether this works, execute Demo/tix/tixwidgets.py.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-26 12:22

Message:
Logged In: YES 
user_id=21627

I still think Python should include Tix. Here are some 
instructions on how to make Tix 8.1.4 work:

1. Unpack as a sibling of tcl8.4.1 and tk8.4.1
2. Edit win\common.mk, to set the following variables
    TCL_VER=8.4
    INSTALLDIR=<directory to pick up installation from later>
    MKDIR=mkdir
3. Edit win\makefile.vc, to set the following variables
    TOOLS32=<directory of cl>
    TOOLS32_rc=<directory of rc.exe>
4. Edit win\tk\pkgindex.tcl, to replace
    lappend dirs ../../Dlls
    with
    lappend dirs [file join [file dirname [info nameofexe]] Dlls]
5. nmake -f makefile.vc
6. nmake -f makefile.vc install
7. Copy INSTALLDIR\bin\tix8184.dll to <python>\DLLs
8. Optionally copy tix8184.lib somewhere
9. copy INSTALLDIR\lib\tix8.1 into <python>\tcl

With these instructions, invoking t.tk.eval("package require 
Tix") succeeds. For some reason, Tix won't still find any of 
the commands; I'll investigate this later.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-12-11 10:14

Message:
Logged In: YES 
user_id=33229

My you're courageous - going with a version of Tcl that doesn't
even pass its own tests :-) Been there, seen it, done it ....

8.1.4 will be out this week, which compiles with 8.4 but I don't
expect it to "support" 8.4 for a while yet (they added more problems
in 8.4.1). 8.3.5 is definitely "supported".

Check back with me before 2.3 goes into beta and I'll do
another minor release if necessary. Maybe Tk will test clean then.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-20 02:36

Message:
Logged In: YES 
user_id=31435

Parents shouldn't disagree in front of their children <wink>.

Not all the Tcl or Tk tests (their tests, not ours) passed 
when I built 8.4.1, but I couldn't (and can't) make time to 
dig into that, and all the Python stuff I tried worked fine.  So 
I don't fear 8.4, and am inclined to accept Martin's 
assurance that 8.4 is best for Python.

We intend to put out the first 2.3 Python alpha by the end 
of the year, and my bet is it won't be a minute before that.  
If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final 
release out well before then.  Yes?  No?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-11-19 23:12

Message:
Logged In: YES 
user_id=21627

I think the recommendation cannot apply to Python; I'm very
much in favour of releasing Python 2.3 with Tk 8.4.x. 

So the question then is whether Python 2.3 should include
Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can
be expected.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-19 20:10

Message:
Logged In: YES 
user_id=33229

Look on http://tix.sourceforge.net/download.shtml for
Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite,
but there are still issues with Tk 8.4 and it has not been
widely tested with yet with 8.4.1, so we still recommend 8.3.5.
(Tcl major releases often aren't stable until patch .3 or so.)

If you have any problems let me know directly by email
and I'll try and help.








----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-18 17:35

Message:
Logged In: YES 
user_id=31435

Does Tix 8.1.3 play with Tcl/Tk 8.4.1?  The 2.3. Windows 
distro is set up to include the latter now.  The 
win\common.mak file from Tix 8.1.3 doesn't have a section 
for Tcl/Tk 8.4, though.

There appear to be several reasons Tix won't compile on 
my box anyway without fiddling the Tix makefiles (e.g., my 
VC doesn't live in \DevStudio), so before spending more 
time on that I'd like to know whether it's doomed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-07 15:52

Message:
Logged In: YES 
user_id=6380

I support this. Tim, I know you're not a big Tk user (to say
the least). I'll offer to help in person.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 08:30

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 06:34

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 04:34

Message:
Logged In: YES 
user_id=6380

Yes, for 2.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 02:48

Message:
Logged In: YES 
user_id=31435

Guido, do you want me to spend time on this?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2002-03-07 14:38

Message:
Logged In: YES 
user_id=361926

Thanks.

Mathias

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-25 13:57

Message:
Logged In: YES 
user_id=21627

The zip file is slightly too large for SF, so it is now at

http://www.informatik.hu-
berlin.de/~loewis/python/tix813win.zip

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-25 13:56

Message:
Logged In: YES 
user_id=21627

Building Tix from sources is non-trivial, and I could not 
find any recent Windows binary distribution (based on Tix 
8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, 
as a drop-in into the Python binary distribution.

Compared to the original distribution, only tix8.1
\pkgIndex.tcl required tweaking, to tell it that 
tix8183.dll can be found in the DLLs subdirectory.

Also, unless TIX_LIBRARY is set, the Tix tcl files *must* 
live in tcl\tix8.1, since tix8183.dll will look in 
TCL_LIBRARY\..\tix<TIX_VERSION> (among other locations).

If a major Tcl release happens before Python 2.3 is 
released (and it is then still desirable to distribute 
Python with Tix), these binaries need to be regenerated.

Would these instructions (unpack zip file into 
distribution tree) be precise enough to allow 
incorporation into the windows installer?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2001-10-29 12:53

Message:
Logged In: YES 
user_id=361926

As mentioned in the mail above (by me, Mathias), Tix is a
package belonging to Tcl/Tk (to be found on sourceforge:
tix.sourceforge.net, or via the Python home page - tkinter
link). 

Everything needed can be found there, just read about it
(and dont forget about the winking,  eyes might be getting
dry)

Mathias



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-25 20:26

Message:
Logged In: YES 
user_id=31435

I don't know anything about Tix, so if somebody wants this 
in the Windows installer, they're going to have to explain 
exactly (by which I mean exactly <0.5 wink>) what's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 14:14:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 06:14:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-739909 ] IMAP4_SSL broken
Message-ID: <E19RXKe-0000vM-00@sc8-sf-web4.sourceforge.net>

Bugs item #739909, was opened at 2003-05-19 11:46
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739909&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: IMAP4_SSL broken

Initial Comment:
Python 2.3b1 (#1, May  6 2003, 10:52:33)
[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import imaplib
>>> imaplib.IMAP4_SSL('mailserver')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/imaplib.py", line 1071, in
__init__
    IMAP4.__init__(self, host, port)
  File "/usr/lib/python2.3/imaplib.py", line 156, in
__init__
    self.open(host, port)
  File "/usr/lib/python2.3/imaplib.py", line 1084, in open
    self.sslobj = socket.ssl(self.sock, self.keyfile,
self.certfile)
TypeError: ssl() argument 1 must be _socket.socket, not
_socketobject

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-15 09:14

Message:
Logged In: YES 
user_id=33168

Fixed by Lib/socket.py 1.42 when fixing #754447.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-21 18:37

Message:
Logged In: YES 
user_id=33168

Raising priority, there may be other problems similar to
this.  Not sure who should look at this though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739909&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 14:15:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 06:15:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-752221 ] print in __getattr__ causes seg fault
Message-ID: <E19RXMJ-00010O-00@sc8-sf-web1.sourceforge.net>

Bugs item #752221, was opened at 2003-06-10 16:58
Message generated for change (Comment added) made by sjones
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher K. Paulicka (paulicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: print in __getattr__ causes seg fault

Initial Comment:
[~/site-packages/WorldPlay/] paulicka@Sliver-14:56:32
$ python
Python 2.3a2+ (#4, Mar  2 2003, 17:13:46) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class A:
...     def __getattr__(self,name):
...             return 3
... 
>>> a=A()
>>> a.c
3
>>> class B:
...     def __getattr__(self,name):
...             print self, name
...             return 3
... 
>>> b=B()
>>> b.c
Segmentation fault
[~/site-packages/WorldPlay/] paulicka@Sliver-14:57:14
$ 

$ uname -a
Darwin Sliver.local. 6.6 Darwin Kernel Version 6.6: Thu 
May  1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/
RELEASE_PPC  Power Macintosh powerpc


----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-15 08:15

Message:
Logged In: YES 
user_id=589306

I did some research and thinking on this problem, and here
is what I think is happening.

1. When you print self inside __getattr__, Python calls
repr(self) to figure out how to print that.
2. repr(self) attempts to call self.__repr__().
3. Since you didn't define __repr__ for this class,
__getattr__ is called to look up the name.
4. __getattr__ attempts to print self again, and you are now
in an infinite loop.

For more information, do a Google Groups search for "Obscure
__getattr__ behavior" which should bring you to the thread
at http://tinyurl.com/ecsh (hope that works, heh). It even
mentions the difference bcannon mentioned between old and
new style classes.

You could solve the problem by defining your own __repr__
(and __str__ for similar reasons). Or you can raise
AttributeError in __getattr__ if name is __repr__ or __str__
so that Python reverts back to defaults for these functions.

Here is a way to write your class so that it does what you want:

>>> class B:
...     def __getattr__(self, name):
...             if name == '__repr__' or name == '__str__':
...                     raise AttributeError
...             print self, name
...             return 3
...
>>> b = B()
>>> b.c
<__main__.B instance at 0x81c785c> c
3


I'm leaning toward the opinion that the infinite loop
behavior is not a bug in Python. Even though the result
wasn't expected, Python was doing exactly as told.

However, the Segmentation Fault you got on your system is
probably a bug. That seems related to your OS / build of
Python though. Can anyone duplicate the segfault?

Maybe Python isn't catching the infinite recursion fast
enough and your stack is overflowing (just a wild guess).
Try running some code like this and see if you get a
RuntimeError or a segfault:

def f():
    f()

Then call f() to see what error you get.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 02:48

Message:
Logged In: YES 
user_id=357491

I get a RuntimeError under OS X just like sjones but only with a 
classic class.  What else that is interesting is that if I just type in 
the instance name and hit enter it also has the RuntimeError.

I checked the bytecode and both are the same so there isn't 
some funky difference there.  Must be some way that classic 
classes handle self compared to new-style and how __getattr__ 
is dealt with.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 20:57

Message:
Logged In: YES 
user_id=589306

I tried running with current CVS and got the following
results on Linux:

Python 2.3b1+ (#3, Jun 13 2003, 07:56:14)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> class A:
...     def __getattr__(self, name):
...             return 3
...
>>> a = A()
>>> a.c
3
>>> class B:
...     def __getattr__(self, name):
...             print self, name
...             return 3
...
>>> b = B()
>>> b.c
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
[Repeats lots of times]
  File "<stdin>", line 3, in __getattr__
RuntimeError: maximum recursion depth exceeded
>>> class C:
...     def __init__(self):
...             self.x = 5
...     def __getattr__(self, name):
...             print self.x
...             return 3
...
>>> c = C()
>>> c.c
5
3

$ uname -a
Linux localhost 2.4.20-18.9 #1 Thu May 29 06:54:41 EDT 2003
i686 athlon i386 GNU/Linux

-------------------------------------------------
Note that I can print things from getattr, it is just
printing self that gets me in trouble.


----------------------------------------------------------------------

Comment By: Christopher K. Paulicka (paulicka)
Date: 2003-06-13 19:20

Message:
Logged In: YES 
user_id=45461

Actually, I can't use the beta, because I used the MacOS Kitchen 
Sink combination of Framework Python, Pygame and PyOpenGL.

I tried building from the CVS repository, but had problems, so 
just moved on...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 22:09

Message:
Logged In: YES 
user_id=80475

Can you try this one on the beta release to see if it is still a 
problem.  I cannot reproduce the segfault on a Windows 
build.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 14:26:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 06:26:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-754870 ] SSL crash interpreter on error
Message-ID: <E19RXWw-0006hg-00@sc8-sf-web3.sourceforge.net>

Bugs item #754870, was opened at 2003-06-15 09:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754870&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: SSL crash interpreter on error

Initial Comment:
When testing bug 739909, I provoked this bug.  To
reproduce:

  # ./python # need to be root to listen on privileged port
  >>> from socket import *
  >>> s = socket(AF_INET, SOCK_STREAM)
  >>> s.bind(('', 993))
  >>> s.listen(5)
  >>> s.accept()

  # now go to another window and do:

  $ ./python
  >>> import imaplib
  >>> imaplib.IMAP4_SSL('localhost')

  # this will wait for the first (root) interpreter
  # exit from first/root interpreter and SSL will crash

There is a stack trace below.

The problem is that in PySSL_SetError(), there is an
assumption that obj->Socket exists, but it doesn't in
this case.

The attached patch  fixes the crash, but I'm not
certain it is correct.

#0  0x4046eaba in PySSL_SetError (obj=0x81e0718, ret=-1)
    at /home/neal/build/python/2_3/Modules/_ssl.c:118
#1  0x4046efed in newPySSLObject (Sock=0x4013f9c8,
key_file=0x0, cert_file=0x0)
    at /home/neal/build/python/2_3/Modules/_ssl.c:259
#2  0x4046f181 in PySocket_ssl (self=0x0, args=0x403e4df4)
    at /home/neal/build/python/2_3/Modules/_ssl.c:296


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754870&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 20:26:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 12:26:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-754870 ] SSL crash interpreter on error
Message-ID: <E19Rd9F-0003pH-00@sc8-sf-web1.sourceforge.net>

Bugs item #754870, was opened at 2003-06-15 15:26
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754870&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: SSL crash interpreter on error

Initial Comment:
When testing bug 739909, I provoked this bug.  To
reproduce:

  # ./python # need to be root to listen on privileged port
  >>> from socket import *
  >>> s = socket(AF_INET, SOCK_STREAM)
  >>> s.bind(('', 993))
  >>> s.listen(5)
  >>> s.accept()

  # now go to another window and do:

  $ ./python
  >>> import imaplib
  >>> imaplib.IMAP4_SSL('localhost')

  # this will wait for the first (root) interpreter
  # exit from first/root interpreter and SSL will crash

There is a stack trace below.

The problem is that in PySSL_SetError(), there is an
assumption that obj->Socket exists, but it doesn't in
this case.

The attached patch  fixes the crash, but I'm not
certain it is correct.

#0  0x4046eaba in PySSL_SetError (obj=0x81e0718, ret=-1)
    at /home/neal/build/python/2_3/Modules/_ssl.c:118
#1  0x4046efed in newPySSLObject (Sock=0x4013f9c8,
key_file=0x0, cert_file=0x0)
    at /home/neal/build/python/2_3/Modules/_ssl.c:259
#2  0x4046f181 in PySocket_ssl (self=0x0, args=0x403e4df4)
    at /home/neal/build/python/2_3/Modules/_ssl.c:296


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-06-15 21:26

Message:
Logged In: YES 
user_id=38388

Sorry, no time for this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754870&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 22:03:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 14:03:20 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-751260 ] Thread in threading.py can only be started once
Message-ID: <E19Reem-0007Hr-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #751260, was opened at 2003-06-09 03:16
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=751260&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Schuenzel (yahoo_alive)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread in threading.py can only be started once

Initial Comment:
class Thread doesn't reset self.__started after run() has terminated, so one cannot reuse 
the thread class and run start() again.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 14:03

Message:
Logged In: YES 
user_id=357491

What Andrew said.  =)  Although I realize if you did already know 
how to make this work you would have made this a patch.

I am reclassifying this as a feature request instead of a bug since 
the code isn't broken; you just want it to do something that it is 
not designed to do at the moment.

----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2003-06-15 05:35

Message:
Logged In: YES 
user_id=50945

> Imagine, you wish your thread to do some background work
> while normal execution goes on (e.g. parsing a website).
> It's a small task doing execatly the same job over an over.
> If that will happen often, the overhead of creating a new
> object might be too hight, especially if your object holds a
> lot of data. And sometime the garbage collector will kick
in...

Asking for this feature on the basis of performance sounds
bogus to me.  I'd expect creating and finishing threads to
be more expensive than the usual way to do this, which is to
have the one thread process chunks of work delivered via a
Queue.Queue (as opposed to creating a short-lived thread for
each chunk of work).

If you really think performance is the issue here, do some
benchmarking of the way things work at the moment versus
your proposal, versus long-lived threads using Queues.  If
you have some compelling numbers, then you'll have more
chance of convincing people this needs to be done.  (But my
guess is you'll find long-lived threads are more efficient.)


----------------------------------------------------------------------

Comment By: Lars Schuenzel (yahoo_alive)
Date: 2003-06-15 04:22

Message:
Logged In: YES 
user_id=647640

Maybe I should state some reasons for adding this functionality:

Imagine, you wish your thread to do some background work
while normal execution goes on (e.g. parsing a website).
It's a small task doing execatly the same job over an over.
If that will happen often, the overhead of creating a new
object might be too hight, especially if your object holds a
lot of data. And sometime the garbage collector will kick in...
If you want to write a really small class build from several
mix-in classes and Thread that only seldom needs to run
start(), you could use all member functions and variables.
Nice and neat.
And last but not least it wouldn't break compatibility.
Programs using threadying.py needn't change a single line.
There are more pro's and con's to this. To my opinion it is
more a matter of coding style and design. I do not know
Java's threads but I agree now with time_one: maybe this
issue is more a feature request than a bug report.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-14 20:56

Message:
Logged In: YES 
user_id=357491

I agree with Tim here.  I don't see a need for this anyway.  Once 
a thread has terminated it is done, period.  Having to 
reinstantiate a class to run another thread is perfectly 
reasonable.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 15:54

Message:
Logged In: YES 
user_id=31435

It's true that Thread instances can't be restarted, but you 
haven't made a case for calling that "a bug".  Python's 
threading model is fashioned loosely on Java's, and, like 
Java's, limits thread instances to one invocation by design.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=751260&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 22:13:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 14:13:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-752221 ] print in __getattr__ causes seg fault
Message-ID: <E19Reor-0004Kg-00@sc8-sf-web3.sourceforge.net>

Bugs item #752221, was opened at 2003-06-10 14:58
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Christopher K. Paulicka (paulicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: print in __getattr__ causes seg fault

Initial Comment:
[~/site-packages/WorldPlay/] paulicka@Sliver-14:56:32
$ python
Python 2.3a2+ (#4, Mar  2 2003, 17:13:46) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class A:
...     def __getattr__(self,name):
...             return 3
... 
>>> a=A()
>>> a.c
3
>>> class B:
...     def __getattr__(self,name):
...             print self, name
...             return 3
... 
>>> b=B()
>>> b.c
Segmentation fault
[~/site-packages/WorldPlay/] paulicka@Sliver-14:57:14
$ 

$ uname -a
Darwin Sliver.local. 6.6 Darwin Kernel Version 6.6: Thu 
May  1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/
RELEASE_PPC  Power Macintosh powerpc


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 14:13

Message:
Logged In: YES 
user_id=357491

Sounds reasonable to me.  Building off of this, I realized why this 
doesn't loop for new-style classes; __getattr__ is assigned lowest 
priority in the attribute lookup order.  This means object's 
__str__ kicks in before __getattr__ is ever called when trying to 
resolve for __str__ for the print statement.

And since I am running OS X and cannot reproduce this with 
Python 2.3b1 I am going to close this bug fix.

Thanks for the help, sjones.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-15 06:15

Message:
Logged In: YES 
user_id=589306

I did some research and thinking on this problem, and here
is what I think is happening.

1. When you print self inside __getattr__, Python calls
repr(self) to figure out how to print that.
2. repr(self) attempts to call self.__repr__().
3. Since you didn't define __repr__ for this class,
__getattr__ is called to look up the name.
4. __getattr__ attempts to print self again, and you are now
in an infinite loop.

For more information, do a Google Groups search for "Obscure
__getattr__ behavior" which should bring you to the thread
at http://tinyurl.com/ecsh (hope that works, heh). It even
mentions the difference bcannon mentioned between old and
new style classes.

You could solve the problem by defining your own __repr__
(and __str__ for similar reasons). Or you can raise
AttributeError in __getattr__ if name is __repr__ or __str__
so that Python reverts back to defaults for these functions.

Here is a way to write your class so that it does what you want:

>>> class B:
...     def __getattr__(self, name):
...             if name == '__repr__' or name == '__str__':
...                     raise AttributeError
...             print self, name
...             return 3
...
>>> b = B()
>>> b.c
<__main__.B instance at 0x81c785c> c
3


I'm leaning toward the opinion that the infinite loop
behavior is not a bug in Python. Even though the result
wasn't expected, Python was doing exactly as told.

However, the Segmentation Fault you got on your system is
probably a bug. That seems related to your OS / build of
Python though. Can anyone duplicate the segfault?

Maybe Python isn't catching the infinite recursion fast
enough and your stack is overflowing (just a wild guess).
Try running some code like this and see if you get a
RuntimeError or a segfault:

def f():
    f()

Then call f() to see what error you get.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 00:48

Message:
Logged In: YES 
user_id=357491

I get a RuntimeError under OS X just like sjones but only with a 
classic class.  What else that is interesting is that if I just type in 
the instance name and hit enter it also has the RuntimeError.

I checked the bytecode and both are the same so there isn't 
some funky difference there.  Must be some way that classic 
classes handle self compared to new-style and how __getattr__ 
is dealt with.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 18:57

Message:
Logged In: YES 
user_id=589306

I tried running with current CVS and got the following
results on Linux:

Python 2.3b1+ (#3, Jun 13 2003, 07:56:14)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> class A:
...     def __getattr__(self, name):
...             return 3
...
>>> a = A()
>>> a.c
3
>>> class B:
...     def __getattr__(self, name):
...             print self, name
...             return 3
...
>>> b = B()
>>> b.c
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
  File "<stdin>", line 3, in __getattr__
[Repeats lots of times]
  File "<stdin>", line 3, in __getattr__
RuntimeError: maximum recursion depth exceeded
>>> class C:
...     def __init__(self):
...             self.x = 5
...     def __getattr__(self, name):
...             print self.x
...             return 3
...
>>> c = C()
>>> c.c
5
3

$ uname -a
Linux localhost 2.4.20-18.9 #1 Thu May 29 06:54:41 EDT 2003
i686 athlon i386 GNU/Linux

-------------------------------------------------
Note that I can print things from getattr, it is just
printing self that gets me in trouble.


----------------------------------------------------------------------

Comment By: Christopher K. Paulicka (paulicka)
Date: 2003-06-13 17:20

Message:
Logged In: YES 
user_id=45461

Actually, I can't use the beta, because I used the MacOS Kitchen 
Sink combination of Framework Python, Pygame and PyOpenGL.

I tried building from the CVS repository, but had problems, so 
just moved on...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-10 20:09

Message:
Logged In: YES 
user_id=80475

Can you try this one on the beta release to see if it is still a 
problem.  I cannot reproduce the segfault on a Windows 
build.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=752221&group_id=5470


From noreply@sourceforge.net  Sun Jun 15 22:23:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 14:23:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-755031 ] zipfile: inconsistent filenames with InfipZip "unzip"
Message-ID: <E19ReyY-0005Yz-00@sc8-sf-web2.sourceforge.net>

Bugs item #755031, was opened at 2003-06-15 17: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=755031&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile: inconsistent filenames with InfipZip "unzip"

Initial Comment:
zipfile.py gives filenames inconsistent with the
InfoZIP "unzip" utility for certain ZIP files.  My
source is an email virus, so the ZIP files are almost
certainl malformed.  Nevertheless, it would be nice if
"unzip -l" and ZipFile.namelist() gave consistent
filenames.

Example: the attached Demo.zip (extracted from an email
virus caught on mail.python.org) looks like this
according to InfoZip:

$ unzip -l /tmp/Demo.zip 
Archive:  /tmp/Demo.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
    44544  01-26-03 20:49  
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe
 --------                   -------
    44544                   1 file

But according to ZipFile.namelist(), the name of that
file is:
 
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exescr000000000000000000.txt

Getting the same result with Python 2.2.2 and a
~2-week-old build of 2.3 CVS.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 00:44:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 16:44:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E19RhAW-0003LA-00@sc8-sf-web4.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 01:37:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 17:37:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-755080 ] AssertionError from urllib.retrieve / httplib
Message-ID: <E19Rhzb-0004VC-00@sc8-sf-web4.sourceforge.net>

Bugs item #755080, was opened at 2003-06-16 10: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=755080&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: AssertionError from urllib.retrieve / httplib

Initial Comment:

The following statement is occasionally generating
AssertionErrors:
    current_page = urllib.urlopen(action,data).read()

Traceback (most recent call last):
  File "/Users/zen/bin/autospamrep.py", line 161, in ?
    current_page = handle_spamcop_page(current_page)
  File "/Users/zen/bin/autospamrep.py", line 137, in 
handle_spamcop_page
    current_page = urllib.urlopen(action,data).read()
  File "/sw/lib/python2.3/httplib.py", line 1150, in read
    assert not self._line_consumed and self._line_left


Fix may be to do the following in 
LineAndFileWrapper.__init__ (last two lines are new):

def __init__(self, line, file):
        self._line = line
        self._file = file
        self._line_consumed = 0
        self._line_offset = 0
        self._line_left = len(line)
        if not self._line_left:
            self._done()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755080&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 01:53:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 17:53:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball
Message-ID: <E19RiF7-0004yt-00@sc8-sf-web1.sourceforge.net>

Bugs item #728051, was opened at 2003-04-27 00:23
Message generated for change (Comment added) made by zenzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Test failures on Linux, Python 2.3b1 tarball

Initial Comment:
"make test" resulted in:

test test_tempfile failed -- Traceback (most recent
call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports
failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
264, in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

test test_time failed -- Traceback (most recent call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_time.py", line
107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST


----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-16 10:53

Message:
Logged In: YES 
user_id=46639

Hmm... no file upload button for me in this topic.
Here is a configure.in patch which should stop time.tzset
being build on Redhat 6, and other platforms with this 'problem'
(being that although tzset() may do something useful, it
doesn't do what is documented or called multiple times by the
same process)


Index: dist/src/configure.in
=======================================
============================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.418
diff -c -c -r1.418 configure.in
*** dist/src/configure.in       14 Jun 2003 21:03:05 -0000      
1.418
--- dist/src/configure.in       16 Jun 2003 00:43:24 -0000
***************
*** 2706,2723 ****
  #include <time.h>
  int main()
  {
        int gmt_hour;
        int eastern_hour;
!       time_t now;
!       now = time((time_t*)NULL);
        putenv("TZ=UTC+0");
        tzset();
!       gmt_hour = localtime(&now)->tm_hour;
        putenv("TZ=EST+5EDT,M4.1.0,M10.5.0");
        tzset();
!       eastern_hour = localtime(&now)->tm_hour;
!       if (eastern_hour == gmt_hour)
            exit(1);
        exit(0);
  }
  ],
--- 2706,2737 ----
  #include <time.h>
  int main()
  {
+       /* Note that we need to ensure that not only does tzset(3)
+          do 'something' with localtime, but it works as 
documented
+          in the library reference and as expected by the test 
suite. */
        int gmt_hour;
        int eastern_hour;
!       int aus_hour;
!       time_t xmas = 1040774400;
! 
        putenv("TZ=UTC+0");
        tzset();
!       gmt_hour = localtime(&xmas)->tm_hour;
!       if (gmt_hour != 0)
!           exit(1);
! 
        putenv("TZ=EST+5EDT,M4.1.0,M10.5.0");
        tzset();
!       eastern_hour = localtime(&xmas)->tm_hour;
!       if (eastern_hour != 19)
!           exit(1);
! 
!       putenv("TZ=AEST-10AEDT-11,M10.5.0,M3.5.0");
!       tzset();
!       aus_hour = localtime(&xmas)->tm_hour;
!       if (aus_hour != 11)
            exit(1);
+ 
        exit(0);
  }
  ],

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-11 10:42

Message:
Logged In: YES 
user_id=357491

Sure thing.  =)  Execute this line from a terminal:

python2.3 -c "from test import test_tempfile; 
test_tempfile.test_main()"

All it is doing is importing the test_tempfile module from the test 
package and then executing test_tempfile.test_main() which 
runs all the tests.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-06-11 08:56

Message:
Logged In: YES 
user_id=56214

I don't know.  Tell me how to run the test on its own, and
I'll tell you.  :)


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-11 08:04

Message:
Logged In: YES 
user_id=357491

How about the test_tempfile failure?  Does that occur when you 
run the test on its own?

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-05-25 23:21

Message:
Logged In: YES 
user_id=56214

Here's the tz info; I'll email you the 'man tzset' separately.

[admin@pilot Python-2.3a1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[admin@pilot Python-2.3a1]$ cd ../Python-2.3b1
[admin@pilot Python-2.3b1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-05-22 10:41

Message:
Logged In: YES 
user_id=46639

This is from my patch.

Phillip - can you please upload a copy of 'man tzset' on that Redhat box
or email it to zen@shangri-la.dropbear.id.au.

I'd also like to see the output of:
    python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='US/Eastern' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='Australia/Melbourne' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'

I'm thinking that tzset(3) and the time libraries are not fully functional on 
this earlier version of Redhat, possibly by not handling southern hemisphere 
daylight savings. If so, it needs to be detected during configuration.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-05 01:00

Message:
Logged In: YES 
user_id=21627

Neal, it appears you have checked in the test for the AEST
zone. Can you analyse the test_time failure in more detail?

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-05-04 23:19

Message:
Logged In: YES 
user_id=56214

It's an ISP-supplied variant of RedHat 6.2.  I see
'libc-2.1.3.so' in the /lib directory, so I assume that's
the version. Running 'strings' on it, I find:

GNU C Library stable release version 2.1.3, by Roland
McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software
Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release).
Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07.
Available extensions:
        GNU libio by Per Bothner
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        BIND-4.9.7-REL
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton 
        linuxthreads-0.8 by Xavier Leroy
        libthread_db work sponsored by Alpha Processor Inc


Python identifies itself as:

Python 2.3b1 (#1, Apr 26 2003, 10:02:40) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I just tested 2.3a1 andr 2.3a2 to confirm where the errors
began.  2.3a1 doesn't show either error.  2.3a2 has the
tempfile problem, but not the time problem.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 22:42

Message:
Logged In: YES 
user_id=21627

What operating system distribution specifically did you use?
What C library does this system use?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 01:55:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 17:55:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-755080 ] AssertionError from urllib.retrieve / httplib
Message-ID: <E19RiHP-00052x-00@sc8-sf-web1.sourceforge.net>

Bugs item #755080, was opened at 2003-06-16 10:37
Message generated for change (Comment added) made by zenzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755080&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: AssertionError from urllib.retrieve / httplib

Initial Comment:

The following statement is occasionally generating
AssertionErrors:
    current_page = urllib.urlopen(action,data).read()

Traceback (most recent call last):
  File "/Users/zen/bin/autospamrep.py", line 161, in ?
    current_page = handle_spamcop_page(current_page)
  File "/Users/zen/bin/autospamrep.py", line 137, in 
handle_spamcop_page
    current_page = urllib.urlopen(action,data).read()
  File "/sw/lib/python2.3/httplib.py", line 1150, in read
    assert not self._line_consumed and self._line_left


Fix may be to do the following in 
LineAndFileWrapper.__init__ (last two lines are new):

def __init__(self, line, file):
        self._line = line
        self._file = file
        self._line_consumed = 0
        self._line_offset = 0
        self._line_left = len(line)
        if not self._line_left:
            self._done()


----------------------------------------------------------------------

>Comment By: Stuart Bishop (zenzen)
Date: 2003-06-16 10:55

Message:
Logged In: YES 
user_id=46639

My suggested fix is wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755080&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 02:05:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 18:05:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E19RiR0-0002vp-00@sc8-sf-web2.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 06:32
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-15 21:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said "when my application exits".  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 19:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-06-15 04:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 04:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 02:19:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 18:19:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-755031 ] zipfile: inconsistent filenames with InfoZip "unzip"
Message-ID: <E19RieC-00025I-00@sc8-sf-web3.sourceforge.net>

Bugs item #755031, was opened at 2003-06-15 17:23
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Nobody/Anonymous (nobody)
>Summary: zipfile: inconsistent filenames with InfoZip "unzip"

Initial Comment:
zipfile.py gives filenames inconsistent with the
InfoZIP "unzip" utility for certain ZIP files.  My
source is an email virus, so the ZIP files are almost
certainl malformed.  Nevertheless, it would be nice if
"unzip -l" and ZipFile.namelist() gave consistent
filenames.

Example: the attached Demo.zip (extracted from an email
virus caught on mail.python.org) looks like this
according to InfoZip:

$ unzip -l /tmp/Demo.zip 
Archive:  /tmp/Demo.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
    44544  01-26-03 20:49  
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe
 --------                   -------
    44544                   1 file

But according to ZipFile.namelist(), the name of that
file is:
 
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exescr000000000000000000.txt

Getting the same result with Python 2.2.2 and a
~2-week-old build of 2.3 CVS.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-15 21:19

Message:
Logged In: YES 
user_id=6380

That almost sounds like an intentional inconsistency. Could
it be that the central directory has one name but the local
header has a different one? Or that there's a null byte in
the filename so that the filename length is inconsistent?
The front of the file looks like this according to od -c:

0000000   P   K 003 004  \n  \0  \0  \0  \0  \0   *   Š   :
  .   c   Ì
0000020  \v   g  \0   ®  \0  \0  \0   ®  \0  \0   D  \0  \0
 \0   D   O
0000040   C   U   M   E   ~   1   \   C   H   R   I   S   S
  ~   1   \
0000060   L   O   C   A   L   S   ~   1   \   T   e   m   p
  \   D   e
0000100   m   o   .   e   x   e  \0  \0   s   c   r  \0   0
  0   0   0
0000120   0   0   0   0   0   0   0   0   0   0   0   0   0
  0   .   t
0000140   x   t   M   Z 220  \0 003  \0  \0  \0 004  \0  \0
 \0   ÿ   ÿ
0000160  \0  \0   ž  \0  \0  \0  \0  \0  \0  \0   @  \0  \0
 \0  \0  \0


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 02:23:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 18:23:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-755031 ] zipfile: inconsistent filenames with InfoZip "unzip"
Message-ID: <E19Rii6-0002AX-00@sc8-sf-web3.sourceforge.net>

Bugs item #755031, was opened at 2003-06-15 16:23
Message generated for change (Comment added) made by sjones
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile: inconsistent filenames with InfoZip "unzip"

Initial Comment:
zipfile.py gives filenames inconsistent with the
InfoZIP "unzip" utility for certain ZIP files.  My
source is an email virus, so the ZIP files are almost
certainl malformed.  Nevertheless, it would be nice if
"unzip -l" and ZipFile.namelist() gave consistent
filenames.

Example: the attached Demo.zip (extracted from an email
virus caught on mail.python.org) looks like this
according to InfoZip:

$ unzip -l /tmp/Demo.zip 
Archive:  /tmp/Demo.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
    44544  01-26-03 20:49  
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe
 --------                   -------
    44544                   1 file

But according to ZipFile.namelist(), the name of that
file is:
 
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exescr000000000000000000.txt

Getting the same result with Python 2.2.2 and a
~2-week-old build of 2.3 CVS.


----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-15 20:23

Message:
Logged In: YES 
user_id=589306

The actual filename from the zipfile is:
filename =
'DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe\x00\x00scr\x00000000000000000000.txt'

Notice there is a \x00 after Demo.exe. My guess is InfoZip
stores the filename in a null terminated string and this
extra null character in the filename terminates it at this
point. Python doesn't care if you have nulls in the string,
so it prints the entire filename.

You can see the zip file format description at
ftp://ftp.info-zip.org/pub/infozip/doc/appnote-981119-iz.zip

The format does say:
      2)  String fields are not null terminated, since the
          length is given explicitly.

But it doesn't really say if strings are allowed to have
nulls in them.

So does Python or InfoZip get this right?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-15 20:19

Message:
Logged In: YES 
user_id=6380

That almost sounds like an intentional inconsistency. Could
it be that the central directory has one name but the local
header has a different one? Or that there's a null byte in
the filename so that the filename length is inconsistent?
The front of the file looks like this according to od -c:

0000000   P   K 003 004  \n  \0  \0  \0  \0  \0   *   Š   :
  .   c   Ì
0000020  \v   g  \0   ®  \0  \0  \0   ®  \0  \0   D  \0  \0
 \0   D   O
0000040   C   U   M   E   ~   1   \   C   H   R   I   S   S
  ~   1   \
0000060   L   O   C   A   L   S   ~   1   \   T   e   m   p
  \   D   e
0000100   m   o   .   e   x   e  \0  \0   s   c   r  \0   0
  0   0   0
0000120   0   0   0   0   0   0   0   0   0   0   0   0   0
  0   .   t
0000140   x   t   M   Z 220  \0 003  \0  \0  \0 004  \0  \0
 \0   ÿ   ÿ
0000160  \0  \0   ž  \0  \0  \0  \0  \0  \0  \0   @  \0  \0
 \0  \0  \0


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 02:26:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 18:26:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-755087 ] anydbm and whichdb one more time
Message-ID: <E19Rilh-0003Mg-00@sc8-sf-web2.sourceforge.net>

Bugs item #755087, was opened at 2003-06-16 11:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755087&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Saunders (grerfy)
Assigned to: Nobody/Anonymous (nobody)
Summary: anydbm and whichdb one more time

Initial Comment:
Bug #744687 was recently closed with an update to the
whichdb.py file. The update fixes the main problem
described in bug 744687, but a tangental problem,
mentioned in 744687, still occurs. The following python
transcript illustrates the problem (it uses the new
whichdb.py file):

---
Python 2.2.2 (#1, Mar 21 2003, 23:01:54) 
[GCC 3.2.3 20030316 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import whichdb, anydbm, dumbdbm
>>> a = dumbdbm.open('/tmp/a', 'c')
>>> a.close()
>>> b = anydbm.open('/tmp/a', 'w')
>>> b['abc'] = 'def'
>>> b.close()
>>> c = anydbm.open('/tmp/a', 'w')
>>> del c['abc']
>>> c.close()
>>> d = anydbm.open('/tmp/a', 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/anydbm.py", line 80, in open
    raise error, "need 'c' or 'n' flag to open new db"
anydbm.error: need 'c' or 'n' flag to open new db
>>> 
---

As can be seen, the change to whichdb.py correctly
detects if the dumbdbm database is created, closed, and
re-opened. However, if the dumbdbm file is populated
with some data, then all that data is removed, the bug
once again rears its ugly head. This occurs because
once data is entered into a dumbdbm database, it is
never removed from the .dat file, only the relevant
entry from the .dir file is removed. I suppose the
correct solution to this is to change the
implementation of dumbdbm. A quicker solution, however,
would be a minor change to the new whichdb.py file to
detect only if the .dir file is empty - a patch is
attached.

regards
Greg


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755087&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 02:58:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 18:58:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball
Message-ID: <E19RjGH-00042E-00@sc8-sf-web2.sourceforge.net>

Bugs item #728051, was opened at 2003-04-26 14:23
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Test failures on Linux, Python 2.3b1 tarball

Initial Comment:
"make test" resulted in:

test test_tempfile failed -- Traceback (most recent
call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports
failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
264, in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

test test_time failed -- Traceback (most recent call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_time.py", line
107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST


----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2003-06-16 01:58

Message:
Logged In: YES 
user_id=56214

Here are the gory details of the tempfile test:

[admin@pilot Python-2.3b1]$ ./python -c "from test import
test_tempfile; test_tempfile.test_main()"
test_exports (test.test_tempfile.test_exports) ... ok
test_get_six_char_str
(test.test_tempfile.test__RandomNameSequence) ... ok
test_many (test.test_tempfile.test__RandomNameSequence) ... ok
test_supports_iter
(test.test_tempfile.test__RandomNameSequence) ... ok
test_nonempty_list
(test.test_tempfile.test__candidate_tempdir_list) ... ok
test_wanted_dirs
(test.test_tempfile.test__candidate_tempdir_list) ... ok
test_retval (test.test_tempfile.test__get_candidate_names)
... ok
test_same_thing
(test.test_tempfile.test__get_candidate_names) ... ok
test_basic (test.test_tempfile.test__mkstemp_inner) ... ok
test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok
test_choose_directory
(test.test_tempfile.test__mkstemp_inner) ... ok
test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok
fd 3 is open in childtest_noinherit
(test.test_tempfile.test__mkstemp_inner) ... FAIL
test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok
test_sane_template (test.test_tempfile.test_gettempprefix)
... ok
test_usable_template (test.test_tempfile.test_gettempprefix)
... ok
test_directory_exists (test.test_tempfile.test_gettempdir)
... ok
test_directory_writable (test.test_tempfile.test_gettempdir)
... ok
test_same_thing (test.test_tempfile.test_gettempdir) ... ok
test_basic (test.test_tempfile.test_mkstemp) ... ok
test_choose_directory (test.test_tempfile.test_mkstemp) ... ok
test_basic (test.test_tempfile.test_mkdtemp) ... ok
test_basic_many (test.test_tempfile.test_mkdtemp) ... ok
test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok
test_mode (test.test_tempfile.test_mkdtemp) ... ok
test_basic (test.test_tempfile.test_mktemp) ... ok
test_many (test.test_tempfile.test_mktemp) ... ok
test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok
test_creates_named
(test.test_tempfile.test_NamedTemporaryFile) ... ok
test_del_on_close
(test.test_tempfile.test_NamedTemporaryFile) ... ok
test_multiple_close
(test.test_tempfile.test_NamedTemporaryFile) ... ok
test_basic (test.test_tempfile.test_TemporaryFile) ... ok
test_has_no_name (test.test_tempfile.test_TemporaryFile) ... ok
test_multiple_close (test.test_tempfile.test_TemporaryFile)
... ok

======================================================================
FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264,
in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

----------------------------------------------------------------------
Ran 34 tests in 0.217s

FAILED (failures=1)
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 651, in test_main
    test_support.run_suite(suite)
  File "/home/admin/Python-2.3b1/Lib/test/test_support.py",
line 229, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264,
in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-16 00:53

Message:
Logged In: YES 
user_id=46639

Hmm... no file upload button for me in this topic.
Here is a configure.in patch which should stop time.tzset
being build on Redhat 6, and other platforms with this 'problem'
(being that although tzset() may do something useful, it
doesn't do what is documented or called multiple times by the
same process)


Index: dist/src/configure.in
=======================================
============================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.418
diff -c -c -r1.418 configure.in
*** dist/src/configure.in       14 Jun 2003 21:03:05 -0000      
1.418
--- dist/src/configure.in       16 Jun 2003 00:43:24 -0000
***************
*** 2706,2723 ****
  #include <time.h>
  int main()
  {
        int gmt_hour;
        int eastern_hour;
!       time_t now;
!       now = time((time_t*)NULL);
        putenv("TZ=UTC+0");
        tzset();
!       gmt_hour = localtime(&now)->tm_hour;
        putenv("TZ=EST+5EDT,M4.1.0,M10.5.0");
        tzset();
!       eastern_hour = localtime(&now)->tm_hour;
!       if (eastern_hour == gmt_hour)
            exit(1);
        exit(0);
  }
  ],
--- 2706,2737 ----
  #include <time.h>
  int main()
  {
+       /* Note that we need to ensure that not only does tzset(3)
+          do 'something' with localtime, but it works as 
documented
+          in the library reference and as expected by the test 
suite. */
        int gmt_hour;
        int eastern_hour;
!       int aus_hour;
!       time_t xmas = 1040774400;
! 
        putenv("TZ=UTC+0");
        tzset();
!       gmt_hour = localtime(&xmas)->tm_hour;
!       if (gmt_hour != 0)
!           exit(1);
! 
        putenv("TZ=EST+5EDT,M4.1.0,M10.5.0");
        tzset();
!       eastern_hour = localtime(&xmas)->tm_hour;
!       if (eastern_hour != 19)
!           exit(1);
! 
!       putenv("TZ=AEST-10AEDT-11,M10.5.0,M3.5.0");
!       tzset();
!       aus_hour = localtime(&xmas)->tm_hour;
!       if (aus_hour != 11)
            exit(1);
+ 
        exit(0);
  }
  ],

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-11 00:42

Message:
Logged In: YES 
user_id=357491

Sure thing.  =)  Execute this line from a terminal:

python2.3 -c "from test import test_tempfile; 
test_tempfile.test_main()"

All it is doing is importing the test_tempfile module from the test 
package and then executing test_tempfile.test_main() which 
runs all the tests.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-06-10 22:56

Message:
Logged In: YES 
user_id=56214

I don't know.  Tell me how to run the test on its own, and
I'll tell you.  :)


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 22:04

Message:
Logged In: YES 
user_id=357491

How about the test_tempfile failure?  Does that occur when you 
run the test on its own?

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-05-25 13:21

Message:
Logged In: YES 
user_id=56214

Here's the tz info; I'll email you the 'man tzset' separately.

[admin@pilot Python-2.3a1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[admin@pilot Python-2.3a1]$ cd ../Python-2.3b1
[admin@pilot Python-2.3b1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-05-22 00:41

Message:
Logged In: YES 
user_id=46639

This is from my patch.

Phillip - can you please upload a copy of 'man tzset' on that Redhat box
or email it to zen@shangri-la.dropbear.id.au.

I'd also like to see the output of:
    python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='US/Eastern' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='Australia/Melbourne' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'

I'm thinking that tzset(3) and the time libraries are not fully functional on 
this earlier version of Redhat, possibly by not handling southern hemisphere 
daylight savings. If so, it needs to be detected during configuration.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 15:00

Message:
Logged In: YES 
user_id=21627

Neal, it appears you have checked in the test for the AEST
zone. Can you analyse the test_time failure in more detail?

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-05-04 13:19

Message:
Logged In: YES 
user_id=56214

It's an ISP-supplied variant of RedHat 6.2.  I see
'libc-2.1.3.so' in the /lib directory, so I assume that's
the version. Running 'strings' on it, I find:

GNU C Library stable release version 2.1.3, by Roland
McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software
Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release).
Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07.
Available extensions:
        GNU libio by Per Bothner
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        BIND-4.9.7-REL
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton 
        linuxthreads-0.8 by Xavier Leroy
        libthread_db work sponsored by Alpha Processor Inc


Python identifies itself as:

Python 2.3b1 (#1, Apr 26 2003, 10:02:40) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I just tested 2.3a1 andr 2.3a2 to confirm where the errors
began.  2.3a1 doesn't show either error.  2.3a2 has the
tempfile problem, but not the time problem.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 12:42

Message:
Logged In: YES 
user_id=21627

What operating system distribution specifically did you use?
What C library does this system use?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 07:19:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 23:19:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E19RnL6-0004VT-00@sc8-sf-web4.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 18:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said "when my application exits".  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 07:58:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 15 Jun 2003 23:58:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E19Rnx5-0003EH-00@sc8-sf-web2.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:58

Message:
Logged In: YES 
user_id=357491

OK, following Tim's advice I checked and it seems that Thread 
calls a method while shutting itself down that calls 
Condition.notifyAll which calls currentThread which is a global.  It 
would appear that offlineimap is leaving its threads running, the 
program gets shut down, the threads raise an error while 
shutting down (probably because things are being torn down), 
this triggers the stopping method in Thread, and this raises its 
own exception because of the teardown which is what we are 
seeing as the TypeError.

So the question is whether Condition should store a local 
reference to currentThread or not.  It is not the most pure 
solution since this shutdown issue is not Condition's, but the only 
other solution I can think of is to have Thread keep a reference 
to currentThread, inject it into the current frame's global 
namespace, call Condition.notifyAll, and then remove the 
reference from the frame again.  I vote for the cleaner, less pure 
solution.  =)

Am I insane on this or does it at least sound like this is the 
problem and proper solution?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 18:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said "when my application exits".  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 14:12:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 06:12:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-746895 ] socket.sendto(SOCK_DGRAM) very slow on OSX!
Message-ID: <E19Rtms-0000zl-00@sc8-sf-web3.sourceforge.net>

Bugs item #746895, was opened at 2003-06-01 08:21
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Kangas (mkangas)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.sendto(SOCK_DGRAM) very slow on OSX!

Initial Comment:
I'm trying to send UDP packets using socket.sendto().
With Python 2.2 on Linux, this works like a champ. On
Mac OS X, something's terribly wrong.

Time to send 100 UDP packets using test code + Python
2.2.1:
- Linux 2.4.18 (RedHat 8): 0.009 sec
- MacOS X 10.2.6: > 1 sec, sometimes > 2 sec.

I've tried the following Python builds on OS X, all
with the same results:
- Stock 2.2 build that comes with OS X 10.2
- 2.2.1 provided by Fink
- built-from-scratch 2.2.3: "./configure; make"

provided are sample programs in Python and C.
ktrace/kdump seem to indicate that both programs make
the same sequence of syscalls. the C program runs
blazingly fast on OS X, while the Python one seems to
stall on every call to socket.sendto().

why does socket.sendto() perform so poorly on OS X?

----------------- python sample ----------------
 
#
# UDP socket test: how fast can we write?
# (5/2003 kangas)
#
# time to run with python 2.2.1:
# - Linux 2.4.18:     0.009 sec
# - Mac OS x 10.2.6:  1.272 sec (!!!)

import socket, time, sys

PORT = 9999
DEST_ADDR = ("192.168.1.60", PORT)

def run():
    maxcount = 100
    data = "pingme pingme pingme pingme pingme..."
    dest = DEST_ADDR

    print "opening socket"
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    
    print "Sending %i packets" % maxcount
    t0 = time.time()
    for i in xrange(0, maxcount):
        s.sendto(data, dest)
    t1 = time.time() - t0
    print "%0.4f secs elapsed" % t1

    s.close()

if __name__=="__main__":
    run()
    

----------------- C sample ----------------

/*
 * UDP socket test: how fast can we write?
 * (5/2003 kangas)
 *
 * Tested on Mac OS X 10.2.6 and Linux 2.4
 */

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>

static const int MAXCOUNT = 100;
static const char DATA[] = "pingme pingme pingme pingme
pingme...";
    
int main(void) {
    int s, i, err;
    struct sockaddr_in serverAddr;

    bzero(&serverAddr, sizeof(serverAddr));
    serverAddr.sin_family = AF_INET;
    serverAddr.sin_port = htons(9999);
    
    inet_pton(AF_INET, "192.168.1.60",
&serverAddr.sin_addr);
    
    printf("opening socket\n");
    if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
	perror("socket");
	exit(1);
    }

    printf("sending %i packets\n", MAXCOUNT);
    for (i=0; i<MAXCOUNT; i++) {
	err = sendto(s, DATA, strlen(DATA), 0,
		     (struct sockaddr *)&serverAddr, sizeof(serverAddr));
	if (err < 0) {
	    perror("sendto");
	    break;
	}
	printf(".");
     };
    printf("\n");

    printf("closing...\n");
    close(s);
    printf("done!\n");
    return 0;
}


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-16 15:12

Message:
Logged In: YES 
user_id=45365

Hmm. It looks like something that is fixed in 2.3.

When running the example with Apple's /usr/bin/python 2.2 I 
get "0.6942 secs elapsed". When I run it with 2.3b2 from CVS I 
get "0.0069 secs elapsed".

Could this be an effect of the gethostbyname() mods that were 
done for numeric addresses? Yes, it seems it could be. 1000 calls 
to gethostbyname("192.168.1.60") cost 7.4 seconds in Python 
2.2, while 2.3b2 needs only 0.02 seconds.

I don't know whether these fixes can be backported to 2.2, 
though (nor even exactly what they are:-)

----------------------------------------------------------------------

Comment By: Matt Kangas (mkangas)
Date: 2003-06-15 00:21

Message:
Logged In: YES 
user_id=234623

"otool -L" (similar to Linux's ldd) shows the following for
my freshly-built Python 2.2.3 interpreter:

drinkycrow:Python-2.2.3$ otool -L python.exe
python.exe:
        /usr/lib/libSystem.B.dylib (compatibility version
1.0.0, current version 63.0.0)
       
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 14.0.0)
       
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 462.0.0)
drinkycrow:Python-2.2.3$ ./python.exe
Python 2.2.3 (#2, Jun 14 2003, 17:58:35)
[GCC 3.1 20020420 (prerelease)] on darwin

--------------------------------------

I added the following CFLAGS line to my makefile:

CFLAGS = -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-no-cpp-precomp -framework System -framework CoreServices
-framework Foundation

These are, AFAIK, all of the relevant options used when
building _socket.so and python.exe. (See attached
"build_notes.txt" for full details)

------------------------------------------

How does the C test-case perform now? Slower than before,
but still an order of magnitude faster than the Python code!

drinkycrow:udp_test_py$ make clean; make
rm socktest
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-no-cpp-precomp -framework System-framework CoreServices
-framework Foundation    socktest.c   -o socktest
socktest.c: In function `main':
socktest.c:21: warning: implicit declaration of function `bzero'
socktest.c:25: warning: implicit declaration of function
`inet_pton'
socktest.c:30: warning: implicit declaration of function `exit'
socktest.c:35: warning: implicit declaration of function
`strlen'
socktest.c:46: warning: implicit declaration of function `close'
drinkycrow:udp_test_py$ time ./socktest
opening socket
sending 100 packets
....................................................................................................
closing...
done!

real    0m0.164s
user    0m0.030s
sys     0m0.040s

drinkycrow:udp_test_py$ otool -L socktest
socktest:
        /usr/lib/libSystem.B.dylib (compatibility version
1.0.0, current version 63.0.0)
       
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 14.0.0)
       
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 462.0.0)


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:55

Message:
Logged In: YES 
user_id=21627

Can you try to link your C program with the same libraries
that python is linked with, and compile it with the same
command line options that socketmodule is compiled with?

My first guess is that enabling pthreads may have an effect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 14:26:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 06:26:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E19Ru06-0006yD-00@sc8-sf-web1.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 05:32
Message generated for change (Comment added) made by jgoerzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2003-06-16 08:26

Message:
Logged In: YES 
user_id=491567

I can confirm that this behavior is not present in Python 2.2 in 
the same version that I am using to test against Python 2.3. 
 
I will be on vacation for most of this and next week.  I'll try to 
get to the logging script before I leave, but I might not get to it 
until I return. 
 
FYI, you can also obtain OfflineIMAP at 
http://quux.org/devel/offlineimap. 
 
 

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 01:58

Message:
Logged In: YES 
user_id=357491

OK, following Tim's advice I checked and it seems that Thread 
calls a method while shutting itself down that calls 
Condition.notifyAll which calls currentThread which is a global.  It 
would appear that offlineimap is leaving its threads running, the 
program gets shut down, the threads raise an error while 
shutting down (probably because things are being torn down), 
this triggers the stopping method in Thread, and this raises its 
own exception because of the teardown which is what we are 
seeing as the TypeError.

So the question is whether Condition should store a local 
reference to currentThread or not.  It is not the most pure 
solution since this shutdown issue is not Condition's, but the only 
other solution I can think of is to have Thread keep a reference 
to currentThread, inject it into the current frame's global 
namespace, call Condition.notifyAll, and then remove the 
reference from the frame again.  I vote for the cleaner, less pure 
solution.  =)

Am I insane on this or does it at least sound like this is the 
problem and proper solution?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 01:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 20:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said "when my application exits".  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 18:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-06-15 03:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 03:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 15:06:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 07:06:06 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-754014 ] list.index() should accept optional start, end arguments
Message-ID: <E19RucY-0005Om-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #754014, was opened at 2003-06-13 10:13
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=754014&group_id=5470

>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Hansen (phansen)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: list.index() should accept optional start, end arguments

Initial Comment:
As with the .index() method on strings, which allows 
scanning only a subset of the string by specifying 
optional start and end arguments, the list type's index() 
method should do the same.

The use case comes from the thread started here: 
http://mail.python.org/pipermail/python-list/2003-
June/168225.html .  

A later posting shows a list-comprehension-based 
solution which is fairly clean, but relies on generating a 
temporary utility list using range() (or xrange()).  
Another easy alternative would be to manually create 
subsets of the list using slicing, but that would involve a 
lot of overhead compared to including it in the index() 
method itself.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 09:06

Message:
Logged In: YES 
user_id=80475

Okay, I'll put this one in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=754014&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 15:20:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 07:20:44 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-753600 ] why should += produce name binding?
Message-ID: <E19Ruqi-00005l-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #753600, was opened at 2003-06-12 17:16
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: why should += produce name binding?

Initial Comment:

Currently, in

def x():
     foo += 1

... 'foo' is a local variable. Why should it be?
If the semantics are changed so that augmented
assignment is not a name-binding operation,
then only broken code will be affected.

This would allow you to use simple things
like   'EventCount += 1' without having to
use 'global EventCount'. After all, I can do
'EventList.append(...)' without the global decl.

For another (better) example, see 
http://mail.python.org/pipermail/edu-sig/2001-June/001329.html

In the response to the above, the poster is referred
to PEP227 which lists 'assignment' as a name-binding
operation. There is no clear-cut implication that this
includes augmented assignment, and in the Python
ref manual, one can only infer this behaviour from
the statement that x += y is almost equivalent
to x = x+y, which is pretty weak. In any case, since
an augmented assignment to a name always requires the
a-priori existence of that name in
an accessible namespace,  IMHO it should not
produce a binding.


















----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 09:20

Message:
Logged In: YES 
user_id=80475

In your example, I prefer the global declaration for 
EventCount.  It adds clarity and allows the reader to 
understand the function without reading the enclosing 
scopes.

I do agree the the += semantics are thorny area for python, 
I prefer the current binding behavior which is what I expect 
out of an assignment operation.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 11:24

Message:
Logged In: YES 
user_id=21627

Can you please explain, in detail, what semantics you
propose for += if the variable does not refer to a mutable
object?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 15:29:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 07:29:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-755031 ] zipfile: inconsistent filenames with InfoZip "unzip"
Message-ID: <E19RuzH-0000Z6-00@sc8-sf-web4.sourceforge.net>

Bugs item #755031, was opened at 2003-06-15 21:23
Message generated for change (Comment added) made by ahlstromjc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile: inconsistent filenames with InfoZip "unzip"

Initial Comment:
zipfile.py gives filenames inconsistent with the
InfoZIP "unzip" utility for certain ZIP files.  My
source is an email virus, so the ZIP files are almost
certainl malformed.  Nevertheless, it would be nice if
"unzip -l" and ZipFile.namelist() gave consistent
filenames.

Example: the attached Demo.zip (extracted from an email
virus caught on mail.python.org) looks like this
according to InfoZip:

$ unzip -l /tmp/Demo.zip 
Archive:  /tmp/Demo.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
    44544  01-26-03 20:49  
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe
 --------                   -------
    44544                   1 file

But according to ZipFile.namelist(), the name of that
file is:
 
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exescr000000000000000000.txt

Getting the same result with Python 2.2.2 and a
~2-week-old build of 2.3 CVS.


----------------------------------------------------------------------

Comment By: James C. Ahlstrom (ahlstromjc)
Date: 2003-06-16 14:29

Message:
Logged In: YES 
user_id=64929

The analysis by sjones is correct.  Python and the zip file 
format both allow null bytes in file names.  But in this case, 
the file is infected with the "I-Worm.Lentin.o" virus and the 
file name is designed to hide this.  The file name ends in ".txt" 
but the file name up to the null byte ends in ".exe".  The 
intention is that a virus scanner would skip this file because it 
ends in ".txt" ( a non-executable text file), but that 
the ".exe" would be seen (an executable program file) if the 
file were clicked, and so the file would be executed.

Testing this on my machine, my virus scanner (Kaspersky) 
nevertheless flags the ".zip" file as containing a virus, but this 
depends on the particular virus scanner and its settings.

I suggest that zipfile.py should terminate file names at a null 
byte as InfoZip does.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-16 01:23

Message:
Logged In: YES 
user_id=589306

The actual filename from the zipfile is:
filename =
'DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe\x00\x00scr\x00000000000000000000.txt'

Notice there is a \x00 after Demo.exe. My guess is InfoZip
stores the filename in a null terminated string and this
extra null character in the filename terminates it at this
point. Python doesn't care if you have nulls in the string,
so it prints the entire filename.

You can see the zip file format description at
ftp://ftp.info-zip.org/pub/infozip/doc/appnote-981119-iz.zip

The format does say:
      2)  String fields are not null terminated, since the
          length is given explicitly.

But it doesn't really say if strings are allowed to have
nulls in them.

So does Python or InfoZip get this right?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-16 01:19

Message:
Logged In: YES 
user_id=6380

That almost sounds like an intentional inconsistency. Could
it be that the central directory has one name but the local
header has a different one? Or that there's a null byte in
the filename so that the filename length is inconsistent?
The front of the file looks like this according to od -c:

0000000   P   K 003 004  \n  \0  \0  \0  \0  \0   *   Š   :
  .   c   Ì
0000020  \v   g  \0   ®  \0  \0  \0   ®  \0  \0   D  \0  \0
 \0   D   O
0000040   C   U   M   E   ~   1   \   C   H   R   I   S   S
  ~   1   \
0000060   L   O   C   A   L   S   ~   1   \   T   e   m   p
  \   D   e
0000100   m   o   .   e   x   e  \0  \0   s   c   r  \0   0
  0   0   0
0000120   0   0   0   0   0   0   0   0   0   0   0   0   0
  0   .   t
0000140   x   t   M   Z 220  \0 003  \0  \0  \0 004  \0  \0
 \0   ÿ   ÿ
0000160  \0  \0   ž  \0  \0  \0  \0  \0  \0  \0   @  \0  \0
 \0  \0  \0


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 15:48:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 07:48:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-621548 ] Numerous defunct threads left behind
Message-ID: <E19RvHC-0001WM-00@sc8-sf-web4.sourceforge.net>

Bugs item #621548, was opened at 2002-10-10 16:25
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470

Category: Threads
Group: Python 2.3
Status: Closed
Resolution: None
Priority: 3
Submitted By: Jamin W. Collins (jamincollins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Numerous defunct threads left behind

Initial Comment:
I originally noticed this problem with Debian's
OfflineIMAP package and filed a report there:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162369

The short of it is that when running offlineimap for an
extended period of time it will eventually leave a
large number of defunct threads behind that eventually
use up all available system processes.  Killing the
original offlineimap thread clears the problem for a while.

The Debian maintainer of OfflineIMAP referred this over
to the python maintainer, who in turn has asked (as you
can see from the link above) that I file a report here.

If there is any more information I can provide (beyond
that in the Debian case already) please let me know.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-16 10:48

Message:
Logged In: YES 
user_id=6380

In an email conversation with OfflineIMAP author John
Goerzen, we've decided that this must be a bug in the
platform pthread library, not in OfflineIMAP nor in Python.

----------------------------------------------------------------------

Comment By: Jamin W. Collins (jamincollins)
Date: 2003-04-17 20:55

Message:
Logged In: YES 
user_id=88136

Go ahead and close it.  Problem still exists.  I don't know
enough about either to say which is at fault.  Nor do I know
enough about python to attempt to replicate it.  I only know
the the OfflineIMAP folks say it's not them and it would
seem now it's not Python either.

*shrug* I tried.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 20:27

Message:
Logged In: YES 
user_id=6380

I don't understand aything that is being said in the last
two comments. If anything, the bug appears to be in the
application (with which I am not familiar).

I'm going to close soon this unless someone has a bug they
can demonstrate with a small sample program that does not
involve OfflineIMAP.


----------------------------------------------------------------------

Comment By: Jamin W. Collins (jamincollins)
Date: 2003-04-17 18:41

Message:
Logged In: YES 
user_id=88136

I used both the TK and the TTY interfaces.  In both cases
(using both Python 2.2 and 2.3) zombie threads would
accumlate over time when it was left running in daemon mode.

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2003-04-17 15:27

Message:
Logged In: YES 
user_id=491567

OfflineIMAP has only two cases where one of these things 
might happen: 
 
1) in the Curses interface module, where it does a fork at the 
very beginning to check to see if Curses will work (just a quick 
fork/exit/cleanup) 
 
2) with the preauth code, where it does a popen2 to a local 
imap daemon. 
 
Few people use preauth, and the Curses problem can easily 
be dismissed by switching to another ui (TTY.TTYUI perhaps?) 
 
I have observed that even the TTY.TTYUI leaves processes 
hanging around in Python 2.2 but not in Python 2.3. 
 
I suspect the original submitter is running the Tk interface; my 
own experimentation has shown it leaves lots of processes 
hanging around. 
 
However -- I have never seen zombie processes hanging 
around. 
 
The processes I see have blocked themselves with 
rt_sigsuspend. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-14 20:35

Message:
Logged In: YES 
user_id=6380

I agree with Martin von Loewis - this does not appear to be
a Python bug.

When a Python thread exits, it does not show up in the ps
listing as <defunct>; that to me suggests that there *is*
some forking going on, perhaps under the guise of system()
or popen(); or perhaps there's a bug in the C library's
thread support.

Lowering the priority as a result. I'll try to followup in
the Debian thread as well, if there's a web interface.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-13 07:05

Message:
Logged In: YES 
user_id=21627

The analysis that this is a Python bug is most likely wrong.
You write

> a number of defunct/zombie processes are spawned.

then John Goerzen writes

> It is likely, in any case, that this is a bug in Python
itself.   The 
> OfflineIMAP program does not fork 

However, John later points out that there are many threads
used in this package. Please understand that threads show up
as processes in Linux ps(1).

IOW, what you are seeing are the many threads, not any
additional processes.

It appears that the system is waiting for somebody to call
pthread_join. This should not be necessary, since Python
invokes pthread_detach for all of its threads. So if the
system does not reclaim terminated threads, it seems there
is a bug in your C library.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 17:53:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 09:53:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-751276 ] cPickle doesn't raise error, pickle does (recursiondepth)
Message-ID: <E19RxEy-0008A8-00@sc8-sf-web4.sourceforge.net>

Bugs item #751276, was opened at 2003-06-09 11:13
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle doesn't raise error, pickle does (recursiondepth)

Initial Comment:
I have this object that causes a recursive call in the
__getattr__ method.

When I unpicke it using pickle, I get a runtimeerror
recursiondepth exceeded. When I unpickle it using
cPickle, everything appears to work -- no error is raised.
(tested on python 2.2.3 and 2.3b1)

The output of the attached python test file is:

***pickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
FAIL!!!  <exceptions.RuntimeError instance at
0x00951C68> maximum recursion depth exceeded
***cPickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
SUCCESS!!! name= myname


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-16 16:53

Message:
Logged In: YES 
user_id=31392

cPickle has a load of PyErr_Clear() calls (well, 13) that
will mask bugs in user code.  I think it's worth fixing
them, but it is a non-trivial project.  I may take a crack
at it, but patches would help.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 19:19

Message:
Logged In: YES 
user_id=21627

I see. The problem occurs when trying to find __setstate__.
pickle.py uses getattr("setstate", None), which only masks
AttributeError, passing RuntimeError through. cPickle masks
all exceptions. It would be indeed possible to have one
match the other.

Reopening the report. Notice that there are dozens such
inconsistencies, so it will be a sisyphus job to fix them all.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2003-06-14 17:08

Message:
Logged In: YES 
user_id=129426

I fail to understand why this cannot be fixed. Is the
cPickle implementation that different from the pickle one?
In this particular case: it doesn't use __getattr__ the same
way as pickle does, apparently. 

Increasing sys.setrecursionlimit won't help because the
recursion is  infinite.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 14:23

Message:
Logged In: YES 
user_id=21627

This problem cannot be fixed. cPickle and pickle work
differently by nature; one is written in C, the other in
Python (as their names suggest).

You can try to sys.setrecursionlimit, to raise the nesting
level that pickle.py supports.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 19:18:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 11:18:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-751933 ] 2.2.3 Latex documentation missing from web page?
Message-ID: <E19RyYb-00004y-00@sc8-sf-web3.sourceforge.net>

Bugs item #751933, was opened at 2003-06-10 10:13
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751933&group_id=5470

Category: Documentation
Group: Python 2.2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 2.2.3 Latex documentation missing from web page?

Initial Comment:
The files named latex-2.2.3.tgz and latex-2.2.3.tar.bz2 in
ftp://python.org/pub/python/doc/2.2.3 appear to contain
documentation for Python 2.3b1 and not for Python 2.2.3.
Is the LaTeX version of the Python 2.2.3 documentation
available elsewhere?

Thanks,

Mark

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-06-16 14:18

Message:
Logged In: YES 
user_id=3066

Ok, after half a second of looking at this, I have a pretty
good idea of how it happened.  Very simply, the build
process for the distrubuted files doesn't know what tag from
the repository to export, so it exports the HEAD.  When it's
right, that's fine, but it's never right for the maintenance
tracks.  So the Doc/tools/mksourcepkg script needs to
receive another argument (a tag which hasn't been defined
when it gets run) or it's gonig to have to get smarter.

For now, I've fixed the 2.2.3 LaTeX packages.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 10:17

Message:
Logged In: YES 
user_id=21627

Fred, any idea how that happened?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751933&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 19:35:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 11:35:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-654558 ] make error reporting better like cgi
Message-ID: <E19RypN-0002hK-00@sc8-sf-web2.sourceforge.net>

Bugs item #654558, was opened at 2002-12-16 05:33
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470

>Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Hunter Peress (hfastedge)
Assigned to: Nobody/Anonymous (nobody)
Summary: make error reporting better like cgi

Initial Comment:
do something bad in something that uses cgitb, it will
show you actual values of the variables at that point
in the error message....and a host of useful info.

I think this should be done normally as well.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-06-16 13:35

Message:
Logged In: YES 
user_id=44345

duplicate of 569574


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-24 11:46

Message:
Logged In: YES 
user_id=6656

OK, but we don't use priorities like that in this project. 
All it acheives is winding people up.

----------------------------------------------------------------------

Comment By: Hunter Peress (hfastedge)
Date: 2003-01-24 11:36

Message:
Logged In: YES 
user_id=479934

montanaro: FIRST, I put the priority on 9 because I finally
added a huge chunk of code to show what I was talking about.
Given this , and since this bug was in the system for so
long, I flagged it to 9, solely so that it would reget some
needed attention, and then  expecting one of the powers that
be to bring it back down to normal.

WELL: not only did you not do this. You closed the bug, AND
you completely did not comprehend what its point is.

Quickly: i show the the STRENGTHS of  the error reporting
mechanism in cgitb, and this bug suggests that some (if not
all) features should be implemented in the normal interpreter.

Most useful is the fact that you get to see values of all
variables on the line causing error.

As you can see, i reflagged this to 9 solely to get your
attention. please bring it back down to 5 when u read this.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-24 11:17

Message:
Logged In: YES 
user_id=44345

Please don't needlessly boost priorities.  This is hardly of highest priority (it doesn't crash the interpreter, for example).

The issue of invoking cgitb functionality automatically was discussed at length when the module was first added to the system.  It was decided that the possibility for breakage was too great.  After all, other people have almost certainly had to address this problem in their own cgi scripts.  Invoking cgitb may thwart those mechanisms, or worse, present clues about
the internal workings of the system which would give bad guys help 
breaking into systems.

In short, feel free to import cgitb into your own cgi scripts, but don't
force others to use it if they choose not to.

----------------------------------------------------------------------

Comment By: Hunter Peress (hfastedge)
Date: 2003-01-23 17:20

Message:
Logged In: YES 
user_id=479934

HOW TO REPRODUCE:

We are going to test a basic piece of logic. In normal
interpreter (from cmdline), and in cgi mode. We will see
just how different the error reporting is:

<b>FIRST the basic LOGIC:
l=[1,2,3,4,5]
for i in range(len(l)):
    print i,l[i],l ; del l[i]

Next implement it in CGI:
#!/usr/bin/python2.2
import sys,commands,os,re,string,cgi,cgitb
cgitb.enable(1)
print "Content-type: text/html\n\n"
LOGIC GOES HERE

NOW Observe how nice the error is:
 /home/hperes/public_html/cgi-bin/cgiShow.cgi
    4 print "Content-type: text/html\n\n"
    5 print "HI"
    6 l=[1,2,3,4,5]
    7 for i in range(len(l)):
    8     print i,l[i],l ; del l[i]
i = 3, l = [2, 4]

IndexError: list index out of range
      __doc__ = 'Sequence index out of range.'
      __getitem__ = <bound method IndexError.__getitem__ of
<exceptions.IndexError instance at 0x8185c14>>
      __init__ = <bound method IndexError.__init__ of
<exceptions.IndexError instance at 0x8185c14>>
      __module__ = 'exceptions'
      __str__ = <bound method IndexError.__str__ of
<exceptions.IndexError instance at 0x8185c14>>
      args = ('list index out of range',) 

See how you can see the values of all the variables on the
line??


Next implement it in cmdline:
0 1 [1, 2, 3, 4, 5]
1 3 [2, 3, 4, 5]
2 5 [2, 4, 5]
3
Traceback (most recent call last):
  File "s", line 5, in ?
    print i,l[i],l ; del l[i]
IndexError: list index out of range


See how much more useless that is?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 19:39:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 11:39:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-511261 ] WIN32 os.path.normpath('./') incorrect
Message-ID: <E19Rysw-0002u1-00@sc8-sf-web2.sourceforge.net>

Bugs item #511261, was opened at 2002-01-31 17:22
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=511261&group_id=5470

Category: Python Library
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Steven Knight (stevenknight)
Assigned to: Nobody/Anonymous (nobody)
Summary: WIN32 os.path.normpath('./') incorrect

Initial Comment:
os.path.normpath() on WIN32 systems returns a null 
string for . followed by a directory separator:

>>> os.path.normpath('./')
''
>>> os.path.normpath('.\')
''
>>> os.path.normpath('.')
'.'
>>>

Contrast with what happens on Linux:

>>> os.path.normpath('./')
'.'
>>> os.path.normpath('.')
'.'
>>>

Sorry, I don't have a later version than 2.1.1 
available to check whether this is fixed in a later 
version, but I did do a search for other reports of 
this bug and found none.

    --SK




----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-16 20:39

Message:
Logged In: YES 
user_id=89016

It seems that this has been fixed in ntpath.py rev 1.41:
$ cvs up -r 1.41 Lib/ntpath.py
P Lib/ntpath.py
$ ./pcbuild/python
Python 2.3b1+ (#40, Jun 16 2003, 18:55:59) [MSC v.1200 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import ntpath
>>> ntpath.normpath(".")
'.'
>>> ntpath.normpath("./")
'.'
>>> ntpath.normpath(".\")
'.'
>>>

$ cvs up -r 1.40 Lib/ntpath.py
P Lib/ntpath.py
$ ./pcbuild/python
Python 2.3b1+ (#40, Jun 16 2003, 18:55:59) [MSC v.1200 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import ntpath
>>> ntpath.normpath(".")
'.'
>>> ntpath.normpath("./")
''
>>> ntpath.normpath(".\")
''

rev 1.41 was part of Python 2.2, so I think we can close
this bug.

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-04 19:42

Message:
Logged In: YES 
user_id=716326

This appears to be fixed in 2.3b1:

Python 2.3b1 (#40, Apr 25 2003, 19:06:24) [MSC v.1200 32 
bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import os
>>> os.path.normpath('./')
'.'
>>> os.path.normpath('.\')
'.'
>>> os.path.normpath('.')
'.'

----------------------------------------------------------------------

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 16:36

Message:
Logged In: YES 
user_id=4923

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.normpath('./')
'.'
>>> os.path.normpath('.\')
'.'
>>> os.path.normpath('.')
'.'
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=511261&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 19:44:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 11:44:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-753711 ] Infinite Loop in RE
Message-ID: <E19Ryy2-0007Le-00@sc8-sf-web1.sourceforge.net>

Bugs item #753711, was opened at 2003-06-12 19:27
Message generated for change (Comment added) made by glchapman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470

Category: Regular Expressions
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Bogosian (mbogosian)
Assigned to: Fredrik Lundh (effbot)
Summary: Infinite Loop in RE

Initial Comment:
This *may* be similar to
<http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=439997>,
but I don't think the current behavior (infinite
loop/unbound execution) is correct.

Here's the python version:

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - 

#!/usr/bin/python

import re

pattern =
'^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,'

# This won't match (missing ',' at end
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

re.search(pattern, str, re.I)

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - 

When run, this script just pegs the CPU and hangs (I'm
running RedHat 8.0). Note: if I change the pattern
slightly it still doesn't work:

pattern = '^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*([^
=,]+\s*)+,'

It's not until the pattern actually matches that things
get better (with both the original and modified patterns):

# Pattern now matches (added a ',' at the end)
str = 'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP),'

I tried doing the same thing in Perl:

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - 

#!/usr/bin/perl

'UPDATE arena_teams SET locked_until =
CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)' =~
'/UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,/i';

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - 

This of course runs just fine. Any ideas?

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-06-16 10:44

Message:
Logged In: YES 
user_id=86307

FWIW, one way to efficiently match this sort of pattern 
(where you have literal text at the end of something 
complex) would be to use the match once and don't 
backtrack operator ('(?>pattern)').  SRE doesn't have the 
(?> operator, but it can be emulated by '(?=(pattern))\1'.  
So one way to avoid the exponential time would be to use 
something like this:

rx = re.compile(
   r'''^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*
   (?=(
       ([^=,]+\s*)+
   ))\1
   ,         #trailing literal
   ''', 
   re.I | re.X
)

By the way, it would be fairly easy to add the (?> operator to 
SRE; it's almost identical to a postive lookahead assertion.  
The only difference is that, upon successfully matching the 
subexpression inside the parentheses, the position in the 
string being matched is advanced to the end of the text 
matched by the subexpression.

Also, in case anyone's interested in why Perl is able to fail so 
quickly here, it appears that the Perl engine keeps track of 
positions (in the target text) where something like 
'(pattern)+' has already been tried and has failed, so it can 
quickly fail if backtracking causes an attempt to match again 
at that position (at least that's my interpretation of the 
numerous "already tried at this position..." messages in the 
trace from running the supplied pattern and text with "use 
re 'debug';").


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-14 20:28

Message:
Logged In: YES 
user_id=357491

sjones is right about it taking exponential time.  A regex engine 
works with greedy quantifiers by sucking up all that it can and 
then trying the next part of the regex and continues until it fails 
or succeeds.  If it fails, though, it backtracks one regex character, 
gives up a character it claimed, and tries again.  It does this for a 
long time.

How long did you wait for the regex to complete?  I bet if you left 
it for a *very* long time it would complete.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 13:42

Message:
Logged In: YES 
user_id=589306

If you change your regex and sample data to the following
simpler forms, you get the same problem:

pattern = '(\S+\s*)+,'
str = 'CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

If you remove some letters from str, the search does finish
but it takes several seconds. I believe the problem is that
your regex takes exponential time to execute based on the
length of str. Here is a recent python-dev post that talks
about the problem:

http://mail.python.org/pipermail/python-dev/2003-May/035916.html

The link you provided in the bug report talks about this as
well. You can also do a web search for "regular expression
exponential" to see more information. I believe that any
regex engine (that has similar features to Python's engine)
will have some regular expressions that take exponential
time or space. Perl has some cases as well (search for
"exponential" in perldoc perlre).  This is just how regular
expressions are and IMHO does not indicate a bug in Python.

As far as how to fix the regular expression, I can't say.
I'm sure there is a way to "rephrase" what you want to get
it to work. Maybe try asking in the comp.lang.python newsgroup.

Good luck!


----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-13 04:15

Message:
Logged In: YES 
user_id=589306

If you change your regex and sample data to the following
simpler forms, you get the same problem:

pattern = '(\S+\s*)+,'
str = 'CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)'

If you remove some letters from str, the search does finish
but it takes several seconds. I believe the problem is that
your regex takes exponential time to execute based on the
length of str. Here is a recent python-dev post that talks
about the problem:

http://mail.python.org/pipermail/python-dev/2003-May/035916.html

The link you provided in the bug report talks about this as
well. You can also do a web search for "regular expression
exponential" to see more information. I believe that any
regex engine (that has similar features to Python's engine)
will have some regular expressions that take exponential
time or space. Perl has some cases as well (search for
"exponential" in perldoc perlre).  This is just how regular
expressions are and IMHO does not indicate a bug in Python.

As far as how to fix the regular expression, I can't say.
I'm sure there is a way to "rephrase" what you want to get
it to work. Maybe try asking in the comp.lang.python newsgroup.

Good luck!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 19:59:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 11:59:58 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-753600 ] why should += produce name binding?
Message-ID: <E19RzCw-0003qT-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #753600, was opened at 2003-06-12 18:16
Message generated for change (Comment added) made by gregsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: why should += produce name binding?

Initial Comment:

Currently, in

def x():
     foo += 1

... 'foo' is a local variable. Why should it be?
If the semantics are changed so that augmented
assignment is not a name-binding operation,
then only broken code will be affected.

This would allow you to use simple things
like   'EventCount += 1' without having to
use 'global EventCount'. After all, I can do
'EventList.append(...)' without the global decl.

For another (better) example, see 
http://mail.python.org/pipermail/edu-sig/2001-June/001329.html

In the response to the above, the poster is referred
to PEP227 which lists 'assignment' as a name-binding
operation. There is no clear-cut implication that this
includes augmented assignment, and in the Python
ref manual, one can only infer this behaviour from
the statement that x += y is almost equivalent
to x = x+y, which is pretty weak. In any case, since
an augmented assignment to a name always requires the
a-priori existence of that name in
an accessible namespace,  IMHO it should not
produce a binding.


















----------------------------------------------------------------------

>Comment By: Gregory Smith (gregsmith)
Date: 2003-06-16 14:59

Message:
Logged In: YES 
user_id=292741

I was not proposing any change to 
the semantics of the operation itself.
Currently, all symbols in a function
definition are locals by default if
they appear as the target of a name
binding operation: "argument
declaration, assignment, class and
function definition, import statements,
for statements and except clauses"
according to PEP227.

I was proposing that augmented assignments
be removed from this list. So that,

def x():
	cnt += 1

(currently unusable) would be equivalent
to 

def x():
	global cnt
	cnt += 1


whereas this would remain unusable:

def x():
	cnt = cnt + 1

Clearly, this change is independent of
whether or not x is mutable since the
parser can't tell. 

Taking another look at Kirby Urner's June/01
message (see link in original msg), I see
a subtley which maybe is what loewis
was alluding to. Urner 'fixes' the problem
there (which relates to nested scopes) by copying
an outer local variable in to a local and
doing += on it (e.g. replacing a+=1 by
s=a; s+=1); this may or may not change 
'a' in the outer scope depending 
on whether it is mutable, whereas the proposed
functionality of a+=1 would change it. The
's=a; s+=1' will never rebind 'a', whereas
the proposed 'a+=1' may do so (but probably
only when it is immutable, when the
change of id is an inevitable side effect
anyway).


So, looking at it again, the example
either adds some more ammo
to my point, or kills it. Suppose you
really want to change 'a': you can't fix
this by using 'global a', since that
would select the top-level scope, not the
containing scope.

Question is, should a nested function
be allowed to do += on an outer
function's local variables, potentially
rebinding them? maybe not. In any case,
as long as there is no way to do direct
assignment on those variables, it would
be a little strange to be allowed +=.

This has tipped the scales for me.
PEP  retracted, on the basis of
my possibly flawed understanding of
this point ...




----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 10:20

Message:
Logged In: YES 
user_id=80475

In your example, I prefer the global declaration for 
EventCount.  It adds clarity and allows the reader to 
understand the function without reading the enclosing 
scopes.

I do agree the the += semantics are thorny area for python, 
I prefer the current binding behavior which is what I expect 
out of an assignment operation.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 12:24

Message:
Logged In: YES 
user_id=21627

Can you please explain, in detail, what semantics you
propose for += if the variable does not refer to a mutable
object?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 20:40:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 12:40:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-755080 ] AssertionError from urllib.retrieve / httplib
Message-ID: <E19Rzpj-0001R2-00@sc8-sf-web1.sourceforge.net>

Bugs item #755080, was opened at 2003-06-16 00:37
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755080&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: AssertionError from urllib.retrieve / httplib

Initial Comment:

The following statement is occasionally generating
AssertionErrors:
    current_page = urllib.urlopen(action,data).read()

Traceback (most recent call last):
  File "/Users/zen/bin/autospamrep.py", line 161, in ?
    current_page = handle_spamcop_page(current_page)
  File "/Users/zen/bin/autospamrep.py", line 137, in 
handle_spamcop_page
    current_page = urllib.urlopen(action,data).read()
  File "/sw/lib/python2.3/httplib.py", line 1150, in read
    assert not self._line_consumed and self._line_left


Fix may be to do the following in 
LineAndFileWrapper.__init__ (last two lines are new):

def __init__(self, line, file):
        self._line = line
        self._file = file
        self._line_consumed = 0
        self._line_offset = 0
        self._line_left = len(line)
        if not self._line_left:
            self._done()


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-16 19:40

Message:
Logged In: YES 
user_id=31392

Can you reproduce this problem easily?  We've seen something
like it before, but have had trouble figuring out what goes
wrong.


----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-16 00:55

Message:
Logged In: YES 
user_id=46639

My suggested fix is wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755080&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 21:18:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 13:18:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-751276 ] cPickle doesn't raise error, pickle does (recursiondepth)
Message-ID: <E19S0Ql-0007MN-00@sc8-sf-web2.sourceforge.net>

Bugs item #751276, was opened at 2003-06-09 11:13
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Irmen de Jong (irmen)
>Assigned to: Jeremy Hylton (jhylton)
Summary: cPickle doesn't raise error, pickle does (recursiondepth)

Initial Comment:
I have this object that causes a recursive call in the
__getattr__ method.

When I unpicke it using pickle, I get a runtimeerror
recursiondepth exceeded. When I unpickle it using
cPickle, everything appears to work -- no error is raised.
(tested on python 2.2.3 and 2.3b1)

The output of the attached python test file is:

***pickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
FAIL!!!  <exceptions.RuntimeError instance at
0x00951C68> maximum recursion depth exceeded
***cPickle***
Creating t...
Thing.__init__ name= myname
Pickle t...
Restore t...
SUCCESS!!! name= myname


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-16 20:18

Message:
Logged In: YES 
user_id=31392

Fixed in rev 2.146 of cPickle.c.
It was easier than I thought.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-16 16:53

Message:
Logged In: YES 
user_id=31392

cPickle has a load of PyErr_Clear() calls (well, 13) that
will mask bugs in user code.  I think it's worth fixing
them, but it is a non-trivial project.  I may take a crack
at it, but patches would help.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 19:19

Message:
Logged In: YES 
user_id=21627

I see. The problem occurs when trying to find __setstate__.
pickle.py uses getattr("setstate", None), which only masks
AttributeError, passing RuntimeError through. cPickle masks
all exceptions. It would be indeed possible to have one
match the other.

Reopening the report. Notice that there are dozens such
inconsistencies, so it will be a sisyphus job to fix them all.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2003-06-14 17:08

Message:
Logged In: YES 
user_id=129426

I fail to understand why this cannot be fixed. Is the
cPickle implementation that different from the pickle one?
In this particular case: it doesn't use __getattr__ the same
way as pickle does, apparently. 

Increasing sys.setrecursionlimit won't help because the
recursion is  infinite.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 14:23

Message:
Logged In: YES 
user_id=21627

This problem cannot be fixed. cPickle and pickle work
differently by nature; one is written in C, the other in
Python (as their names suggest).

You can try to sys.setrecursionlimit, to raise the nesting
level that pickle.py supports.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751276&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 21:28:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 13:28:59 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-753600 ] why should += produce name binding?
Message-ID: <E19S0b5-0003ji-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #753600, was opened at 2003-06-13 00:16
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: why should += produce name binding?

Initial Comment:

Currently, in

def x():
     foo += 1

... 'foo' is a local variable. Why should it be?
If the semantics are changed so that augmented
assignment is not a name-binding operation,
then only broken code will be affected.

This would allow you to use simple things
like   'EventCount += 1' without having to
use 'global EventCount'. After all, I can do
'EventList.append(...)' without the global decl.

For another (better) example, see 
http://mail.python.org/pipermail/edu-sig/2001-June/001329.html

In the response to the above, the poster is referred
to PEP227 which lists 'assignment' as a name-binding
operation. There is no clear-cut implication that this
includes augmented assignment, and in the Python
ref manual, one can only infer this behaviour from
the statement that x += y is almost equivalent
to x = x+y, which is pretty weak. In any case, since
an augmented assignment to a name always requires the
a-priori existence of that name in
an accessible namespace,  IMHO it should not
produce a binding.


















----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-16 22:28

Message:
Logged In: YES 
user_id=21627

Just *not* making += a name-binding operation has a
different effect than the one you expect. There would *not*
be an implicit global declaration. Instead, lookup would
first find the global. It then would invoke __iadd__, which
is not supported for integers. So it would fall-back to
__add__, which produces a new value. Since += is not
name-binding, no name would be bound by that operation, so
the result is simply discarded. IOW, your example would be
equivalent to

def x():
  cnt + 1

which, I assume, is not what you want.

OTOH, I can also interpret your last message as saying "+="
should imply a global statement. In that case, the function

def y():
  cnt = 1
  cnt += 1

would change to

def y():
  global cnt
  cnt = 1
  cnt += 1

which I think is also not what you want. So what is it that
you want?

I interpret your last sentence that you withdraw this RFE;
so I'm closing it.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2003-06-16 20:59

Message:
Logged In: YES 
user_id=292741

I was not proposing any change to 
the semantics of the operation itself.
Currently, all symbols in a function
definition are locals by default if
they appear as the target of a name
binding operation: "argument
declaration, assignment, class and
function definition, import statements,
for statements and except clauses"
according to PEP227.

I was proposing that augmented assignments
be removed from this list. So that,

def x():
	cnt += 1

(currently unusable) would be equivalent
to 

def x():
	global cnt
	cnt += 1


whereas this would remain unusable:

def x():
	cnt = cnt + 1

Clearly, this change is independent of
whether or not x is mutable since the
parser can't tell. 

Taking another look at Kirby Urner's June/01
message (see link in original msg), I see
a subtley which maybe is what loewis
was alluding to. Urner 'fixes' the problem
there (which relates to nested scopes) by copying
an outer local variable in to a local and
doing += on it (e.g. replacing a+=1 by
s=a; s+=1); this may or may not change 
'a' in the outer scope depending 
on whether it is mutable, whereas the proposed
functionality of a+=1 would change it. The
's=a; s+=1' will never rebind 'a', whereas
the proposed 'a+=1' may do so (but probably
only when it is immutable, when the
change of id is an inevitable side effect
anyway).


So, looking at it again, the example
either adds some more ammo
to my point, or kills it. Suppose you
really want to change 'a': you can't fix
this by using 'global a', since that
would select the top-level scope, not the
containing scope.

Question is, should a nested function
be allowed to do += on an outer
function's local variables, potentially
rebinding them? maybe not. In any case,
as long as there is no way to do direct
assignment on those variables, it would
be a little strange to be allowed +=.

This has tipped the scales for me.
PEP  retracted, on the basis of
my possibly flawed understanding of
this point ...




----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 16:20

Message:
Logged In: YES 
user_id=80475

In your example, I prefer the global declaration for 
EventCount.  It adds clarity and allows the reader to 
understand the function without reading the enclosing 
scopes.

I do agree the the += semantics are thorny area for python, 
I prefer the current binding behavior which is what I expect 
out of an assignment operation.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 18:24

Message:
Logged In: YES 
user_id=21627

Can you please explain, in detail, what semantics you
propose for += if the variable does not refer to a mutable
object?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 22:37:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 14:37:34 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-753600 ] why should += produce name binding?
Message-ID: <E19S1fS-0004yt-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #753600, was opened at 2003-06-12 18:16
Message generated for change (Comment added) made by gregsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470

Category: Parser/Compiler
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: why should += produce name binding?

Initial Comment:

Currently, in

def x():
     foo += 1

... 'foo' is a local variable. Why should it be?
If the semantics are changed so that augmented
assignment is not a name-binding operation,
then only broken code will be affected.

This would allow you to use simple things
like   'EventCount += 1' without having to
use 'global EventCount'. After all, I can do
'EventList.append(...)' without the global decl.

For another (better) example, see 
http://mail.python.org/pipermail/edu-sig/2001-June/001329.html

In the response to the above, the poster is referred
to PEP227 which lists 'assignment' as a name-binding
operation. There is no clear-cut implication that this
includes augmented assignment, and in the Python
ref manual, one can only infer this behaviour from
the statement that x += y is almost equivalent
to x = x+y, which is pretty weak. In any case, since
an augmented assignment to a name always requires the
a-priori existence of that name in
an accessible namespace,  IMHO it should not
produce a binding.


















----------------------------------------------------------------------

>Comment By: Gregory Smith (gregsmith)
Date: 2003-06-16 17:37

Message:
Logged In: YES 
user_id=292741

I don't follow the first part. name binding does not
happen at run time, but at compile time.
 If there is no binding, the name would be assumed
global by the compiler. So you would get this for
the first two x() examples:

          9 LOAD_GLOBAL              0 (cnt)
         12 LOAD_CONST               1 (1)
         15 INPLACE_ADD
         16 STORE_GLOBAL             0 (cnt)


which is currently what you get if the 'global' is present,
and would work if the global var is present when run.

I was never suggesting that there should be an implicit
'global' on each +=, rather, that in the absence of
 *other* name binding operations on the same
name, += would fail to create a local -- which is
another way of saying that "+= is not a name
binding operation", which is the way
I phrased the request in the first place.

Basically, a+=1
would fall into the same category, in terms of name
scopes, as a.b +=1. There is no implicit 'global a'
when you write a.b +=1, or a(), but if you don't mention
'a' anywhere else, that's what you get.


I'm still confused as to why this is so radical - basically,
the rationale is that you can't += on a name if it
isn't defined, which, currently, it can't possibly be
if there are no other name binding ops in the block.

It seems unwarranted to create a local (at compile
time) due to the existence of an assignment op that requires
(at run time) that local to be previously
defined, and in the absence (at compile time)
of any statement that would cause it to be defined
at run time. But that is the current behaviour.

The problem with the RFE only occurs, in my view,
when you += on a local belonging to an enclosing
scope, since the consistent application of the RFE
would produce an operation (rebinding of an
enclosing scope's local variable) which may be harmful 
somehow, and for which an opcode may not even exist, since
this is currently impossible. This is what caused me to
retract it -
I hadn't seen that implication in the first place, and
don't know how to deal  with it.



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-16 16:28

Message:
Logged In: YES 
user_id=21627

Just *not* making += a name-binding operation has a
different effect than the one you expect. There would *not*
be an implicit global declaration. Instead, lookup would
first find the global. It then would invoke __iadd__, which
is not supported for integers. So it would fall-back to
__add__, which produces a new value. Since += is not
name-binding, no name would be bound by that operation, so
the result is simply discarded. IOW, your example would be
equivalent to

def x():
  cnt + 1

which, I assume, is not what you want.

OTOH, I can also interpret your last message as saying "+="
should imply a global statement. In that case, the function

def y():
  cnt = 1
  cnt += 1

would change to

def y():
  global cnt
  cnt = 1
  cnt += 1

which I think is also not what you want. So what is it that
you want?

I interpret your last sentence that you withdraw this RFE;
so I'm closing it.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2003-06-16 14:59

Message:
Logged In: YES 
user_id=292741

I was not proposing any change to 
the semantics of the operation itself.
Currently, all symbols in a function
definition are locals by default if
they appear as the target of a name
binding operation: "argument
declaration, assignment, class and
function definition, import statements,
for statements and except clauses"
according to PEP227.

I was proposing that augmented assignments
be removed from this list. So that,

def x():
	cnt += 1

(currently unusable) would be equivalent
to 

def x():
	global cnt
	cnt += 1


whereas this would remain unusable:

def x():
	cnt = cnt + 1

Clearly, this change is independent of
whether or not x is mutable since the
parser can't tell. 

Taking another look at Kirby Urner's June/01
message (see link in original msg), I see
a subtley which maybe is what loewis
was alluding to. Urner 'fixes' the problem
there (which relates to nested scopes) by copying
an outer local variable in to a local and
doing += on it (e.g. replacing a+=1 by
s=a; s+=1); this may or may not change 
'a' in the outer scope depending 
on whether it is mutable, whereas the proposed
functionality of a+=1 would change it. The
's=a; s+=1' will never rebind 'a', whereas
the proposed 'a+=1' may do so (but probably
only when it is immutable, when the
change of id is an inevitable side effect
anyway).


So, looking at it again, the example
either adds some more ammo
to my point, or kills it. Suppose you
really want to change 'a': you can't fix
this by using 'global a', since that
would select the top-level scope, not the
containing scope.

Question is, should a nested function
be allowed to do += on an outer
function's local variables, potentially
rebinding them? maybe not. In any case,
as long as there is no way to do direct
assignment on those variables, it would
be a little strange to be allowed +=.

This has tipped the scales for me.
PEP  retracted, on the basis of
my possibly flawed understanding of
this point ...




----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 10:20

Message:
Logged In: YES 
user_id=80475

In your example, I prefer the global declaration for 
EventCount.  It adds clarity and allows the reader to 
understand the function without reading the enclosing 
scopes.

I do agree the the += semantics are thorny area for python, 
I prefer the current binding behavior which is what I expect 
out of an assignment operation.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 12:24

Message:
Logged In: YES 
user_id=21627

Can you please explain, in detail, what semantics you
propose for += if the variable does not refer to a mutable
object?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=753600&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 22:42:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 14:42:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-755560 ] MacPython help needs "community" section
Message-ID: <E19S1ju-0001k9-00@sc8-sf-web3.sourceforge.net>

Bugs item #755560, was opened at 2003-06-16 23: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=755560&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacPython help needs "community" section

Initial Comment:
The MacPython help book needs one more page pointing to 
the SIG and other resources.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755560&group_id=5470


From noreply@sourceforge.net  Mon Jun 16 22:53:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 14:53:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-755564 ] Tutorial: 4.7.2 Keyword Arguments **name output order wrong
Message-ID: <E19S1uX-0007cl-00@sc8-sf-web1.sourceforge.net>

Bugs item #755564, was opened at 2003-06-17 00: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=755564&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Jan Mattila (kakkonen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial: 4.7.2 Keyword Arguments **name output order wrong

Initial Comment:
In the Tutorial at chapter 4.7.2 Keyword Arguments, 
there is an example about the formal parameter **name. 
I'm quoting the whole thing, for quick reference:

--- begin extract from Tutorial ---
def cheeseshop(kind, *arguments, **keywords):
    print "-- Do you have any", kind, '?'
    print "-- I'm sorry, we're all out of", kind
    for arg in arguments: print arg
    print '-'*40
    for kw in keywords.keys(): print kw, ':', keywords[kw]

It could be called like this:

cheeseshop('Limburger', "It's very runny, sir.",
           "It's really very, VERY runny, sir.",
           client='John Cleese',
           shopkeeper='Michael Palin',
           sketch='Cheese Shop Sketch')

and of course it would print:

-- Do you have any Limburger ?
-- I'm sorry, we're all out of Limburger
It's very runny, sir.
It's really very, VERY runny, sir.
----------------------------------------
client : John Cleese
shopkeeper : Michael Palin
sketch : Cheese Shop Sketch
--- end extract from Tutorial ---

What it actually prints on my LFS 3.3 (linuxfromscratch)
based distribution with Python 2.1.3 is

--- begin print out of cheeseshop ---
-- Do you have any Limburger ?
-- I'm sorry, we're all out of Limburger
It's very runny, sir.
It's really very, VERY runny, sir.
----------------------------------------
client : John Cleese
sketch : Cheese Shop Sketch
shopkeeper : Michael Palin
--- end print out of cheeseshop ---

The problem is that the keywords[kw] list order is
garbled. I tried stripping this function of the *arguments
formal parameter and I got the same result. I tried
different amounts of **keywords in different
aphabetical orders. The resulting order does not 
seem to be random and does not seem to be aplhabetical
nor related to the length of the **keywords or anything
I could figure out.

It's probably not a typo (on my part), because I copied 
the code straight from the Tutorial page. 

Now, this is not really a bug in my opinion, so I'm not 
expecting a fix, but I was just trying to read through
the Tutorial and try all the example code and got 
stuck trying to figure how you could tell the print order 
of a formal parameter **name -type's name[kw] list.

I was thinking, that maybe if someone of class wizard 
or higher would care to indulge me in the reason for 
this behaviour I could become enlightened on another 
aspect of Python. I'm not expecting swift replies, since
this is a zero-priority glitch, but someone, somewhere,
someday, maybe? No? Okay. Just a thought...

So much for trying to make this short.

I managed to reproduce the problem on Python 1.5.2
on Red Hat Linux 7.3.2 on linux-i386

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 00:38:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 16:38:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-751998 ] Object destruction is broken for slots
Message-ID: <E19S3Yf-0001Qd-00@sc8-sf-web4.sourceforge.net>

Bugs item #751998, was opened at 2003-06-10 11:55
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
>Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Object destruction is broken for slots

Initial Comment:
The following code worked without errors in
Python 2.3b1, but seems to be broken in
the current Python 2.3 CVS:

class Foo(object):
  __slots__ = ('bar','__dict__')

  def __init__(self):
    self.bar = 1
    self.baz = 2

  def __del__(self):
    print 'In __del__.'
    print '  baz =',self.baz
    print '  bar =',self.bar

foo=Foo()

Python 2.3b1: No error, output:
  In __del__.
    baz = 2
    bar = 1

However, the current CVS outputs:
  In __del__.
    baz = 2
    Exception exceptions.AttributeError: 'bar' in 
    <bound method Foo.__del__ of 
    <__main__.Foo object at 0x403ace6c>> ignored

Somehow, descriptor lookup seems to be failing
in objects that are in the process of being deleted,
since commenting out the __slots__ declaration 
makes the problem go away.

I wish I had time to look into this, but I'm currently 
swamped.  Hopefully this is the result of something
recent and this report will trigger some light-bulbs.
If not, I'll see if I can make time next week.  As it
stands, I see this as a serious bug, since it prevents
finalization from completing on these objects.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 19:38

Message:
Logged In: YES 
user_id=33168

Checked in a test too:
 * Lib/test/test_descr.py 1.194, 1.113.4.34
 * Objects/typeobject.c 2.126.4.39

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-13 16:57

Message:
Logged In: YES 
user_id=6380

Sorry, the checkin barfed and I didn't notice. Try again now.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-13 16:41

Message:
Logged In: YES 
user_id=33168

Hmm, did you check anything in?  The report says it's broken
in CVS, but works in 2.3b1.  It is still broken for me
without the patch.  Did you want me to test the patch and
then backport?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-13 15:42

Message:
Logged In: YES 
user_id=6380

Thanks! Fixed in CVS for 2.3. This should be backported to
2.2 too; assiged to Neal Norwitz for that purpose.


----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:24

Message:
Logged In: YES 
user_id=459565

er, see Bug 742911 instead.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:21

Message:
Logged In: YES 
user_id=459565

Oh, and with the patch, 'make test' completes without
any new errors, my attached test case works, as does
the minimal test case associated with Bug 751998.


----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 14:19

Message:
Logged In: YES 
user_id=459565

Okay, I had a few minutes free.  The problem is that
slots are being deallocated too early -- before tp_dealloc.
I'm attaching a patch that corrects this at the expense of
having to travel up the path of base class tp_dealloc
entries twice.  Here is the new sequence of actions:

1) Find the nearest base with a different tp_dealloc
2) Clear weakrefs
3) Call finalizer
4) Check to see if object was resurrected, if so stop
5) Clear all slots up to nearest base with a different 
    tp_dealloc
6) DECREF dict pointer, if necessary
7) proceed as usual... (call basedealloc, DECREF type, etc.)

Without my patch, step number 5  is done as part of step
1, and bad things happen.


----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2003-06-10 13:07

Message:
Logged In: YES 
user_id=459565

The fix checked in to solve Bug 751998 is the cause of this
potentially more serious one bug.  I have yet to figure 
out why, though I have isolated the problem to revision
2.234 of typeobject.c.  I've not looked to see if this also 
affects Python 2.2.3, though I wouldn't be too suprised if it 
does.

More soon, hopefully.  Maybe...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751998&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 00:40:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 16:40:23 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-229840 ] IDLE needs to print !
Message-ID: <E19S3aJ-0001Tm-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #229840, was opened at 2001-01-23 13:52
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=229840&group_id=5470

Category: IDLE
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: Charles Doutriaux (cdoutri)
Assigned to: Neal Norwitz (nnorwitz)
Summary: IDLE needs to print !

Initial Comment:
It'd be really nice if idle had a print function, all these nice colors got to be printed ! or at least a postscript output would be nice.

Thanks,

C.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 19:40

Message:
Logged In: YES 
user_id=33168

Now that IDLEfork has been integrated back into Python 2.3,
I'm closing this.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 15:37

Message:
Logged In: YES 
user_id=33168

Reminder to close once IDLEfork is merged.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-10 12:46

Message:
Logged In: YES 
user_id=31435

Changed Category to IDLE.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-23 21:40

Message:
The kind folks from reportlab.com once contributed a printing function.  it was kind of slow though.  But maybe it should still be added.  I think I have it somewhere still.  The problem is the licensing (it's not relesed under the same license as Python itself).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=229840&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 00:41:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 16:41:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-646730 ] Can't run script from IDLE
Message-ID: <E19S3ba-0003Ij-00@sc8-sf-web1.sourceforge.net>

Bugs item #646730, was opened at 2002-12-01 19:44
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470

Category: IDLE
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Can't run script from IDLE

Initial Comment:
When I try to run any of my scripts from the IDLE GUI, 
in Windows, through the Edit>Run Scipt menuitem, all I 
get is this error:

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python22\lib\lib-tk\Tkinter.py", line 1300, in 
__call__
    return apply(self.func, args)
  File "C:\Python22\Tools\idle\ScriptBinding.py", line 
151, in run_script_event
    interp.execfile(filename)
  File "C:\Python22\Tools\idle\PyShell.py", line 178, in 
execfile
    code = compile(source, filename, "exec")
UnicodeError: ASCII encoding error: ordinal not in range
(128)

I checked the stack-trace, and saw that the "ordinal" it's 
complaining about must be the "å" in my Windows user 
name.  IMHO, I should be able to run scripts even if my 
user name isn't all ASCII ...

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 19:41

Message:
Logged In: YES 
user_id=33168

This should be fixed now that IDLEfork has been merged back
into Python 2.3.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-02 09:54

Message:
Logged In: YES 
user_id=33168

If you think it's important, I suppose.  I don't find it
that important.  But I have no idea how difficult it is to
fix.  If it was simple, I would want it fixed.

----------------------------------------------------------------------

Comment By: Håkan Waara (hwaara)
Date: 2002-12-02 09:51

Message:
Logged In: YES 
user_id=72743

nnorwitz, thanks for your help.

Should I file a bug about the lowercase issue?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-02 09:37

Message:
Logged In: YES 
user_id=33168

Håkan, idlefork will be merged back into python.  So after
the merge, everything should be fine for python 2.2.3 and
2.3.  I will leave this bug open until after the merge.

As for the lower casing, I have no idea.

If you have time, it would be great if you could test idlefork.
An alpha release will be made soon, but the more testing it
gets the better.

----------------------------------------------------------------------

Comment By: Håkan Waara (hwaara)
Date: 2002-12-02 09:25

Message:
Logged In: YES 
user_id=72743

By the way, as a separate note... this is is how it looks:

Traceback (innermost last)
  File "c:\documents and settings\håkan\skrivbord\guitest.py", 
line 22, in ?
<snip>

Shouldn't the path be case-sensitive? It's all-lowercase above, 
whereas it should have quite a few uppercase chars... 
However, I'm happy as long as it works!

----------------------------------------------------------------------

Comment By: Håkan Waara (hwaara)
Date: 2002-12-02 09:23

Message:
Logged In: YES 
user_id=72743

In idlefork it worked! Woo-hoo! And when I ran into an 
exception, even the "å" in "Håkan" was written out correctly.

So this gotta mean that there's a patch waiting, if only the 
IDLE maintainers will accept it? How should we go forward?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-01 23:50

Message:
Logged In: YES 
user_id=33168

Can you try the version from idlefork?  See idlefork.sf.net.

----------------------------------------------------------------------

Comment By: Håkan Waara (hwaara)
Date: 2002-12-01 19:49

Message:
Logged In: YES 
user_id=72743

More info.  Here's the path to my script, in Windows:

*  C:\Documents and Settings\Håkan\Skrivbord\guitest.py

and here it is, kind of thrashed, as I intercepted it in the stack 
trace:

*  u'C:\Documents and 
Settings\H\xe5kan\Skrivbord\guitest.py'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 00:42:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 16:42:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-527022 ] raw_input non-ascii failure on Linux/KDE
Message-ID: <E19S3c9-0003K8-00@sc8-sf-web1.sourceforge.net>

Bugs item #527022, was opened at 2002-03-07 11:31
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527022&group_id=5470

Category: IDLE
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Neal Norwitz (nnorwitz)
Summary: raw_input non-ascii failure on Linux/KDE

Initial Comment:
With default encoding left as 'ascii', interactively
doing x=raw_input('say something funny: ') and 
entering a non-ascii character seems to work OK
in a textmode interactive interpreter (Linux 
Mandrake
8.1 and KDE Console, Win98) and on IDLE on Win98.  
On
IDLE with Linux Mandrake 8.1 and KDE, though:

Python 2.2 (#1, Dec 23 2001, 20:09:01) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 
2.96-0.62mdk)] on linux2
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> palö
UnicodeError: ASCII encoding error: ordinal not in 
range(128)
>>> x=raw_input('say something funny: ')
say something funny: palö
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in ?
    x=raw_input('say something funny: ')
TypeError: object.readline() returned non-string
>>> 

This came up on python-help (not sure what platform 
the querant was using), I originally didn't think of
it as a bug and told the querant to change the 
default encoding in site.py, but Skip doubted that
was OK and asked on python-list, where Martin said:

"In IDLE, I'd say there is a bug somewhere. I'm not 
sure what ... If there is a bug, it is ok to work 
around it with any means you find.
It would be better to report it to SF, though."

so here it is, the SF bug report as requested.


Alex


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 19:42

Message:
Logged In: YES 
user_id=33168

Now that IDLEfork has been merged into 2.3, this should be
fixed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-13 17:13

Message:
Logged In: YES 
user_id=33168

This is fixed in IDLEfork.  Remind to close when idlefork is
merged.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527022&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 01:07:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 17:07:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-751956 ] graminit.[ch] don't build on windows
Message-ID: <E19S40O-00026B-00@sc8-sf-web4.sourceforge.net>

Bugs item #751956, was opened at 2003-06-10 10:47
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751956&group_id=5470

>Category: Parser/Compiler
>Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Duncan Booth (duncanb)
>Assigned to: Tim Peters (tim_one)
Summary: graminit.[ch] don't build on windows

Initial Comment:
Using grammar.mak to build new graminit.c and 
graminit.h files doesn't currently work on windows.

The line in grammar.mak:

CFLAGS= /I ..\Include /I ..\PC /D 
MS_NO_COREDLL  /MD

needs to be changed to:

CFLAGS= /I ..\Include /I ..\PC /D 
MS_NO_COREDLL /D PGEN /MD

otherwise you get an undefined symbol when 
attempting to link caused by a reference to 
PyExc_DeprecationWarning in tokenizer.c.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-16 20:07

Message:
Logged In: YES 
user_id=31435

Thanks!  Changes applied, in Parser/grammar.mak, rev 1.3.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751956&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 01:13:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 17:13:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19S461-0002HW-00@sc8-sf-web4.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 17: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=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 01:21:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 17:21:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-755618 ] os module: Need a better description of "mode"
Message-ID: <E19S4ES-0004UM-00@sc8-sf-web1.sourceforge.net>

Bugs item #755618, was opened at 2003-06-16 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=755618&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755618&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 02:05:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 18:05:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-755618 ] os module: Need a better description of "mode"
Message-ID: <E19S4un-000279-00@sc8-sf-web2.sourceforge.net>

Bugs item #755618, was opened at 2003-06-16 20:21
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755618&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 21:05

Message:
Logged In: YES 
user_id=33168

Closing. Duplicate of 755617.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755618&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 02:06:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 18:06:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19S4vq-0003nr-00@sc8-sf-web4.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 20:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 21:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 02:28:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 18:28:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-744164 ] ipv6 sockaddr is bad
Message-ID: <E19S5Gn-0002lZ-00@sc8-sf-web2.sourceforge.net>

Bugs item #744164, was opened at 2003-05-27 10:22
Message generated for change (Comment added) made by cypherpunks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744164&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cypherpunks (cypherpunks)
Assigned to: Nobody/Anonymous (nobody)
>Summary: ipv6 sockaddr is bad

Initial Comment:
ipv6 addrinfo becomes a 4-tuple in python, with
additional scope-id and flowinfo members that are never
used in practice by normal apps. scope id might be used
once in a blue moon by something like a dhcp server
(use link local addresses).

this difference causes a large portion of work involved
in porting python apps to suppot v6. i suggest it be
changed to just an address-port tuple, or add some kind
of hack to allow it ot be unpacked like "host, port =
addr".

  -- erno kuusela <erno@iki.fi>

----------------------------------------------------------------------

>Comment By: cypherpunks (cypherpunks)
Date: 2003-06-17 01:28

Message:
Logged In: YES 
user_id=16535

(sorry, title should have sockaddr and not addrinfo.)

It is a bug because it is gratuitous incompatibility between
6/4. "large portion" does not mean "huge absolute amount" -
just that at least for server apps otherwise you'd only need
to change a couple of lines and libraries expecting ipv4
sockets wouldn't know the difference. just grep 'host, port'
from most networking programs.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:20

Message:
Logged In: YES 
user_id=21627

Why is this a bug, and what kind of large portion of work is
involved to support IPv6? Please have a look at
httplib/ftplib, which both support IPv6, with minimum amount
of work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744164&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 03:05:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 19:05:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19S5qo-0005QG-00@sc8-sf-web4.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 17:13
Message generated for change (Comment added) made by mshomphe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

>Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-16 19:05

Message:
Logged In: YES 
user_id=716326

Here's my first pass at some additional documentation.  My 
HTML skills are not up to par, but I've tried :)  I've attached 
the document separately.

m@

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 18:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 03:51:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 19:51:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19S6ZY-0003Ex-00@sc8-sf-web3.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 19:13
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-16 21:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I'd start with os.popen
("cacls ...")  Even win32security requires some serious 
programming just to get started with manipulating ACLs.

Typical security looks something like this:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant>xcacls "\Program files"
C:\Program Files BUILTIN\Users:R
                 BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                           GENERIC_READ
                                           GENERIC_EXECUTE

                 BUILTIN\Power Users:C
                 BUILTIN\Power Users:(OI)(CI)(IO)C
                 BUILTIN\Administrators:F
                 BUILTIN\Administrators:(OI)(CI)(IO)F
                 NT AUTHORITY\SYSTEM:F
                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
                 BUILTIN\Administrators:F
                 CREATOR OWNER:(OI)(CI)(IO)F


C:\Documents and Settings\grant>

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-16 21:05

Message:
Logged In: YES 
user_id=716326

Here's my first pass at some additional documentation.  My 
HTML skills are not up to par, but I've tried :)  I've attached 
the document separately.

m@

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 20:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 04:28:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 20:28:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19S794-0006MD-00@sc8-sf-web2.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 20:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-16 23:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-16 22:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I'd start with os.popen
("cacls ...")  Even win32security requires some serious 
programming just to get started with manipulating ACLs.

Typical security looks something like this:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant>xcacls "\Program files"
C:\Program Files BUILTIN\Users:R
                 BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                           GENERIC_READ
                                           GENERIC_EXECUTE

                 BUILTIN\Power Users:C
                 BUILTIN\Power Users:(OI)(CI)(IO)C
                 BUILTIN\Administrators:F
                 BUILTIN\Administrators:(OI)(CI)(IO)F
                 NT AUTHORITY\SYSTEM:F
                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
                 BUILTIN\Administrators:F
                 CREATOR OWNER:(OI)(CI)(IO)F


C:\Documents and Settings\grant>

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-16 22:05

Message:
Logged In: YES 
user_id=716326

Here's my first pass at some additional documentation.  My 
HTML skills are not up to par, but I've tried :)  I've attached 
the document separately.

m@

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 21:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 04:37:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 20:37:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19S7HN-0006Z6-00@sc8-sf-web2.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 19:13
Message generated for change (Comment added) made by blunck2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-16 22:37

Message:
Logged In: YES 
user_id=531881

see patch 755677

sheesh neal, you couldn't patch this?  ;-)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-16 22:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-16 21:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I'd start with os.popen
("cacls ...")  Even win32security requires some serious 
programming just to get started with manipulating ACLs.

Typical security looks something like this:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant>xcacls "\Program files"
C:\Program Files BUILTIN\Users:R
                 BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                           GENERIC_READ
                                           GENERIC_EXECUTE

                 BUILTIN\Power Users:C
                 BUILTIN\Power Users:(OI)(CI)(IO)C
                 BUILTIN\Administrators:F
                 BUILTIN\Administrators:(OI)(CI)(IO)F
                 NT AUTHORITY\SYSTEM:F
                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
                 BUILTIN\Administrators:F
                 CREATOR OWNER:(OI)(CI)(IO)F


C:\Documents and Settings\grant>

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-16 21:05

Message:
Logged In: YES 
user_id=716326

Here's my first pass at some additional documentation.  My 
HTML skills are not up to par, but I've tried :)  I've attached 
the document separately.

m@

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 20:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 04:45:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 20:45:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-755564 ] Tutorial: 4.7.2 Keyword Arguments **name output order wrong
Message-ID: <E19S7Py-0004oC-00@sc8-sf-web3.sourceforge.net>

Bugs item #755564, was opened at 2003-06-16 16:53
Message generated for change (Comment added) made by blunck2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Jan Mattila (kakkonen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial: 4.7.2 Keyword Arguments **name output order wrong

Initial Comment:
In the Tutorial at chapter 4.7.2 Keyword Arguments, 
there is an example about the formal parameter **name. 
I'm quoting the whole thing, for quick reference:

--- begin extract from Tutorial ---
def cheeseshop(kind, *arguments, **keywords):
    print "-- Do you have any", kind, '?'
    print "-- I'm sorry, we're all out of", kind
    for arg in arguments: print arg
    print '-'*40
    for kw in keywords.keys(): print kw, ':', keywords[kw]

It could be called like this:

cheeseshop('Limburger', "It's very runny, sir.",
           "It's really very, VERY runny, sir.",
           client='John Cleese',
           shopkeeper='Michael Palin',
           sketch='Cheese Shop Sketch')

and of course it would print:

-- Do you have any Limburger ?
-- I'm sorry, we're all out of Limburger
It's very runny, sir.
It's really very, VERY runny, sir.
----------------------------------------
client : John Cleese
shopkeeper : Michael Palin
sketch : Cheese Shop Sketch
--- end extract from Tutorial ---

What it actually prints on my LFS 3.3 (linuxfromscratch)
based distribution with Python 2.1.3 is

--- begin print out of cheeseshop ---
-- Do you have any Limburger ?
-- I'm sorry, we're all out of Limburger
It's very runny, sir.
It's really very, VERY runny, sir.
----------------------------------------
client : John Cleese
sketch : Cheese Shop Sketch
shopkeeper : Michael Palin
--- end print out of cheeseshop ---

The problem is that the keywords[kw] list order is
garbled. I tried stripping this function of the *arguments
formal parameter and I got the same result. I tried
different amounts of **keywords in different
aphabetical orders. The resulting order does not 
seem to be random and does not seem to be aplhabetical
nor related to the length of the **keywords or anything
I could figure out.

It's probably not a typo (on my part), because I copied 
the code straight from the Tutorial page. 

Now, this is not really a bug in my opinion, so I'm not 
expecting a fix, but I was just trying to read through
the Tutorial and try all the example code and got 
stuck trying to figure how you could tell the print order 
of a formal parameter **name -type's name[kw] list.

I was thinking, that maybe if someone of class wizard 
or higher would care to indulge me in the reason for 
this behaviour I could become enlightened on another 
aspect of Python. I'm not expecting swift replies, since
this is a zero-priority glitch, but someone, somewhere,
someday, maybe? No? Okay. Just a thought...

So much for trying to make this short.

I managed to reproduce the problem on Python 1.5.2
on Red Hat Linux 7.3.2 on linux-i386

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-16 22:45

Message:
Logged In: YES 
user_id=531881

Hi Jan-

The tutorial points out:

Note that the sort() method of the list of keyword argument
names is called before printing the contents of the keywords
dictionary; if this is not done, the order in which the
arguments are
printed is undefined.

Not sure if a patch is necessary :)


-c

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 05:06:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 21:06:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-700827 ] Compiler Limits (indentation)
Message-ID: <E19S7kB-0005NQ-00@sc8-sf-web3.sourceforge.net>

Bugs item #700827, was opened at 2003-03-10 08:43
Message generated for change (Comment added) made by blunck2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Two Inches (twoinches)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler Limits (indentation)

Initial Comment:
The reference manual does not mention the indentation
limits of compiler implementations.

Suggestion: In section 2.1.7 Indentation add the
following at the end of the section:

Implementations may explicity limit the maximum
indentation level. 

For CPython check tokenizer.h for build specifics
(default value is set to 100). 
For Jython check
org.python.parser.PythonGrammerTokenManager (default
value is set to 20).

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-16 23:06

Message:
Logged In: YES 
user_id=531881

see bug 755683

http://www.python.org/sf/755683

-c

----------------------------------------------------------------------

Comment By: Two Inches (twoinches)
Date: 2003-06-08 16:51

Message:
Logged In: YES 
user_id=730363

Agreed. 

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 16:30

Message:
Logged In: YES 
user_id=357491

I have no issue adding a comment that the indentation level is 
not infinite, but I don't think it should be mentioned where to 
find it since the reference manual is for the language and not 
any specific implementation.

Anyone else agree?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 06:07:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 22:07:08 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-754014 ] list.index() should accept optional start, end arguments
Message-ID: <E19S8gW-00073U-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #754014, was opened at 2003-06-13 10:13
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=754014&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: list.index() should accept optional start, end arguments

Initial Comment:
As with the .index() method on strings, which allows 
scanning only a subset of the string by specifying 
optional start and end arguments, the list type's index() 
method should do the same.

The use case comes from the thread started here: 
http://mail.python.org/pipermail/python-list/2003-
June/168225.html .  

A later posting shows a list-comprehension-based 
solution which is fairly clean, but relies on generating a 
temporary utility list using range() (or xrange()).  
Another easy alternative would be to manually create 
subsets of the list using slicing, but that would involve a 
lot of overhead compared to including it in the index() 
method itself.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-17 00:07

Message:
Logged In: YES 
user_id=80475

Committed to Objects/listobject.c 2.154 and Lib/UserList.py 
1.19.   Updated both test suites to match.  Closing RFE.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 09:06

Message:
Logged In: YES 
user_id=80475

Okay, I'll put this one in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=754014&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 06:35:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 16 Jun 2003 22:35:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19S97f-0005J8-00@sc8-sf-web1.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 19:13
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-17 00:35

Message:
Logged In: YES 
user_id=699438

All I'm saying is that although chmod is valid windows call, it 
will not produce the effect that most users expect.  There's 
no harm in calling it, but it's not going to accomplish what 
most users want it to do.  This information is more important 
to a user than other inconsistencies in the Windows 
implementation.  (i.e. os.stat returning a value that is 
different than chmod set)

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-16 22:37

Message:
Logged In: YES 
user_id=531881

see patch 755677

sheesh neal, you couldn't patch this?  ;-)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-16 22:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-16 21:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I'd start with os.popen
("cacls ...")  Even win32security requires some serious 
programming just to get started with manipulating ACLs.

Typical security looks something like this:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant>xcacls "\Program files"
C:\Program Files BUILTIN\Users:R
                 BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                           GENERIC_READ
                                           GENERIC_EXECUTE

                 BUILTIN\Power Users:C
                 BUILTIN\Power Users:(OI)(CI)(IO)C
                 BUILTIN\Administrators:F
                 BUILTIN\Administrators:(OI)(CI)(IO)F
                 NT AUTHORITY\SYSTEM:F
                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
                 BUILTIN\Administrators:F
                 CREATOR OWNER:(OI)(CI)(IO)F


C:\Documents and Settings\grant>

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-16 21:05

Message:
Logged In: YES 
user_id=716326

Here's my first pass at some additional documentation.  My 
HTML skills are not up to par, but I've tried :)  I've attached 
the document separately.

m@

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 20:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 13:55:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 05:55:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-741843 ] _locale in Python-2.3b1/Tru64Unix 5.1A doesn't link
Message-ID: <E19SFzO-0001vF-00@sc8-sf-web3.sourceforge.net>

Bugs item #741843, was opened at 2003-05-22 18:25
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: _locale in Python-2.3b1/Tru64Unix 5.1A doesn't link

Initial Comment:
I have managed to compile python on Tru64Unix, but am
curious when I rerun "make", I get:

make
case $MAKEFLAGS in \
*-s*)  CC='cc -pthread' LDSHARED='ld -shared
-expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E
./setup.py -q build;; \
*)  CC='cc -pthread' LDSHARED='ld -shared
-expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E
./setup.py build;; \
esac
running build
running build_ext
building '_locale' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_localemodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -o
build/lib.osf1-V5.1-alpha-2.3/_locale.so
*** WARNING: renaming "_locale" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol
"libintl_gettext" unresolved
building '_curses' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
*** WARNING: renaming "_curses" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_curses.so: symbol
"_acs_map" unresolved
building '_curses_panel' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_curses_panel.c -o
build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o
cc: Severe: /mnt/Python-2.3b1/Modules/_curses_panel.c,
line 17: Cannot find file <panel.h> specified in
#include directive. (noinclfilef)
#include <panel.h>
-^
running build_scripts


This looks suspicious. I have ncurses available on the
system too, also termcap

I see that ncurses isn't found because newer version
are in $prefix/include/ncurses/ and not anymore in
$prefix/include/. There configure fails to detect them.
So, I have to configure as:

F77=f77 F90=f90 CC="cc -pthread" CXX="cxx -pthread"
CFLAGS="$CFLAGS -pthread -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses" CPPFLAGS=$CFLAGS
CXXFLAGS=$CFLAGS ./configure
--prefix=/software/@sys/usr --host=alphaev56-dec-osf5.1
--with-dec-threads --enable-large-file

But even in this case, CPPFLAGS weren't propagated to
Makefiles:
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_curses_panel.c -o
build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o
cc: Severe: /mnt/Python-2.3b1/./Include/py_curses.h,
line 16: Cannot find file <ncurses.h> specified in
#include directive. (noinclfilef)
#include <ncurses.h>
-^


Ooops! Not propagated, they are NOT USED! See
config.status:

s,@CXX@,cxx -pthread,;t t
s,@MAINOBJ@,python.o,;t t
s,@EXEEXT@,,;t t
s,@CC@,cc -pthread,;t t
s,@CFLAGS@,-O2 -arch ev56 -pthread
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses,;t t
s,@LDFLAGS@,,;t t
s,@CPPFLAGS@,-O2 -arch ev56 -pthread
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses,;t t
s,@ac_ct_CC@,,;t t
s,@OBJEXT@,o,;t t
s,@CPP@,cc -pthread -E,;t t

And during build I still see:

case $MAKEFLAGS in \
*-s*)  CC='cc -pthread -O2 -arch ev56
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses' LDSHARED='ld
-shared -expect_unresolved "*"' OPT='-DNDEBUG -O'
./python -E ./setup.py -q build;; \
*)  CC='cc -pthread -O2 -arch ev56
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses' LDSHARED='ld
-shared -expect_unresolved "*"' OPT='-DNDEBUG -O'
./python -E ./setup.py build;; \
esac
running build
running build_ext
building '_locale' extension
cc -pthread -O2 -arch ev56 -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses -DNDEBUG -O
-Olimit 1500 -I. -I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_localemodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -o
build/lib.osf1-V5.1-alpha-2.3/_locale.so
*** WARNING: renaming "_locale" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol
"libintl_gettext" unresolved
running build_scripts


I've reinstalled gettext/libiconv/ncurses, but no
difference. 



----------------------------------------------------------------------

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 14:55

Message:
Logged In: YES 
user_id=696559

I don't know if _locale has to do with with ncurses or not.
I just says what doesn't build on Tru64Unix 5.1A and what I
tried. I repeat, that linking against -lintl helps and
propose configure and generated Makefiles to be improved.
Possibly someone should investigate if -lgettextlib might be
needed too.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 10:23

Message:
Logged In: YES 
user_id=21627

Please report one bug at a time. What is the bug you are
reporting here? In particular, what does ncurses.h have to
do with _locale?

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-04 17:16

Message:
Logged In: YES 
user_id=696559

I believe linking additionally against -lintl will solve the
problem.

I think configur ehas to be improved to detect cases when
-lintl and -lgettextlib might be needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 14:00:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 06:00:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs a last distribution
Message-ID: <E19SG4T-0003M9-00@sc8-sf-web1.sourceforge.net>

Bugs item #748926, was opened at 2003-06-04 17:23
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken ncurses support in current cvs a last distribution

Initial Comment:
I found configure looks for ncurses.h instead of
ncurses/ncurses.h. Please note that newer version of
ncurses have moved ncurses.h to a subdirectory ncurses/.

Even after fixing configure and
Modules/_curses_panel.c, I get:

cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 506: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addch (const chtype);      
                 /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 507: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchnstr (const chtype *,
int);             /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 508: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchstr (const chtype *); 
                 /* generated */
---------------------------^

Any ideas?

----------------------------------------------------------------------

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:00

Message:
Logged In: YES 
user_id=696559

Sorry, I'm not aprogrammer, should I attach some of the
headers files distributed by ncurses?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:50

Message:
Logged In: YES 
user_id=21627

Can you report how NCURSES_EXPORT is defined on your system?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 14:29:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 06:29:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-748928 ] last threads fixes broke linker
Message-ID: <E19SGWP-0004kx-00@sc8-sf-web1.sourceforge.net>

Bugs item #748928, was opened at 2003-06-04 17:25
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: last threads fixes broke linker

Initial Comment:
In current cvs, -pthread and -ieee is properly set for
OSF1/Tru64Unix. Unfortunately, -ieee is somewhat passed
to linker:

building '_curses' extension
cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/mnt/python/dist/src/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/python/dist/src/Include -I/mnt/python/dist/src
-c /mnt/python/dist/src/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved * -ieee -std -Olimit 1500
-DNDEBUG -O -I. -I./Include
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
ld:
-ieee: Unknown flag
ld: Usage: ld [options] file [...]
building '_curses_panel' extension


----------------------------------------------------------------------

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:29

Message:
Logged In: YES 
user_id=696559

Actually, I don't know why -ieee is needed, I'm not a
programmer, sorry. The manpage cc(1) says:

  -ieee
      Ensure support of all portable features of the IEEE
Standard for Binary
      Floating-Point Arithmetic (ANSI/IEEE Std 754-1985),
including the
      treatment of denormalized numbers, NaNs, and
infinities and the han-
      dling of error cases. This option also sets the
_IEEE_FP C preprocessor
      macro.

      If your program must use IEEE signaling features that
are not portable
      across different IEEE implementations, see the ieee(3)
reference page
      for a discussion of how to access them under the Tru64
UNIX operating
      system.



Yes, -ieee is not listed in mapage for ld(1). I do not have
an access to that machine probably for a whole week, but are
you sure the -ieee is not in teh generated Makefiles passed
inside some variable to linker directly?



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:40

Message:
Logged In: YES 
user_id=21627

Is it not the case that cc(1) supports -ieee? If so, why
does it then pass the option to ld?

Perhaps it depends on the cc version whether -ieee is
supported? Perhaps the compiler should be invoked with a
different name?

Please don't make us guess as to how your operating system
works. If you can contribute to a solution, that would be
much appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 15:10:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 07:10:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs a last distribution
Message-ID: <E19SHAN-0005z9-00@sc8-sf-web3.sourceforge.net>

Bugs item #748926, was opened at 2003-06-04 17:23
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken ncurses support in current cvs a last distribution

Initial Comment:
I found configure looks for ncurses.h instead of
ncurses/ncurses.h. Please note that newer version of
ncurses have moved ncurses.h to a subdirectory ncurses/.

Even after fixing configure and
Modules/_curses_panel.c, I get:

cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 506: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addch (const chtype);      
                 /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 507: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchnstr (const chtype *,
int);             /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 508: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchstr (const chtype *); 
                 /* generated */
---------------------------^

Any ideas?

----------------------------------------------------------------------

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 16:10

Message:
Logged In: YES 
user_id=696559

I asked the developer of ncurses. This is his first reply.

From: Thomas Dickey <dickey@herndon4.his.com>

My guess (because I've seen it a few times)
is that it's a system where someone installed a new version
of gcc. Its fixincludes script was modified a year or two
ago with the effect of putting a copy of curses.h into gcc's
so-called fixed-include files, e.g.,

        /usr/lib/gcc-lib/i386-linux/3.0.4/include

(It's "fixing" a place which is providing a typedef if it
doesn't exist). I modified the ifdef's to avoid this
problem.  The quick fix is to remove curses.h from gcc's
fixed-includes.  The reason why NCURSES_EXPORT is not
defined is because gcc finds the wrong curses.h and doesn't
find ncurses_dll.h because its fixed-include forces it into
the wrong search path.

If it's not that - perhaps more info.  (Perhaps just setting
$CPPFLAGS in the environment is needed).


----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:00

Message:
Logged In: YES 
user_id=696559

Sorry, I'm not aprogrammer, should I attach some of the
headers files distributed by ncurses?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:50

Message:
Logged In: YES 
user_id=21627

Can you report how NCURSES_EXPORT is defined on your system?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 15:49:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 07:49:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19SHmL-0002MT-00@sc8-sf-web2.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 20:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-17 10:49

Message:
Logged In: YES 
user_id=31435

Then please suggest the actual text you want to see in the 
docs.  I can't do it for you (for example, chmod has always 
done exactly what I've wanted it to do on Windows -- but 
then I've never wanted to do anything with it on Windows 
beyond fiddling the readonly bit).

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-17 01:35

Message:
Logged In: YES 
user_id=699438

All I'm saying is that although chmod is valid windows call, it 
will not produce the effect that most users expect.  There's 
no harm in calling it, but it's not going to accomplish what 
most users want it to do.  This information is more important 
to a user than other inconsistencies in the Windows 
implementation.  (i.e. os.stat returning a value that is 
different than chmod set)

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-16 23:37

Message:
Logged In: YES 
user_id=531881

see patch 755677

sheesh neal, you couldn't patch this?  ;-)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-16 23:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-16 22:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I'd start with os.popen
("cacls ...")  Even win32security requires some serious 
programming just to get started with manipulating ACLs.

Typical security looks something like this:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant>xcacls "\Program files"
C:\Program Files BUILTIN\Users:R
                 BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                           GENERIC_READ
                                           GENERIC_EXECUTE

                 BUILTIN\Power Users:C
                 BUILTIN\Power Users:(OI)(CI)(IO)C
                 BUILTIN\Administrators:F
                 BUILTIN\Administrators:(OI)(CI)(IO)F
                 NT AUTHORITY\SYSTEM:F
                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
                 BUILTIN\Administrators:F
                 CREATOR OWNER:(OI)(CI)(IO)F


C:\Documents and Settings\grant>

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-16 22:05

Message:
Logged In: YES 
user_id=716326

Here's my first pass at some additional documentation.  My 
HTML skills are not up to par, but I've tried :)  I've attached 
the document separately.

m@

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 21:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 16:18:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 08:18:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19SIDg-0001Rd-00@sc8-sf-web3.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 19:13
Message generated for change (Comment added) made by blunck2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 10:18

Message:
Logged In: YES 
user_id=531881

Tim-

I captured what Matthew Shomphe recommended into patch 755677
(http://www.python.org/sf/755677).  Hope this helps.

-c

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 09:49

Message:
Logged In: YES 
user_id=31435

Then please suggest the actual text you want to see in the 
docs.  I can't do it for you (for example, chmod has always 
done exactly what I've wanted it to do on Windows -- but 
then I've never wanted to do anything with it on Windows 
beyond fiddling the readonly bit).

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-17 00:35

Message:
Logged In: YES 
user_id=699438

All I'm saying is that although chmod is valid windows call, it 
will not produce the effect that most users expect.  There's 
no harm in calling it, but it's not going to accomplish what 
most users want it to do.  This information is more important 
to a user than other inconsistencies in the Windows 
implementation.  (i.e. os.stat returning a value that is 
different than chmod set)

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-16 22:37

Message:
Logged In: YES 
user_id=531881

see patch 755677

sheesh neal, you couldn't patch this?  ;-)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-16 22:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-16 21:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I'd start with os.popen
("cacls ...")  Even win32security requires some serious 
programming just to get started with manipulating ACLs.

Typical security looks something like this:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant>xcacls "\Program files"
C:\Program Files BUILTIN\Users:R
                 BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                           GENERIC_READ
                                           GENERIC_EXECUTE

                 BUILTIN\Power Users:C
                 BUILTIN\Power Users:(OI)(CI)(IO)C
                 BUILTIN\Administrators:F
                 BUILTIN\Administrators:(OI)(CI)(IO)F
                 NT AUTHORITY\SYSTEM:F
                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
                 BUILTIN\Administrators:F
                 CREATOR OWNER:(OI)(CI)(IO)F


C:\Documents and Settings\grant>

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-16 21:05

Message:
Logged In: YES 
user_id=716326

Here's my first pass at some additional documentation.  My 
HTML skills are not up to par, but I've tried :)  I've attached 
the document separately.

m@

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 20:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 16:50:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 08:50:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-755031 ] zipfile: inconsistent filenames with InfoZip "unzip"
Message-ID: <E19SIjS-0006fG-00@sc8-sf-web4.sourceforge.net>

Bugs item #755031, was opened at 2003-06-15 21:23
Message generated for change (Comment added) made by ahlstromjc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile: inconsistent filenames with InfoZip "unzip"

Initial Comment:
zipfile.py gives filenames inconsistent with the
InfoZIP "unzip" utility for certain ZIP files.  My
source is an email virus, so the ZIP files are almost
certainl malformed.  Nevertheless, it would be nice if
"unzip -l" and ZipFile.namelist() gave consistent
filenames.

Example: the attached Demo.zip (extracted from an email
virus caught on mail.python.org) looks like this
according to InfoZip:

$ unzip -l /tmp/Demo.zip 
Archive:  /tmp/Demo.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
    44544  01-26-03 20:49  
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe
 --------                   -------
    44544                   1 file

But according to ZipFile.namelist(), the name of that
file is:
 
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exescr000000000000000000.txt

Getting the same result with Python 2.2.2 and a
~2-week-old build of 2.3 CVS.


----------------------------------------------------------------------

Comment By: James C. Ahlstrom (ahlstromjc)
Date: 2003-06-17 15:50

Message:
Logged In: YES 
user_id=64929

I submitted a patch for this.  It is 755987.  See further 
comments there.

----------------------------------------------------------------------

Comment By: James C. Ahlstrom (ahlstromjc)
Date: 2003-06-16 14:29

Message:
Logged In: YES 
user_id=64929

The analysis by sjones is correct.  Python and the zip file 
format both allow null bytes in file names.  But in this case, 
the file is infected with the "I-Worm.Lentin.o" virus and the 
file name is designed to hide this.  The file name ends in ".txt" 
but the file name up to the null byte ends in ".exe".  The 
intention is that a virus scanner would skip this file because it 
ends in ".txt" ( a non-executable text file), but that 
the ".exe" would be seen (an executable program file) if the 
file were clicked, and so the file would be executed.

Testing this on my machine, my virus scanner (Kaspersky) 
nevertheless flags the ".zip" file as containing a virus, but this 
depends on the particular virus scanner and its settings.

I suggest that zipfile.py should terminate file names at a null 
byte as InfoZip does.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-16 01:23

Message:
Logged In: YES 
user_id=589306

The actual filename from the zipfile is:
filename =
'DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe\x00\x00scr\x00000000000000000000.txt'

Notice there is a \x00 after Demo.exe. My guess is InfoZip
stores the filename in a null terminated string and this
extra null character in the filename terminates it at this
point. Python doesn't care if you have nulls in the string,
so it prints the entire filename.

You can see the zip file format description at
ftp://ftp.info-zip.org/pub/infozip/doc/appnote-981119-iz.zip

The format does say:
      2)  String fields are not null terminated, since the
          length is given explicitly.

But it doesn't really say if strings are allowed to have
nulls in them.

So does Python or InfoZip get this right?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-16 01:19

Message:
Logged In: YES 
user_id=6380

That almost sounds like an intentional inconsistency. Could
it be that the central directory has one name but the local
header has a different one? Or that there's a null byte in
the filename so that the filename length is inconsistent?
The front of the file looks like this according to od -c:

0000000   P   K 003 004  \n  \0  \0  \0  \0  \0   *   Š   :
  .   c   Ì
0000020  \v   g  \0   ®  \0  \0  \0   ®  \0  \0   D  \0  \0
 \0   D   O
0000040   C   U   M   E   ~   1   \   C   H   R   I   S   S
  ~   1   \
0000060   L   O   C   A   L   S   ~   1   \   T   e   m   p
  \   D   e
0000100   m   o   .   e   x   e  \0  \0   s   c   r  \0   0
  0   0   0
0000120   0   0   0   0   0   0   0   0   0   0   0   0   0
  0   .   t
0000140   x   t   M   Z 220  \0 003  \0  \0  \0 004  \0  \0
 \0   ÿ   ÿ
0000160  \0  \0   ž  \0  \0  \0  \0  \0  \0  \0   @  \0  \0
 \0  \0  \0


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 19:17:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 11:17:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-756093 ] complex pow() crash on Alpha
Message-ID: <E19SL1N-0002el-00@sc8-sf-web1.sourceforge.net>

Bugs item #756093, was opened at 2003-06-17 20: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=756093&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: complex pow() crash on Alpha

Initial Comment:
Python crashes with a floating point exception on SF's
 Alpha/Linux 2.2 machine in the compile farm:
$ ./python
Python 2.3b1+ (#2, Jun 17 2003, 10:50:58) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> pow(1e200+1j,1e200+1j)
Floating point exception
$

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756093&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 19:25:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 11:25:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-756104 ] Calling socket.recv() with a large number breaks
Message-ID: <E19SL9J-0006A4-00@sc8-sf-web4.sourceforge.net>

Bugs item #756104, was opened at 2003-06-17 18: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=756104&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex R.M. Turner (plexq)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling socket.recv() with a large number breaks

Initial Comment:
I have a backup script that calls socket.recv() passing
the amount of data that is left to get for a given file
as the argument.  For very large files (I have one here
that is 1.9Gig) it seems to break horribly after
receiving about 130Meg.  I have tried to track it down
precisely with basic debugging (putting in print
statements in the python code) but it just seams to
freak out around the 130meg mark, and it just doesn't
make sense.  If I change the argument passed to recv to
32767 it works just fine.  I have attatched the loop
that reads data from the socket (In a working state,
the bad code is commented out).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 20:31:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 12:31:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-755617 ] os module: Need a better description of "mode"
Message-ID: <E19SMAZ-0005Vs-00@sc8-sf-web3.sourceforge.net>

Bugs item #755617, was opened at 2003-06-16 19:13
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page <http://www.python.
org/doc/current/lib/os-file-dir.html> says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-17 14:31

Message:
Logged In: YES 
user_id=699438

Something like:

"NOTE: Although Windows supports chmod, it incorporates 
much different functionality than a typical Unix user would 
expect.  Please refer to Microsoft’s documentation for more 
details."

would be nice.

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 10:18

Message:
Logged In: YES 
user_id=531881

Tim-

I captured what Matthew Shomphe recommended into patch 755677
(http://www.python.org/sf/755677).  Hope this helps.

-c

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 09:49

Message:
Logged In: YES 
user_id=31435

Then please suggest the actual text you want to see in the 
docs.  I can't do it for you (for example, chmod has always 
done exactly what I've wanted it to do on Windows -- but 
then I've never wanted to do anything with it on Windows 
beyond fiddling the readonly bit).

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-17 00:35

Message:
Logged In: YES 
user_id=699438

All I'm saying is that although chmod is valid windows call, it 
will not produce the effect that most users expect.  There's 
no harm in calling it, but it's not going to accomplish what 
most users want it to do.  This information is more important 
to a user than other inconsistencies in the Windows 
implementation.  (i.e. os.stat returning a value that is 
different than chmod set)

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-16 22:37

Message:
Logged In: YES 
user_id=531881

see patch 755677

sheesh neal, you couldn't patch this?  ;-)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-16 22:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-06-16 21:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I'd start with os.popen
("cacls ...")  Even win32security requires some serious 
programming just to get started with manipulating ACLs.

Typical security looks something like this:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant>xcacls "\Program files"
C:\Program Files BUILTIN\Users:R
                 BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                           GENERIC_READ
                                           GENERIC_EXECUTE

                 BUILTIN\Power Users:C
                 BUILTIN\Power Users:(OI)(CI)(IO)C
                 BUILTIN\Administrators:F
                 BUILTIN\Administrators:(OI)(CI)(IO)F
                 NT AUTHORITY\SYSTEM:F
                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
                 BUILTIN\Administrators:F
                 CREATOR OWNER:(OI)(CI)(IO)F


C:\Documents and Settings\grant>

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-16 21:05

Message:
Logged In: YES 
user_id=716326

Here's my first pass at some additional documentation.  My 
HTML skills are not up to par, but I've tried :)  I've attached 
the document separately.

m@

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-16 20:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 21:04:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 13:04:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-755564 ] Tutorial: 4.7.2 Keyword Arguments **name output order wrong
Message-ID: <E19SMhL-0001A6-00@sc8-sf-web2.sourceforge.net>

Bugs item #755564, was opened at 2003-06-17 00:53
Message generated for change (Comment added) made by kakkonen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
>Priority: 3
Submitted By: Jan Mattila (kakkonen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial: 4.7.2 Keyword Arguments **name output order wrong

Initial Comment:
In the Tutorial at chapter 4.7.2 Keyword Arguments, 
there is an example about the formal parameter **name. 
I'm quoting the whole thing, for quick reference:

--- begin extract from Tutorial ---
def cheeseshop(kind, *arguments, **keywords):
    print "-- Do you have any", kind, '?'
    print "-- I'm sorry, we're all out of", kind
    for arg in arguments: print arg
    print '-'*40
    for kw in keywords.keys(): print kw, ':', keywords[kw]

It could be called like this:

cheeseshop('Limburger', "It's very runny, sir.",
           "It's really very, VERY runny, sir.",
           client='John Cleese',
           shopkeeper='Michael Palin',
           sketch='Cheese Shop Sketch')

and of course it would print:

-- Do you have any Limburger ?
-- I'm sorry, we're all out of Limburger
It's very runny, sir.
It's really very, VERY runny, sir.
----------------------------------------
client : John Cleese
shopkeeper : Michael Palin
sketch : Cheese Shop Sketch
--- end extract from Tutorial ---

What it actually prints on my LFS 3.3 (linuxfromscratch)
based distribution with Python 2.1.3 is

--- begin print out of cheeseshop ---
-- Do you have any Limburger ?
-- I'm sorry, we're all out of Limburger
It's very runny, sir.
It's really very, VERY runny, sir.
----------------------------------------
client : John Cleese
sketch : Cheese Shop Sketch
shopkeeper : Michael Palin
--- end print out of cheeseshop ---

The problem is that the keywords[kw] list order is
garbled. I tried stripping this function of the *arguments
formal parameter and I got the same result. I tried
different amounts of **keywords in different
aphabetical orders. The resulting order does not 
seem to be random and does not seem to be aplhabetical
nor related to the length of the **keywords or anything
I could figure out.

It's probably not a typo (on my part), because I copied 
the code straight from the Tutorial page. 

Now, this is not really a bug in my opinion, so I'm not 
expecting a fix, but I was just trying to read through
the Tutorial and try all the example code and got 
stuck trying to figure how you could tell the print order 
of a formal parameter **name -type's name[kw] list.

I was thinking, that maybe if someone of class wizard 
or higher would care to indulge me in the reason for 
this behaviour I could become enlightened on another 
aspect of Python. I'm not expecting swift replies, since
this is a zero-priority glitch, but someone, somewhere,
someday, maybe? No? Okay. Just a thought...

So much for trying to make this short.

I managed to reproduce the problem on Python 1.5.2
on Red Hat Linux 7.3.2 on linux-i386

----------------------------------------------------------------------

>Comment By: Jan Mattila (kakkonen)
Date: 2003-06-17 23:04

Message:
Logged In: YES 
user_id=802538

Thanks  Christopher,

Your reply solved the mystery, but I was unable to find the 
text you mentioned in the Tutorial at:

http://www.python.org/doc/2.1.3/tut/tut.html

I tried searching the whole thing, just in case, and the
closest 
I found was this:

"The keys() method of a dictionary object returns a list of all 
the keys used in the dictionary, in random order (if you want 
it sorted, just apply the sort() method to the list of keys)."

But it was in chapter 5.4 Dictionaries, which is quite a way
from the mystery at Chapter 4.7.2. 

I mean the text you quoted? would solve the mystery instantly
and even shed light on how to fix it. That is, if it was in the
tutorial.

My question is: Can you or someone put it there?

Additionally it would be nice to either exclude the sorted
list from the Tutorial or add a snippet of code for reproducing
the list exactly. 

I think this could do it (although I'm sure someone knows
a better way, and that should go into the tutorial):

def cheeseshop(kind, *arguments, **keywords):
        print "-- Do you have any", kind, '?'
        print "-- I'm sorry, we're all out of", kind
        for arg in arguments: print arg
        print '-'*40
        info = keywords.items()
        info.sort()
        for value in info:
                print value[0], ':', value[1]


-Jan

(forgot to sign my last message...)

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 06:45

Message:
Logged In: YES 
user_id=531881

Hi Jan-

The tutorial points out:

Note that the sort() method of the list of keyword argument
names is called before printing the contents of the keywords
dictionary; if this is not done, the order in which the
arguments are
printed is undefined.

Not sure if a patch is necessary :)


-c

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 21:33:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 13:33:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-741843 ] _locale in Python-2.3b1/Tru64Unix 5.1A doesn't link
Message-ID: <E19SN9O-0002c7-00@sc8-sf-web2.sourceforge.net>

Bugs item #741843, was opened at 2003-05-22 18:25
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: _locale in Python-2.3b1/Tru64Unix 5.1A doesn't link

Initial Comment:
I have managed to compile python on Tru64Unix, but am
curious when I rerun "make", I get:

make
case $MAKEFLAGS in \
*-s*)  CC='cc -pthread' LDSHARED='ld -shared
-expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E
./setup.py -q build;; \
*)  CC='cc -pthread' LDSHARED='ld -shared
-expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E
./setup.py build;; \
esac
running build
running build_ext
building '_locale' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_localemodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -o
build/lib.osf1-V5.1-alpha-2.3/_locale.so
*** WARNING: renaming "_locale" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol
"libintl_gettext" unresolved
building '_curses' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
*** WARNING: renaming "_curses" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_curses.so: symbol
"_acs_map" unresolved
building '_curses_panel' extension
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_curses_panel.c -o
build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o
cc: Severe: /mnt/Python-2.3b1/Modules/_curses_panel.c,
line 17: Cannot find file <panel.h> specified in
#include directive. (noinclfilef)
#include <panel.h>
-^
running build_scripts


This looks suspicious. I have ncurses available on the
system too, also termcap

I see that ncurses isn't found because newer version
are in $prefix/include/ncurses/ and not anymore in
$prefix/include/. There configure fails to detect them.
So, I have to configure as:

F77=f77 F90=f90 CC="cc -pthread" CXX="cxx -pthread"
CFLAGS="$CFLAGS -pthread -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses" CPPFLAGS=$CFLAGS
CXXFLAGS=$CFLAGS ./configure
--prefix=/software/@sys/usr --host=alphaev56-dec-osf5.1
--with-dec-threads --enable-large-file

But even in this case, CPPFLAGS weren't propagated to
Makefiles:
cc -pthread -DNDEBUG -O -Olimit 1500 -I.
-I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_curses_panel.c -o
build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o
cc: Severe: /mnt/Python-2.3b1/./Include/py_curses.h,
line 16: Cannot find file <ncurses.h> specified in
#include directive. (noinclfilef)
#include <ncurses.h>
-^


Ooops! Not propagated, they are NOT USED! See
config.status:

s,@CXX@,cxx -pthread,;t t
s,@MAINOBJ@,python.o,;t t
s,@EXEEXT@,,;t t
s,@CC@,cc -pthread,;t t
s,@CFLAGS@,-O2 -arch ev56 -pthread
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses,;t t
s,@LDFLAGS@,,;t t
s,@CPPFLAGS@,-O2 -arch ev56 -pthread
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses,;t t
s,@ac_ct_CC@,,;t t
s,@OBJEXT@,o,;t t
s,@CPP@,cc -pthread -E,;t t

And during build I still see:

case $MAKEFLAGS in \
*-s*)  CC='cc -pthread -O2 -arch ev56
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses' LDSHARED='ld
-shared -expect_unresolved "*"' OPT='-DNDEBUG -O'
./python -E ./setup.py -q build;; \
*)  CC='cc -pthread -O2 -arch ev56
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses' LDSHARED='ld
-shared -expect_unresolved "*"' OPT='-DNDEBUG -O'
./python -E ./setup.py build;; \
esac
running build
running build_ext
building '_locale' extension
cc -pthread -O2 -arch ev56 -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses -DNDEBUG -O
-Olimit 1500 -I. -I/mnt/Python-2.3b1/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c
/mnt/Python-2.3b1/Modules/_localemodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_localemodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -o
build/lib.osf1-V5.1-alpha-2.3/_locale.so
*** WARNING: renaming "_locale" since importing it
failed: dlopen:
build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol
"libintl_gettext" unresolved
running build_scripts


I've reinstalled gettext/libiconv/ncurses, but no
difference. 



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 22:33

Message:
Logged In: YES 
user_id=21627

I see. This has been fixed in CVS; Python now tries to link
-lintl to _locale. Closing this report as fixed.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 14:55

Message:
Logged In: YES 
user_id=696559

I don't know if _locale has to do with with ncurses or not.
I just says what doesn't build on Tru64Unix 5.1A and what I
tried. I repeat, that linking against -lintl helps and
propose configure and generated Makefiles to be improved.
Possibly someone should investigate if -lgettextlib might be
needed too.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 10:23

Message:
Logged In: YES 
user_id=21627

Please report one bug at a time. What is the bug you are
reporting here? In particular, what does ncurses.h have to
do with _locale?

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-04 17:16

Message:
Logged In: YES 
user_id=696559

I believe linking additionally against -lintl will solve the
problem.

I think configur ehas to be improved to detect cases when
-lintl and -lgettextlib might be needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 21:35:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 13:35:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs a last distribution
Message-ID: <E19SNB2-0002k0-00@sc8-sf-web2.sourceforge.net>

Bugs item #748926, was opened at 2003-06-04 17:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470

Category: None
>Group: 3rd Party
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken ncurses support in current cvs a last distribution

Initial Comment:
I found configure looks for ncurses.h instead of
ncurses/ncurses.h. Please note that newer version of
ncurses have moved ncurses.h to a subdirectory ncurses/.

Even after fixing configure and
Modules/_curses_panel.c, I get:

cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 506: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addch (const chtype);      
                 /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 507: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchnstr (const chtype *,
int);             /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 508: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchstr (const chtype *); 
                 /* generated */
---------------------------^

Any ideas?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 22:35

Message:
Logged In: YES 
user_id=21627

I see. This seems to be either a bug in ncurses, or in gcc.
Closing as third-party.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 16:10

Message:
Logged In: YES 
user_id=696559

I asked the developer of ncurses. This is his first reply.

From: Thomas Dickey <dickey@herndon4.his.com>

My guess (because I've seen it a few times)
is that it's a system where someone installed a new version
of gcc. Its fixincludes script was modified a year or two
ago with the effect of putting a copy of curses.h into gcc's
so-called fixed-include files, e.g.,

        /usr/lib/gcc-lib/i386-linux/3.0.4/include

(It's "fixing" a place which is providing a typedef if it
doesn't exist). I modified the ifdef's to avoid this
problem.  The quick fix is to remove curses.h from gcc's
fixed-includes.  The reason why NCURSES_EXPORT is not
defined is because gcc finds the wrong curses.h and doesn't
find ncurses_dll.h because its fixed-include forces it into
the wrong search path.

If it's not that - perhaps more info.  (Perhaps just setting
$CPPFLAGS in the environment is needed).


----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:00

Message:
Logged In: YES 
user_id=696559

Sorry, I'm not aprogrammer, should I attach some of the
headers files distributed by ncurses?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:50

Message:
Logged In: YES 
user_id=21627

Can you report how NCURSES_EXPORT is defined on your system?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 21:38:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 13:38:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-748928 ] last threads fixes broke linker
Message-ID: <E19SNDi-0002ts-00@sc8-sf-web2.sourceforge.net>

Bugs item #748928, was opened at 2003-06-04 17:25
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: last threads fixes broke linker

Initial Comment:
In current cvs, -pthread and -ieee is properly set for
OSF1/Tru64Unix. Unfortunately, -ieee is somewhat passed
to linker:

building '_curses' extension
cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/mnt/python/dist/src/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/python/dist/src/Include -I/mnt/python/dist/src
-c /mnt/python/dist/src/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved * -ieee -std -Olimit 1500
-DNDEBUG -O -I. -I./Include
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
ld:
-ieee: Unknown flag
ld: Usage: ld [options] file [...]
building '_curses_panel' extension


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 22:38

Message:
Logged In: YES 
user_id=21627

I see; -ieee is indeed passed to ld. I am a programmer, but
I cannot develop on Tru64. So we have to wait until a
programmer with access to Tru64 shows up.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:29

Message:
Logged In: YES 
user_id=696559

Actually, I don't know why -ieee is needed, I'm not a
programmer, sorry. The manpage cc(1) says:

  -ieee
      Ensure support of all portable features of the IEEE
Standard for Binary
      Floating-Point Arithmetic (ANSI/IEEE Std 754-1985),
including the
      treatment of denormalized numbers, NaNs, and
infinities and the han-
      dling of error cases. This option also sets the
_IEEE_FP C preprocessor
      macro.

      If your program must use IEEE signaling features that
are not portable
      across different IEEE implementations, see the ieee(3)
reference page
      for a discussion of how to access them under the Tru64
UNIX operating
      system.



Yes, -ieee is not listed in mapage for ld(1). I do not have
an access to that machine probably for a whole week, but are
you sure the -ieee is not in teh generated Makefiles passed
inside some variable to linker directly?



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:40

Message:
Logged In: YES 
user_id=21627

Is it not the case that cc(1) supports -ieee? If so, why
does it then pass the option to ld?

Perhaps it depends on the cc version whether -ieee is
supported? Perhaps the compiler should be invoked with a
different name?

Please don't make us guess as to how your operating system
works. If you can contribute to a solution, that would be
much appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 22:30:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 14:30:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-748928 ] last threads fixes broke linker
Message-ID: <E19SO23-0005ho-00@sc8-sf-web2.sourceforge.net>

Bugs item #748928, was opened at 2003-06-04 17:25
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: last threads fixes broke linker

Initial Comment:
In current cvs, -pthread and -ieee is properly set for
OSF1/Tru64Unix. Unfortunately, -ieee is somewhat passed
to linker:

building '_curses' extension
cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/mnt/python/dist/src/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/python/dist/src/Include -I/mnt/python/dist/src
-c /mnt/python/dist/src/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved * -ieee -std -Olimit 1500
-DNDEBUG -O -I. -I./Include
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
ld:
-ieee: Unknown flag
ld: Usage: ld [options] file [...]
building '_curses_panel' extension


----------------------------------------------------------------------

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 23:30

Message:
Logged In: YES 
user_id=696559

Get free account on testing machine at
http://www.testdrive.compaq.com/

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 22:38

Message:
Logged In: YES 
user_id=21627

I see; -ieee is indeed passed to ld. I am a programmer, but
I cannot develop on Tru64. So we have to wait until a
programmer with access to Tru64 shows up.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:29

Message:
Logged In: YES 
user_id=696559

Actually, I don't know why -ieee is needed, I'm not a
programmer, sorry. The manpage cc(1) says:

  -ieee
      Ensure support of all portable features of the IEEE
Standard for Binary
      Floating-Point Arithmetic (ANSI/IEEE Std 754-1985),
including the
      treatment of denormalized numbers, NaNs, and
infinities and the han-
      dling of error cases. This option also sets the
_IEEE_FP C preprocessor
      macro.

      If your program must use IEEE signaling features that
are not portable
      across different IEEE implementations, see the ieee(3)
reference page
      for a discussion of how to access them under the Tru64
UNIX operating
      system.



Yes, -ieee is not listed in mapage for ld(1). I do not have
an access to that machine probably for a whole week, but are
you sure the -ieee is not in teh generated Makefiles passed
inside some variable to linker directly?



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:40

Message:
Logged In: YES 
user_id=21627

Is it not the case that cc(1) supports -ieee? If so, why
does it then pass the option to ld?

Perhaps it depends on the cc version whether -ieee is
supported? Perhaps the compiler should be invoked with a
different name?

Please don't make us guess as to how your operating system
works. If you can contribute to a solution, that would be
much appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 22:37:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 14:37:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs a last distribution
Message-ID: <E19SO9B-0006Bp-00@sc8-sf-web2.sourceforge.net>

Bugs item #748926, was opened at 2003-06-04 17:23
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470

Category: None
Group: 3rd Party
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken ncurses support in current cvs a last distribution

Initial Comment:
I found configure looks for ncurses.h instead of
ncurses/ncurses.h. Please note that newer version of
ncurses have moved ncurses.h to a subdirectory ncurses/.

Even after fixing configure and
Modules/_curses_panel.c, I get:

cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 506: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addch (const chtype);      
                 /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 507: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchnstr (const chtype *,
int);             /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 508: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchstr (const chtype *); 
                 /* generated */
---------------------------^

Any ideas?

----------------------------------------------------------------------

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 23:37

Message:
Logged In: YES 
user_id=696559

Second reply(I have to add I'll retry once more, but I
believe the whole story is python used to compile fine with
older ncurses, which placed headers into include/ . Newer
versions place headers into include/ncurses/ subdirectory,
and that is not expected. I do not have the gcc problem with
gcc fixincludes as the machine was recently installed and
there were always ncurses 5.0 and above installed.):

> Hi Thomas,
>   but I use cc from DEC?DIGITAL/COMPAQ/HP, so it shouldn't
see those
> "fixed" headers, right?

no - gcc is the one that "fixes" headers.  It is unlikely
that your $CFLAGS
or $CPPFLAGS has an explicit
        -I/usr/lib/gcc-lib/i386-linux/3.0.4/include

Then it sounds like a variation of the other sort of
problem:  compiler finds
one of the headers, but not all.  The message seems to
indicate that the
compiler did not find a definition for NCURSES_EXPORT, which
is defined in
ncurses_dll.h

What I'd look for: since most applications do not distinguish
        #include <ncurses/curses.h>
and
        #include <curses.h>
by ifdef's is that your options have only
        -I/software/@sys/usr/include/ncurses
rather than
        -I/software/@sys/usr/include
        -I/software/@sys/usr/include/ncurses
Since the ncurses headers (unctrl.h, term.h) will have a
line like
        #include <ncurses/curses.h>
it really needs both -I options.  (Specifying both still
does not work around
the gcc fixincludes problem - that's why I remember that one
first).
 
> > (It's "fixing" a place which is providing a typedef if
it doesn't exist).
> > I modified the ifdef's to avoid this problem.  The quick
fix is to remove
> > curses.h from gcc's fixed-includes.  The reason why
NCURSES_EXPORT is not
> > defined is because gcc finds the wrong curses.h and
doesn't find ncurses_dll.h
> > because its fixed-include forces it into the wrong
search path.
> >
> > If it's not that - perhaps more info.  (Perhaps just
setting $CPPFLAGS in
> > the environment is needed).
> 
> But the message
> 
> cc: Error: /software/@sys/usr/include/ncurses/curses.h,
> line 506: Missing identifier. (parnoident)
> extern NCURSES_EXPORT(int) addch (const chtype);
> /* generated */
> ---------------------------^
> cc: Error: /software/@sys/usr/include/ncurses/curses.h,
> line 507: Missing identifier. (parnoident)
> extern NCURSES_EXPORT(int) addchnstr (const chtype *,
> int); /* generated */
> ---------------------------^
> cc: Error: /software/@sys/usr/include/ncurses/curses.h,
> line 508: Missing identifier. (parnoident)
> extern NCURSES_EXPORT(int) addchstr (const chtype *);
> /* generated */
> ---------------------------^
> 
> confirms that CPPFLAGS or CFLAGS point to the location
where ncurses are
> installed! Maybe the problem is that ncurses/ncurses.h are
stored as
> ncurses/curses.h?
> 


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 22:35

Message:
Logged In: YES 
user_id=21627

I see. This seems to be either a bug in ncurses, or in gcc.
Closing as third-party.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 16:10

Message:
Logged In: YES 
user_id=696559

I asked the developer of ncurses. This is his first reply.

From: Thomas Dickey <dickey@herndon4.his.com>

My guess (because I've seen it a few times)
is that it's a system where someone installed a new version
of gcc. Its fixincludes script was modified a year or two
ago with the effect of putting a copy of curses.h into gcc's
so-called fixed-include files, e.g.,

        /usr/lib/gcc-lib/i386-linux/3.0.4/include

(It's "fixing" a place which is providing a typedef if it
doesn't exist). I modified the ifdef's to avoid this
problem.  The quick fix is to remove curses.h from gcc's
fixed-includes.  The reason why NCURSES_EXPORT is not
defined is because gcc finds the wrong curses.h and doesn't
find ncurses_dll.h because its fixed-include forces it into
the wrong search path.

If it's not that - perhaps more info.  (Perhaps just setting
$CPPFLAGS in the environment is needed).


----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:00

Message:
Logged In: YES 
user_id=696559

Sorry, I'm not aprogrammer, should I attach some of the
headers files distributed by ncurses?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:50

Message:
Logged In: YES 
user_id=21627

Can you report how NCURSES_EXPORT is defined on your system?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 22:54:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 14:54:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs a last distribution
Message-ID: <E19SOPf-0005W6-00@sc8-sf-web1.sourceforge.net>

Bugs item #748926, was opened at 2003-06-04 17:23
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470

Category: None
>Group: Python 2.3
>Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken ncurses support in current cvs a last distribution

Initial Comment:
I found configure looks for ncurses.h instead of
ncurses/ncurses.h. Please note that newer version of
ncurses have moved ncurses.h to a subdirectory ncurses/.

Even after fixing configure and
Modules/_curses_panel.c, I get:

cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 506: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addch (const chtype);      
                 /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 507: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchnstr (const chtype *,
int);             /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 508: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchstr (const chtype *); 
                 /* generated */
---------------------------^

Any ideas?

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 23:37

Message:
Logged In: YES 
user_id=696559

Second reply(I have to add I'll retry once more, but I
believe the whole story is python used to compile fine with
older ncurses, which placed headers into include/ . Newer
versions place headers into include/ncurses/ subdirectory,
and that is not expected. I do not have the gcc problem with
gcc fixincludes as the machine was recently installed and
there were always ncurses 5.0 and above installed.):

> Hi Thomas,
>   but I use cc from DEC?DIGITAL/COMPAQ/HP, so it shouldn't
see those
> "fixed" headers, right?

no - gcc is the one that "fixes" headers.  It is unlikely
that your $CFLAGS
or $CPPFLAGS has an explicit
        -I/usr/lib/gcc-lib/i386-linux/3.0.4/include

Then it sounds like a variation of the other sort of
problem:  compiler finds
one of the headers, but not all.  The message seems to
indicate that the
compiler did not find a definition for NCURSES_EXPORT, which
is defined in
ncurses_dll.h

What I'd look for: since most applications do not distinguish
        #include <ncurses/curses.h>
and
        #include <curses.h>
by ifdef's is that your options have only
        -I/software/@sys/usr/include/ncurses
rather than
        -I/software/@sys/usr/include
        -I/software/@sys/usr/include/ncurses
Since the ncurses headers (unctrl.h, term.h) will have a
line like
        #include <ncurses/curses.h>
it really needs both -I options.  (Specifying both still
does not work around
the gcc fixincludes problem - that's why I remember that one
first).
 
> > (It's "fixing" a place which is providing a typedef if
it doesn't exist).
> > I modified the ifdef's to avoid this problem.  The quick
fix is to remove
> > curses.h from gcc's fixed-includes.  The reason why
NCURSES_EXPORT is not
> > defined is because gcc finds the wrong curses.h and
doesn't find ncurses_dll.h
> > because its fixed-include forces it into the wrong
search path.
> >
> > If it's not that - perhaps more info.  (Perhaps just
setting $CPPFLAGS in
> > the environment is needed).
> 
> But the message
> 
> cc: Error: /software/@sys/usr/include/ncurses/curses.h,
> line 506: Missing identifier. (parnoident)
> extern NCURSES_EXPORT(int) addch (const chtype);
> /* generated */
> ---------------------------^
> cc: Error: /software/@sys/usr/include/ncurses/curses.h,
> line 507: Missing identifier. (parnoident)
> extern NCURSES_EXPORT(int) addchnstr (const chtype *,
> int); /* generated */
> ---------------------------^
> cc: Error: /software/@sys/usr/include/ncurses/curses.h,
> line 508: Missing identifier. (parnoident)
> extern NCURSES_EXPORT(int) addchstr (const chtype *);
> /* generated */
> ---------------------------^
> 
> confirms that CPPFLAGS or CFLAGS point to the location
where ncurses are
> installed! Maybe the problem is that ncurses/ncurses.h are
stored as
> ncurses/curses.h?
> 


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 22:35

Message:
Logged In: YES 
user_id=21627

I see. This seems to be either a bug in ncurses, or in gcc.
Closing as third-party.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 16:10

Message:
Logged In: YES 
user_id=696559

I asked the developer of ncurses. This is his first reply.

From: Thomas Dickey <dickey@herndon4.his.com>

My guess (because I've seen it a few times)
is that it's a system where someone installed a new version
of gcc. Its fixincludes script was modified a year or two
ago with the effect of putting a copy of curses.h into gcc's
so-called fixed-include files, e.g.,

        /usr/lib/gcc-lib/i386-linux/3.0.4/include

(It's "fixing" a place which is providing a typedef if it
doesn't exist). I modified the ifdef's to avoid this
problem.  The quick fix is to remove curses.h from gcc's
fixed-includes.  The reason why NCURSES_EXPORT is not
defined is because gcc finds the wrong curses.h and doesn't
find ncurses_dll.h because its fixed-include forces it into
the wrong search path.

If it's not that - perhaps more info.  (Perhaps just setting
$CPPFLAGS in the environment is needed).


----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:00

Message:
Logged In: YES 
user_id=696559

Sorry, I'm not aprogrammer, should I attach some of the
headers files distributed by ncurses?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:50

Message:
Logged In: YES 
user_id=21627

Can you report how NCURSES_EXPORT is defined on your system?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470


From noreply@sourceforge.net  Tue Jun 17 23:10:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 15:10:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-755564 ] Tutorial: 4.7.2 Keyword Arguments **name output order wrong
Message-ID: <E19SOfA-0000TC-00@sc8-sf-web4.sourceforge.net>

Bugs item #755564, was opened at 2003-06-17 00:53
Message generated for change (Comment added) made by kakkonen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 3
Submitted By: Jan Mattila (kakkonen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial: 4.7.2 Keyword Arguments **name output order wrong

Initial Comment:
In the Tutorial at chapter 4.7.2 Keyword Arguments, 
there is an example about the formal parameter **name. 
I'm quoting the whole thing, for quick reference:

--- begin extract from Tutorial ---
def cheeseshop(kind, *arguments, **keywords):
    print "-- Do you have any", kind, '?'
    print "-- I'm sorry, we're all out of", kind
    for arg in arguments: print arg
    print '-'*40
    for kw in keywords.keys(): print kw, ':', keywords[kw]

It could be called like this:

cheeseshop('Limburger', "It's very runny, sir.",
           "It's really very, VERY runny, sir.",
           client='John Cleese',
           shopkeeper='Michael Palin',
           sketch='Cheese Shop Sketch')

and of course it would print:

-- Do you have any Limburger ?
-- I'm sorry, we're all out of Limburger
It's very runny, sir.
It's really very, VERY runny, sir.
----------------------------------------
client : John Cleese
shopkeeper : Michael Palin
sketch : Cheese Shop Sketch
--- end extract from Tutorial ---

What it actually prints on my LFS 3.3 (linuxfromscratch)
based distribution with Python 2.1.3 is

--- begin print out of cheeseshop ---
-- Do you have any Limburger ?
-- I'm sorry, we're all out of Limburger
It's very runny, sir.
It's really very, VERY runny, sir.
----------------------------------------
client : John Cleese
sketch : Cheese Shop Sketch
shopkeeper : Michael Palin
--- end print out of cheeseshop ---

The problem is that the keywords[kw] list order is
garbled. I tried stripping this function of the *arguments
formal parameter and I got the same result. I tried
different amounts of **keywords in different
aphabetical orders. The resulting order does not 
seem to be random and does not seem to be aplhabetical
nor related to the length of the **keywords or anything
I could figure out.

It's probably not a typo (on my part), because I copied 
the code straight from the Tutorial page. 

Now, this is not really a bug in my opinion, so I'm not 
expecting a fix, but I was just trying to read through
the Tutorial and try all the example code and got 
stuck trying to figure how you could tell the print order 
of a formal parameter **name -type's name[kw] list.

I was thinking, that maybe if someone of class wizard 
or higher would care to indulge me in the reason for 
this behaviour I could become enlightened on another 
aspect of Python. I'm not expecting swift replies, since
this is a zero-priority glitch, but someone, somewhere,
someday, maybe? No? Okay. Just a thought...

So much for trying to make this short.

I managed to reproduce the problem on Python 1.5.2
on Red Hat Linux 7.3.2 on linux-i386

----------------------------------------------------------------------

>Comment By: Jan Mattila (kakkonen)
Date: 2003-06-18 01:10

Message:
Logged In: YES 
user_id=802538

Right,

Can you force the submitter's comments to fall in line with the
rest of the comments, instead of getting pushed to the front
of the que? This order breaks the chain of comments and, 
is IMHO more difficult to read. 

Be that as it may. I read a couple of these bug report thingies
and felt that I should propose some text in html format if
I wanted anything to go anywhere, without burdening people
with genuinely important things to do.

I'm attaching a file with the bit of code from the last comment
and some explanatory text in html format (please excuse the
language). The text is proposed to replace chapter 4.7.2 in the
Python 2.1.3 Tutorial at:

http://www.python.org/doc/2.1.3/tut/node6.html#SECTION006720000000000000000


N.B. There are two comments in the html, so if none are allowed
in the tutorial html, you know what to do with them.


-Jan 

P.S. I realise that putting all of this under the heading 
"Keyword arguments" is stretching it beyond breaking
point. Thus maybe the quickest way would be to just
add the text from chapter 5.4 to chapter 4.7.2, something
like this:

"Note that the keys() method of a dictionary object returns 
a list of all the keys used in the dictionary, in random order."

----------------------------------------------------------------------

Comment By: Jan Mattila (kakkonen)
Date: 2003-06-17 23:04

Message:
Logged In: YES 
user_id=802538

Thanks  Christopher,

Your reply solved the mystery, but I was unable to find the 
text you mentioned in the Tutorial at:

http://www.python.org/doc/2.1.3/tut/tut.html

I tried searching the whole thing, just in case, and the
closest 
I found was this:

"The keys() method of a dictionary object returns a list of all 
the keys used in the dictionary, in random order (if you want 
it sorted, just apply the sort() method to the list of keys)."

But it was in chapter 5.4 Dictionaries, which is quite a way
from the mystery at Chapter 4.7.2. 

I mean the text you quoted? would solve the mystery instantly
and even shed light on how to fix it. That is, if it was in the
tutorial.

My question is: Can you or someone put it there?

Additionally it would be nice to either exclude the sorted
list from the Tutorial or add a snippet of code for reproducing
the list exactly. 

I think this could do it (although I'm sure someone knows
a better way, and that should go into the tutorial):

def cheeseshop(kind, *arguments, **keywords):
        print "-- Do you have any", kind, '?'
        print "-- I'm sorry, we're all out of", kind
        for arg in arguments: print arg
        print '-'*40
        info = keywords.items()
        info.sort()
        for value in info:
                print value[0], ':', value[1]


-Jan

(forgot to sign my last message...)

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 06:45

Message:
Logged In: YES 
user_id=531881

Hi Jan-

The tutorial points out:

Note that the sort() method of the list of keyword argument
names is called before printing the contents of the keywords
dictionary; if this is not done, the order in which the
arguments are
printed is undefined.

Not sure if a patch is necessary :)


-c

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 02:08:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 18:08:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-755031 ] zipfile: inconsistent filenames with InfoZip "unzip"
Message-ID: <E19SRRa-0008Vp-00@sc8-sf-web3.sourceforge.net>

Bugs item #755031, was opened at 2003-06-15 17:23
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Greg Ward (gward)
Summary: zipfile: inconsistent filenames with InfoZip "unzip"

Initial Comment:
zipfile.py gives filenames inconsistent with the
InfoZIP "unzip" utility for certain ZIP files.  My
source is an email virus, so the ZIP files are almost
certainl malformed.  Nevertheless, it would be nice if
"unzip -l" and ZipFile.namelist() gave consistent
filenames.

Example: the attached Demo.zip (extracted from an email
virus caught on mail.python.org) looks like this
according to InfoZip:

$ unzip -l /tmp/Demo.zip 
Archive:  /tmp/Demo.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
    44544  01-26-03 20:49  
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe
 --------                   -------
    44544                   1 file

But according to ZipFile.namelist(), the name of that
file is:
 
DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exescr000000000000000000.txt

Getting the same result with Python 2.2.2 and a
~2-week-old build of 2.3 CVS.


----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2003-06-17 21:08

Message:
Logged In: YES 
user_id=14422

Fixed with patch #755987.

----------------------------------------------------------------------

Comment By: James C. Ahlstrom (ahlstromjc)
Date: 2003-06-17 11:50

Message:
Logged In: YES 
user_id=64929

I submitted a patch for this.  It is 755987.  See further 
comments there.

----------------------------------------------------------------------

Comment By: James C. Ahlstrom (ahlstromjc)
Date: 2003-06-16 10:29

Message:
Logged In: YES 
user_id=64929

The analysis by sjones is correct.  Python and the zip file 
format both allow null bytes in file names.  But in this case, 
the file is infected with the "I-Worm.Lentin.o" virus and the 
file name is designed to hide this.  The file name ends in ".txt" 
but the file name up to the null byte ends in ".exe".  The 
intention is that a virus scanner would skip this file because it 
ends in ".txt" ( a non-executable text file), but that 
the ".exe" would be seen (an executable program file) if the 
file were clicked, and so the file would be executed.

Testing this on my machine, my virus scanner (Kaspersky) 
nevertheless flags the ".zip" file as containing a virus, but this 
depends on the particular virus scanner and its settings.

I suggest that zipfile.py should terminate file names at a null 
byte as InfoZip does.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-15 21:23

Message:
Logged In: YES 
user_id=589306

The actual filename from the zipfile is:
filename =
'DOCUME~1\CHRISS~1\LOCALS~1\Temp\Demo.exe\x00\x00scr\x00000000000000000000.txt'

Notice there is a \x00 after Demo.exe. My guess is InfoZip
stores the filename in a null terminated string and this
extra null character in the filename terminates it at this
point. Python doesn't care if you have nulls in the string,
so it prints the entire filename.

You can see the zip file format description at
ftp://ftp.info-zip.org/pub/infozip/doc/appnote-981119-iz.zip

The format does say:
      2)  String fields are not null terminated, since the
          length is given explicitly.

But it doesn't really say if strings are allowed to have
nulls in them.

So does Python or InfoZip get this right?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-15 21:19

Message:
Logged In: YES 
user_id=6380

That almost sounds like an intentional inconsistency. Could
it be that the central directory has one name but the local
header has a different one? Or that there's a null byte in
the filename so that the filename length is inconsistent?
The front of the file looks like this according to od -c:

0000000   P   K 003 004  \n  \0  \0  \0  \0  \0   *   Š   :
  .   c   Ì
0000020  \v   g  \0   ®  \0  \0  \0   ®  \0  \0   D  \0  \0
 \0   D   O
0000040   C   U   M   E   ~   1   \   C   H   R   I   S   S
  ~   1   \
0000060   L   O   C   A   L   S   ~   1   \   T   e   m   p
  \   D   e
0000100   m   o   .   e   x   e  \0  \0   s   c   r  \0   0
  0   0   0
0000120   0   0   0   0   0   0   0   0   0   0   0   0   0
  0   .   t
0000140   x   t   M   Z 220  \0 003  \0  \0  \0 004  \0  \0
 \0   ÿ   ÿ
0000160  \0  \0   ž  \0  \0  \0  \0  \0  \0  \0   @  \0  \0
 \0  \0  \0


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755031&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 02:13:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 18:13:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-753451 ] classmethod abuse --> SystemError
Message-ID: <E19SRWO-0000Cq-00@sc8-sf-web3.sourceforge.net>

Bugs item #753451, was opened at 2003-06-12 13:09
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753451&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: classmethod abuse --> SystemError

Initial Comment:
This is obviously a silly thing to do:

>>> classmethod(1).__get__(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: ../Objects/classobject.c:2102: bad
argument to internal function

but I think that's still a bug.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-17 20:13

Message:
Logged In: YES 
user_id=80475

Added a callability check.
See Objects/funcobject.c 1.195

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 03:00

Message:
Logged In: YES 
user_id=357491

Well, couldn't we check if the argument is a non-data descriptor 
at least?  Since classmethod only works with new-style we know 
the method will be a non-data descriptor.  That should prevent 
allowing arguments like 1 being allowed through.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753451&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 02:18:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 18:18:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-750092 ] exec documentation not updated
Message-ID: <E19SRaT-0006a2-00@sc8-sf-web4.sourceforge.net>

Bugs item #750092, was opened at 2003-06-06 09:01
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750092&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michele Simionato (michele_s)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: exec documentation not updated

Initial Comment:
The 2.3b1 reference manual (last update april 25 2003)
still says 
that executable strings must end with a newline, but
this has
been fixed now (finally, it was very annoying :-).

                                                      
                       M.S.

----------------------------------------------------------------------

Comment By: Steven Taschuk (staschuk)
Date: 2003-06-08 15:29

Message:
Logged In: YES 
user_id=666873

Patch 751038.

http://www.python.org/sf/751038

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750092&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 02:33:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 17 Jun 2003 18:33:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-750092 ] exec documentation not updated
Message-ID: <E19SRpc-0006ye-00@sc8-sf-web4.sourceforge.net>

Bugs item #750092, was opened at 2003-06-06 09:01
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750092&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michele Simionato (michele_s)
Assigned to: Raymond Hettinger (rhettinger)
Summary: exec documentation not updated

Initial Comment:
The 2.3b1 reference manual (last update april 25 2003)
still says 
that executable strings must end with a newline, but
this has
been fixed now (finally, it was very annoying :-).

                                                      
                       M.S.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-17 20:33

Message:
Logged In: YES 
user_id=80475

Applied Steven's patch.
See Applied as Doc/ref/ref6.tex 1.66

----------------------------------------------------------------------

Comment By: Steven Taschuk (staschuk)
Date: 2003-06-08 15:29

Message:
Logged In: YES 
user_id=666873

Patch 751038.

http://www.python.org/sf/751038

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750092&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 14:01:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 06:01:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-756576 ] Recursion limit too high for MacOSX
Message-ID: <E19ScYk-0005qw-00@sc8-sf-web4.sourceforge.net>

Bugs item #756576, was opened at 2003-06-18 15:01
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=756576&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recursion limit too high for MacOSX

Initial Comment:
Python's recursion limit is too high for Mac OS X, where the 
default stack size is 512K. The attached script will never 
trigger a maximum recursion depth exception, it will have 
crashed Python with a segmentation violation before that.

A possible solution is a call to sys.setrecursionlimit() in 
site.py, another is to change the number "1000" in ceval.c 
to a configure-time constant.

Other platforms may also suffer this problem, it may be a 
good idea to add a test_stackoverflow.

I'm willing to do the work involved, but I'd like some 
feedback first.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756576&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 14:19:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 06:19:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-753518 ] Installing idle from new location
Message-ID: <E19Scq8-0003EX-00@sc8-sf-web1.sourceforge.net>

Bugs item #753518, was opened at 2003-06-12 21:51
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Installing idle from new location

Initial Comment:
Makefile.pre.in and Mac/OSX/Makefile still use Tools/idle as 
the source from which they install idle in stead of the new 
Lib/idletools.

I'm mainly putting this bug report in the database so we 
don't forget to fix this before 2.3b2.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-18 15:19

Message:
Logged In: YES 
user_id=45365

Kurt, can this bug be closed?

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-06-13 19:33

Message:
Logged In: YES 
user_id=149084

Jack, I've got Makefile.pre.in mostly done,
(there's a problem installing the icons).  I was 
going to do exactly what you suggest: look at
Mac/OSX/Makefile and /maybe/ make a first try,
then assign this to you.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-13 10:25

Message:
Logged In: YES 
user_id=45365

And, Kurt, could you please assign to me when Makefile.pre.in is 
done, so I can fix Mac/OSX/Makefile? (unless you want to give 
that a go too:-)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-13 03:15

Message:
Logged In: YES 
user_id=33168

Kurt, can you take a look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 15:15:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 07:15:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-753518 ] Installing idle from new location
Message-ID: <E19Sdic-0005sO-00@sc8-sf-web1.sourceforge.net>

Bugs item #753518, was opened at 2003-06-12 14:51
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Jack Jansen (jackjansen)
Summary: Installing idle from new location

Initial Comment:
Makefile.pre.in and Mac/OSX/Makefile still use Tools/idle as 
the source from which they install idle in stead of the new 
Lib/idletools.

I'm mainly putting this bug report in the database so we 
don't forget to fix this before 2.3b2.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-06-18 09:15

Message:
Logged In: YES 
user_id=149084

Guido finished this off over the weekend and
IDLE installs fine on Linux.  There may be some
remaining issues on Windows with the icons and
the location/composition of the 'idle' scripts. (I
can't build on Windows yet.)

I see you've done some work on the Mac side.
I'm going to pass it off to you at this point.

Thanks for the help!

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-18 08:19

Message:
Logged In: YES 
user_id=45365

Kurt, can this bug be closed?

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-06-13 12:33

Message:
Logged In: YES 
user_id=149084

Jack, I've got Makefile.pre.in mostly done,
(there's a problem installing the icons).  I was 
going to do exactly what you suggest: look at
Mac/OSX/Makefile and /maybe/ make a first try,
then assign this to you.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-13 03:25

Message:
Logged In: YES 
user_id=45365

And, Kurt, could you please assign to me when Makefile.pre.in is 
done, so I can fix Mac/OSX/Makefile? (unless you want to give 
that a go too:-)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-12 20:15

Message:
Logged In: YES 
user_id=33168

Kurt, can you take a look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 16:40:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 08:40:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-756576 ] Recursion limit too high for MacOSX
Message-ID: <E19Sf3T-0005R6-00@sc8-sf-web2.sourceforge.net>

Bugs item #756576, was opened at 2003-06-18 13:01
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756576&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recursion limit too high for MacOSX

Initial Comment:
Python's recursion limit is too high for Mac OS X, where the 
default stack size is 512K. The attached script will never 
trigger a maximum recursion depth exception, it will have 
crashed Python with a segmentation violation before that.

A possible solution is a call to sys.setrecursionlimit() in 
site.py, another is to change the number "1000" in ceval.c 
to a configure-time constant.

Other platforms may also suffer this problem, it may be a 
good idea to add a test_stackoverflow.

I'm willing to do the work involved, but I'd like some 
feedback first.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-18 15:40

Message:
Logged In: YES 
user_id=31392

I'd like to see a per-platform recusion limit, because the
limit could be much higher on Linux and Windows than 1000.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756576&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 17:02:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 09:02:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-756104 ] Calling socket.recv() with a large number breaks
Message-ID: <E19SfOe-0007kO-00@sc8-sf-web4.sourceforge.net>

Bugs item #756104, was opened at 2003-06-17 18:25
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex R.M. Turner (plexq)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling socket.recv() with a large number breaks

Initial Comment:
I have a backup script that calls socket.recv() passing
the amount of data that is left to get for a given file
as the argument.  For very large files (I have one here
that is 1.9Gig) it seems to break horribly after
receiving about 130Meg.  I have tried to track it down
precisely with basic debugging (putting in print
statements in the python code) but it just seams to
freak out around the 130meg mark, and it just doesn't
make sense.  If I change the argument passed to recv to
32767 it works just fine.  I have attatched the loop
that reads data from the socket (In a working state,
the bad code is commented out).

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-18 16:02

Message:
Logged In: YES 
user_id=31392

What happens when you write a C program that does the same
thing?  I expect you'll see similar problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 17:29:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 09:29:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-756104 ] Calling socket.recv() with a large number breaks
Message-ID: <E19SfoQ-0008Eh-00@sc8-sf-web3.sourceforge.net>

Bugs item #756104, was opened at 2003-06-17 14:25
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex R.M. Turner (plexq)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling socket.recv() with a large number breaks

Initial Comment:
I have a backup script that calls socket.recv() passing
the amount of data that is left to get for a given file
as the argument.  For very large files (I have one here
that is 1.9Gig) it seems to break horribly after
receiving about 130Meg.  I have tried to track it down
precisely with basic debugging (putting in print
statements in the python code) but it just seams to
freak out around the 130meg mark, and it just doesn't
make sense.  If I change the argument passed to recv to
32767 it works just fine.  I have attatched the loop
that reads data from the socket (In a working state,
the bad code is commented out).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-18 12:29

Message:
Logged In: YES 
user_id=31435

BTW, if you're new to socket programming, do read Python's 
socket programming HOWTO:

http://www.amk.ca/python/howto/sockets/

I expect you're the only person in history to try passing such 
a large value to recv() -- even if it worked, you'd almost 
certainly run out of memory trying to allocate buffer space for 
1.9GB.  sockets are a low-level facility, and it's common to 
pass a relatively small power of 2 (for best match with 
hardware and network realities).

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-18 12:02

Message:
Logged In: YES 
user_id=31392

What happens when you write a C program that does the same
thing?  I expect you'll see similar problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 19:22:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 11:22:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-756104 ] Calling socket.recv() with a large number breaks
Message-ID: <E19ShZx-00005y-00@sc8-sf-web1.sourceforge.net>

Bugs item #756104, was opened at 2003-06-17 18:25
Message generated for change (Comment added) made by plexq
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex R.M. Turner (plexq)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling socket.recv() with a large number breaks

Initial Comment:
I have a backup script that calls socket.recv() passing
the amount of data that is left to get for a given file
as the argument.  For very large files (I have one here
that is 1.9Gig) it seems to break horribly after
receiving about 130Meg.  I have tried to track it down
precisely with basic debugging (putting in print
statements in the python code) but it just seams to
freak out around the 130meg mark, and it just doesn't
make sense.  If I change the argument passed to recv to
32767 it works just fine.  I have attatched the loop
that reads data from the socket (In a working state,
the bad code is commented out).

----------------------------------------------------------------------

>Comment By: Alex R.M. Turner (plexq)
Date: 2003-06-18 18:22

Message:
Logged In: YES 
user_id=60034

That as maybe - it might be worth putting a suggested
maximum in the docs.  However I would say that given that an
IPv6 packet could be as large as 2Gig, it's not unreasonable
to ask for a packet as large as 1 Gig.  Wether the problem
is in glibc or python I don't know, although it seems that
asking for a buffer of 1.3 Gig in size, and passing that to
recv() would be odd behaviour on a current system in C given
that most systems couldn't allocate that much memory to a
buffer ;).  I have written fairly extensive socket code in
C/C++ before, and I never used anything larger than 65536
for the obvious reason that you can't receive anything
bigger than that in IPv4 (and most NICs can't handle
anything that big either).  I figured it would be
interesting to see what happened :).  I have a penchant for
being the only person in history to do quite a few things
apparently!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-18 16:29

Message:
Logged In: YES 
user_id=31435

BTW, if you're new to socket programming, do read Python's 
socket programming HOWTO:

http://www.amk.ca/python/howto/sockets/

I expect you're the only person in history to try passing such 
a large value to recv() -- even if it worked, you'd almost 
certainly run out of memory trying to allocate buffer space for 
1.9GB.  sockets are a low-level facility, and it's common to 
pass a relatively small power of 2 (for best match with 
hardware and network realities).

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-18 16:02

Message:
Logged In: YES 
user_id=31392

What happens when you write a C program that does the same
thing?  I expect you'll see similar problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 19:51:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 11:51:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-756104 ] Calling socket.recv() with a large number breaks
Message-ID: <E19Si1m-0004jR-00@sc8-sf-web3.sourceforge.net>

Bugs item #756104, was opened at 2003-06-17 14:25
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex R.M. Turner (plexq)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling socket.recv() with a large number breaks

Initial Comment:
I have a backup script that calls socket.recv() passing
the amount of data that is left to get for a given file
as the argument.  For very large files (I have one here
that is 1.9Gig) it seems to break horribly after
receiving about 130Meg.  I have tried to track it down
precisely with basic debugging (putting in print
statements in the python code) but it just seams to
freak out around the 130meg mark, and it just doesn't
make sense.  If I change the argument passed to recv to
32767 it works just fine.  I have attatched the loop
that reads data from the socket (In a working state,
the bad code is commented out).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-18 14:51

Message:
Logged In: YES 
user_id=31435

I assume you're running on Linux.  Python's implementation of 
recv asks the platform malloc for a buffer of the size 
requested, and raises an exception if malloc returns NULL.  
Unfortunately, malloc on Linux has a nasty habit of returning 
non-NULL even if there's no chance you can actually use the 
amount of memory requested.  There's really nothing Python 
can do about that.

So back to Jeremy's comment:  try the same thing in C.  If 
you get ridiculous behavior there too, it's a platform C/OS 
bug, and Python won't be able to hide it from you.

----------------------------------------------------------------------

Comment By: Alex R.M. Turner (plexq)
Date: 2003-06-18 14:22

Message:
Logged In: YES 
user_id=60034

That as maybe - it might be worth putting a suggested
maximum in the docs.  However I would say that given that an
IPv6 packet could be as large as 2Gig, it's not unreasonable
to ask for a packet as large as 1 Gig.  Wether the problem
is in glibc or python I don't know, although it seems that
asking for a buffer of 1.3 Gig in size, and passing that to
recv() would be odd behaviour on a current system in C given
that most systems couldn't allocate that much memory to a
buffer ;).  I have written fairly extensive socket code in
C/C++ before, and I never used anything larger than 65536
for the obvious reason that you can't receive anything
bigger than that in IPv4 (and most NICs can't handle
anything that big either).  I figured it would be
interesting to see what happened :).  I have a penchant for
being the only person in history to do quite a few things
apparently!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-18 12:29

Message:
Logged In: YES 
user_id=31435

BTW, if you're new to socket programming, do read Python's 
socket programming HOWTO:

http://www.amk.ca/python/howto/sockets/

I expect you're the only person in history to try passing such 
a large value to recv() -- even if it worked, you'd almost 
certainly run out of memory trying to allocate buffer space for 
1.9GB.  sockets are a low-level facility, and it's common to 
pass a relatively small power of 2 (for best match with 
hardware and network realities).

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-18 12:02

Message:
Logged In: YES 
user_id=31392

What happens when you write a C program that does the same
thing?  I expect you'll see similar problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 22:17:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 14:17:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-756842 ] Ms VC 2003 not supported
Message-ID: <E19SkJJ-000836-00@sc8-sf-web1.sourceforge.net>

Bugs item #756842, was opened at 2003-06-18 21: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=756842&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Paolo Invernizzi (darkarathorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ms VC 2003 not supported

Initial Comment:
The current msvccompiler.py has no support for Ms
Visual Studio NET 2003 release.
The registry keys are different than the original
VS.NET and NET Framework

File
"d:\repositories\python\dist\src\lib\distutils\msvccompiler.py",
line 114, in set_macro
    self.macros["$(%s)" % macro] = d[key]
KeyError: 'sdkinstallroot'


---
Paolo Invernizzi

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756842&group_id=5470


From noreply@sourceforge.net  Wed Jun 18 22:30:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 14:30:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-753518 ] Installing idle from new location
Message-ID: <E19SkVP-00005G-00@sc8-sf-web1.sourceforge.net>

Bugs item #753518, was opened at 2003-06-12 21:51
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470

Category: Installation
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Installing idle from new location

Initial Comment:
Makefile.pre.in and Mac/OSX/Makefile still use Tools/idle as 
the source from which they install idle in stead of the new 
Lib/idletools.

I'm mainly putting this bug report in the database so we 
don't forget to fix this before 2.3b2.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-18 23:30

Message:
Logged In: YES 
user_id=45365

I'm happy with it as it is now, so I'll close it.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-06-18 16:15

Message:
Logged In: YES 
user_id=149084

Guido finished this off over the weekend and
IDLE installs fine on Linux.  There may be some
remaining issues on Windows with the icons and
the location/composition of the 'idle' scripts. (I
can't build on Windows yet.)

I see you've done some work on the Mac side.
I'm going to pass it off to you at this point.

Thanks for the help!

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-18 15:19

Message:
Logged In: YES 
user_id=45365

Kurt, can this bug be closed?

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-06-13 19:33

Message:
Logged In: YES 
user_id=149084

Jack, I've got Makefile.pre.in mostly done,
(there's a problem installing the icons).  I was 
going to do exactly what you suggest: look at
Mac/OSX/Makefile and /maybe/ make a first try,
then assign this to you.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-13 10:25

Message:
Logged In: YES 
user_id=45365

And, Kurt, could you please assign to me when Makefile.pre.in is 
done, so I can fix Mac/OSX/Makefile? (unless you want to give 
that a go too:-)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-13 03:15

Message:
Logged In: YES 
user_id=33168

Kurt, can you take a look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753518&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 00:16:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 16:16:55 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-756914 ] SSL support for poplib
Message-ID: <E19SmAh-00033R-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #756914, was opened at 2003-06-18 17:16
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=756914&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL support for poplib

Initial Comment:
I was surprised to find poplib doesn't
have support for SSL.

Any reason why this hasn't been added?

I need this ability for my own use, so
I'd be willing to write the support for
this if there is interest in including it
in poplib.py.

I seems like it would be easy to add a
POP3_SSL subclass similar to IMAP4_SSL
in imaplib.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=756914&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 00:28:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 16:28:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-756924 ] SIGSEGV causes hung threads (Linux)
Message-ID: <E19SmLx-0003SH-00@sc8-sf-web4.sourceforge.net>

Bugs item #756924, was opened at 2003-06-18 16: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=756924&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIGSEGV causes hung threads (Linux)

Initial Comment:
When a segmentation fault happens on Linux in any 
thread but the main thread, the program exits, but 
zombie threads remain behind.

Steps to reproduce:
1. Download attached tar and extract files zombie.py 
and zombieCmodule.c.
2. Compile and link zombieCmodule.c as a shared library 
(or whatever other method you prefer for making a 
Python extension module).
3. Put the output from step 2 (zombieC.so) in your 
lib/python directory.
4. Run python2.2 zombie.py.
5. After the program exits, run ps.

zombie.py launches several threads that just loop 
forever, and one that calls a C function in zombieC. The 
latter prints "NULL!" then segfaults intentionally, 
printing "Segmentation fault". Then the program exits, 
returning control back to the shell.

Expected, and Python 2.1 behavior:
No Python threads appear in the output of ps.

Actual Python 2.2 behavior:
5 Python threads appear in the output of ps. To kill 
them, you have to apply kill -9 to each one individually.

  Not only does this bug leave around messy zombie 
threads, but the threads left behind hold on to program 
resources. For example, if the program binds a socket, 
that port cannot be bound again until someone kills the 
threads. Of course programs should not generate 
segfaults, but if they do they should fail gracefully.

  I have identified the cause of this bug. The old Python 
2.1 behavior can be restored by removing these lines of 
Python/thread_pthread.h:

sigfillset(&newmask);
SET_THREAD_SIGMASK(SIG_BLOCK, &newmask, 
&oldmask);

... and ...

SET_THREAD_SIGMASK(SIG_SETMASK, &oldmask, NULL);

  I guess even SIGSEGV gets blocked by this code, and 
somehow that prevents the default behavior of segfaults 
from working correctly.

  I'm not suggesting that removing this code is a good 
way to fix this bug. This is just an example to show that 
it seems to be the blocking of signals that causes this 
bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756924&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 00:32:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 16:32:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E19SmPY-0007v3-00@sc8-sf-web3.sourceforge.net>

Bugs item #588756, was opened at 2002-07-31 06:12
Message generated for change (Comment added) made by cantanker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

Comment By: Adrian van den Dries (cantanker)
Date: 2003-06-19 09:32

Message:
Logged In: YES 
user_id=209092

Did anyone bother *reading* the FHS?

http://www.pathname.com/fhs/2.2/fhs-4.7.html

> /usr/lib includes object files, libraries, and internal
binaries

http://www.pathname.com/fhs/2.2/fhs-4.11.html

> The /usr/share hierarchy is for all read-only architecture
independent data files.

.py{,c} files are *libraries*, not *data files*.

Thankyou, move along.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-04 02:38

Message:
Logged In: YES 
user_id=357491

It won't help with that request.  Doing that would require changing install 
paths as suggested below.

As for your questions about implementing --fhs-prefix, I can answer a few.  
For Distutils questions you can just email python-dev to get the attention of 
Distutils developers.  For adding a second site-packages directory I am 
against (use PYTHONPATH if that is needed).

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-06-03 22:49

Message:
Logged In: YES 
user_id=60903

PEP 304 addresses one part: the location of the generated
.py[co] files. I fail to see, how it adds support to put .py
files in /usr/share.

So it partly solves the problem.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-21 14:38

Message:
Logged In: YES 
user_id=357491

Will PEP 304 solve your problem?

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-31 18:59

Message:
Logged In: YES 
user_id=60903

Ok, I'll give --fhs-prefix a try. some questions:

- the lib_python in getpath.c hardcodes lib/pythonX.Y to 
search for the libraries. Is it enouogh to set PYTHONPATH to 
pythonX.Y?

- who to ask for distutils? are there concerns if a 
module/library is splitted over two directories? Or should there 
symlinks from /usr/lib/pythonX.Y to /usr/share/pythonX.Y?

- currently there is only one site-packages directory. how 
should two site-packages be supported (lib and share)?

- speaking of etc: this is a configuration file and should belong 
into the etc hierarchy. should etc be searched before or after 
the library directories?

Python's include files: not all packages separate platform 
specific headers from generic headers, probably therefore the 
FHS puts them in /usr/include.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-31 06:51

Message:
Logged In: YES 
user_id=45365

The layouts are similar, but not the same. MacPython-OS9 uses the source tree layout, and Windows-Python too, IIRC.
MacPython-OSX in a framework build uses a normal layout, but in a very funny place, with lots of symlinks to make it behave like a framework. I would be very surprised if, say WinCE python or AS/400 python had anything resembling a unix layout. But all these layouts are similar enough that I've never come across a Python where I felt completely lost.

I think there's nothing wrong with enabling people to use their preferred layout, if they have a good reason for it, but I would be against enforcing it unless the advantages are clear and universal.

And someone has to do the work:-)


----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-31 06:32

Message:
Logged In: YES 
user_id=163326

Sorry, Matthias. I was confusing the FHS with the Linux
Standard Base.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-31 06:24

Message:
Logged In: YES 
user_id=163326

I assume that the Python directory layout is the same on all
currently supported platforms by Python. I really don't know
enough to be sure - the less that's true, the less my
following argument will be valid:

There are really two concerns:
1) make Python conform to the FHS
2) make Python behave the same cross-platform (Windows,
Unix, Mac, BeOS, OS/2, VMS, AS/400, ...)

You can't have both unless you force the FHS directory
layout onto all other platforms. I personally think that 2)
is a good thing.

I welcome the proposal of a configuration option to make
Python FHS-compliant, but I think it should not be the
default. Btw. you'd probably have to patch distutils, too.

Jack said that Pyhon include files should be cross-platform.
AFAIK they are, with one exceptions: pyconfig.h.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 22:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 22:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 21:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 20:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 18:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 16:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 22:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 21:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-31 06:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 00:52:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 16:52:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-756940 ] can't CNTRL-C when running os.system in a thread
Message-ID: <E19SmjE-0000JC-00@sc8-sf-web3.sourceforge.net>

Bugs item #756940, was opened at 2003-06-18 16:52
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=756940&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't CNTRL-C when running os.system in a thread

Initial Comment:
This is related to Bug #756924.

When os.system is called in a thread, Control-C is 
ignored.

Steps to reproduce:
1. Download the attached file fibonacci.py.
2. Run python2.2 fibonacci.py.
3. Hit CNTRL-C.

fibonacci.py starts a thread that executes fibonacci.py 
again (but with a flag to prevent this from recursing 
infinitely). Then it computes and prints the Fibonacci 
sequence, the slow way. The process executed in the 
thread redirects this to a file to avoid conflict over 
stdout. All this is just to give the program something to 
do while you hit CNTRL-C.

Expected, and Python 2.1 behavior:
You get a KeyboardInterrupt exception, a stack trace, 
and the program exits.

Actual Python 2.2 behavior:
No response. You have to run kill on the process.

Maybe this is not a bug, but rather a limitation of Linux, 
since I understand SIGINT is blocked during the C 
function 'system'. However, CNTRL-C worked in Python 
2.1, and that was nicer.


Removing the lines of code described in Bug #756924 
also fix this bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 00:54:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 16:54:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-756924 ] SIGSEGV causes hung threads (Linux)
Message-ID: <E19Smku-0000Pq-00@sc8-sf-web3.sourceforge.net>

Bugs item #756924, was opened at 2003-06-18 16:28
Message generated for change (Comment added) made by morngnstar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756924&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIGSEGV causes hung threads (Linux)

Initial Comment:
When a segmentation fault happens on Linux in any 
thread but the main thread, the program exits, but 
zombie threads remain behind.

Steps to reproduce:
1. Download attached tar and extract files zombie.py 
and zombieCmodule.c.
2. Compile and link zombieCmodule.c as a shared library 
(or whatever other method you prefer for making a 
Python extension module).
3. Put the output from step 2 (zombieC.so) in your 
lib/python directory.
4. Run python2.2 zombie.py.
5. After the program exits, run ps.

zombie.py launches several threads that just loop 
forever, and one that calls a C function in zombieC. The 
latter prints "NULL!" then segfaults intentionally, 
printing "Segmentation fault". Then the program exits, 
returning control back to the shell.

Expected, and Python 2.1 behavior:
No Python threads appear in the output of ps.

Actual Python 2.2 behavior:
5 Python threads appear in the output of ps. To kill 
them, you have to apply kill -9 to each one individually.

  Not only does this bug leave around messy zombie 
threads, but the threads left behind hold on to program 
resources. For example, if the program binds a socket, 
that port cannot be bound again until someone kills the 
threads. Of course programs should not generate 
segfaults, but if they do they should fail gracefully.

  I have identified the cause of this bug. The old Python 
2.1 behavior can be restored by removing these lines of 
Python/thread_pthread.h:

sigfillset(&newmask);
SET_THREAD_SIGMASK(SIG_BLOCK, &newmask, 
&oldmask);

... and ...

SET_THREAD_SIGMASK(SIG_SETMASK, &oldmask, NULL);

  I guess even SIGSEGV gets blocked by this code, and 
somehow that prevents the default behavior of segfaults 
from working correctly.

  I'm not suggesting that removing this code is a good 
way to fix this bug. This is just an example to show that 
it seems to be the blocking of signals that causes this 
bug.

----------------------------------------------------------------------

>Comment By: Greg Jones (morngnstar)
Date: 2003-06-18 16:54

Message:
Logged In: YES 
user_id=554883

Related to Bug #756940.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756924&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 03:19:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 19:19:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-756982 ] mailbox should use email not rfc822
Message-ID: <E19Sp0v-0005Kx-00@sc8-sf-web3.sourceforge.net>

Bugs item #756982, was opened at 2003-06-19 02: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=756982&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Leslie (benno37)
Assigned to: Nobody/Anonymous (nobody)
Summary: mailbox should use email not rfc822

Initial Comment:
The mailbox module uses the rfc822 module as its
default factory for creating message objects. The
rfc822 documentation claims that its use is deprecated.
The mailbox module should probably use the new email
module as its default factory.

Of course this has backward compatibility issues, in
which case it should at least be mentioned in the
mailbox documentation that it uses the deprecated
rfc822 module, and provide an example of how to use the
email module instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 03:27:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 19:27:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-225476 ] Codec naming scheme and aliasing support
Message-ID: <E19Sp8h-0007ca-00@sc8-sf-web2.sourceforge.net>

Bugs item #225476, was opened at 2000-12-12 14:51
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470

Category: Unicode
Group: Feature Request
>Status: Closed
Resolution: None
Priority: 3
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Codec naming scheme and aliasing support

Initial Comment:
The docs should contain a note about the codec naming scheme,
the use of codec packages and how to address them in the
encoding name and some notes about the aliasing support
which is available for codecs which are found by the standard
codec search function in the encodings package.

Here's a starter (actually a posting to python-dev, but it has all
the needed details):
"""
I just wanted to inform you of a change I plan for the standard
encodings search function to enable better support for aliasing
of encoding names.

The current implementation caches the aliases returned from the
codecs .getaliases() function in the encodings lookup cache
rather than in the alias cache. As a consequence, the hyphen to
underscore mapping is not applied to the aliases. A codec would
have to return a list of all combinations of names with hyphens
and underscores in order to emulate the standard lookup 
behaviour.

I have a ptach which fixes this and also assures that aliases
cannot be overwritten by codecs which register at some later
point in time. This assures that we won't run into situations
where a codec import suddenly overrides behaviour of previously
active codecs. [The patch was checked into CVS on 2000-12-12.]

I would also like to propose the use of a new naming scheme
for codecs which enables drop-in installation. As discussed
on the i18n-sig list, people would like to install codecs
without having the users to call a codec registration function
or to touch site.py.

The standard search function in the encodings package has a
nice property (which I only noticed after the fact ;) which
allows using Python package names in the encoding names,
e.g. you can install a package 'japanese' and the access the
codecs in that package using 'japanese.shiftjis' without
having to bother registering a new codec search function
for the package -- the encodings package search function
will redirect the lookup to the 'japanese' package.

Using package names in the encoding name has several
advantages:
* you know where the codec comes from
* you can have mutliple codecs for the same encoding
* drop-in installation without registration is possible
* the need for a non-default encoding package is visible in the
  source code
* you no longer need to drop new codecs into the Python
  standard lib

"""


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 02:27

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:39

Message:
Logged In: YES 
user_id=31392

Is this a bug?  Or should you just write a PEP?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 10:48

Message:
Logged In: YES 
user_id=38388

This should probably become a PEP...

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 03:33:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 19:33:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-225476 ] Codec naming scheme and aliasing support
Message-ID: <E19SpET-0007nr-00@sc8-sf-web2.sourceforge.net>

Bugs item #225476, was opened at 2000-12-12 14:51
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470

Category: Unicode
Group: Feature Request
Status: Closed
Resolution: None
Priority: 3
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Codec naming scheme and aliasing support

Initial Comment:
The docs should contain a note about the codec naming scheme,
the use of codec packages and how to address them in the
encoding name and some notes about the aliasing support
which is available for codecs which are found by the standard
codec search function in the encodings package.

Here's a starter (actually a posting to python-dev, but it has all
the needed details):
"""
I just wanted to inform you of a change I plan for the standard
encodings search function to enable better support for aliasing
of encoding names.

The current implementation caches the aliases returned from the
codecs .getaliases() function in the encodings lookup cache
rather than in the alias cache. As a consequence, the hyphen to
underscore mapping is not applied to the aliases. A codec would
have to return a list of all combinations of names with hyphens
and underscores in order to emulate the standard lookup 
behaviour.

I have a ptach which fixes this and also assures that aliases
cannot be overwritten by codecs which register at some later
point in time. This assures that we won't run into situations
where a codec import suddenly overrides behaviour of previously
active codecs. [The patch was checked into CVS on 2000-12-12.]

I would also like to propose the use of a new naming scheme
for codecs which enables drop-in installation. As discussed
on the i18n-sig list, people would like to install codecs
without having the users to call a codec registration function
or to touch site.py.

The standard search function in the encodings package has a
nice property (which I only noticed after the fact ;) which
allows using Python package names in the encoding names,
e.g. you can install a package 'japanese' and the access the
codecs in that package using 'japanese.shiftjis' without
having to bother registering a new codec search function
for the package -- the encodings package search function
will redirect the lookup to the 'japanese' package.

Using package names in the encoding name has several
advantages:
* you know where the codec comes from
* you can have mutliple codecs for the same encoding
* drop-in installation without registration is possible
* the need for a non-default encoding package is visible in the
  source code
* you no longer need to drop new codecs into the Python
  standard lib

"""


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 02:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 02:27

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:39

Message:
Logged In: YES 
user_id=31392

Is this a bug?  Or should you just write a PEP?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 10:48

Message:
Logged In: YES 
user_id=38388

This should probably become a PEP...

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 03:33:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 19:33:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-225476 ] Codec naming scheme and aliasing support
Message-ID: <E19SpFA-0007oQ-00@sc8-sf-web2.sourceforge.net>

Bugs item #225476, was opened at 2000-12-12 14:51
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470

Category: Unicode
Group: Feature Request
Status: Closed
Resolution: None
Priority: 3
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Codec naming scheme and aliasing support

Initial Comment:
The docs should contain a note about the codec naming scheme,
the use of codec packages and how to address them in the
encoding name and some notes about the aliasing support
which is available for codecs which are found by the standard
codec search function in the encodings package.

Here's a starter (actually a posting to python-dev, but it has all
the needed details):
"""
I just wanted to inform you of a change I plan for the standard
encodings search function to enable better support for aliasing
of encoding names.

The current implementation caches the aliases returned from the
codecs .getaliases() function in the encodings lookup cache
rather than in the alias cache. As a consequence, the hyphen to
underscore mapping is not applied to the aliases. A codec would
have to return a list of all combinations of names with hyphens
and underscores in order to emulate the standard lookup 
behaviour.

I have a ptach which fixes this and also assures that aliases
cannot be overwritten by codecs which register at some later
point in time. This assures that we won't run into situations
where a codec import suddenly overrides behaviour of previously
active codecs. [The patch was checked into CVS on 2000-12-12.]

I would also like to propose the use of a new naming scheme
for codecs which enables drop-in installation. As discussed
on the i18n-sig list, people would like to install codecs
without having the users to call a codec registration function
or to touch site.py.

The standard search function in the encodings package has a
nice property (which I only noticed after the fact ;) which
allows using Python package names in the encoding names,
e.g. you can install a package 'japanese' and the access the
codecs in that package using 'japanese.shiftjis' without
having to bother registering a new codec search function
for the package -- the encodings package search function
will redirect the lookup to the 'japanese' package.

Using package names in the encoding name has several
advantages:
* you know where the codec comes from
* you can have mutliple codecs for the same encoding
* drop-in installation without registration is possible
* the need for a non-default encoding package is visible in the
  source code
* you no longer need to drop new codecs into the Python
  standard lib

"""


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 02:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 02:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 02:27

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:39

Message:
Logged In: YES 
user_id=31392

Is this a bug?  Or should you just write a PEP?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 10:48

Message:
Logged In: YES 
user_id=38388

This should probably become a PEP...

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 03:58:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 18 Jun 2003 19:58:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-756940 ] can't CNTRL-C when running os.system in a thread
Message-ID: <E19SpdX-0002t6-00@sc8-sf-web1.sourceforge.net>

Bugs item #756940, was opened at 2003-06-18 16:52
Message generated for change (Comment added) made by morngnstar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't CNTRL-C when running os.system in a thread

Initial Comment:
This is related to Bug #756924.

When os.system is called in a thread, Control-C is 
ignored.

Steps to reproduce:
1. Download the attached file fibonacci.py.
2. Run python2.2 fibonacci.py.
3. Hit CNTRL-C.

fibonacci.py starts a thread that executes fibonacci.py 
again (but with a flag to prevent this from recursing 
infinitely). Then it computes and prints the Fibonacci 
sequence, the slow way. The process executed in the 
thread redirects this to a file to avoid conflict over 
stdout. All this is just to give the program something to 
do while you hit CNTRL-C.

Expected, and Python 2.1 behavior:
You get a KeyboardInterrupt exception, a stack trace, 
and the program exits.

Actual Python 2.2 behavior:
No response. You have to run kill on the process.

Maybe this is not a bug, but rather a limitation of Linux, 
since I understand SIGINT is blocked during the C 
function 'system'. However, CNTRL-C worked in Python 
2.1, and that was nicer.


Removing the lines of code described in Bug #756924 
also fix this bug.

----------------------------------------------------------------------

>Comment By: Greg Jones (morngnstar)
Date: 2003-06-18 19:58

Message:
Logged In: YES 
user_id=554883

OS is Linux.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 09:28:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 01:28:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-225476 ] Codec naming scheme and aliasing support
Message-ID: <E19SumI-0001VJ-00@sc8-sf-web2.sourceforge.net>

Bugs item #225476, was opened at 2000-12-12 15:51
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470

Category: Unicode
Group: Feature Request
>Status: Pending
Resolution: None
>Priority: 1
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Codec naming scheme and aliasing support

Initial Comment:
The docs should contain a note about the codec naming scheme,
the use of codec packages and how to address them in the
encoding name and some notes about the aliasing support
which is available for codecs which are found by the standard
codec search function in the encodings package.

Here's a starter (actually a posting to python-dev, but it has all
the needed details):
"""
I just wanted to inform you of a change I plan for the standard
encodings search function to enable better support for aliasing
of encoding names.

The current implementation caches the aliases returned from the
codecs .getaliases() function in the encodings lookup cache
rather than in the alias cache. As a consequence, the hyphen to
underscore mapping is not applied to the aliases. A codec would
have to return a list of all combinations of names with hyphens
and underscores in order to emulate the standard lookup 
behaviour.

I have a ptach which fixes this and also assures that aliases
cannot be overwritten by codecs which register at some later
point in time. This assures that we won't run into situations
where a codec import suddenly overrides behaviour of previously
active codecs. [The patch was checked into CVS on 2000-12-12.]

I would also like to propose the use of a new naming scheme
for codecs which enables drop-in installation. As discussed
on the i18n-sig list, people would like to install codecs
without having the users to call a codec registration function
or to touch site.py.

The standard search function in the encodings package has a
nice property (which I only noticed after the fact ;) which
allows using Python package names in the encoding names,
e.g. you can install a package 'japanese' and the access the
codecs in that package using 'japanese.shiftjis' without
having to bother registering a new codec search function
for the package -- the encodings package search function
will redirect the lookup to the 'japanese' package.

Using package names in the encoding name has several
advantages:
* you know where the codec comes from
* you can have mutliple codecs for the same encoding
* drop-in installation without registration is possible
* the need for a non-default encoding package is visible in the
  source code
* you no longer need to drop new codecs into the Python
  standard lib

"""


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-06-19 10:28

Message:
Logged In: YES 
user_id=38388

PEP 42 wouldn't help. The functionality mentioned in the
above quote is all there, so this is just about writing an
informational PEP as guideline for codec authors.

I've set the request to pending and lowered the priority.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:27

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:39

Message:
Logged In: YES 
user_id=31392

Is this a bug?  Or should you just write a PEP?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 12:48

Message:
Logged In: YES 
user_id=38388

This should probably become a PEP...

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 09:33:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 01:33:49 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-225476 ] Codec naming scheme and aliasing support
Message-ID: <E19Surd-0001iM-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #225476, was opened at 2000-12-12 15:51
Message generated for change (Settings changed) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=225476&group_id=5470

>Category: None
>Group: None
>Status: Open
Resolution: None
Priority: 1
Submitted By: M.-A. Lemburg (lemburg)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Codec naming scheme and aliasing support

Initial Comment:
The docs should contain a note about the codec naming scheme,
the use of codec packages and how to address them in the
encoding name and some notes about the aliasing support
which is available for codecs which are found by the standard
codec search function in the encodings package.

Here's a starter (actually a posting to python-dev, but it has all
the needed details):
"""
I just wanted to inform you of a change I plan for the standard
encodings search function to enable better support for aliasing
of encoding names.

The current implementation caches the aliases returned from the
codecs .getaliases() function in the encodings lookup cache
rather than in the alias cache. As a consequence, the hyphen to
underscore mapping is not applied to the aliases. A codec would
have to return a list of all combinations of names with hyphens
and underscores in order to emulate the standard lookup 
behaviour.

I have a ptach which fixes this and also assures that aliases
cannot be overwritten by codecs which register at some later
point in time. This assures that we won't run into situations
where a codec import suddenly overrides behaviour of previously
active codecs. [The patch was checked into CVS on 2000-12-12.]

I would also like to propose the use of a new naming scheme
for codecs which enables drop-in installation. As discussed
on the i18n-sig list, people would like to install codecs
without having the users to call a codec registration function
or to touch site.py.

The standard search function in the encodings package has a
nice property (which I only noticed after the fact ;) which
allows using Python package names in the encoding names,
e.g. you can install a package 'japanese' and the access the
codecs in that package using 'japanese.shiftjis' without
having to bother registering a new codec search function
for the package -- the encodings package search function
will redirect the lookup to the 'japanese' package.

Using package names in the encoding name has several
advantages:
* you know where the codec comes from
* you can have mutliple codecs for the same encoding
* drop-in installation without registration is possible
* the need for a non-default encoding package is visible in the
  source code
* you no longer need to drop new codecs into the Python
  standard lib

"""


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-06-19 10:28

Message:
Logged In: YES 
user_id=38388

PEP 42 wouldn't help. The functionality mentioned in the
above quote is all there, so this is just about writing an
informational PEP as guideline for codec authors.

I've set the request to pending and lowered the priority.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:27

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:39

Message:
Logged In: YES 
user_id=31392

Is this a bug?  Or should you just write a PEP?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 12:48

Message:
Logged In: YES 
user_id=38388

This should probably become a PEP...

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=225476&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 09:35:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 01:35:21 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-225476 ] Codec naming scheme and aliasing support
Message-ID: <E19Sut7-0001mo-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #225476, was opened at 2000-12-12 15:51
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=225476&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 1
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Codec naming scheme and aliasing support

Initial Comment:
The docs should contain a note about the codec naming scheme,
the use of codec packages and how to address them in the
encoding name and some notes about the aliasing support
which is available for codecs which are found by the standard
codec search function in the encodings package.

Here's a starter (actually a posting to python-dev, but it has all
the needed details):
"""
I just wanted to inform you of a change I plan for the standard
encodings search function to enable better support for aliasing
of encoding names.

The current implementation caches the aliases returned from the
codecs .getaliases() function in the encodings lookup cache
rather than in the alias cache. As a consequence, the hyphen to
underscore mapping is not applied to the aliases. A codec would
have to return a list of all combinations of names with hyphens
and underscores in order to emulate the standard lookup 
behaviour.

I have a ptach which fixes this and also assures that aliases
cannot be overwritten by codecs which register at some later
point in time. This assures that we won't run into situations
where a codec import suddenly overrides behaviour of previously
active codecs. [The patch was checked into CVS on 2000-12-12.]

I would also like to propose the use of a new naming scheme
for codecs which enables drop-in installation. As discussed
on the i18n-sig list, people would like to install codecs
without having the users to call a codec registration function
or to touch site.py.

The standard search function in the encodings package has a
nice property (which I only noticed after the fact ;) which
allows using Python package names in the encoding names,
e.g. you can install a package 'japanese' and the access the
codecs in that package using 'japanese.shiftjis' without
having to bother registering a new codec search function
for the package -- the encodings package search function
will redirect the lookup to the 'japanese' package.

Using package names in the encoding name has several
advantages:
* you know where the codec comes from
* you can have mutliple codecs for the same encoding
* drop-in installation without registration is possible
* the need for a non-default encoding package is visible in the
  source code
* you no longer need to drop new codecs into the Python
  standard lib

"""


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-06-19 10:35

Message:
Logged In: YES 
user_id=38388

Changed tracker type to "Feature Request" and state to open
again.
The "pending" state doesn't seem to remain listed on the
My.SF page.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-06-19 10:28

Message:
Logged In: YES 
user_id=38388

PEP 42 wouldn't help. The functionality mentioned in the
above quote is all there, so this is just about writing an
informational PEP as guideline for codec authors.

I've set the request to pending and lowered the priority.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:27

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:39

Message:
Logged In: YES 
user_id=31392

Is this a bug?  Or should you just write a PEP?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 12:48

Message:
Logged In: YES 
user_id=38388

This should probably become a PEP...

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=225476&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 09:35:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 01:35:56 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-225476 ] Codec naming scheme and aliasing support
Message-ID: <E19Sutg-0001nV-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #225476, was opened at 2000-12-12 15:51
Message generated for change (Settings changed) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=225476&group_id=5470

>Category: Unicode
Group: None
Status: Open
>Resolution: Remind
Priority: 1
Submitted By: M.-A. Lemburg (lemburg)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: Codec naming scheme and aliasing support

Initial Comment:
The docs should contain a note about the codec naming scheme,
the use of codec packages and how to address them in the
encoding name and some notes about the aliasing support
which is available for codecs which are found by the standard
codec search function in the encodings package.

Here's a starter (actually a posting to python-dev, but it has all
the needed details):
"""
I just wanted to inform you of a change I plan for the standard
encodings search function to enable better support for aliasing
of encoding names.

The current implementation caches the aliases returned from the
codecs .getaliases() function in the encodings lookup cache
rather than in the alias cache. As a consequence, the hyphen to
underscore mapping is not applied to the aliases. A codec would
have to return a list of all combinations of names with hyphens
and underscores in order to emulate the standard lookup 
behaviour.

I have a ptach which fixes this and also assures that aliases
cannot be overwritten by codecs which register at some later
point in time. This assures that we won't run into situations
where a codec import suddenly overrides behaviour of previously
active codecs. [The patch was checked into CVS on 2000-12-12.]

I would also like to propose the use of a new naming scheme
for codecs which enables drop-in installation. As discussed
on the i18n-sig list, people would like to install codecs
without having the users to call a codec registration function
or to touch site.py.

The standard search function in the encodings package has a
nice property (which I only noticed after the fact ;) which
allows using Python package names in the encoding names,
e.g. you can install a package 'japanese' and the access the
codecs in that package using 'japanese.shiftjis' without
having to bother registering a new codec search function
for the package -- the encodings package search function
will redirect the lookup to the 'japanese' package.

Using package names in the encoding name has several
advantages:
* you know where the codec comes from
* you can have mutliple codecs for the same encoding
* drop-in installation without registration is possible
* the need for a non-default encoding package is visible in the
  source code
* you no longer need to drop new codecs into the Python
  standard lib

"""


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-06-19 10:35

Message:
Logged In: YES 
user_id=38388

Changed tracker type to "Feature Request" and state to open
again.
The "pending" state doesn't seem to remain listed on the
My.SF page.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-06-19 10:28

Message:
Logged In: YES 
user_id=38388

PEP 42 wouldn't help. The functionality mentioned in the
above quote is all there, so this is just about writing an
informational PEP as guideline for codec authors.

I've set the request to pending and lowered the priority.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:33

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 04:27

Message:
Logged In: YES 
user_id=31392

No real activity here in more than 2 years.  Move it to PEP 42 
if you don't want to forget.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:39

Message:
Logged In: YES 
user_id=31392

Is this a bug?  Or should you just write a PEP?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 12:48

Message:
Logged In: YES 
user_id=38388

This should probably become a PEP...

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=225476&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 17:35:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 09:35:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-757365 ] FutureWarning: %u/%o/%x/%X of negative int will return a sig
Message-ID: <E19T2Ni-0004FH-00@sc8-sf-web3.sourceforge.net>

Bugs item #757365, was opened at 2003-06-19 16: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=757365&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Grant (duncangrantuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: FutureWarning: %u/%o/%x/%X of negative int will return a sig

Initial Comment:
printf style formatting:

"FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up"

The library reference clearly states that these are UNSIGNED representations, so the Futurewarning must be spurious!

Please tell me you don't really intend to break this in 2.4 !!!!

In 20+ yrs of low level bit-twiddling I have never ever wanted a signed hexadecimal. The idea of a signed hex or octal is just plain stupid. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757365&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 18:24:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 10:24:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-592112 ] Hint for speeding up cPickle
Message-ID: <E19T391-0006JK-00@sc8-sf-web3.sourceforge.net>

Bugs item #592112, was opened at 2002-08-07 15:31
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592112&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hint for speeding up cPickle

Initial Comment:
There is a strange behaviour in cPickle (in Python 2.2.1).
For big serialized file, the following:

        cPickle.loads(open("my_file").read())

can be much (e.g. 7 times) faster than:

        cPickle.load(open("my_file"))

It seems that cPickle use unbuffered reading or what ?
The pickle implementation doesn't have this behaviour,
and can even be
faster than the C one!

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 17:24

Message:
Logged In: YES 
user_id=31392

Really no time to deal with this.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-08 17:15

Message:
Logged In: YES 
user_id=31392

I expect this has to do with extra overhead in Python to
read from the file, independent of buffering.  The cPickle
code is trying to read small numbers of bytes at a time. 
Each read used fread().  This is slow, because fread is slow
for small numbers of bytes.  It's also slow because cPickle
releases and acquires the global interpeter lock around the
fread() calls.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592112&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 18:25:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 10:25:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-544248 ] gcc warning in unicodeobject.c
Message-ID: <E19T39w-0006LB-00@sc8-sf-web3.sourceforge.net>

Bugs item #544248, was opened at 2002-04-15 16:29
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 1
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: gcc warning in unicodeobject.c

Initial Comment:
gcc 2.96 on Linux (RedHat 7.1) issues the following 
warning when compiling Objects/unicodeobject.c 2.138 
(configured with --enable-unicode=ucs4)

Objects/unicodeobject.c: In function 
`PyUnicodeUCS4_Format':
Objects/unicodeobject.c:5574: warning: int format, 
long int 
arg (arg 3)
Objects/unicodeobject.c:5574: warning: unsigned int 
format, 
long unsigned int arg (arg 4)


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-19 17:25

Message:
Logged In: YES 
user_id=31392

Any chance of progress here?


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-09-18 19:22

Message:
Logged In: YES 
user_id=89016

If all relevant implementations of sprintf() support %lx I'd
say we should change PyString_FromFormatV(). But to decide
that, you should definitely ask on Python-dev.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-13 13:47

Message:
Logged In: YES 
user_id=33168

Line is 6469 in current CVS.  I fixed the warning for arg 3,
arg 4 is a bit harder.  It requires using %lx which is not
supported in PyString_FromFormatV().  I'm not sure the
changes are worthwhile (that's why I didn't make the
change).  To fix PyString_FromFormatV(), these changes are
required:

Line 194:
-                       if (*f == 'l' && *(f+1) == 'd')
+                       if (*f == 'l' && (*(f+1) == 'd' ||
*(f+1) == 'x'))

Line: 266
-                       if (*f == 'l' && *(f+1) == 'd') {
+                       if (*f == 'l' && (*(f+1) == 'd' ||
*(f+1) == 'x')) {

Line: 287
-                               sprintf(s, "%x",
va_arg(vargs, int));
+                               if (longflag)
+                                       sprintf(s, "%lx",
va_arg(vargs, unsigned
 long));
+                               else
+                                       sprintf(s, "%x",
va_arg(vargs, unsigned)
);


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 18:26:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 10:26:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-620190 ] inspect and object instances
Message-ID: <E19T3Au-0006Np-00@sc8-sf-web3.sourceforge.net>

Bugs item #620190, was opened at 2002-10-08 12:26
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620190&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
>Assigned to: Jeremy Hylton (jhylton)
Summary: inspect and object instances

Initial Comment:
inspect.getargspec(NewKlass.aMethod)  fails (which
might technically be OK because the docs only mention
functions, not methods) but I also vaguely seem to
remember that some other operations in the inspect
module only worked for oldstyle classes under 2.2.1.

----------------------------------------------------------------------

Comment By: Michael Stone (mbrierst)
Date: 2003-02-11 22:46

Message:
Logged In: YES 
user_id=670441

Well I think this (one line)
patch will make getargspec work with
methods, if anyone wants to apply it.
Did you find any other operations that
don't work?

patch:
Index: Lib/inspect.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/inspect.py,v
retrieving revision 1.41
diff -c -r1.41 inspect.py
*** Lib/inspect.py	19 Jan 2003 13:21:20 -0000	1.41
--- Lib/inspect.py	11 Feb 2003 22:35:41 -0000
***************
*** 16,22 ****
      getmodule() - determine the module that an object came from
      getclasstree() - arrange classes so as to represent their hierarchy
  
!     getargspec(), getargvalues() - get info about function arguments
      formatargspec(), formatargvalues() - format an argument spec
      getouterframes(), getinnerframes() - get info about frames
      currentframe() - get the current stack frame
--- 16,22 ----
      getmodule() - determine the module that an object came from
      getclasstree() - arrange classes so as to represent their hierarchy
  
!     getargspec(), getargvalues() - get info about function or method's arguments
      formatargspec(), formatargvalues() - format an argument spec
      getouterframes(), getinnerframes() - get info about frames
      currentframe() - get the current stack frame
***************
*** 625,636 ****
      return args, varargs, varkw
  
  def getargspec(func):
!     """Get the names and default values of a function's arguments.
  
      A tuple of four things is returned: (args, varargs, varkw, defaults).
      'args' is a list of the argument names (it may contain nested lists).
      'varargs' and 'varkw' are the names of the * and ** arguments or None.
      'defaults' is an n-tuple of the default values of the last n arguments."""
      if not isfunction(func): raise TypeError, 'arg is not a Python function'
      args, varargs, varkw = getargs(func.func_code)
      return args, varargs, varkw, func.func_defaults
--- 625,637 ----
      return args, varargs, varkw
  
  def getargspec(func):
!     """Get the names and default values of a function or method's arguments.
  
      A tuple of four things is returned: (args, varargs, varkw, defaults).
      'args' is a list of the argument names (it may contain nested lists).
      'varargs' and 'varkw' are the names of the * and ** arguments or None.
      'defaults' is an n-tuple of the default values of the last n arguments."""
+     if ismethod(func): func = func.im_func
      if not isfunction(func): raise TypeError, 'arg is not a Python function'
      args, varargs, varkw = getargs(func.func_code)
      return args, varargs, varkw, func.func_defaults


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620190&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 22:19:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 14:19:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-757520 ] irreproducable segfault on int(1e100)
Message-ID: <E19T6os-0008Ha-00@sc8-sf-web3.sourceforge.net>

Bugs item #757520, was opened at 2003-06-19 23: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=757520&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: irreproducable segfault on int(1e100)

Initial Comment:
Segmentation Fault:

 20 >>> i
1e+100
 21 >>> int(i)Segmentation fault
23:16:12:2:gerrit@stopcontact:~/downl$ python
Python 2.3b1+ (#3, Jun 19 2003, 10:34:37)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> i=1e100
  1 >>> int(i)Segmentation fault
23:16:21:2:gerrit@stopcontact:~/downl$ python
Python 2.3b1+ (#3, Jun 19 2003, 10:34:37)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> i=1e100
  1 >>> int(i)
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104L

I'm unable to reproduce this (sorry). I noticed before
that sometimes, the interactive Python interpreter
segfaults irreproducable: only now, it was two times in
succession but not more than two times. I never
encounered this problem while executing Python programs
from scripts.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757520&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 22:27:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 14:27:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-755560 ] MacPython help needs "community" section
Message-ID: <E19T6wo-00008W-00@sc8-sf-web3.sourceforge.net>

Bugs item #755560, was opened at 2003-06-16 23:42
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755560&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacPython help needs "community" section

Initial Comment:
The MacPython help book needs one more page pointing to 
the SIG and other resources.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-19 23:27

Message:
Logged In: YES 
user_id=45365

Fixed in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755560&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 22:29:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 14:29:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-731631 ] OSX installer .pkg file permissions
Message-ID: <E19T6yZ-0000DZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #731631, was opened at 2003-05-03 00:34
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: OSX installer .pkg file permissions

Initial Comment:
The files installed by the OSX installer .pkg should be group writable. 
This goes both for the files installed in /Library/Frameworks/
Python.framework and /Applications/MacPython-2.3


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-19 23:29

Message:
Logged In: YES 
user_id=45365

I think this is finally fixed. Could you do me a favor and test it? 
Just run Mac/OSX/Dist/build, remove your current /Library/
Frameworks/Python.framework and /Application/MacPython-2.3 
and try the installer built by "build".

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-05-08 01:14

Message:
Logged In: YES 
user_id=92689

Maybe my diagnosis is off. When I install (a non-framework) Python from the 
source, I don't use sudo, I just do "make install". In that case all files are 
owned by me. The installer however installs everything as root, and with the 
files being not group writable it means that I (even as an admin) can't move/
overwrite/delete the files without using sudo or changing the permissions.

I would expect to be able to have write permissions to the installed files if 
I'm an admin user. Don't know how to fix that easily, either.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-05-07 14:04

Message:
Logged In: YES 
user_id=45365

This turns out to be non-trivial: the installed Python tree that is used to 
create the installer has group-write turned off, that's the way Python always 
installs the tree.

I could do a recursive chmod g+w before creating the installer, what do you 
think, would that be safe?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 22:53:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 14:53:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-757542 ] Need to register PythonLauncher as handler for .py
Message-ID: <E19T7LT-0004op-00@sc8-sf-web4.sourceforge.net>

Bugs item #757542, was opened at 2003-06-19 23: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=757542&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Need to register PythonLauncher as handler for .py

Initial Comment:
We still need a way to register PythonLauncher as the 
handler for .py, pyw and .pyc documents. PythonLauncher 
itself could do this easily, but that requires people to run 
PythonLauncher at least once. Or we would have to 
arrange for the installer to do it, or (at the very least) the 
IDE.

The latter is difficult because we don't have access to the 
Launch Services API from Python, yet.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757542&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 22:56:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 14:56:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-757544 ] PythonLauncher needs script-arguments field
Message-ID: <E19T7OE-0004vS-00@sc8-sf-web4.sourceforge.net>

Bugs item #757544, was opened at 2003-06-19 23: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=757544&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PythonLauncher needs script-arguments field

Initial Comment:
PythonLauncher needs a field where you can specify 
command-line arguments to pass to the script.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757544&group_id=5470


From noreply@sourceforge.net  Thu Jun 19 23:43:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 19 Jun 2003 15:43:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-757567 ] Mac/OSX/README outdated
Message-ID: <E19T87v-0006ZE-00@sc8-sf-web4.sourceforge.net>

Bugs item #757567, was opened at 2003-06-20 00: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=757567&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Mac/OSX/README outdated

Initial Comment:
Mac/OSX/README needs work. Some pathnames are 
wrong, and the section on how to build a binary installer is 
incorrect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757567&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 12:11:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 04:11:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-757815 ] Infinite floats don't work in compiled modules on windows
Message-ID: <E19TJnf-0008C7-00@sc8-sf-web3.sourceforge.net>

Bugs item #757815, was opened at 2003-06-20 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=757815&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Tim Peters (tim_one)
Summary: Infinite floats don't work in compiled modules on windows

Initial Comment:
On windows, let's consider the following Python module :


# test.py
INFINITY = 10E40000
print INFINITY


When imported the first time (import test), it displays
"1.#inf" as expected.
But if you quit the Python interpreter, lauch a new one
and import the module again, it displays "1.0" !

The bug occurs only when the module is loaded from the
compiled file (test.pyc), and not when the source file
(test.py) is loaded and compiled.

BTW infinity behaves differently under Linux and
windows (under Linux, they are displayed as "inf", and
float("inf") is ok).

The bug seems to be windows-specific (never seen on
Linux). I tested it with Python 2.2.3 and 2.3b.

BTW infinity behaves differently under Linux and
windows (under Linux, they are displayed as "inf", and
float("inf") is ok).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757815&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 12:19:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 04:19:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-757818 ] tuple assignment -- SystemError: unknown opcode
Message-ID: <E19TJvH-0005aB-00@sc8-sf-web4.sourceforge.net>

Bugs item #757818, was opened at 2003-06-20 07: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=757818&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: tuple assignment -- SystemError: unknown opcode

Initial Comment:
Python 2.3b1 (#2, Jun  4 2003, 03:08:06)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
>>> i,j = True and (1, -1) or (-1, 1)
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = True and (1, -1)  #works
>>> True and (1, -1) or (-1, 1)  #also works
(1, -1)
>>> i,j = (1, -1) or (-1, 1) #nope
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = False and (1, -1) or (-1, 1) #works
>>> i,j
(-1, 1)

Thanks guys!

Mark

P.S. -1 on keyword initialization of dictionary (Liskov)
P.P.S. +1 on adding keys from iterable

$0.02 (*clink*)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 12:29:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 04:29:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-757821 ] logging module docs
Message-ID: <E19TK5P-0000UE-00@sc8-sf-web3.sourceforge.net>

Bugs item #757821, was opened at 2003-06-20 07: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=757821&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module docs

Initial Comment:
http://www.python.org/dev/doc/devel/lib/node297.html

It should be mentioned that it is necessary to import 
"logging.config" to call fileConfig().  The explanation
does not mention the config module so it is confusing
when people try:

import logging
logging.fileConfig(...)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757821&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 12:31:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 04:31:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-757822 ] Additional index items, other minor details
Message-ID: <E19TK7A-000646-00@sc8-sf-web4.sourceforge.net>

Bugs item #757822, was opened at 2003-06-20 07: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=757822&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: Additional index items, other minor details

Initial Comment:
It seems that various recent language changes have not
made it into any of the indices (super, property,
__slots__, ...).

LibRef:

3.14, first paragraph, last sentence unfinished "...to
avoid confusing."

3.3, first paragraph after XXX:  "Not all objects can
be weakly referenced; those objects which do include
class instances,..."


If I get around to it myself, will try to submit
patches for above :).

Thanks...

Mark

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757822&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 14:01:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 06:01:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-757818 ] tuple assignment -- SystemError: unknown opcode
Message-ID: <E19TLW4-0006xy-00@sc8-sf-web2.sourceforge.net>

Bugs item #757818, was opened at 2003-06-20 13:19
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: tuple assignment -- SystemError: unknown opcode

Initial Comment:
Python 2.3b1 (#2, Jun  4 2003, 03:08:06)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
>>> i,j = True and (1, -1) or (-1, 1)
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = True and (1, -1)  #works
>>> True and (1, -1) or (-1, 1)  #also works
(1, -1)
>>> i,j = (1, -1) or (-1, 1) #nope
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = False and (1, -1) or (-1, 1) #works
>>> i,j
(-1, 1)

Thanks guys!

Mark

P.S. -1 on keyword initialization of dictionary (Liskov)
P.P.S. +1 on adding keys from iterable

$0.02 (*clink*)

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 15:01

Message:
Logged In: YES 
user_id=45365

Looks like one of the recent peephole optimizations is to blame, if 
I disassemble a function with i,j = True and (1, -1) or (-1, 1) in it 
I get:
  2           0 LOAD_GLOBAL              0 (True)
              3 JUMP_IF_FALSE           10 (to 16)
              6 POP_TOP             
              7 LOAD_CONST               1 (1)
             10 LOAD_CONST               2 (-1)
             13 BUILD_TUPLE              2
        >>   16 JUMP_IF_TRUE            10 (to 29)
             19 POP_TOP             
             20 LOAD_CONST               2 (-1)
             23 LOAD_CONST               1 (1)
             26 ROT_TWO             
             27 JUMP_FORWARD             2 (to 32)
             30 DUP_TOP             
             31 POP_TOP             
        >>   32 STORE_FAST               0 (i)
             35 STORE_FAST               1 (j)
             38 LOAD_CONST               0 (None)
             41 RETURN_VALUE        

Note the jump at address 16 going to 29, which isn't at an 
instruction boundary. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 15:20:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 07:20:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-757818 ] tuple assignment -- SystemError: unknown opcode
Message-ID: <E19TMkH-0001OF-00@sc8-sf-web3.sourceforge.net>

Bugs item #757818, was opened at 2003-06-20 11:19
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: tuple assignment -- SystemError: unknown opcode

Initial Comment:
Python 2.3b1 (#2, Jun  4 2003, 03:08:06)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
>>> i,j = True and (1, -1) or (-1, 1)
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = True and (1, -1)  #works
>>> True and (1, -1) or (-1, 1)  #also works
(1, -1)
>>> i,j = (1, -1) or (-1, 1) #nope
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = False and (1, -1) or (-1, 1) #works
>>> i,j
(-1, 1)

Thanks guys!

Mark

P.S. -1 on keyword initialization of dictionary (Liskov)
P.P.S. +1 on adding keys from iterable

$0.02 (*clink*)

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-20 14:20

Message:
Logged In: YES 
user_id=31392

The failure is a little more obvious if you look at the code
that was generated before optimization.  (I disassembled the
2.2 bytecode.)  The optimization don't respect basic block
boundaries.  In this case, the code that builds seq and
unpacks seq spans two blocks.  Since it's possible to jump
to the unpack, it can't be optimized away.

          0 SET_LINENO               1

          3 SET_LINENO               2
          6 LOAD_GLOBAL              0 (True)
          9 JUMP_IF_FALSE           10 (to 22)
         12 POP_TOP             
         13 LOAD_CONST               1 (1)
         16 LOAD_CONST               2 (-1)
         19 BUILD_TUPLE              2
    >>   22 JUMP_IF_TRUE            10 (to 35)
         25 POP_TOP             
         26 LOAD_CONST               2 (-1)
         29 LOAD_CONST               1 (1)
         32 BUILD_TUPLE              2
    >>   35 UNPACK_SEQUENCE          2
         38 STORE_FAST               0 (i)
         41 STORE_FAST               1 (j)
         44 LOAD_CONST               0 (None)
         47 RETURN_VALUE        


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 13:01

Message:
Logged In: YES 
user_id=45365

Looks like one of the recent peephole optimizations is to blame, if 
I disassemble a function with i,j = True and (1, -1) or (-1, 1) in it 
I get:
  2           0 LOAD_GLOBAL              0 (True)
              3 JUMP_IF_FALSE           10 (to 16)
              6 POP_TOP             
              7 LOAD_CONST               1 (1)
             10 LOAD_CONST               2 (-1)
             13 BUILD_TUPLE              2
        >>   16 JUMP_IF_TRUE            10 (to 29)
             19 POP_TOP             
             20 LOAD_CONST               2 (-1)
             23 LOAD_CONST               1 (1)
             26 ROT_TWO             
             27 JUMP_FORWARD             2 (to 32)
             30 DUP_TOP             
             31 POP_TOP             
        >>   32 STORE_FAST               0 (i)
             35 STORE_FAST               1 (j)
             38 LOAD_CONST               0 (None)
             41 RETURN_VALUE        

Note the jump at address 16 going to 29, which isn't at an 
instruction boundary. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 16:15:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 08:15:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-757567 ] Mac/OSX/README outdated
Message-ID: <E19TNbt-0004lX-00@sc8-sf-web3.sourceforge.net>

Bugs item #757567, was opened at 2003-06-20 00:43
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757567&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Just van Rossum (jvr)
Summary: Mac/OSX/README outdated

Initial Comment:
Mac/OSX/README needs work. Some pathnames are 
wrong, and the section on how to build a binary installer is 
incorrect.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 17:15

Message:
Logged In: YES 
user_id=45365

I think it is fine again now. I'm assigning to you for testing, could 
you please close it if you agree?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757567&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 16:49:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 08:49:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-757818 ] tuple assignment -- SystemError: unknown opcode
Message-ID: <E19TO8o-00006l-00@sc8-sf-web2.sourceforge.net>

Bugs item #757818, was opened at 2003-06-20 07:19
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Mark J (average)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: tuple assignment -- SystemError: unknown opcode

Initial Comment:
Python 2.3b1 (#2, Jun  4 2003, 03:08:06)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
>>> i,j = True and (1, -1) or (-1, 1)
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = True and (1, -1)  #works
>>> True and (1, -1) or (-1, 1)  #also works
(1, -1)
>>> i,j = (1, -1) or (-1, 1) #nope
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = False and (1, -1) or (-1, 1) #works
>>> i,j
(-1, 1)

Thanks guys!

Mark

P.S. -1 on keyword initialization of dictionary (Liskov)
P.P.S. +1 on adding keys from iterable

$0.02 (*clink*)

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-20 11:49

Message:
Logged In: YES 
user_id=33168

This is a result of the code optimization.  Attached are 2
files of the disassembled byte code with and without the
optimization enabled.  The problem is that with optimization
the 16 JUMP_IF_TRUE 10 (to 29) goes to an invalid opcode
(there is none at offset 29).

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-20 10:20

Message:
Logged In: YES 
user_id=31392

The failure is a little more obvious if you look at the code
that was generated before optimization.  (I disassembled the
2.2 bytecode.)  The optimization don't respect basic block
boundaries.  In this case, the code that builds seq and
unpacks seq spans two blocks.  Since it's possible to jump
to the unpack, it can't be optimized away.

          0 SET_LINENO               1

          3 SET_LINENO               2
          6 LOAD_GLOBAL              0 (True)
          9 JUMP_IF_FALSE           10 (to 22)
         12 POP_TOP             
         13 LOAD_CONST               1 (1)
         16 LOAD_CONST               2 (-1)
         19 BUILD_TUPLE              2
    >>   22 JUMP_IF_TRUE            10 (to 35)
         25 POP_TOP             
         26 LOAD_CONST               2 (-1)
         29 LOAD_CONST               1 (1)
         32 BUILD_TUPLE              2
    >>   35 UNPACK_SEQUENCE          2
         38 STORE_FAST               0 (i)
         41 STORE_FAST               1 (j)
         44 LOAD_CONST               0 (None)
         47 RETURN_VALUE        


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 09:01

Message:
Logged In: YES 
user_id=45365

Looks like one of the recent peephole optimizations is to blame, if 
I disassemble a function with i,j = True and (1, -1) or (-1, 1) in it 
I get:
  2           0 LOAD_GLOBAL              0 (True)
              3 JUMP_IF_FALSE           10 (to 16)
              6 POP_TOP             
              7 LOAD_CONST               1 (1)
             10 LOAD_CONST               2 (-1)
             13 BUILD_TUPLE              2
        >>   16 JUMP_IF_TRUE            10 (to 29)
             19 POP_TOP             
             20 LOAD_CONST               2 (-1)
             23 LOAD_CONST               1 (1)
             26 ROT_TWO             
             27 JUMP_FORWARD             2 (to 32)
             30 DUP_TOP             
             31 POP_TOP             
        >>   32 STORE_FAST               0 (i)
             35 STORE_FAST               1 (j)
             38 LOAD_CONST               0 (None)
             41 RETURN_VALUE        

Note the jump at address 16 going to 29, which isn't at an 
instruction boundary. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 17:13:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 09:13:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-757818 ] tuple assignment -- SystemError: unknown opcode
Message-ID: <E19TOWE-0004sk-00@sc8-sf-web1.sourceforge.net>

Bugs item #757818, was opened at 2003-06-20 06:19
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Mark J (average)
Assigned to: Raymond Hettinger (rhettinger)
Summary: tuple assignment -- SystemError: unknown opcode

Initial Comment:
Python 2.3b1 (#2, Jun  4 2003, 03:08:06)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
>>> i,j = True and (1, -1) or (-1, 1)
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = True and (1, -1)  #works
>>> True and (1, -1) or (-1, 1)  #also works
(1, -1)
>>> i,j = (1, -1) or (-1, 1) #nope
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = False and (1, -1) or (-1, 1) #works
>>> i,j
(-1, 1)

Thanks guys!

Mark

P.S. -1 on keyword initialization of dictionary (Liskov)
P.P.S. +1 on adding keys from iterable

$0.02 (*clink*)

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-20 11:13

Message:
Logged In: YES 
user_id=80475

Removed bytecode transformation for sequence packing and 
unpacking.   A better solution would be to restore the basic 
block checker that had been previously removed; however, it 
is too late in the development cycle for that.

See Python/compile.c 2.290

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-20 10:49

Message:
Logged In: YES 
user_id=33168

This is a result of the code optimization.  Attached are 2
files of the disassembled byte code with and without the
optimization enabled.  The problem is that with optimization
the 16 JUMP_IF_TRUE 10 (to 29) goes to an invalid opcode
(there is none at offset 29).

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-20 09:20

Message:
Logged In: YES 
user_id=31392

The failure is a little more obvious if you look at the code
that was generated before optimization.  (I disassembled the
2.2 bytecode.)  The optimization don't respect basic block
boundaries.  In this case, the code that builds seq and
unpacks seq spans two blocks.  Since it's possible to jump
to the unpack, it can't be optimized away.

          0 SET_LINENO               1

          3 SET_LINENO               2
          6 LOAD_GLOBAL              0 (True)
          9 JUMP_IF_FALSE           10 (to 22)
         12 POP_TOP             
         13 LOAD_CONST               1 (1)
         16 LOAD_CONST               2 (-1)
         19 BUILD_TUPLE              2
    >>   22 JUMP_IF_TRUE            10 (to 35)
         25 POP_TOP             
         26 LOAD_CONST               2 (-1)
         29 LOAD_CONST               1 (1)
         32 BUILD_TUPLE              2
    >>   35 UNPACK_SEQUENCE          2
         38 STORE_FAST               0 (i)
         41 STORE_FAST               1 (j)
         44 LOAD_CONST               0 (None)
         47 RETURN_VALUE        


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 08:01

Message:
Logged In: YES 
user_id=45365

Looks like one of the recent peephole optimizations is to blame, if 
I disassemble a function with i,j = True and (1, -1) or (-1, 1) in it 
I get:
  2           0 LOAD_GLOBAL              0 (True)
              3 JUMP_IF_FALSE           10 (to 16)
              6 POP_TOP             
              7 LOAD_CONST               1 (1)
             10 LOAD_CONST               2 (-1)
             13 BUILD_TUPLE              2
        >>   16 JUMP_IF_TRUE            10 (to 29)
             19 POP_TOP             
             20 LOAD_CONST               2 (-1)
             23 LOAD_CONST               1 (1)
             26 ROT_TWO             
             27 JUMP_FORWARD             2 (to 32)
             30 DUP_TOP             
             31 POP_TOP             
        >>   32 STORE_FAST               0 (i)
             35 STORE_FAST               1 (j)
             38 LOAD_CONST               0 (None)
             41 RETURN_VALUE        

Note the jump at address 16 going to 29, which isn't at an 
instruction boundary. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 17:28:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 09:28:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-757997 ] Using __slots__ with str derived classes can cause segfault
Message-ID: <E19TOkY-0008Jz-00@sc8-sf-web3.sourceforge.net>

Bugs item #757997, was opened at 2003-06-20 16: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=757997&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using __slots__ with str derived classes can cause segfault

Initial Comment:
The following results in a segfault on Linux with 2.3b1:
-------------------------
class StringDerived(str):
  __slots__ = ['a']
  def __init__(self, string):
    str.__init__(self, string)
    self.a = 1

class DerivedAgain(StringDerived):
  pass

o = DerivedAgain('hello world')
o.b = 2
--------------------------
Python 2.2.2 raises a TypeError when attempting to
derive a class from str with a non-empty __slots__,
maybe 2.3 should do the same?

I have no use case for deriving from str and defining
__slots__; I encountered the bug when writing test
cases for a debugger.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757997&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 18:06:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 10:06:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-757815 ] Infinite floats don't work in compiled modules on windows
Message-ID: <E19TPLL-0007HQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #757815, was opened at 2003-06-20 07:11
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757815&group_id=5470

Category: Windows
>Group: Feature Request
>Status: Closed
>Resolution: Postponed
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Tim Peters (tim_one)
Summary: Infinite floats don't work in compiled modules on windows

Initial Comment:
On windows, let's consider the following Python module :


# test.py
INFINITY = 10E40000
print INFINITY


When imported the first time (import test), it displays
"1.#inf" as expected.
But if you quit the Python interpreter, lauch a new one
and import the module again, it displays "1.0" !

The bug occurs only when the module is loaded from the
compiled file (test.pyc), and not when the source file
(test.py) is loaded and compiled.

BTW infinity behaves differently under Linux and
windows (under Linux, they are displayed as "inf", and
float("inf") is ok).

The bug seems to be windows-specific (never seen on
Linux). I tested it with Python 2.2.3 and 2.3b.

BTW infinity behaves differently under Linux and
windows (under Linux, they are displayed as "inf", and
float("inf") is ok).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-20 13:06

Message:
Logged In: YES 
user_id=31435

I've added this feature request to PEP 42.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-20 13:06

Message:
Logged In: YES 
user_id=31435

Sorry, all behavior wrt infinities (and NaNs, and signed zeroes) 
is a platform- and release-dependent accident.  I've added a 
link to this report in PEP 42, under the "Non-accidental IEEE-
754 support" feature request heading.

On most platforms you can worm around your specific problem 
by doing

INFINITY = 1e200 * 1e200

instead.

The business about how infinities display, and whether they 
can be read back in, is another batch of accidents inherited 
from the platform C I/O routines.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757815&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 18:18:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 10:18:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-757997 ] Using __slots__ with str derived classes can cause segfault
Message-ID: <E19TPWu-0007xu-00@sc8-sf-web1.sourceforge.net>

Bugs item #757997, was opened at 2003-06-20 12:28
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757997&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using __slots__ with str derived classes can cause segfault

Initial Comment:
The following results in a segfault on Linux with 2.3b1:
-------------------------
class StringDerived(str):
  __slots__ = ['a']
  def __init__(self, string):
    str.__init__(self, string)
    self.a = 1

class DerivedAgain(StringDerived):
  pass

o = DerivedAgain('hello world')
o.b = 2
--------------------------
Python 2.2.2 raises a TypeError when attempting to
derive a class from str with a non-empty __slots__,
maybe 2.3 should do the same?

I have no use case for deriving from str and defining
__slots__; I encountered the bug when writing test
cases for a debugger.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-20 13:18

Message:
Logged In: YES 
user_id=33168

unicode, list, and dict don't crash, only string.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757997&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 20:11:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 12:11:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-758112 ] Python.framework/Python should be +x
Message-ID: <E19TRI8-0001Gm-00@sc8-sf-web2.sourceforge.net>

Bugs item #758112, was opened at 2003-06-20 21: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=758112&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 4
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: Python.framework/Python should be +x

Initial Comment:
I think it's good if Python.framework/Python (or rather 
Python.framework/Versions/<version>/Python) would 
have the executable flag set. All other frameworks that I 
checked have a main file that's executable (just as .so files 
as created by distutils).

The reason I care about this is that I would like to make 
bundlebuilder's --strip flag a little smarter: right now it only 
strips the main executable as well as any .so files, but I'd 
like to simply traverse the contents of the bundle and run 
strip on all executable files (including those specified with --
lib and those included in other frameworks).

I would have a go at this myself, but I could use a hint...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758112&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 20:57:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 12:57:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-731631 ] OSX installer .pkg file permissions
Message-ID: <E19TS0h-00068p-00@sc8-sf-web4.sourceforge.net>

Bugs item #731631, was opened at 2003-05-03 00:34
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: OSX installer .pkg file permissions

Initial Comment:
The files installed by the OSX installer .pkg should be group writable. 
This goes both for the files installed in /Library/Frameworks/
Python.framework and /Applications/MacPython-2.3


----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2003-06-20 21:57

Message:
Logged In: YES 
user_id=92689

Some files are group writable, for group "admin", which is 
perfect. Some directories and Python.framework/Python are not.

However, I can throw away both the framework and the apps 
folder from the finder without problems, so it's not all bad...

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-19 23:29

Message:
Logged In: YES 
user_id=45365

I think this is finally fixed. Could you do me a favor and test it? 
Just run Mac/OSX/Dist/build, remove your current /Library/
Frameworks/Python.framework and /Application/MacPython-2.3 
and try the installer built by "build".

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-05-08 01:14

Message:
Logged In: YES 
user_id=92689

Maybe my diagnosis is off. When I install (a non-framework) Python from the 
source, I don't use sudo, I just do "make install". In that case all files are 
owned by me. The installer however installs everything as root, and with the 
files being not group writable it means that I (even as an admin) can't move/
overwrite/delete the files without using sudo or changing the permissions.

I would expect to be able to have write permissions to the installed files if 
I'm an admin user. Don't know how to fix that easily, either.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-05-07 14:04

Message:
Logged In: YES 
user_id=45365

This turns out to be non-trivial: the installed Python tree that is used to 
create the installer has group-write turned off, that's the way Python always 
installs the tree.

I could do a recursive chmod g+w before creating the installer, what do you 
think, would that be safe?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 21:34:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 13:34:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-723562 ] app-building with Bundlebuilder for framework builds
Message-ID: <E19TSb2-0007q1-00@sc8-sf-web1.sourceforge.net>

Bugs item #723562, was opened at 2003-04-18 10:40
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723562&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: app-building with Bundlebuilder for framework builds

Initial Comment:
Just,
why can bundlebuilder build applications for non-framework Pythons but not framework Pythons?

If the problem is that relocating the framework is difficult: I just came across the tool "install_name_tool" (available if you have the developer tools installed) and the accompanying linker flag "-header-pad_max_install_names", these two should allow us to relocate frameworks.

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2003-06-20 22:34

Message:
Logged In: YES 
user_id=92689

Support for Python.framework as been added to bundlebuilder.py 
in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723562&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 21:36:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 13:36:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-684679 ] Freeze can not be made to exclude implicits
Message-ID: <E19TScR-0002GI-00@sc8-sf-web3.sourceforge.net>

Bugs item #684679, was opened at 2003-02-11 17:01
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=684679&group_id=5470

Category: Demos and Tools
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Lawrence Hudson (lhudson)
Assigned to: Just van Rossum (jvr)
Summary: Freeze can not be made to exclude implicits

Initial Comment:
Freeze always includes site and exceptions in the
resulting binary.  This is undesirable when creating an
extension module that contains frozen code;in sucha
situation the extension module should import the site
and exceptions (and all other standard library modules)
from the target system at runtime.

Patch 684677 fixes this bug.

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2003-06-20 22:36

Message:
Logged In: YES 
user_id=92689

The patch mentioned above has been applied a long time ago. 
Closing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=684679&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 21:37:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 13:37:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-758112 ] Python.framework/Python should be +x
Message-ID: <E19TSdS-0002JL-00@sc8-sf-web3.sourceforge.net>

Bugs item #758112, was opened at 2003-06-20 21:11
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758112&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: Python.framework/Python should be +x

Initial Comment:
I think it's good if Python.framework/Python (or rather 
Python.framework/Versions/<version>/Python) would 
have the executable flag set. All other frameworks that I 
checked have a main file that's executable (just as .so files 
as created by distutils).

The reason I care about this is that I would like to make 
bundlebuilder's --strip flag a little smarter: right now it only 
strips the main executable as well as any .so files, but I'd 
like to simply traverse the contents of the bundle and run 
strip on all executable files (including those specified with --
lib and those included in other frameworks).

I would have a go at this myself, but I could use a hint...

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 22:37

Message:
Logged In: YES 
user_id=45365

Fixed in Makefile.pre.in rev. 1.133.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758112&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 21:38:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 13:38:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads
Message-ID: <E19TSek-0004y6-00@sc8-sf-web2.sourceforge.net>

Bugs item #539990, was opened at 2002-04-05 23:29
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470

Category: Macintosh
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Pieter Claerhout (pclaerhout)
Assigned to: Just van Rossum (jvr)
Summary: Framework.mainloop() - multiple threads

Initial Comment:
I tried to use the threading module to start the XML 
RPC server in a different thread (xmlrpcServer itself 
also is a threaded piece of code), but that seems to 
conflict with the mainloop. If you start this 
application, it starts the thread, starts the mainloop 
and stays in there, once you finish the mainloop, the 
thread continues.

You've stumbled on a bug in Framework.mainloop(): it 
doesn't know anything about multiple threads. It gives 
time to other applications (by calling WaitNextEvent) 
but not to other threads within Python.

Also see
http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005416.html

and 

http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005428.html

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2003-06-20 22:38

Message:
Logged In: YES 
user_id=92689

autoGIL is now part of MacPython and works well with 
Framework.py on Mach-O on OSX. It does _not_ work with the 
GUSI-based CFM OS9 MacPython, nor will it ever, as far as I'm 
concerned. Closing this as "fixed".

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-05-03 00:46

Message:
Logged In: YES 
user_id=92689

In case it wasn't clear: autoGIL is completely unrelated to Mark's work.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-05-03 00:36

Message:
Logged In: YES 
user_id=45365

Ok, it is now clear that I didn't look at the end result of Mark Hammonds 
work, I thought it needed source modifications too. If it is just a module: by 
all means, check it in! And please add it to setup.py too (and either also add 
it to genpluginmodules.py and fullbuild.py, or assign this bug to me later).


----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-05-02 22:30

Message:
Logged In: YES 
user_id=92689

Mac tree: somewhere in Mac/Modules/. It's a completely standalone module, 
it has no impact on the rest of the (Mac)Python source tree. PythonIDE.py 
would import it and call autoGIL.installAutoGIL(). You should have a look ;-)

I'm playing with it now, and somehow it doesn't always quite work like I 
thought. Need to do more testing. It works perfectly in Cocoa apps, but not 
always under W/FrameWork's WaitNextEvent() loop. Don't know whether this 
is an inherent problem, but if so, that would be a reason to move to 
CarbonEvents pretty soon (assuming it _does_ work under 
CarbonEvt.RunApplicationEventLoop()). Hm.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-05-02 22:22

Message:
Logged In: YES 
user_id=45365

What do you mean by "add it to the mac tree"?

Anyway: I would love to have this functionality, but I think it is probably 
prudent to do development on a branch (unless you're pretty sure of it).

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-05-02 20:28

Message:
Logged In: YES 
user_id=92689

I finally got around playing with autoGIL in the IDE (briefly, though): it seems 
to work just fine! Reopeing this report.

Jack, I could add autoGIL.c to the Mac tree if you want. A good experiment 
would be to make the PackagaManager threaded...

----------------------------------------------------------------------

Comment By: Jurjen N.E. Bos (jneb)
Date: 2003-04-25 11:35

Message:
Logged In: YES 
user_id=446428

Probably fixing this will also allow to run a long computation and still use 
the IDE for writing other code, or run commands in interactive mode.
Sounds like a cool feature!

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-25 11:43

Message:
Logged In: YES 
user_id=45365

If that is true I would be very happy. Could you please investigate this and put it in if it works? Before 2.3b1 please: I don't want to mess with the core of the MacOS support modules after that...

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-24 19:51

Message:
Logged In: YES 
user_id=92689

Jack, have you forgotten about autoGIL? It's quite likely that the autoGIL module (as part of the PyObjC project) would fix this issue out of the box on OSX. Do "import autoGIL; autoGIL.installAutoGIL()" before you enter the event loop and the second thread gets time to run.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-24 17:45

Message:
Logged In: YES 
user_id=45365

Let's admit this isn't going to be fixed unless someone wants it real bad.

Pieter: if you want it real bad then reopen the bug and I'll find time for it.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 16:03

Message:
Logged In: YES 
user_id=45365

After some discussion on the SIG it turns out this is a rather complicated problem, because WNE() may cause callbacks to be called (for Carbon Event handlers, for instance), and releasing the GIL would mean those callbacks would be hosed.

A solution will have to have all callback wrappers acquire the GIL, and it will either have to make very sure we never enter WNE() or friends with the GIL held, or the callback code will need to be able to handle both the case of being called with the GIL held and the case of being called without it.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-07 23:26

Message:
Logged In: YES 
user_id=45365

Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 22:22:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 14:22:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-757542 ] Need to register PythonLauncher as handler for .py
Message-ID: <E19TTKl-0006sP-00@sc8-sf-web2.sourceforge.net>

Bugs item #757542, was opened at 2003-06-19 23:53
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757542&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Need to register PythonLauncher as handler for .py

Initial Comment:
We still need a way to register PythonLauncher as the 
handler for .py, pyw and .pyc documents. PythonLauncher 
itself could do this easily, but that requires people to run 
PythonLauncher at least once. Or we would have to 
arrange for the installer to do it, or (at the very least) the 
IDE.

The latter is difficult because we don't have access to the 
Launch Services API from Python, yet.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 23:22

Message:
Logged In: YES 
user_id=45365

Turns out there isn't an API for setting the handler, at least not a 
public one. But PythonLauncher now does test that it is the 
current handler, and shows a (supressible) warning dialog if it 
isn't.

I hope the magic of the installer, combined with the fact that 
PythonLancher advertises itself as being able to handle Python 
documents, will do the trick. I'm leaving this report open until 
that has been confirmed, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757542&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 22:42:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 14:42:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-731631 ] OSX installer .pkg file permissions
Message-ID: <E19TTea-0007Y9-00@sc8-sf-web2.sourceforge.net>

Bugs item #731631, was opened at 2003-05-03 00:34
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: OSX installer .pkg file permissions

Initial Comment:
The files installed by the OSX installer .pkg should be group writable. 
This goes both for the files installed in /Library/Frameworks/
Python.framework and /Applications/MacPython-2.3


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 23:42

Message:
Logged In: YES 
user_id=45365

I give up. I now do a recursive chmod ug+w on the installed 
tree, and set umask to 2 before doing the compileall on the 
destination system. Please try again...

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-06-20 21:57

Message:
Logged In: YES 
user_id=92689

Some files are group writable, for group "admin", which is 
perfect. Some directories and Python.framework/Python are not.

However, I can throw away both the framework and the apps 
folder from the finder without problems, so it's not all bad...

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-19 23:29

Message:
Logged In: YES 
user_id=45365

I think this is finally fixed. Could you do me a favor and test it? 
Just run Mac/OSX/Dist/build, remove your current /Library/
Frameworks/Python.framework and /Application/MacPython-2.3 
and try the installer built by "build".

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-05-08 01:14

Message:
Logged In: YES 
user_id=92689

Maybe my diagnosis is off. When I install (a non-framework) Python from the 
source, I don't use sudo, I just do "make install". In that case all files are 
owned by me. The installer however installs everything as root, and with the 
files being not group writable it means that I (even as an admin) can't move/
overwrite/delete the files without using sudo or changing the permissions.

I would expect to be able to have write permissions to the installed files if 
I'm an admin user. Don't know how to fix that easily, either.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-05-07 14:04

Message:
Logged In: YES 
user_id=45365

This turns out to be non-trivial: the installed Python tree that is used to 
create the installer has group-write turned off, that's the way Python always 
installs the tree.

I could do a recursive chmod g+w before creating the installer, what do you 
think, would that be safe?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 22:48:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 14:48:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-756982 ] mailbox should use email not rfc822
Message-ID: <E19TTkc-0000wX-00@sc8-sf-web1.sourceforge.net>

Bugs item #756982, was opened at 2003-06-18 22:19
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ben Leslie (benno37)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: mailbox should use email not rfc822

Initial Comment:
The mailbox module uses the rfc822 module as its
default factory for creating message objects. The
rfc822 documentation claims that its use is deprecated.
The mailbox module should probably use the new email
module as its default factory.

Of course this has backward compatibility issues, in
which case it should at least be mentioned in the
mailbox documentation that it uses the deprecated
rfc822 module, and provide an example of how to use the
email module instead.

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-06-20 17:48

Message:
Logged In: YES 
user_id=12800

I've added some sample code to the mailbox documentation
that explain how to use the email package with the mailbox
module.  We can't change the default for backward
compatibility reasons, as you point out.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470


From noreply@sourceforge.net  Fri Jun 20 23:21:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 15:21:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-757544 ] PythonLauncher needs script-arguments field
Message-ID: <E19TUGL-0001ia-00@sc8-sf-web1.sourceforge.net>

Bugs item #757544, was opened at 2003-06-19 23:56
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757544&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PythonLauncher needs script-arguments field

Initial Comment:
PythonLauncher needs a field where you can specify 
command-line arguments to pass to the script.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-21 00:21

Message:
Logged In: YES 
user_id=45365

Fixed in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757544&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 02:27:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 18:27:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-758239 ] socket timeout exception unhelpful
Message-ID: <E19TX9t-00078I-00@sc8-sf-web1.sourceforge.net>

Bugs item #758239, was opened at 2003-06-20 18: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=758239&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Halley (rthalley)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket timeout exception unhelpful

Initial Comment:
The new settimeout feature for sockets is great, but
the exception that is raised on timeout, socket.error,
is not very helpful.  It's not
possible to write code which catches and deals with
timeouts as opposed to the multitude of other socket
errors.

Even looking at the additional detail isn't helpful,
because you get errnos like EINPROGRESS or EAGAIN,
because the socket code doesn't deal with timeouts
explicitly when it selects.  Rather, it just lets the
internal_select() return, and then you get an error
when whatever was doing the waiting tries to do its
operation.

I propose that a new exception:

class socket.timeout(socket.error):
    pass

be created, and raised whenever the internal_select
times out (i.e. select() returns 0).

This lets applications catch socket.timeout
specifically if they want to, but also allows existing
code to catch socket.error and get all socket-related
exceptions.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758239&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 02:41:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 20 Jun 2003 18:41:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-758241 ] asyncore with non-default map problems
Message-ID: <E19TXNF-0006HA-00@sc8-sf-web2.sourceforge.net>

Bugs item #758241, was opened at 2003-06-20 18: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=758241&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Halley (rthalley)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore with non-default map problems

Initial Comment:
When you use asyncore with a non-default map, methods
of the dispatcher object break.

E.g. if you close() the object, it tries to remove
itself from the default map, not from the map the
dispatcher was created with.

There should be a map instance variable that contains
the map the object was created with, and it should be
used whenever the map needs to be referenced, e.g. in
add_channel/del_channel.

This would make close work correctly again.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758241&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 14:40:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 06:40:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-700827 ] Compiler Limits (indentation)
Message-ID: <E19Tibu-0000rs-00@sc8-sf-web2.sourceforge.net>

Bugs item #700827, was opened at 2003-03-10 14:43
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Two Inches (twoinches)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler Limits (indentation)

Initial Comment:
The reference manual does not mention the indentation
limits of compiler implementations.

Suggestion: In section 2.1.7 Indentation add the
following at the end of the section:

Implementations may explicity limit the maximum
indentation level. 

For CPython check tokenizer.h for build specifics
(default value is set to 100). 
For Jython check
org.python.parser.PythonGrammerTokenManager (default
value is set to 20).

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:40

Message:
Logged In: YES 
user_id=21627

Fixed in ref2.tex 1.48.

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 06:06

Message:
Logged In: YES 
user_id=531881

see bug 755683

http://www.python.org/sf/755683

-c

----------------------------------------------------------------------

Comment By: Two Inches (twoinches)
Date: 2003-06-08 23:51

Message:
Logged In: YES 
user_id=730363

Agreed. 

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 23:30

Message:
Logged In: YES 
user_id=357491

I have no issue adding a comment that the indentation level is 
not infinite, but I don't think it should be mentioned where to 
find it since the reference manual is for the language and not 
any specific implementation.

Anyone else agree?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 14:44:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 06:44:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-757520 ] irreproducable segfault on int(1e100)
Message-ID: <E19Tiew-0006mI-00@sc8-sf-web3.sourceforge.net>

Bugs item #757520, was opened at 2003-06-19 23:19
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757520&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: irreproducable segfault on int(1e100)

Initial Comment:
Segmentation Fault:

 20 >>> i
1e+100
 21 >>> int(i)Segmentation fault
23:16:12:2:gerrit@stopcontact:~/downl$ python
Python 2.3b1+ (#3, Jun 19 2003, 10:34:37)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> i=1e100
  1 >>> int(i)Segmentation fault
23:16:21:2:gerrit@stopcontact:~/downl$ python
Python 2.3b1+ (#3, Jun 19 2003, 10:34:37)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> i=1e100
  1 >>> int(i)
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104L

I'm unable to reproduce this (sorry). I noticed before
that sometimes, the interactive Python interpreter
segfaults irreproducable: only now, it was two times in
succession but not more than two times. I never
encounered this problem while executing Python programs
from scripts.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:44

Message:
Logged In: YES 
user_id=21627

I suspect this is a bug in the C library. To find out for
sure, one would have to study the relevant assembler code in
glibc in detail.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757520&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 14:48:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 06:48:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-756842 ] Ms VC 2003 not supported
Message-ID: <E19Tiir-0006tS-00@sc8-sf-web3.sourceforge.net>

Bugs item #756842, was opened at 2003-06-18 23:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756842&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Paolo Invernizzi (darkarathorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ms VC 2003 not supported

Initial Comment:
The current msvccompiler.py has no support for Ms
Visual Studio NET 2003 release.
The registry keys are different than the original
VS.NET and NET Framework

File
"d:\repositories\python\dist\src\lib\distutils\msvccompiler.py",
line 114, in set_macro
    self.macros["$(%s)" % macro] = d[key]
KeyError: 'sdkinstallroot'


---
Paolo Invernizzi

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:48

Message:
Logged In: YES 
user_id=21627

What version of msvccompiler.py are you using? Specifically,
what is its __revision__?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756842&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 14:50:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 06:50:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-756576 ] Recursion limit too high for MacOSX
Message-ID: <E19TilG-00034C-00@sc8-sf-web4.sourceforge.net>

Bugs item #756576, was opened at 2003-06-18 15:01
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756576&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recursion limit too high for MacOSX

Initial Comment:
Python's recursion limit is too high for Mac OS X, where the 
default stack size is 512K. The attached script will never 
trigger a maximum recursion depth exception, it will have 
crashed Python with a segmentation violation before that.

A possible solution is a call to sys.setrecursionlimit() in 
site.py, another is to change the number "1000" in ceval.c 
to a configure-time constant.

Other platforms may also suffer this problem, it may be a 
good idea to add a test_stackoverflow.

I'm willing to do the work involved, but I'd like some 
feedback first.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:50

Message:
Logged In: YES 
user_id=21627

If more work is put into recursion limits, I think platform
mechanisms should be used where available. For example,
there might be ways to find out, at run-time, what the stack
consumption is, and what the stack availalability is, and
compute a recursion limit from that.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-18 17:40

Message:
Logged In: YES 
user_id=31392

I'd like to see a per-platform recusion limit, because the
limit could be much higher on Linux and Windows than 1000.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756576&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 14:51:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 06:51:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-756093 ] complex pow() crash on Alpha
Message-ID: <E19Tim2-000174-00@sc8-sf-web2.sourceforge.net>

Bugs item #756093, was opened at 2003-06-17 20:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756093&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: complex pow() crash on Alpha

Initial Comment:
Python crashes with a floating point exception on SF's
 Alpha/Linux 2.2 machine in the compile farm:
$ ./python
Python 2.3b1+ (#2, Jun 17 2003, 10:50:58) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> pow(1e200+1j,1e200+1j)
Floating point exception
$

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:51

Message:
Logged In: YES 
user_id=21627

Can you tell whether you were compiling with -ieee?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756093&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 14:55:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 06:55:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-755087 ] anydbm and whichdb one more time
Message-ID: <E19Tips-0003Bo-00@sc8-sf-web4.sourceforge.net>

Bugs item #755087, was opened at 2003-06-16 03:26
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755087&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Gregory Saunders (grerfy)
Assigned to: Nobody/Anonymous (nobody)
Summary: anydbm and whichdb one more time

Initial Comment:
Bug #744687 was recently closed with an update to the
whichdb.py file. The update fixes the main problem
described in bug 744687, but a tangental problem,
mentioned in 744687, still occurs. The following python
transcript illustrates the problem (it uses the new
whichdb.py file):

---
Python 2.2.2 (#1, Mar 21 2003, 23:01:54) 
[GCC 3.2.3 20030316 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import whichdb, anydbm, dumbdbm
>>> a = dumbdbm.open('/tmp/a', 'c')
>>> a.close()
>>> b = anydbm.open('/tmp/a', 'w')
>>> b['abc'] = 'def'
>>> b.close()
>>> c = anydbm.open('/tmp/a', 'w')
>>> del c['abc']
>>> c.close()
>>> d = anydbm.open('/tmp/a', 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/anydbm.py", line 80, in open
    raise error, "need 'c' or 'n' flag to open new db"
anydbm.error: need 'c' or 'n' flag to open new db
>>> 
---

As can be seen, the change to whichdb.py correctly
detects if the dumbdbm database is created, closed, and
re-opened. However, if the dumbdbm file is populated
with some data, then all that data is removed, the bug
once again rears its ugly head. This occurs because
once data is entered into a dumbdbm database, it is
never removed from the .dat file, only the relevant
entry from the .dir file is removed. I suppose the
correct solution to this is to change the
implementation of dumbdbm. A quicker solution, however,
would be a minor change to the new whichdb.py file to
detect only if the .dir file is empty - a patch is
attached.

regards
Greg


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:55

Message:
Logged In: YES 
user_id=21627

Thanks, applied as whichdb.py 1.16.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755087&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 19:50:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 11:50:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-758504 ] test_sax fails on python 2.2.3 & patch for regrtest.py
Message-ID: <E19TnRQ-0002Fc-00@sc8-sf-web2.sourceforge.net>

Bugs item #758504, was opened at 2003-06-21 18: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=758504&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: PieterB (pieterb)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_sax fails on python 2.2.3 & patch for regrtest.py

Initial Comment:
Hi,

1) testing using the FreeBSD ports version of Python 
2.2.3 fails (both on FreeBSD 5 and FreeBSD 4.8). The 
test test_sax.py fails, because test_sax seems to 
require expat2 (?), which isn't available by default on 
FreeBSD).

2) I've also patched regrtest.py so that it works on 
FreeBSD 4/5
(Chimp@IRC tested it on FreeBSD4.8), can somebody
apply the patches from regrtest.py to CVS?
Source: http://www.gewis.nl/~pieterb/python/bugs-
2.2.3/

In detail:

1) testing using the FreeBSD ports version of Python 
2.2.3 failed
==========================================
========================

Using Python 2.2.3 from recent FreeBSD ports
"cd /usr/ports/lang/python ; make ; cd work/Python-
2.2.3 ; make test"
gives:

174 tests OK.
1 test failed:
    test_sax
18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on freebsd5.
*** Error code 1

Stop in /usr/ports/lang/python/work/Python-2.2.3.

----------------------------------------------------

cd /usr/ports/lang/python/work/Python-2.2.3/Lib/test
../../python test_sax.py
gives:
test_support.TestFailed: 3 of 40 tests failed

...
Expected:
[('start', ('http://xml.python.org/1', 'abc'), 'abc'),
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/1', u'abc'), None),
 ('start', (u'http://xml.python.org/2', u'def'), None),
 ('end', (u'http://xml.python.org/2', u'def'), None),
 ('start', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'abc'), None)]
Failed test_expat_nsdecl_pair_diff
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'),
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('start', (u'http://xml.python.org/', u'def'), None),
 ('end', (u'http://xml.python.org/', u'def'), None),
 ('start', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_pair_same
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'abc'),
 ('end', ('http://xml.python.org/', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_single

I managed to fixed this by patching test_sax.py,
see http://gewis.nl/~pieterb/python/bugs-2.2.3/

2) i've patched regrtest.py so that it works on FreeBSD 
4/5
==========================================
=================
This make it possible to run 'make test' on Python.
It will give the following output:
  175 tests OK.
  18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
  Those skips are all expected on freebsd5.

Can anybody confirm that it's ok to skip those tests.  
Can anybody
download the patched version of regrtest.py from the 
URL above check
it into Python CVS?

Thanks to Chimp@IRC for testing it on FreeBSD4.8
Thanks to itz@irc and others at IRC:#python for their 
help.

PieterB

--
http://zwiki.org/PieterB





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 19:58:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 11:58:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-621579 ] test_sax fails on freebsd
Message-ID: <E19TnYs-0003O3-00@sc8-sf-web1.sourceforge.net>

Bugs item #621579, was opened at 2002-10-10 21:21
Message generated for change (Comment added) made by pieterb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621579&group_id=5470

Category: Build
Group: 3rd Party
Status: Closed
Resolution: Invalid
Priority: 6
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: test_sax fails on freebsd

Initial Comment:
test_sax consistently fails on the freebsd system on
SF's compile farm.  Fred said he'll look into it, so
creating this bug report so he doesn't forget <wink>.

----------------------------------------------------------------------

Comment By: PieterB (pieterb)
Date: 2003-06-21 18:58

Message:
Logged In: YES 
user_id=458461

PyXML and expat2 are not included in the default Python 
FreeBSD port (as far as I know).

See also: http://sourceforge.net/tracker/?
group_id=5470&atid=105470&func=detail&aid=758504


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-12 03:36

Message:
Logged In: YES 
user_id=3066

Oddly enough, this isn't a real problem.  ;-)  What's
getting tested on that machine is not the xml.sax package
provided with Python 2.2.2, but PyXML 0.7.1, which does
indeed exhibit that bug (more recent versions of PyXML do
not have that one).

What's happening is that the default prefix, /usr/local/,
already contains a Python 2.2 installation with PyXML 0.7.1
installed, and Python's default sys.path when running from
the build directory includes the site-packages of the
corresponding installation.  I think *that's* a bug, and
there's already a SF bug report on the issue.

Building Python with a prefix that isn't "contanimated" in
this way shows that the pyexpat module is built using the
Expat 1.95.2 installed on this system, and the tests pass.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-10 21:26

Message:
Logged In: YES 
user_id=3066

Here's the relevant part of the test output Barry emailed to
me earlier.  Hopefully it won't get too badly munged by SF.  ;-)

Failed test_expat_nsattrs_wattr
Expected:
[('start', ('http://xml.python.org/1', 'abc'), 'abc'),
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/1', u'abc'), None),
 ('start', (u'http://xml.python.org/2', u'def'), None),
 ('end', (u'http://xml.python.org/2', u'def'), None),
 ('start', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'abc'), None)]
Failed test_expat_nsdecl_pair_diff
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'),
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('start', (u'http://xml.python.org/', u'def'), None),
 ('end', (u'http://xml.python.org/', u'def'), None),
 ('start', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_pair_same
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'abc'),
 ('end', ('http://xml.python.org/', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_single


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621579&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 20:00:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 12:00:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-758504 ] test_sax fails on python 2.2.3 & patch for regrtest.py
Message-ID: <E19TnbV-0004cQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #758504, was opened at 2003-06-21 18:50
Message generated for change (Comment added) made by pieterb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: PieterB (pieterb)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_sax fails on python 2.2.3 & patch for regrtest.py

Initial Comment:
Hi,

1) testing using the FreeBSD ports version of Python 
2.2.3 fails (both on FreeBSD 5 and FreeBSD 4.8). The 
test test_sax.py fails, because test_sax seems to 
require expat2 (?), which isn't available by default on 
FreeBSD).

2) I've also patched regrtest.py so that it works on 
FreeBSD 4/5
(Chimp@IRC tested it on FreeBSD4.8), can somebody
apply the patches from regrtest.py to CVS?
Source: http://www.gewis.nl/~pieterb/python/bugs-
2.2.3/

In detail:

1) testing using the FreeBSD ports version of Python 
2.2.3 failed
==========================================
========================

Using Python 2.2.3 from recent FreeBSD ports
"cd /usr/ports/lang/python ; make ; cd work/Python-
2.2.3 ; make test"
gives:

174 tests OK.
1 test failed:
    test_sax
18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on freebsd5.
*** Error code 1

Stop in /usr/ports/lang/python/work/Python-2.2.3.

----------------------------------------------------

cd /usr/ports/lang/python/work/Python-2.2.3/Lib/test
../../python test_sax.py
gives:
test_support.TestFailed: 3 of 40 tests failed

...
Expected:
[('start', ('http://xml.python.org/1', 'abc'), 'abc'),
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/1', u'abc'), None),
 ('start', (u'http://xml.python.org/2', u'def'), None),
 ('end', (u'http://xml.python.org/2', u'def'), None),
 ('start', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'abc'), None)]
Failed test_expat_nsdecl_pair_diff
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'),
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('start', (u'http://xml.python.org/', u'def'), None),
 ('end', (u'http://xml.python.org/', u'def'), None),
 ('start', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_pair_same
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'abc'),
 ('end', ('http://xml.python.org/', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_single

I managed to fixed this by patching test_sax.py,
see http://gewis.nl/~pieterb/python/bugs-2.2.3/

2) i've patched regrtest.py so that it works on FreeBSD 
4/5
==========================================
=================
This make it possible to run 'make test' on Python.
It will give the following output:
  175 tests OK.
  18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
  Those skips are all expected on freebsd5.

Can anybody confirm that it's ok to skip those tests.  
Can anybody
download the patched version of regrtest.py from the 
URL above check
it into Python CVS?

Thanks to Chimp@IRC for testing it on FreeBSD4.8
Thanks to itz@irc and others at IRC:#python for their 
help.

PieterB

--
http://zwiki.org/PieterB





----------------------------------------------------------------------

>Comment By: PieterB (pieterb)
Date: 2003-06-21 19:00

Message:
Logged In: YES 
user_id=458461

See also: http://sourceforge.net/tracker/?
group_id=5470&atid=105470&func=detail&aid=621579

a search on "test_sax" indicates that isn't running on quite a 
lot of other platforms.

PieterB
--
http://zwiki.org/PieterB

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 20:08:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 12:08:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-747460 ] make test errors Tru64 UNIX V5.1A
Message-ID: <E19Tnim-0004qV-00@sc8-sf-web4.sourceforge.net>

Bugs item #747460, was opened at 2003-06-02 10:45
Message generated for change (Comment added) made by pieterb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747460&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gottfried Mueller (muellergm4t9)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test errors Tru64 UNIX V5.1A

Initial Comment:
What can I do? 
 
1. Test Error 
python Lib/test/test_compile.py 
 
Testing whether compiler catches assignment to 
__debug__ 
Running tests on argument handling 
testing complex args 
1 2 
1 2 
3 4 
1 2 3 
1 2 3 
2 3 4 
testing bad float literals 
testing literals with leading zeroes 
Traceback (most recent call last): 
  File "Lib/test/test_compile.py", line 128, in ? 
    expect_same("0xffffffff", -1) 
  File "Lib/test/test_compile.py", line 90, in expect_same 
    raise TestFailed("eval(%r) gave %r, but expected %r" 
% 
test_support.TestFailed: eval('0xffffffff') gave 
4294967295, but expected -1 
 
2.Test Error 
python Lib/test/test_long.py    
 
long / * % divmod 
long bit-operation identities 
long str/hex/oct/atol 
long miscellaneous operations 
auto-convert int->long on overflow 
long->float overflow 
Traceback (most recent call last): 
  File "Lib/test/test_long.py", line 409, in ? 
    test_float_overflow() 
  File "Lib/test/test_long.py", line 362, in 
test_float_overflow 
    eval(test, namespace) 
  File "<string>", line 0, in ? 
ValueError: invalid literal for float(): 
123451234512345123451234512345123451234 
51234512345123451234512345123451234512345123451234512345123451234512345123451234 
51234512345123451234512345123451234512345123451234512345123451234512345123451234 
5 
 
3. Test Error 
python Lib/test/test_sax.py 
 
Passed test_attrs_empty 
Passed test_attrs_wattr 
Passed test_double_quoteattr 
Passed test_escape_all 
Passed test_escape_basic 
Passed test_escape_extra 
Passed test_expat_attrs_empty 
Passed test_expat_attrs_wattr 
Passed test_expat_dtdhandler 
Passed test_expat_entityresolver 
Passed test_expat_file 
Passed test_expat_incomplete 
Passed test_expat_incremental 
Passed test_expat_incremental_reset 
Passed test_expat_inpsource_filename 
Passed test_expat_inpsource_location 
Passed test_expat_inpsource_stream 
Passed test_expat_inpsource_sysid 
Passed test_expat_locator_noinfo 
Passed test_expat_locator_withinfo 
Passed test_expat_nsattrs_empty 
Passed test_expat_nsattrs_wattr 
Expected: 
[('start', ('http://xml.python.org/1', 'abc'), 'abc'), 
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'), 
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'), 
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'), 
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'), 
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')] 
Received: 
[('start', (u'http://xml.python.org/1', u'abc'), None), 
 ('start', (u'http://xml.python.org/2', u'def'), None), 
 ('end', (u'http://xml.python.org/2', u'def'), None), 
 ('start', (u'http://xml.python.org/1', u'ghi'), None), 
 ('end', (u'http://xml.python.org/1', u'ghi'), None), 
 ('end', (u'http://xml.python.org/1', u'abc'), None)] 
Failed test_expat_nsdecl_pair_diff 
Expected: 
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'), 
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'), 
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'), 
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), 
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), 
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')] 
Received: 
[('start', (u'http://xml.python.org/', u'abc'), None), 
 ('start', (u'http://xml.python.org/', u'def'), None), 
 ('end', (u'http://xml.python.org/', u'def'), None), 
 ('start', (u'http://xml.python.org/', u'ghi'), None), 
 ('end', (u'http://xml.python.org/', u'ghi'), None), 
 ('end', (u'http://xml.python.org/', u'abc'), None)] 
Failed test_expat_nsdecl_pair_same 
Expected: 
[('start', ('http://xml.python.org/', 'abc'), 'abc'), 
 ('end', ('http://xml.python.org/', 'abc'), 'abc')] 
Received: 
[('start', (u'http://xml.python.org/', u'abc'), None), 
 ('end', (u'http://xml.python.org/', u'abc'), None)] 
Failed test_expat_nsdecl_single 
Passed test_filter_basic 
Passed test_make_parser 
Passed test_make_parser2 
Passed test_nsattrs_empty 
Passed test_nsattrs_wattr 
Passed test_quoteattr_basic 
Passed test_single_double_quoteattr 
Passed test_single_quoteattr 
Passed test_xmlgen_attr_escape 
Passed test_xmlgen_basic 
Passed test_xmlgen_content 
Passed test_xmlgen_content_escape 
Passed test_xmlgen_ignorable 
Passed test_xmlgen_ns 
Passed test_xmlgen_pi 
40 tests, 3 failures 
Traceback (most recent call last): 
  File "Lib/test/test_sax.py", line 707, in ? 
    raise TestFailed, "%d of %d tests failed" % (fails, tests) 
test_support.TestFailed: 3 of 40 tests failed 
 

----------------------------------------------------------------------

Comment By: PieterB (pieterb)
Date: 2003-06-21 19:08

Message:
Logged In: YES 
user_id=458461

test_sax fails because it requires expat2 or pyxml, see:
http://sourceforge.net/tracker/?
group_id=5470&atid=105470&func=detail&aid=758504

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-04 14:55

Message:
Logged In: YES 
user_id=696559

Try current cvs sources, they work for me on same platform.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747460&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 23:10:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 15:10:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-607814 ] IDE look and feel
Message-ID: <E19TqYw-00023K-00@sc8-sf-web4.sourceforge.net>

Bugs item #607814, was opened at 2002-09-11 15:25
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: IDE look and feel

Initial Comment:
The IDE needs to get a more MacOSX-like look and feel. I would suggest using the standard fonts for the various UI components (I know how attached you are to Python-Sans, so let's reformulate that as "optionally using the standard fonts"), and making all buttons, scrollbars and other such elements the standard sizes.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-22 00:10

Message:
Logged In: YES 
user_id=45365

The current IDE will have to suffice for 2.3, and we hope to have 
something better in Cocoa shortly.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-03-18 19:20

Message:
Logged In: YES 
user_id=92689

Jack, assigning to you, feel free to close it as "won't fix". What we really need is a new IDE, written with PyObjC.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-09-11 17:08

Message:
Logged In: YES 
user_id=45365

What time frame are you thinking? We need something decent for Python 2.3, and I would think that a complete W rewrite may be too much work. Note that I'm perfectly willing to do a bit of tweaking myself, as long as it's ok with you.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-09-11 15:31

Message:
Logged In: YES 
user_id=92689

All true, but there's SO much that's not 100% ok on OSX, that I'm 
considering abandoning the W gui kit altogether. As long as I'm not sure 
what the best way is (either a better gui kit based on Carbon or going all 
the way with Cocoa) I don't want to spend all that much time on W and 
IDE. So how's pyobjc coming along? ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 23:14:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 15:14:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-758565 ] IDE needs to remember status of interactive window
Message-ID: <E19TqdH-0002A8-00@sc8-sf-web4.sourceforge.net>

Bugs item #758565, was opened at 2003-06-22 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=758565&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: IDE needs to remember status of interactive window

Initial Comment:
the IDE needs to remember the status of the interactive 
window (open/closed) between runs, and when started for 
the very first time it needs to open that window.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758565&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 23:17:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 15:17:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-758566 ] IDE preferences cleanup
Message-ID: <E19Tqfk-0002EV-00@sc8-sf-web4.sourceforge.net>

Bugs item #758566, was opened at 2003-06-22 00: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=758566&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: IDE preferences cleanup

Initial Comment:
The IDE preferences need to go under the Application-
>Preferences menu. I think the only reasonable way to do 
this without changing too much code is that that menu 
entry opens a window that shows the current settings, 
with buttons that open the windows that are used in the 
current implementation. The funny font selector for the 
GUI elements also needs to be named better. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758566&group_id=5470


From noreply@sourceforge.net  Sat Jun 21 23:41:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 15:41:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-711967 ] Lookup of Mac error string can mess up resfile chain
Message-ID: <E19Tr2a-0001o8-00@sc8-sf-web1.sourceforge.net>

Bugs item #711967, was opened at 2003-03-29 23:32
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711967&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 4
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Lookup of Mac error string can mess up resfile chain

Initial Comment:
Looking up a Mac error string may open a resource file, and the resource file chain isn't reset correctly afterwards. This may mess up code that uses Get1Resource and friends.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-22 00:41

Message:
Logged In: YES 
user_id=45365

Try as I might I cannot repeat this anymore...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711967&group_id=5470


From noreply@sourceforge.net  Sun Jun 22 02:38:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 18:38:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E19Ttnt-0005UC-00@sc8-sf-web2.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 22:25
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-21 21:38

Message:
Logged In: YES 
user_id=31435

Built a Python 2.3b2 candidate with Tcl/Tk 8.4.3 and the 
original problem is still there on Win98SE, although it seems to 
be harder to provoke now.  First attempt failed after 40 tries, 
the second attempt on the 23rd.  Same stuff:  frozen DOS 
box, Winoldap can be killed via the Task Manager then, 
python23.dll remains in use and can't be freed again, etc.

So I'm closing this bug as hopeless (Won't Fix).  I expect the 
last Win9x user will die before it's really fixed <0.5 wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-24 22:55

Message:
Logged In: YES 
user_id=31435

That's cool -- Python 2.3 is on its second alpha release, so 
there's no time crunch yet.  I'll grab 8.4.2 when it's ready 
and try it again.  Thanks for paying attention to this 
miserable report for so many years <wink>!

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2003-02-24 22:49

Message:
Logged In: YES 
user_id=72656

Note that I really meant 8.4.1+, as in post-8.4.1.  Just 
grabbing 8.4.1 final will not suffice.  8.4.2 is about to come 
out for a checkpoint release with the fix.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-24 22:35

Message:
Logged In: YES 
user_id=31435

I just tried, and saw the original symptom on the 3rd try, 
with Python 2.3a2 on Win98SE.  Then reproduced it twice 
after two reboots.  That installs Tcl/Tk 8.4.1.  They were 
not built with OPTS=threads.  I don't know whether 
OPTS=threads would cure it.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2003-02-24 12:04

Message:
Logged In: YES 
user_id=72656

This was against an older version (8.3.2 or 8.3.3).  Make sure 
any verification occurs against the HEAD or 8.3.5.

Also, Martin provided a threaded Tkinter implmentation, IIUC, 
so that makes this doubly out-of-date.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2003-02-24 08:33

Message:
Logged In: YES 
user_id=79902

Exactly which version (including patchlevel) of tcl.dll and
tk.dll is this bug reported against?  (Well, which is the
most recent version...)  Is it one which the Tcl Maintainers
believe to have all identified relevant bugs in the area
resolved, or does it predate that?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-24 07:59

Message:
Logged In: YES 
user_id=6380

Um, I think it's *not* closed, but I'll assign it back to
Tim. I believe Tim said about this somewhere "the Tcl folks
have often thought they'd nailed it, but they still
haven't". Unless that was an entirely different problem. But
it used to happen for me on Win98 too (haven't tried in a
while).

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2003-02-24 02:13

Message:
Logged In: YES 
user_id=38376

(a bugfix a day keeps etc)

Tim, can we close this one?  I don't have access to any-
thing even remotely similar to a Win95-box any longer...

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-12-09 23:16

Message:
Logged In: YES 
user_id=72656

Interesting last couple of comments ...

Anyway, I think the cause of this problem may have finally 
been identified by Tcl bug 651139.  I have attached a patch 
here for it against 8.3.5.  Both the 8.3.5 branch and 8.4.1+ 
head have this fix.  Amazingly it didn't effect Tcl, but could 
likely have caught Tkinter (only on Windows with non-
threaded builds).

Oh look, not allowed to attach a patch, so I'll attach it to Tcl 
bug 651139.

----------------------------------------------------------------------

Comment By: christian soldan (elacademico)
Date: 2002-11-30 21:07

Message:
Logged In: YES 
user_id=659858

how do i hack my fuckers friends

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-30 19:23

Message:
Logged In: NO 

i would like to know some moves

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-21 20:08

Message:
Logged In: YES 
user_id=143340

Hi,

tried wrapping the WaitForSingleObject() with if (consolePtr-
>toWrite) { ... as suggested. Solves the problem for me in 
debug and release builds (without thread support).

What is "the tcl83.dll from www.tcl.tk", what changes does 
it include?

cheers,
John.


----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2002-08-16 19:03

Message:
Logged In: YES 
user_id=148444

I downloaded and tested the tcl83.dll from www.tcl.tk with 
Python 2.2.1 on Win98SE using my BugDemo.py script 
from a related bug report [231207]. Several test runs 
showed that a problem still exists. The app hangs until 
Winopldapp is killed, however this leaves tcl83.dll in use. 
The problem does not occur on every execution. Some 
types of activity seem to provoke the hang, for instance, 
minimizing and maximizing the window seems to increase 
the change that it will hang on exit.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-16 17:53

Message:
Logged In: YES 
user_id=7549

Whoop, error in the patch..  consoleMutex might not need to 
be locked.  It could cause a new dead-lock.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-16 17:41

Message:
Logged In: YES 
user_id=7549

>It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
>at about line 527:
>WaitForSingleObject(consolePtr->writeThread, INFINITE);

Jeff, this might need the same attention the pipe reader 
thread got for that [exec] memory leak bug.  I think 
ConsoleWriterThread() should use WaitForMultipleObjects 
instead of WaitForSingleObject with a second event handle 
used to single a fall-out like the pipe reader thread does.  It 
appears that ConsoleCloseProc() has no way to signal the 
writer thread to close at all.

This doesn't address the blocking WriteFile() in 
ConsoleWriterThread(), though.  Is it blocking there, too?
Sorry for the large post.  I'm given the option to attach a file.

Index: tclWinConsole.c
=============================================
======================
RCS file: /cvsroot/tcl/tcl/win/tclWinConsole.c,v
retrieving revision 1.7
diff -c -r1.7 tclWinConsole.c
*** tclWinConsole.c	15 Jan 2002 17:55:30 -0000	1.7
--- tclWinConsole.c	16 Aug 2002 21:31:56 -0000
***************
*** 79,84 ****
--- 79,87 ----
      HANDLE startWriter;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the writer thread should attempt
  				 * to write to the 
console. */
+     HANDLE stopWriter;		/* Auto-reset 
event used by the main thread to
+ 				 * signal when 
the writer thread should
+ 				 * terminate. */
      HANDLE startReader;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the reader thread should attempt
  				 * to read from 
the console. */
***************
*** 516,522 ****
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	TerminateThread(consolePtr->writeThread, 0);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
--- 519,525 ----
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	SetEvent(consolePtr->stopWriter);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
***************
*** 1134,1149 ****
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
      for (;;) {
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	WaitForSingleObject(infoPtr->startWriter, 
INFINITE);
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
--- 1137,1163 ----
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
+     HANDLE events[2];
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
+     events[0] = infoPtr->stopWriter;
+     events[1] = infoPtr->startWriter;
+ 
      for (;;) {
+ 	DWORD dwWait;
+ 
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	dwWait = WaitForMultipleObjects(events, 2, 
FALSE, INFINITE);
! 
! 	if (dwWait != (WAIT_OBJECT_0 + 1)) {
! 	    /* either the stop event or some other error, so 
exit */
! 	    return 0;
! 	}
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
***************
*** 1251,1256 ****
--- 1265,1271 ----
      if (permissions & TCL_WRITABLE) {
  	infoPtr->writable = CreateEvent(NULL, TRUE, 
TRUE, NULL);
  	infoPtr->startWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
+ 	infoPtr->stopWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
  	infoPtr->writeThread = CreateThread(NULL, 8000, 
ConsoleWriterThread,
  	        infoPtr, 0, &id);
      }


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 14:56

Message:
Logged In: YES 
user_id=72656

I'm finding it a bit hard to reproduce, and now not at all.  
Could people please try replacing their current tcl83.dll with 
the one at http://www.tcl.tk/tcl83.dll.  The sig on it is:
634880 Aug 16 10:53 tcl83.dll
(md5) b35628568ddc4afed4f675d2d9a50faf  tcl83.dll

I can't hang anymore with python 2.2.1 at the Win98 
command prompt with:
   python \Python22\Tools\idle\idle.pyw

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 13:50

Message:
Logged In: YES 
user_id=72656

johnny - That actually helps a lot and fairly clearly indicates 
the source of this hanging problem.  To give more context to 
that area, this is in the final shutdown code where it is 
(obviously) shutting down the console I/O.  The reader is 
shutdown without a check for more input (why, we are 
exiting?), so there is no issue there.

The writer however wants to make sure that the console 
output channel is drained before exit.  A blocking channel 
that is not being flushed will cause a hang.

So the question is, what is the stdio setup for Tcl in 
Py/Tkinter?  That should be examined to see whether stdio is 
clear to flush on exit.

Perhaps you can also help with more debugging.  Could you 
wrap the problematic WaitForSingleObject call with
if (consolePtr->toWrite) { ...
and perhaps also print out what to write.  It may be that 
blocking output isn't the problem at all, but rather that we are 
never receiving the signal on consolePtr->writable (usually 
done in the writer thread).  The consolePtr->toWrite check 
will at least ensure flushed channels do not enter this 
potential hanging state.

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-16 10:16

Message:
Logged In: YES 
user_id=143340

I have dug out the setup I used previously and, apart from 
using Python 2.2 instead of 2.0.1, have had a go at 
reproducing my previous results.

With a debug build of Tcl/Tk and threads disabled I have 
managed to get this stack trace when it locks on exit (after 
doing a break):

ConsoleCloseProc(int * 0x006a0ae4, Tcl_Interp * 
0x00000000) line 527 + 17 bytes
TclFinalizeIOSubsystem() line 241 + 20 bytes
Tcl_FinalizeThread() line 911
Tcl_Finalize() line 812
DllMain(HINSTANCE__ * 0x00970000, unsigned long 
0x00000000, void * 0x00000001) line 197
TCL83! _DllMainCRTStartup@12 + 80 bytes
KERNEL32! bff7ddd6()
KERNEL32! bff8d123()
8176b5fc()

It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
at about line 527:
WaitForSingleObject(consolePtr->writeThread, INFINITE);

I tried changing the timeout from INFINITE to 100ms and 
testing the return value for WAIT_TIMEOUT. Sure enough it 
occasionaly printed a message (and didn't lock-up).

Don't know if this helps. Will try to reproduce the double 
free problem in the threaded build later,

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 10:19

Message:
Logged In: YES 
user_id=6380

Just a note so I won't forget this: Jeff Hobbs once said the
code to look at is

tk/generic/tkConsole.c:Tk_InitConsoleChannels

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 09:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 09:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 08:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-14 21:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-14 20:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 15:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 14:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 13:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 09:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 15:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 14:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 12:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 09:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 21:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 19:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 18:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 18:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 17:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 18:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 04:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 13:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 16:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-06 00:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 21:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 15:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 12:47

Message:
Same as I've reported earlier; it hangs in the call to
Tcl_Finalize (which is called by the DLL finalization
code).  It's less likely to hang if I call Tcl_Finalize
from the _tkinter DLL (from user code).

Note that the problem isn't really Python-related -- I
have stand-alone samples (based on wish) that hangs in
the same way.

More later.

</F>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 10:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 13:25

Message:
The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either.

As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again.

Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 03:37

Message:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up.  There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to get the job done.  PrcView (a freeware process viewer) itself locks up if I try to kill them using it.  Process Viewer freezes for several seconds before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Sun Jun 22 06:20:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 21 Jun 2003 22:20:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-758665 ] cgi module should handle large post attack
Message-ID: <E19TxH2-0003lU-00@sc8-sf-web4.sourceforge.net>

Bugs item #758665, was opened at 2003-06-22 05: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=758665&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Yue Luo (yueluo)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi module should handle large post attack

Initial Comment:
Currently, the FieldStorage class will try to read in all 
the client's input to the cgi script.  This may result in 
deny of service attack if the client tries to post huge 
amount of data.   I wonder if FieldStorage could take a 
parameter limiting the max post size just like the 
$CGI::POST_MAX in Perl CGI.pm module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758665&group_id=5470


From noreply@sourceforge.net  Sun Jun 22 13:31:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 22 Jun 2003 05:31:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-758565 ] IDE needs to remember status of interactive window
Message-ID: <E19U40W-0007wk-00@sc8-sf-web4.sourceforge.net>

Bugs item #758565, was opened at 2003-06-22 00:14
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758565&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: IDE needs to remember status of interactive window

Initial Comment:
the IDE needs to remember the status of the interactive 
window (open/closed) between runs, and when started for 
the very first time it needs to open that window.

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2003-06-22 14:31

Message:
Logged In: YES 
user_id=92689

Hm, the IDE always used to do just that. No time right now, will 
investigate later. Feel free to assign to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758565&group_id=5470


From noreply@sourceforge.net  Sun Jun 22 14:45:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 22 Jun 2003 06:45:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-494589 ] os.path.expandvars deletes things on w32
Message-ID: <E19U59b-00068O-00@sc8-sf-web3.sourceforge.net>

Bugs item #494589, was opened at 2001-12-18 15:29
Message generated for change (Comment added) made by bdadsetan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael McCandless (mikemccand)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars deletes things on w32

Initial Comment:

Try this:

  import os.path
  print os.path.expandvars('foo$doesnotexist')

On FreeBSD, Python 2.1, I get:

  'foo$doesnotexist'

But on WIN32, Python 2.1, I get:

  'foo'

The docs explicitly states that variables that are not 
found will be left in place ... but on win32 that 
appears to not be the case.

----------------------------------------------------------------------

Comment By: Behrang Dadsetan (bdadsetan)
Date: 2003-06-22 15:45

Message:
Logged In: YES 
user_id=806514

tim_one is right. There is plenty of dodgy things hiding
behind the os.path world, especially when it comes to
os.path.expandvars()

There are two problems here. 
- Mismatch in between the doc strings of the different
implementation of expandvars and the "official"
os.path.expandvars documentation.
- the ntpath and dospath implementations are buggy when
compared to their comments/docstrings.

About the first problem, the inconsistency created some time
ago in between the different implementations tasks makes it
difficult to choose a solution. Everyone will probably agree
that all the platform specific implementations of expandvars
should have the same functionality. The one that should be
taken over will probably need to be announced by the BDFL.

Some rule which should not have let this here happen, and on
which I believe we all will agree on:
Same interface=same documentation->same functionality

To implement either copy paste exactly the same expandvars
definition from one platform to another (NT, DOS, POSIX), or
somehow rather arrange that when there is no specific
implementation for the platform, a "default" python
implementation is used on the os.path level. To maximize the
fruits of my small work, I would of course prefer that the
version below becomes the standard and that the
documentation get updated.

To be complete, shall the documentation remain unchanged and
the implementation of dos and nt gets adapted (copied from
posix), the mac implementation could remain unchanged. But I
feel its docstring and its documentation should be in line
with the rest of the implementations.

So my view point-> same interface, same documentation

For the second problem - as of now a real bug whatever we
decide, I wrote within this comment (hereafter) a new
expandvars version which fits the docstring documentation of
dospath.py and the comments of ntpath.py. Sorry you will be
getting no patch from me at the moment since sourceforge's
anonymous CVS access does not like me. Please note that my
version borrows alot from the posixpath.py implementation
and my changes are the ones of a python amateur who is open
to critic.

#expandvars() implementation
_varprog = None
_findquotes = None
def expandvars(path):
    """Expand paths containing shell variable substitutions.
    The following rules apply:
        - no expansion within single quotes
        - no escape character, except for '$$' which is
translated into '$'
        - ${varname} is accepted.
        - varnames can be made out of letters, digits and
the character '_'"""
    global _varprog, _findquotes
    if '$' not in path:
        return path
    if not _varprog:
        import re
        _varprog = re.compile(r'\')
        _findquotes = re.compile("'.*?'")
    quoteareas = []
    i = 0
    while 1:
        quotearea = _findquotes.search(path, i)
        if not quotearea:
            break
        (i, j) = quotearea.span(0)
        quoteareas.append((i, j))
        i = j
    i = 0
    while 1:
        m = _varprog.search(path, i)
        if not m:
            break
        i, j = m.span(0)
        insidequotes=None
        for (quotebegin, quoteend) in quoteareas:
            if quotebegin < i and quoteend > i:
                insidequotes=1
                break
        if insidequotes:
            i = j
            continue
        name = m.group(1)
        if name[:1] == '$':
            path = path[:i] + '$' + path[j:]
            i = i + 1
        else:
            if name[:1] == '{' and name[-1:] == '}':
                name = name[1:-1]
            if os.environ.has_key(name):
                tail = path[j:]
                path = path[:i] + os.environ[name]
                i = len(path)
                path = path + tail
            else:
                i = j
    return path

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-19 07:56

Message:
Logged In: YES 
user_id=31435

Another bug:  with two adjacent envars that do exist, only 
the first is expanded (on Windows):

>>> os.path.expandvars('$TMP$TMP')
'c:\windows\TEMP$TMP'
>>>

Another bug:  the Windows expandvars doesn't expand envars 
in single quotes, but the posixpath flavor does:

>>> ntpath.expandvars("'$TMP'")
"'$TMP'"
>>> posixpath.expandvars("'$TMP'")
"'c:\windows\TEMP'"
>>>

Another bug:  $$ is an escape sequence (meaning a single $) 
on Windows but not on Unix:

>>> ntpath.expandvars('$$')
'$'
>>> posixpath.expandvars('$$')
'$$'
>>>

Unassigning from me, as this is a bottomless pit spanning 
platforms and bristling with backward-compatibility traps 
no matter what's done about it.  Somebody who cares enough 
should write a PEPlet to sort out the mess, else I'd just 
leave it alone.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-18 15:43

Message:
Logged In: YES 
user_id=6380

Hm, I do understand it, the code is broken (compared to the
spec).

No time to fix it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-18 15:35

Message:
Logged In: YES 
user_id=6380

Confirmed, also in 2.2. I don't understand it, the code
looks OK.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470


From noreply@sourceforge.net  Sun Jun 22 16:37:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 22 Jun 2003 08:37:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-758665 ] cgi module should handle large post attack
Message-ID: <E19U6u3-0001ZD-00@sc8-sf-web3.sourceforge.net>

Bugs item #758665, was opened at 2003-06-22 05:20
Message generated for change (Comment added) made by yueluo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758665&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Yue Luo (yueluo)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi module should handle large post attack

Initial Comment:
Currently, the FieldStorage class will try to read in all 
the client's input to the cgi script.  This may result in 
deny of service attack if the client tries to post huge 
amount of data.   I wonder if FieldStorage could take a 
parameter limiting the max post size just like the 
$CGI::POST_MAX in Perl CGI.pm module.

----------------------------------------------------------------------

>Comment By: Yue Luo (yueluo)
Date: 2003-06-22 15:37

Message:
Logged In: YES 
user_id=806666

Also, a parameter like Perl's $CGI::DISABLE_UPLOADS is also a 
good idea.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758665&group_id=5470


From noreply@sourceforge.net  Sun Jun 22 18:05:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 22 Jun 2003 10:05:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-620190 ] inspect and object instances
Message-ID: <E19U8Hb-0004sk-00@sc8-sf-web3.sourceforge.net>

Bugs item #620190, was opened at 2002-10-08 12:26
Message generated for change (Comment added) made by aschmolck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620190&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Jeremy Hylton (jhylton)
Summary: inspect and object instances

Initial Comment:
inspect.getargspec(NewKlass.aMethod)  fails (which
might technically be OK because the docs only mention
functions, not methods) but I also vaguely seem to
remember that some other operations in the inspect
module only worked for oldstyle classes under 2.2.1.

----------------------------------------------------------------------

>Comment By: Alexander Schmolck (aschmolck)
Date: 2003-06-22 17:05

Message:
Logged In: YES 
user_id=559641

a late reply RE: other problems (the notification I received
from SF for a (mysterious) 'settings change' prompted me to
look at this report again).

There doesn't seem to be a straightforwad way to test for
(instance) "methodness".
For example, I think it ought to be easy to get the
instance, class and/or staticmethods of something,
independent of whether it is old-style class, new-style
class or builtin type etc., which to most extents and
purposes is an insignificant implementation detail. For
example, I doubt the following will do what the casual
programmer expects:

>>> inspect.getmembers(foo, inspect.ismethod)

because foo might e.g. be a Numeric.array. The only function
in `inspect` that returns something along those lines that
is useful and understandable to someone who hasn't got the
most exquisite knowledge about python's
old-style/new-style/builin-type, method-wrapper, __slots__
etc. chaos is `classify_class_attrs', only that this doesn't
work for types or classes with __slots__ (at least the
latter ought to be fixed) and also packages together
functionality that I think should exist seperately.


----------------------------------------------------------------------

Comment By: Michael Stone (mbrierst)
Date: 2003-02-11 22:46

Message:
Logged In: YES 
user_id=670441

Well I think this (one line)
patch will make getargspec work with
methods, if anyone wants to apply it.
Did you find any other operations that
don't work?

patch:
Index: Lib/inspect.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/inspect.py,v
retrieving revision 1.41
diff -c -r1.41 inspect.py
*** Lib/inspect.py	19 Jan 2003 13:21:20 -0000	1.41
--- Lib/inspect.py	11 Feb 2003 22:35:41 -0000
***************
*** 16,22 ****
      getmodule() - determine the module that an object came from
      getclasstree() - arrange classes so as to represent their hierarchy
  
!     getargspec(), getargvalues() - get info about function arguments
      formatargspec(), formatargvalues() - format an argument spec
      getouterframes(), getinnerframes() - get info about frames
      currentframe() - get the current stack frame
--- 16,22 ----
      getmodule() - determine the module that an object came from
      getclasstree() - arrange classes so as to represent their hierarchy
  
!     getargspec(), getargvalues() - get info about function or method's arguments
      formatargspec(), formatargvalues() - format an argument spec
      getouterframes(), getinnerframes() - get info about frames
      currentframe() - get the current stack frame
***************
*** 625,636 ****
      return args, varargs, varkw
  
  def getargspec(func):
!     """Get the names and default values of a function's arguments.
  
      A tuple of four things is returned: (args, varargs, varkw, defaults).
      'args' is a list of the argument names (it may contain nested lists).
      'varargs' and 'varkw' are the names of the * and ** arguments or None.
      'defaults' is an n-tuple of the default values of the last n arguments."""
      if not isfunction(func): raise TypeError, 'arg is not a Python function'
      args, varargs, varkw = getargs(func.func_code)
      return args, varargs, varkw, func.func_defaults
--- 625,637 ----
      return args, varargs, varkw
  
  def getargspec(func):
!     """Get the names and default values of a function or method's arguments.
  
      A tuple of four things is returned: (args, varargs, varkw, defaults).
      'args' is a list of the argument names (it may contain nested lists).
      'varargs' and 'varkw' are the names of the * and ** arguments or None.
      'defaults' is an n-tuple of the default values of the last n arguments."""
+     if ismethod(func): func = func.im_func
      if not isfunction(func): raise TypeError, 'arg is not a Python function'
      args, varargs, varkw = getargs(func.func_code)
      return args, varargs, varkw, func.func_defaults


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620190&group_id=5470


From noreply@sourceforge.net  Sun Jun 22 18:11:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 22 Jun 2003 10:11:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-758504 ] test_sax fails on python 2.2.3 & patch for regrtest.py
Message-ID: <E19U8Nh-0000AQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #758504, was opened at 2003-06-21 20:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: PieterB (pieterb)
>Assigned to: Martin v. Löwis (loewis)
Summary: test_sax fails on python 2.2.3 & patch for regrtest.py

Initial Comment:
Hi,

1) testing using the FreeBSD ports version of Python 
2.2.3 fails (both on FreeBSD 5 and FreeBSD 4.8). The 
test test_sax.py fails, because test_sax seems to 
require expat2 (?), which isn't available by default on 
FreeBSD).

2) I've also patched regrtest.py so that it works on 
FreeBSD 4/5
(Chimp@IRC tested it on FreeBSD4.8), can somebody
apply the patches from regrtest.py to CVS?
Source: http://www.gewis.nl/~pieterb/python/bugs-
2.2.3/

In detail:

1) testing using the FreeBSD ports version of Python 
2.2.3 failed
==========================================
========================

Using Python 2.2.3 from recent FreeBSD ports
"cd /usr/ports/lang/python ; make ; cd work/Python-
2.2.3 ; make test"
gives:

174 tests OK.
1 test failed:
    test_sax
18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on freebsd5.
*** Error code 1

Stop in /usr/ports/lang/python/work/Python-2.2.3.

----------------------------------------------------

cd /usr/ports/lang/python/work/Python-2.2.3/Lib/test
../../python test_sax.py
gives:
test_support.TestFailed: 3 of 40 tests failed

...
Expected:
[('start', ('http://xml.python.org/1', 'abc'), 'abc'),
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/1', u'abc'), None),
 ('start', (u'http://xml.python.org/2', u'def'), None),
 ('end', (u'http://xml.python.org/2', u'def'), None),
 ('start', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'abc'), None)]
Failed test_expat_nsdecl_pair_diff
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'),
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('start', (u'http://xml.python.org/', u'def'), None),
 ('end', (u'http://xml.python.org/', u'def'), None),
 ('start', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_pair_same
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'abc'),
 ('end', ('http://xml.python.org/', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_single

I managed to fixed this by patching test_sax.py,
see http://gewis.nl/~pieterb/python/bugs-2.2.3/

2) i've patched regrtest.py so that it works on FreeBSD 
4/5
==========================================
=================
This make it possible to run 'make test' on Python.
It will give the following output:
  175 tests OK.
  18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
  Those skips are all expected on freebsd5.

Can anybody confirm that it's ok to skip those tests.  
Can anybody
download the patched version of regrtest.py from the 
URL above check
it into Python CVS?

Thanks to Chimp@IRC for testing it on FreeBSD4.8
Thanks to itz@irc and others at IRC:#python for their 
help.

PieterB

--
http://zwiki.org/PieterB





----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-22 19:11

Message:
Logged In: YES 
user_id=21627

I'm unsure why test_locale, test_nis, and test_socket_ssl
would be skipped. 

I'm also surprised test_pyexpat is skipped when test_minidom
is executed. This is impossible.

----------------------------------------------------------------------

Comment By: PieterB (pieterb)
Date: 2003-06-21 21:00

Message:
Logged In: YES 
user_id=458461

See also: http://sourceforge.net/tracker/?
group_id=5470&atid=105470&func=detail&aid=621579

a search on "test_sax" indicates that isn't running on quite a 
lot of other platforms.

PieterB
--
http://zwiki.org/PieterB

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&group_id=5470


From noreply@sourceforge.net  Sun Jun 22 22:36:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 22 Jun 2003 14:36:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-758565 ] IDE needs to remember status of interactive window
Message-ID: <E19UCVt-0007SM-00@sc8-sf-web2.sourceforge.net>

Bugs item #758565, was opened at 2003-06-22 00:14
Message generated for change (Settings changed) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758565&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Just van Rossum (jvr)
Summary: IDE needs to remember status of interactive window

Initial Comment:
the IDE needs to remember the status of the interactive 
window (open/closed) between runs, and when started for 
the very first time it needs to open that window.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-06-22 14:31

Message:
Logged In: YES 
user_id=92689

Hm, the IDE always used to do just that. No time right now, will 
investigate later. Feel free to assign to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758565&group_id=5470


From noreply@sourceforge.net  Sun Jun 22 22:59:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 22 Jun 2003 14:59:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-756576 ] Recursion limit too high for MacOSX
Message-ID: <E19UCrd-0008Hi-00@sc8-sf-web2.sourceforge.net>

Bugs item #756576, was opened at 2003-06-18 15:01
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756576&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recursion limit too high for MacOSX

Initial Comment:
Python's recursion limit is too high for Mac OS X, where the 
default stack size is 512K. The attached script will never 
trigger a maximum recursion depth exception, it will have 
crashed Python with a segmentation violation before that.

A possible solution is a call to sys.setrecursionlimit() in 
site.py, another is to change the number "1000" in ceval.c 
to a configure-time constant.

Other platforms may also suffer this problem, it may be a 
good idea to add a test_stackoverflow.

I'm willing to do the work involved, but I'd like some 
feedback first.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-22 23:59

Message:
Logged In: YES 
user_id=45365

A runtime mechanism is already available (PyOS_CheckStack), 
but it is only used on platforms where a stack overrun would be 
disastrous (i.e. run into your heap in stead of giving a SEGV), 
because it is pretty expensive. If there is a common way to do 
this easier (i.e. set a red zone pointer and do one pointer 
compare in a stack test macro) I would be all for it, bt I don't 
know how to do this.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:50

Message:
Logged In: YES 
user_id=21627

If more work is put into recursion limits, I think platform
mechanisms should be used where available. For example,
there might be ways to find out, at run-time, what the stack
consumption is, and what the stack availalability is, and
compute a recursion limit from that.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-18 17:40

Message:
Logged In: YES 
user_id=31392

I'd like to see a per-platform recusion limit, because the
limit could be much higher on Linux and Windows than 1000.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756576&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 01:10:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 22 Jun 2003 17:10:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-695688 ] Problems with non-greedy match groups
Message-ID: <E19UEvB-0005D7-00@sc8-sf-web4.sourceforge.net>

Bugs item #695688, was opened at 2003-03-01 18:52
Message generated for change (Settings changed) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695688&group_id=5470

Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel (kamek)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Problems with non-greedy match groups

Initial Comment:
The problem is better explained with this code:

import re
regexp = re.compile(r'^begin ((.*?)X)?(.+) end$')

print regexp.search('begin oneXtwo end').groups()
# The above one will correctly print:
#   ('oneX', 'one', 'two')

print regexp.search('begin two end').groups()
# ...but the above one will print:
#   (None, 'two end', 'two')
# If we change regexp's non-greedy
# .*? into .*, it works as it should:
#   (None, None, 'two')


The problem lies in sre; pre correctly matches the non-
greedy version.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695688&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 07:32:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 22 Jun 2003 23:32:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-747460 ] make test errors Tru64 UNIX V5.1A
Message-ID: <E19UKss-00049V-00@sc8-sf-web3.sourceforge.net>

Bugs item #747460, was opened at 2003-06-02 12:45
Message generated for change (Settings changed) made by muellergm4t9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747460&group_id=5470

Category: Build
Group: Python 2.2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Gottfried Mueller (muellergm4t9)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test errors Tru64 UNIX V5.1A

Initial Comment:
What can I do? 
 
1. Test Error 
python Lib/test/test_compile.py 
 
Testing whether compiler catches assignment to 
__debug__ 
Running tests on argument handling 
testing complex args 
1 2 
1 2 
3 4 
1 2 3 
1 2 3 
2 3 4 
testing bad float literals 
testing literals with leading zeroes 
Traceback (most recent call last): 
  File "Lib/test/test_compile.py", line 128, in ? 
    expect_same("0xffffffff", -1) 
  File "Lib/test/test_compile.py", line 90, in expect_same 
    raise TestFailed("eval(%r) gave %r, but expected %r" 
% 
test_support.TestFailed: eval('0xffffffff') gave 
4294967295, but expected -1 
 
2.Test Error 
python Lib/test/test_long.py    
 
long / * % divmod 
long bit-operation identities 
long str/hex/oct/atol 
long miscellaneous operations 
auto-convert int->long on overflow 
long->float overflow 
Traceback (most recent call last): 
  File "Lib/test/test_long.py", line 409, in ? 
    test_float_overflow() 
  File "Lib/test/test_long.py", line 362, in 
test_float_overflow 
    eval(test, namespace) 
  File "<string>", line 0, in ? 
ValueError: invalid literal for float(): 
123451234512345123451234512345123451234 
51234512345123451234512345123451234512345123451234512345123451234512345123451234 
51234512345123451234512345123451234512345123451234512345123451234512345123451234 
5 
 
3. Test Error 
python Lib/test/test_sax.py 
 
Passed test_attrs_empty 
Passed test_attrs_wattr 
Passed test_double_quoteattr 
Passed test_escape_all 
Passed test_escape_basic 
Passed test_escape_extra 
Passed test_expat_attrs_empty 
Passed test_expat_attrs_wattr 
Passed test_expat_dtdhandler 
Passed test_expat_entityresolver 
Passed test_expat_file 
Passed test_expat_incomplete 
Passed test_expat_incremental 
Passed test_expat_incremental_reset 
Passed test_expat_inpsource_filename 
Passed test_expat_inpsource_location 
Passed test_expat_inpsource_stream 
Passed test_expat_inpsource_sysid 
Passed test_expat_locator_noinfo 
Passed test_expat_locator_withinfo 
Passed test_expat_nsattrs_empty 
Passed test_expat_nsattrs_wattr 
Expected: 
[('start', ('http://xml.python.org/1', 'abc'), 'abc'), 
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'), 
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'), 
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'), 
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'), 
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')] 
Received: 
[('start', (u'http://xml.python.org/1', u'abc'), None), 
 ('start', (u'http://xml.python.org/2', u'def'), None), 
 ('end', (u'http://xml.python.org/2', u'def'), None), 
 ('start', (u'http://xml.python.org/1', u'ghi'), None), 
 ('end', (u'http://xml.python.org/1', u'ghi'), None), 
 ('end', (u'http://xml.python.org/1', u'abc'), None)] 
Failed test_expat_nsdecl_pair_diff 
Expected: 
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'), 
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'), 
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'), 
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), 
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), 
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')] 
Received: 
[('start', (u'http://xml.python.org/', u'abc'), None), 
 ('start', (u'http://xml.python.org/', u'def'), None), 
 ('end', (u'http://xml.python.org/', u'def'), None), 
 ('start', (u'http://xml.python.org/', u'ghi'), None), 
 ('end', (u'http://xml.python.org/', u'ghi'), None), 
 ('end', (u'http://xml.python.org/', u'abc'), None)] 
Failed test_expat_nsdecl_pair_same 
Expected: 
[('start', ('http://xml.python.org/', 'abc'), 'abc'), 
 ('end', ('http://xml.python.org/', 'abc'), 'abc')] 
Received: 
[('start', (u'http://xml.python.org/', u'abc'), None), 
 ('end', (u'http://xml.python.org/', u'abc'), None)] 
Failed test_expat_nsdecl_single 
Passed test_filter_basic 
Passed test_make_parser 
Passed test_make_parser2 
Passed test_nsattrs_empty 
Passed test_nsattrs_wattr 
Passed test_quoteattr_basic 
Passed test_single_double_quoteattr 
Passed test_single_quoteattr 
Passed test_xmlgen_attr_escape 
Passed test_xmlgen_basic 
Passed test_xmlgen_content 
Passed test_xmlgen_content_escape 
Passed test_xmlgen_ignorable 
Passed test_xmlgen_ns 
Passed test_xmlgen_pi 
40 tests, 3 failures 
Traceback (most recent call last): 
  File "Lib/test/test_sax.py", line 707, in ? 
    raise TestFailed, "%d of %d tests failed" % (fails, tests) 
test_support.TestFailed: 3 of 40 tests failed 
 

----------------------------------------------------------------------

Comment By: PieterB (pieterb)
Date: 2003-06-21 21:08

Message:
Logged In: YES 
user_id=458461

test_sax fails because it requires expat2 or pyxml, see:
http://sourceforge.net/tracker/?
group_id=5470&atid=105470&func=detail&aid=758504

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-04 16:55

Message:
Logged In: YES 
user_id=696559

Try current cvs sources, they work for me on same platform.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747460&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 08:58:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 23 Jun 2003 00:58:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-756842 ] Ms VC 2003 not supported
Message-ID: <E19UMDw-0001as-00@sc8-sf-web4.sourceforge.net>

Bugs item #756842, was opened at 2003-06-18 21:17
Message generated for change (Comment added) made by darkarathorn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756842&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Paolo Invernizzi (darkarathorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ms VC 2003 not supported

Initial Comment:
The current msvccompiler.py has no support for Ms
Visual Studio NET 2003 release.
The registry keys are different than the original
VS.NET and NET Framework

File
"d:\repositories\python\dist\src\lib\distutils\msvccompiler.py",
line 114, in set_macro
    self.macros["$(%s)" % macro] = d[key]
KeyError: 'sdkinstallroot'


---
Paolo Invernizzi

----------------------------------------------------------------------

>Comment By: Paolo Invernizzi (darkarathorn)
Date: 2003-06-23 07:58

Message:
Logged In: YES 
user_id=172594

__revision__ = "$Id: msvccompiler.py,v 1.56 2003/05/14
19:48:57 lemburg Exp $"


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 13:48

Message:
Logged In: YES 
user_id=21627

What version of msvccompiler.py are you using? Specifically,
what is its __revision__?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756842&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 11:09:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 23 Jun 2003 03:09:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-758504 ] test_sax fails on python 2.2.3 & patch for regrtest.py
Message-ID: <E19UOG0-00045Q-00@sc8-sf-web3.sourceforge.net>

Bugs item #758504, was opened at 2003-06-22 04:50
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: PieterB (pieterb)
Assigned to: Martin v. Löwis (loewis)
Summary: test_sax fails on python 2.2.3 & patch for regrtest.py

Initial Comment:
Hi,

1) testing using the FreeBSD ports version of Python 
2.2.3 fails (both on FreeBSD 5 and FreeBSD 4.8). The 
test test_sax.py fails, because test_sax seems to 
require expat2 (?), which isn't available by default on 
FreeBSD).

2) I've also patched regrtest.py so that it works on 
FreeBSD 4/5
(Chimp@IRC tested it on FreeBSD4.8), can somebody
apply the patches from regrtest.py to CVS?
Source: http://www.gewis.nl/~pieterb/python/bugs-
2.2.3/

In detail:

1) testing using the FreeBSD ports version of Python 
2.2.3 failed
==========================================
========================

Using Python 2.2.3 from recent FreeBSD ports
"cd /usr/ports/lang/python ; make ; cd work/Python-
2.2.3 ; make test"
gives:

174 tests OK.
1 test failed:
    test_sax
18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on freebsd5.
*** Error code 1

Stop in /usr/ports/lang/python/work/Python-2.2.3.

----------------------------------------------------

cd /usr/ports/lang/python/work/Python-2.2.3/Lib/test
../../python test_sax.py
gives:
test_support.TestFailed: 3 of 40 tests failed

...
Expected:
[('start', ('http://xml.python.org/1', 'abc'), 'abc'),
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/1', u'abc'), None),
 ('start', (u'http://xml.python.org/2', u'def'), None),
 ('end', (u'http://xml.python.org/2', u'def'), None),
 ('start', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'abc'), None)]
Failed test_expat_nsdecl_pair_diff
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'),
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('start', (u'http://xml.python.org/', u'def'), None),
 ('end', (u'http://xml.python.org/', u'def'), None),
 ('start', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_pair_same
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'abc'),
 ('end', ('http://xml.python.org/', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_single

I managed to fixed this by patching test_sax.py,
see http://gewis.nl/~pieterb/python/bugs-2.2.3/

2) i've patched regrtest.py so that it works on FreeBSD 
4/5
==========================================
=================
This make it possible to run 'make test' on Python.
It will give the following output:
  175 tests OK.
  18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
  Those skips are all expected on freebsd5.

Can anybody confirm that it's ok to skip those tests.  
Can anybody
download the patched version of regrtest.py from the 
URL above check
it into Python CVS?

Thanks to Chimp@IRC for testing it on FreeBSD4.8
Thanks to itz@irc and others at IRC:#python for their 
help.

PieterB

--
http://zwiki.org/PieterB





----------------------------------------------------------------------

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-23 20:09

Message:
Logged In: YES 
user_id=250749

I haven't looked to see what the port is doing, but just
using configure, I find with 2.2.3 on FreeBSD 4.8:-
- test_locale fails becuase "en_US" is not a supported
locale; the test would have to use one of "en_US.US-ASCII",
"en_US.ISO8859-1" or "en_US.ISO8859-15" (I have no idea
which would be most appropriate).

- test_nis will fail if it can't find a NIS master for any
NIS map.

- test_socket_ssl & test_socketserver will be skipped if the
network resource is not enabled.

- test_sax & test_pyexpat both pass.

FreeBSD has its own expat package (which is using expat
1.95.6 on both 4.8 & 5.1).  pyexpat is a separately
selectable package/port.  If you haven't installed the
pyexpat package, or built same from the port, then test_sax
& test_pyexpat are both going to be skipped.

I'm still looking at a couple of other issues with building
on 5.1.

Given that FreeBSD 5.0 was a technology preview not intended
for production use, and a STABLE branch will not be declared
until at least after 5.2 is released, it will not be trivial
to keep track of build issues until release of 5.2.  I am
not in a position to track the FreeBSD 5.x CVS, but I will
try and keep up with releases.

I'm not sure whether anyone has yet stepped in to take Alan
Eldridge's place as maintainer of FreeBSD's ports of Python
& various modules. IMO, many of the issues here should have
been taken up with the Python port maintainer, rather than
being dealt with in Python's tracker (I tried to contact
AlanE about some of this not long before he died).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-23 03:11

Message:
Logged In: YES 
user_id=21627

I'm unsure why test_locale, test_nis, and test_socket_ssl
would be skipped. 

I'm also surprised test_pyexpat is skipped when test_minidom
is executed. This is impossible.

----------------------------------------------------------------------

Comment By: PieterB (pieterb)
Date: 2003-06-22 05:00

Message:
Logged In: YES 
user_id=458461

See also: http://sourceforge.net/tracker/?
group_id=5470&atid=105470&func=detail&aid=621579

a search on "test_sax" indicates that isn't running on quite a 
lot of other platforms.

PieterB
--
http://zwiki.org/PieterB

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 12:13:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 23 Jun 2003 04:13:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-756093 ] complex pow() crash on Alpha
Message-ID: <E19UPGk-0000qZ-00@sc8-sf-web4.sourceforge.net>

Bugs item #756093, was opened at 2003-06-17 20:17
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756093&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: complex pow() crash on Alpha

Initial Comment:
Python crashes with a floating point exception on SF's
 Alpha/Linux 2.2 machine in the compile farm:
$ ./python
Python 2.3b1+ (#2, Jun 17 2003, 10:50:58) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> pow(1e200+1j,1e200+1j)
Floating point exception
$

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-23 13:13

Message:
Logged In: YES 
user_id=89016

Doesn't seem that way: gcc -pthread -c  -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE
-o Objects/complexobject.o Objects/complexobject.c

Changing OPT in Makefile to include -ieee and recompiling
doesn't fix the problem, I still get a "Floating point
exception".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:51

Message:
Logged In: YES 
user_id=21627

Can you tell whether you were compiling with -ieee?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756093&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 14:45:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 23 Jun 2003 06:45:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-759227 ] improbable __nonzero__ crash
Message-ID: <E19URd3-0007Wg-00@sc8-sf-web2.sourceforge.net>

Bugs item #759227, was opened at 2003-06-23 13: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=759227&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: improbable __nonzero__ crash

Initial Comment:
>>> class X(object):
...   def __nonzero__(self):
...     return self
... 
>>> x=X()
>>> not x
Segmentation fault

This is just a stupid artificial exploit of the fact
that PyObject_IsTrue calls the user-defined __nonzero__
and get a Python object whose truth-value itself is
determined by a call to PyObject_IsTrue.

For old-style classes we check that __nonzero__
actually returned an int. This trick was safe, but no
longer is, because it could be a subclass of int with a
custom __nonzero__ again.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 17:58:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 23 Jun 2003 09:58:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-759227 ] improbable __nonzero__ crash
Message-ID: <E19UUeO-0004K5-00@sc8-sf-web1.sourceforge.net>

Bugs item #759227, was opened at 2003-06-23 09:45
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: improbable __nonzero__ crash

Initial Comment:
>>> class X(object):
...   def __nonzero__(self):
...     return self
... 
>>> x=X()
>>> not x
Segmentation fault

This is just a stupid artificial exploit of the fact
that PyObject_IsTrue calls the user-defined __nonzero__
and get a Python object whose truth-value itself is
determined by a call to PyObject_IsTrue.

For old-style classes we check that __nonzero__
actually returned an int. This trick was safe, but no
longer is, because it could be a subclass of int with a
custom __nonzero__ again.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 12:58

Message:
Logged In: YES 
user_id=33168

This is also a 2.2.3 problem.  This seems easy enough to fix
(patch attached), but the question is what should the answer
be?  I made it return 1 (true).  Should it be an exception?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 18:01:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 23 Jun 2003 10:01:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-759227 ] improbable __nonzero__ crash
Message-ID: <E19UUhM-0001Ts-00@sc8-sf-web4.sourceforge.net>

Bugs item #759227, was opened at 2003-06-23 09:45
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: improbable __nonzero__ crash

Initial Comment:
>>> class X(object):
...   def __nonzero__(self):
...     return self
... 
>>> x=X()
>>> not x
Segmentation fault

This is just a stupid artificial exploit of the fact
that PyObject_IsTrue calls the user-defined __nonzero__
and get a Python object whose truth-value itself is
determined by a call to PyObject_IsTrue.

For old-style classes we check that __nonzero__
actually returned an int. This trick was safe, but no
longer is, because it could be a subclass of int with a
custom __nonzero__ again.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 13:01

Message:
Logged In: YES 
user_id=33168

Note: the patch doesn't address a case of mutual recursion
where 2 or more objects are involved.  That could be fixed
by tying the call into the recursion limit.  Not sure how
difficult that is or if it's worth it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 12:58

Message:
Logged In: YES 
user_id=33168

This is also a 2.2.3 problem.  This seems easy enough to fix
(patch attached), but the question is what should the answer
be?  I made it return 1 (true).  Should it be an exception?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 21:18:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 23 Jun 2003 13:18:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-703066 ] os.utime can fail with TypeError
Message-ID: <E19UXlu-0007tf-00@sc8-sf-web3.sourceforge.net>

Bugs item #703066, was opened at 2003-03-13 08:40
Message generated for change (Comment added) made by bescoto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703066&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.utime can fail with TypeError

Initial Comment:
Occasionally os.utime can fail with a TypeError:

# python
Python 2.2.2 (#1, Dec 16 2002, 02:51:47)
[GCC 3.2.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os,time
>>>
os.utime("/backup/test/interhost/ace/.maildir-sent/cur/rdiff-backup.tmp.1980",
... (time.time(), 1038064008));
Traceback (most recent call last):
  File "<stdin>", line 2, in ?
TypeError: utime() arg 2 must be a tuple (atime, mtime)

if one of the elements in the time pair is a float and
not a long.  Strangely it seems to work sporadically. 
It may just be a documentation problem -- add a note in
the docs saying longs are required, and then have the
TypeError say:

TypeError: utime() arg 2 must be a tuple of longs
(atime, mtime)

----------------------------------------------------------------------

>Comment By: Ben Escoto (bescoto)
Date: 2003-06-23 13:18

Message:
Logged In: YES 
user_id=218965

Hmm, I'm not seeing it now.  Was very strange to begin with,
hope (for personal sanity) that it existed to begin with. 
Closing...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 14:39

Message:
Logged In: YES 
user_id=33168

Ben, I can't reproduce this problem with 2.2.3 or 2.3.  Can
you verify this is still a problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703066&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 22:24:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 23 Jun 2003 14:24:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-756093 ] complex pow() crash on Alpha
Message-ID: <E19UYnV-0006PL-00@sc8-sf-web4.sourceforge.net>

Bugs item #756093, was opened at 2003-06-17 20:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756093&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: complex pow() crash on Alpha

Initial Comment:
Python crashes with a floating point exception on SF's
 Alpha/Linux 2.2 machine in the compile farm:
$ ./python
Python 2.3b1+ (#2, Jun 17 2003, 10:50:58) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> pow(1e200+1j,1e200+1j)
Floating point exception
$

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-23 23:24

Message:
Logged In: YES 
user_id=21627

Ah, I see: LINUX. This is probably a compiler bug, without
even looking at the details.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-23 13:13

Message:
Logged In: YES 
user_id=89016

Doesn't seem that way: gcc -pthread -c  -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE
-o Objects/complexobject.o Objects/complexobject.c

Changing OPT in Makefile to include -ieee and recompiling
doesn't fix the problem, I still get a "Floating point
exception".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:51

Message:
Logged In: YES 
user_id=21627

Can you tell whether you were compiling with -ieee?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756093&group_id=5470


From noreply@sourceforge.net  Mon Jun 23 23:43:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 23 Jun 2003 15:43:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-759525 ] inspect.getmembers broken (?)
Message-ID: <E19Ua21-0008OC-00@sc8-sf-web2.sourceforge.net>

Bugs item #759525, was opened at 2003-06-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=759525&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getmembers broken (?)

Initial Comment:
inspect.getmembers currently uses `dir` to obtain a
list of an object's "members", which omits certain
things such as methods of the metaclass, e.g:

  >>> 'mro' in dict(inspect.getmembers(int))
  0

Since I can't find a description of what exactly
constitutes a "member", it is not strictly possible to
tell whether this is the intended behavior, but then
the documentation should be updated in this case to
clarify the semantics more.

It currently seems quite hard to answer seemingly
innocuous questions such as "What are the methods of
class/type X?" with introspection. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759525&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 13:46:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 05:46:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-755080 ] AssertionError from urllib.retrieve / httplib
Message-ID: <E19UnCI-0008Lx-00@sc8-sf-web1.sourceforge.net>

Bugs item #755080, was opened at 2003-06-16 10:37
Message generated for change (Comment added) made by zenzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755080&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: AssertionError from urllib.retrieve / httplib

Initial Comment:

The following statement is occasionally generating
AssertionErrors:
    current_page = urllib.urlopen(action,data).read()

Traceback (most recent call last):
  File "/Users/zen/bin/autospamrep.py", line 161, in ?
    current_page = handle_spamcop_page(current_page)
  File "/Users/zen/bin/autospamrep.py", line 137, in 
handle_spamcop_page
    current_page = urllib.urlopen(action,data).read()
  File "/sw/lib/python2.3/httplib.py", line 1150, in read
    assert not self._line_consumed and self._line_left


Fix may be to do the following in 
LineAndFileWrapper.__init__ (last two lines are new):

def __init__(self, line, file):
        self._line = line
        self._file = file
        self._line_consumed = 0
        self._line_offset = 0
        self._line_left = len(line)
        if not self._line_left:
            self._done()


----------------------------------------------------------------------

>Comment By: Stuart Bishop (zenzen)
Date: 2003-06-24 22:46

Message:
Logged In: YES 
user_id=46639

I've been unable to repeat the problem through a tcpwatch.py 
proxy, so I'm guessing the trigger is connecting to a fairly loaded 
server over a 56k modem - possibly the socket is in a bad state 
and nothing noticed?

I'll try not going through tcpwatch.py for a bit and see if I can still 
trigger the problem in case there was a server problem triggering 
it that has been fixed.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-17 05:40

Message:
Logged In: YES 
user_id=31392

Can you reproduce this problem easily?  We've seen something
like it before, but have had trouble figuring out what goes
wrong.


----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-16 10:55

Message:
Logged In: YES 
user_id=46639

My suggested fix is wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755080&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 14:16:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 06:16:53 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-759792 ] Make urllib2 more extensibile (patch)
Message-ID: <E19UnfJ-0001Qx-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #759792, was opened at 2003-06-24 14:16
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=759792&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make urllib2 more extensibile (patch)

Initial Comment:
Problem with urllib2 as it stands: many things would be 
nice to implement as a handler rather than by overriding 
methods (and inevitably duplicating code and increasing 
fragility), but it's not always possible to do so.  For 
example (all from HTTP), automatically adding Referer 
headers, handling 200 responses that should have been 
non-2xx errors if the server were sane, handling cookies, 
handling HTTP-EQUIV headers as if they were normal 
HTTP headers, automatically making responses 
seekable, and following Refresh headers.  I've done all 
these things, but I had to duplicate code to do it, 
because I don't see how to do it with handlers.  I've now 
rewritten this code by adding a 'processor' scheme to 
urllib2 (I'm *not* using 'scheme' in the technical URL 
sense here!). 
 
Processors work quite similarly to handlers, except that 
 
1. They always *all* get run (rather than just the first to 
handle a request or response -- unlike handlers). 
 
2. The methods that get called on processors are of the 
form <proto>_request and <proto>_response, and are 
called, respectively, immediately before and immediately 
after the normal OpenerDirector.open machinery.  
http_request, for example, gets called on all processors 
before, and pre-processes HTTP requests; http_response 
post-processes HTTP responses. 
 
3. <proto>_request methods return request objects, and 
<proto>_response methods return response objects. 
 
4. Even 200 responses get processed. 
 
 
You use it like this: 
 
# just pass processors to build_opener as if they were 
handlers 
opener = build_opener(FooHandler, BarProcessor, 
BazHandler) 
response = opener.open("http://www.example.com/") 
 
I've reimplemented all my stuff (the features listed in the 
first paragraph, above) in terms of this scheme, and it all 
seems to be working fine (but no unit tests yet).  So, the 
scheme does achieve the extensibility it aims for.  The 
patch I've attached here doesn't include most of those 
features -- the only new functionality it adds is an 
HTTPRefererProcessor.  If this gets accepted, I intend to 
submit patches adding new processors for cookie 
handling etc. later. 
 
Two things I'd like to know: 1. will my solution break 
people's code 2. is there a better way? 
 
For 1., I *think* it shouldn't break code. 
 
For 2., the obvious problem with my solution (below) is 
that handlers are pretty similar to my processors already.  
The thing is, I can't see how to reimplement these things 
in terms of handlers.  First, I need to *see* all requests 
(responses) -- I can do that using handlers by giving 
them low (high) .handler_order in Python 2.3 and 
returning None from http_open (http_error_xxx).  
However, 200 responses never get seen by 
http_error_xxx, so that doesn't work (and changing that 
would break old code).  Second, I need to actually 
modify the requests and responses.  Sometimes I'd much 
rather do that by making a new request or response than 
modifying the old one in-place (redirections, for 
example) -- and in general, even if I *am* just modifying 
in-place, I'd still prefer to explictly return the object than 
rely on side-effects.  Perhaps just adding a couple of 
hooks to AbstractHTTPHandler might get these jobs 
done, but I think the increased simplicity of 
AbstractHTTPHandler.do_open and the various 
processors makes my approach worthwhile (assuming it 
actually works & is backwards-compat., of course...). 
 
 
Comments? 
 
 
A few notes: 
 
Some headers (Content-Length, Referer, ...)  mustn't be 
copied to requests for a redirected URL.  This requires 
the addition of a new dict to Request.  I've added an 
add_unredirected_headers method, too.  The old 
implementation just sends these headers directly, but 
that's not possible if you want to use procesors to 
implement these things. 
 
The current response object (httplib.HTTPResponse, 
wrapped with urllib.addinfourl) doesn't include response 
code or message (because code is always 200).  The 
patch just assigns .code and .msg attributes (maybe they 
should be methods, for uniformity with the rest of the 
response interface). 
 
 
Backwards-compatibility notes: 
 
People who override AbstractHTTPHandler.do_open will 
do non-200 response handling there, which will break 
processors, but that's a forwards-compat. issue.  I don't 
think the existence of overridden do_open methods in old 
code should be a problem for backwards-compatibility. 
 
Note that, though processors see all responses, the end 
user still only gets 200 responses returned.  
ErrorProcessor ensures that by passing non-200 
responses on to the existing urllib2 error machinery. 
 
 
John 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 16:40:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 08:40:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-759889 ] Pickling of Random is broken
Message-ID: <E19Upui-0005wH-00@sc8-sf-web4.sourceforge.net>

Bugs item #759889, was opened at 2003-06-24 10: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=759889&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank McIngvale (frankmci)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickling of Random is broken

Initial Comment:
The following shows pickling of Randoms doesn't work in
2.3b1

Python 2.3b1 (#1, Jun 17 2003, 17:56:12)              
                                                
[GCC 2.95.3 20010315 (release)] on linux2             
                                                
Type "help", "copyright", "credits" or "license" for
more information.                                 
>>> import pickle                                     
                                                
>>> import random                                     
                                                
>>> r = random.Random()                               
                                                
>>> pickle.dumps(r)                                   
                                                
Traceback (most recent call last):                    
                                                
  File "<stdin>", line 1, in ?                        
                                                
  File "/usr/lib/python2.3/pickle.py", line 1386, in
dumps                                             
    Pickler(file, protocol, bin).dump(obj)            
                                                
  File "/usr/lib/python2.3/pickle.py", line 231, in
dump                                               
    self.save(obj)                                    
                                                
  File "/usr/lib/python2.3/pickle.py", line 338, in
save                                               
    self.save_reduce(obj=obj, *rv)                    
                                                
  File "/usr/lib/python2.3/pickle.py", line 415, in
save_reduce                                        
    save(args)                                        
                                                
  File "/usr/lib/python2.3/pickle.py", line 293, in
save                                               
    f(self, obj) # Call unbound method with explicit
self                                              
  File "/usr/lib/python2.3/pickle.py", line 576, in
save_tuple                                         
    save(element)                                     
                                                
  File "/usr/lib/python2.3/pickle.py", line 313, in
save                                               
    rv = reduce(self.proto)                           
                                                
  File "/usr/lib/python2.3/copy_reg.py", line 61, in
_reduce_ex                                        
    raise TypeError, "can't pickle %s objects" %
base.__name__                                         
TypeError: can't pickle Random objects                
                                                
>>>                  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759889&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 18:18:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 10:18:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-759889 ] Pickling of Random is broken
Message-ID: <E19UrQo-0002SK-00@sc8-sf-web4.sourceforge.net>

Bugs item #759889, was opened at 2003-06-24 10:40
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759889&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank McIngvale (frankmci)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Pickling of Random is broken

Initial Comment:
The following shows pickling of Randoms doesn't work in
2.3b1

Python 2.3b1 (#1, Jun 17 2003, 17:56:12)              
                                                
[GCC 2.95.3 20010315 (release)] on linux2             
                                                
Type "help", "copyright", "credits" or "license" for
more information.                                 
>>> import pickle                                     
                                                
>>> import random                                     
                                                
>>> r = random.Random()                               
                                                
>>> pickle.dumps(r)                                   
                                                
Traceback (most recent call last):                    
                                                
  File "<stdin>", line 1, in ?                        
                                                
  File "/usr/lib/python2.3/pickle.py", line 1386, in
dumps                                             
    Pickler(file, protocol, bin).dump(obj)            
                                                
  File "/usr/lib/python2.3/pickle.py", line 231, in
dump                                               
    self.save(obj)                                    
                                                
  File "/usr/lib/python2.3/pickle.py", line 338, in
save                                               
    self.save_reduce(obj=obj, *rv)                    
                                                
  File "/usr/lib/python2.3/pickle.py", line 415, in
save_reduce                                        
    save(args)                                        
                                                
  File "/usr/lib/python2.3/pickle.py", line 293, in
save                                               
    f(self, obj) # Call unbound method with explicit
self                                              
  File "/usr/lib/python2.3/pickle.py", line 576, in
save_tuple                                         
    save(element)                                     
                                                
  File "/usr/lib/python2.3/pickle.py", line 313, in
save                                               
    rv = reduce(self.proto)                           
                                                
  File "/usr/lib/python2.3/copy_reg.py", line 61, in
_reduce_ex                                        
    raise TypeError, "can't pickle %s objects" %
base.__name__                                         
TypeError: can't pickle Random objects                
                                                
>>>                  

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 12:18

Message:
Logged In: YES 
user_id=80475

I cannot reproduce the error in Py2.3b1+:

Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import random
>>> import pickle
>>> r = random.Random()
>>> pickle.dumps(r)
'(irandom\nRandom\np0\n(I1\n(I17199\nI25463\nI295
\ntp2\nNtp3\nb.'

The pickling tools had been updated recently and may have 
had a bug that was subsequently fixed.  Will add this to the 
test suite to make sure the bug stays dead.  If the new test 
doesn't provoke failure on some other platform, will mark 
this one as fixed and will close the bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759889&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 18:34:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 10:34:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-759889 ] Pickling of Random is broken
Message-ID: <E19Urgu-0001Cv-00@sc8-sf-web2.sourceforge.net>

Bugs item #759889, was opened at 2003-06-24 10:40
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759889&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank McIngvale (frankmci)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Pickling of Random is broken

Initial Comment:
The following shows pickling of Randoms doesn't work in
2.3b1

Python 2.3b1 (#1, Jun 17 2003, 17:56:12)              
                                                
[GCC 2.95.3 20010315 (release)] on linux2             
                                                
Type "help", "copyright", "credits" or "license" for
more information.                                 
>>> import pickle                                     
                                                
>>> import random                                     
                                                
>>> r = random.Random()                               
                                                
>>> pickle.dumps(r)                                   
                                                
Traceback (most recent call last):                    
                                                
  File "<stdin>", line 1, in ?                        
                                                
  File "/usr/lib/python2.3/pickle.py", line 1386, in
dumps                                             
    Pickler(file, protocol, bin).dump(obj)            
                                                
  File "/usr/lib/python2.3/pickle.py", line 231, in
dump                                               
    self.save(obj)                                    
                                                
  File "/usr/lib/python2.3/pickle.py", line 338, in
save                                               
    self.save_reduce(obj=obj, *rv)                    
                                                
  File "/usr/lib/python2.3/pickle.py", line 415, in
save_reduce                                        
    save(args)                                        
                                                
  File "/usr/lib/python2.3/pickle.py", line 293, in
save                                               
    f(self, obj) # Call unbound method with explicit
self                                              
  File "/usr/lib/python2.3/pickle.py", line 576, in
save_tuple                                         
    save(element)                                     
                                                
  File "/usr/lib/python2.3/pickle.py", line 313, in
save                                               
    rv = reduce(self.proto)                           
                                                
  File "/usr/lib/python2.3/copy_reg.py", line 61, in
_reduce_ex                                        
    raise TypeError, "can't pickle %s objects" %
base.__name__                                         
TypeError: can't pickle Random objects                
                                                
>>>                  

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 12:34

Message:
Logged In: YES 
user_id=80475

Nix that.
I've reproduced the error and will get it fixed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 12:18

Message:
Logged In: YES 
user_id=80475

I cannot reproduce the error in Py2.3b1+:

Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import random
>>> import pickle
>>> r = random.Random()
>>> pickle.dumps(r)
'(irandom\nRandom\np0\n(I1\n(I17199\nI25463\nI295
\ntp2\nNtp3\nb.'

The pickling tools had been updated recently and may have 
had a bug that was subsequently fixed.  Will add this to the 
test suite to make sure the bug stays dead.  If the new test 
doesn't provoke failure on some other platform, will mark 
this one as fixed and will close the bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759889&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 18:49:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 10:49:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-759227 ] improbable __nonzero__ crash
Message-ID: <E19Urv9-0006yi-00@sc8-sf-web1.sourceforge.net>

Bugs item #759227, was opened at 2003-06-23 08:45
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: improbable __nonzero__ crash

Initial Comment:
>>> class X(object):
...   def __nonzero__(self):
...     return self
... 
>>> x=X()
>>> not x
Segmentation fault

This is just a stupid artificial exploit of the fact
that PyObject_IsTrue calls the user-defined __nonzero__
and get a Python object whose truth-value itself is
determined by a call to PyObject_IsTrue.

For old-style classes we check that __nonzero__
actually returned an int. This trick was safe, but no
longer is, because it could be a subclass of int with a
custom __nonzero__ again.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 12:49

Message:
Logged In: YES 
user_id=80475

Preventing mutually recursive calls is probably not worth it.  
Your simple patch does the trick.  Please do add a test case 
for it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 12:01

Message:
Logged In: YES 
user_id=33168

Note: the patch doesn't address a case of mutual recursion
where 2 or more objects are involved.  That could be fixed
by tying the call into the recursion limit.  Not sure how
difficult that is or if it's worth it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 11:58

Message:
Logged In: YES 
user_id=33168

This is also a 2.2.3 problem.  This seems easy enough to fix
(patch attached), but the question is what should the answer
be?  I made it return 1 (true).  Should it be an exception?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 21:07:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 13:07:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-756842 ] Ms VC 2003 not supported
Message-ID: <E19Uu4o-0006nw-00@sc8-sf-web3.sourceforge.net>

Bugs item #756842, was opened at 2003-06-18 21:17
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756842&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Paolo Invernizzi (darkarathorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ms VC 2003 not supported

Initial Comment:
The current msvccompiler.py has no support for Ms
Visual Studio NET 2003 release.
The registry keys are different than the original
VS.NET and NET Framework

File
"d:\repositories\python\dist\src\lib\distutils\msvccompiler.py",
line 114, in set_macro
    self.macros["$(%s)" % macro] = d[key]
KeyError: 'sdkinstallroot'


---
Paolo Invernizzi

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-24 20:07

Message:
Logged In: YES 
user_id=31392

Paolo mentioned this recipe in private email.

The problems are some little changes is some keys in registry...
The MSVS is reported as 7.1, and at line 118 is turned to:
- vsbase = r"Software\Microsoft\VisualStudio\%s.0" % version
+ vsbase = r"Software\Microsoft\VisualStudio\%s.1" % version

The .NET framework is the 1.1,  and line 123 is:
- self.set_macro("FrameworkSDKDir", net, "sdkinstallroot")
+ self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv1.1")

Note that the installation of VC71 *wants* this SDK, not the
old 1.0, so 
there is no confusion...
VC7 -> SDK 1.0
VC71 -> SDK 1.1


----------------------------------------------------------------------

Comment By: Paolo Invernizzi (darkarathorn)
Date: 2003-06-23 07:58

Message:
Logged In: YES 
user_id=172594

__revision__ = "$Id: msvccompiler.py,v 1.56 2003/05/14
19:48:57 lemburg Exp $"


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 13:48

Message:
Logged In: YES 
user_id=21627

What version of msvccompiler.py are you using? Specifically,
what is its __revision__?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756842&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 21:12:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 13:12:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-759227 ] improbable __nonzero__ crash
Message-ID: <E19Uu9D-0004qg-00@sc8-sf-web1.sourceforge.net>

Bugs item #759227, was opened at 2003-06-23 13:45
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: improbable __nonzero__ crash

Initial Comment:
>>> class X(object):
...   def __nonzero__(self):
...     return self
... 
>>> x=X()
>>> not x
Segmentation fault

This is just a stupid artificial exploit of the fact
that PyObject_IsTrue calls the user-defined __nonzero__
and get a Python object whose truth-value itself is
determined by a call to PyObject_IsTrue.

For old-style classes we check that __nonzero__
actually returned an int. This trick was safe, but no
longer is, because it could be a subclass of int with a
custom __nonzero__ again.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-24 20:12

Message:
Logged In: YES 
user_id=31392

I think this patch is too specialized.  It only handles the
contrived case that Armin reported.  It's possible to get
unbounded recursion in a variety of ways.  I don't see why
we should patch the code to deal with a single one.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 17:49

Message:
Logged In: YES 
user_id=80475

Preventing mutually recursive calls is probably not worth it.  
Your simple patch does the trick.  Please do add a test case 
for it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 17:01

Message:
Logged In: YES 
user_id=33168

Note: the patch doesn't address a case of mutual recursion
where 2 or more objects are involved.  That could be fixed
by tying the call into the recursion limit.  Not sure how
difficult that is or if it's worth it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 16:58

Message:
Logged In: YES 
user_id=33168

This is also a 2.2.3 problem.  This seems easy enough to fix
(patch attached), but the question is what should the answer
be?  I made it return 1 (true).  Should it be an exception?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 21:30:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 13:30:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-759889 ] Pickling of Random is broken
Message-ID: <E19UuQa-0005Zw-00@sc8-sf-web1.sourceforge.net>

Bugs item #759889, was opened at 2003-06-24 10:40
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759889&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Frank McIngvale (frankmci)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Pickling of Random is broken

Initial Comment:
The following shows pickling of Randoms doesn't work in
2.3b1

Python 2.3b1 (#1, Jun 17 2003, 17:56:12)              
                                                
[GCC 2.95.3 20010315 (release)] on linux2             
                                                
Type "help", "copyright", "credits" or "license" for
more information.                                 
>>> import pickle                                     
                                                
>>> import random                                     
                                                
>>> r = random.Random()                               
                                                
>>> pickle.dumps(r)                                   
                                                
Traceback (most recent call last):                    
                                                
  File "<stdin>", line 1, in ?                        
                                                
  File "/usr/lib/python2.3/pickle.py", line 1386, in
dumps                                             
    Pickler(file, protocol, bin).dump(obj)            
                                                
  File "/usr/lib/python2.3/pickle.py", line 231, in
dump                                               
    self.save(obj)                                    
                                                
  File "/usr/lib/python2.3/pickle.py", line 338, in
save                                               
    self.save_reduce(obj=obj, *rv)                    
                                                
  File "/usr/lib/python2.3/pickle.py", line 415, in
save_reduce                                        
    save(args)                                        
                                                
  File "/usr/lib/python2.3/pickle.py", line 293, in
save                                               
    f(self, obj) # Call unbound method with explicit
self                                              
  File "/usr/lib/python2.3/pickle.py", line 576, in
save_tuple                                         
    save(element)                                     
                                                
  File "/usr/lib/python2.3/pickle.py", line 313, in
save                                               
    rv = reduce(self.proto)                           
                                                
  File "/usr/lib/python2.3/copy_reg.py", line 61, in
_reduce_ex                                        
    raise TypeError, "can't pickle %s objects" %
base.__name__                                         
TypeError: can't pickle Random objects                
                                                
>>>                  

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 15:30

Message:
Logged In: YES 
user_id=80475

Fixed.
See Lib/random.py 1.51 and Lib/test/test_random.py 1.12

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 12:34

Message:
Logged In: YES 
user_id=80475

Nix that.
I've reproduced the error and will get it fixed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 12:18

Message:
Logged In: YES 
user_id=80475

I cannot reproduce the error in Py2.3b1+:

Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import random
>>> import pickle
>>> r = random.Random()
>>> pickle.dumps(r)
'(irandom\nRandom\np0\n(I1\n(I17199\nI25463\nI295
\ntp2\nNtp3\nb.'

The pickling tools had been updated recently and may have 
had a bug that was subsequently fixed.  Will add this to the 
test suite to make sure the bug stays dead.  If the new test 
doesn't provoke failure on some other platform, will mark 
this one as fixed and will close the bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759889&group_id=5470


From noreply@sourceforge.net  Tue Jun 24 21:58:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 24 Jun 2003 13:58:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE
Message-ID: <E19Uus0-00088f-00@sc8-sf-web2.sourceforge.net>

Bugs item #430160, was opened at 2001-06-05 02:09
Message generated for change (Comment added) made by weoweo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470

Category: Windows
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Steve Holden (holdenweb)
Summary: CGIHTTPServer.py POST bug using IE

Initial Comment:
>From the readme included in the zip:
This set of files shows a bug that occurs when doing 
POST requests via the CGIHTTPServer.py module in 
Python 2.1 The testpost.html file when accessed via 
Internet Explorer 5.5 from webserver.py should show 
this bug. On short POST requests IE will end up doing 
a second POST and then displaying an error message 
while longer POSTs will be followed by a second POST 
and then a GET.

The problem appears to be specific to the interaction 
of IE and the handling of windows sockets in Python in 
the CGIHTTPServer.py module which relies on 
BaseHTTPServer.py, SocketServer.py...

posttestwebserver.py is currently setup to use 
C:\tmp\testpost as the document root, so either move 
the "testpost" folder to C:\tmp or change the 
directory to wherever the testpost folder is located. 
Start the server using the .bat file and bring 
up .html page with something like:
  http://localhost/testpost.html

The bug should occur when you try:
  Test short CGI response with POST
or
  Test long CGI response with POST

The other requests should work fine. The bug will 
occur regardless of whether IE is set to use HTTP/1.0 
or HTTP/1.1. The bug doesn't appear to occur when 
going through a simple proxy. You can also get the bug 
to occur using a remote IE client (either on a LAN or 
over the Net). In addition, it doesn't appear to 
matter whether running with unbuffered binary pipes 
(python -u) or not. I also tested against my modified 
CGIHTTPServer.py See the bug I posted at:
http://sourceforge.net/tracker/?
func=detail&atid=105470&aid=427345&group_id=5470

My configuration:
Windows 2000 Pro, SP2
AMD 1.2GHz
256MB RAM
ActiveStatet Python 2.1 (build 210)
Internet Explorer 5.5 (5.50.4522.1800)

ka
---
Mark Lutz said:
"FWIW, I noticed today (in between lecturing a class) 
that on Windows, Python actually uses a special Python-
coded socket.py library module, not the standard C-
coded socket extension module.  socket.py lives in the 
library directory; it does unique things for closes 
and deletes that may not make sense in all cases 
(e.g., the makefile call generates a class instance, 
not a true file object).  It may also be trying to 
close the underlying socket twice.  I don't have"


----------------------------------------------------------------------

Comment By: Wolfgang Ocker (weoweo)
Date: 2003-06-24 22:58

Message:
Logged In: YES 
user_id=23630

The patch might cause the server to loop endlessly, if the
client has closed the connection. I suggest to change the
patch as follows:

   while select.select([self.rfile], [], [], 0)[0]:
-    waste = self.rfile.read(1)

to

   while select.select([self.rfile], [], [], 0)[0]:
+    if not self.rfile.read(1): break

Maybe this is necessary for the Windows case as well ...

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2003-01-08 19:58

Message:
Logged In: YES 
user_id=88157

Should be fixed by patch 654910 committed today.

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-16 04:25

Message:
Logged In: YES 
user_id=88157

This patch appears to fix the basic CGIHTTPServer behavior, 
at least for Unix and Wiondows platforms, but I'm not yet 
confident of its robustness in the face of Forking or threading 
mixin code. More later ...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 16:57

Message:
Logged In: YES 
user_id=6380

Steve, I'm assigning this bug to you. Feel free to check in
a fix if you think one exists (as long as it doesn't break
on Unix).

----------------------------------------------------------------------

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 21:49

Message:
Logged In: YES 
user_id=247536

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.

not sure what the real fix for this should be?


----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 13:28

Message:
Logged In: YES 
user_id=88157

Please note that I have observed this behavior on Windows
98 using Python 2.0 (#8, Mar  7 2001, 16:04:37) [MSC 32 bit 
(Intel)] using the same build of IE, so it is not a Win2k-
specific problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 14:07:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 06:07:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-654766 ] asyncore.py and "handle_expt"
Message-ID: <E19V9ze-0007dQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #654766, was opened at 2002-12-16 19:42
Message generated for change (Settings changed) made by jcea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654766&group_id=5470

Category: Python Library
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jesús Cea Avión (jcea)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore.py and "handle_expt"

Initial Comment:
Python 2.2.2 here.

Asyncore.py doesn't invoke "handle_expt" ever
("handle_expt" is documented in docs). Managing OOB
data is imprescindible to handle "connection refused"
errors in Windows, for example.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654766&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 14:11:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 06:11:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-760475 ] asyncore.py and "handle_error"
Message-ID: <E19VA3c-0001ua-00@sc8-sf-web1.sourceforge.net>

Bugs item #760475, was opened at 2003-06-25 15: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=760475&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jesús Cea Avión (jcea)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore.py and "handle_error"

Initial Comment:
When an uncached exception arises in "asyncore", the
method "handle_error" is called. This method calls
"self.close()" when it MUST call "self.handle_close()",
in order to support correctly the "delegation" design
pattern, for example.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760475&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 15:30:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 07:30:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19VBI2-0005iU-00@sc8-sf-web1.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 17:44
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 09:30

Message:
Logged In: YES 
user_id=80475

Can this be closed?

----------------------------------------------------------------------

Comment By: mark lee smith (netytan)
Date: 2003-06-11 17:36

Message:
Logged In: YES 
user_id=797196

Will do, I'll try run the script from my box upstairs and one at 
work. Thanks for all your help, at least it's sending email, be it 
you need to send "^D" in that example but with a little 
reworking it should be a problem. Thank's again.

P.S let's blame Microsoft, never did like them, so dodgy lol. If 
I could get away from Windows I would but unfortunatly it's a 
commercial standard.. Ta

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-11 16:36

Message:
Logged In: YES 
user_id=31435

I don't hold out much hope that this will get resolved.  
Windows has tons of bugs (a lot more than Python!), and it's 
not uncommon to find a program (Python-based or otherwise) 
that fails on only one specific Windows box in the world.  For 
example, you could have a corrupted bit in any of the 
thousand Windows DLLs on your box, or you may simply be 
behind in running Windows Update.  Other possibilities include 
that you're running a virus checker (those often interfere with 
normal program operations), or are behind an improperly 
written firewall.

So long as your report is the only one of this nature, there's 
really no hope for resolving it short you digging into it.  I don't 
see any evidence of a bug in Python here (worse, a crash in a 
core OS DLL is prima facia evidence of a bug in the OS!).

If you can, try running the same thing on a friend's Windows 
box.  I bet you won't have any problem there.

----------------------------------------------------------------------

Comment By: mark lee smith (netytan)
Date: 2003-06-11 16:22

Message:
Logged In: YES 
user_id=797196

Ok, I ran your file and it returned the same as when I ran 
mine,  both crashed the Kernal. I think the reason that the 
mail wasn't being sent before was that I forgot to finish the 
message with "^D" although the main problem remains, what 
is the Kernal crashing out :S..  

----------------------------------------------------------------------

Comment By: mark lee smith (netytan)
Date: 2003-06-11 15:53

Message:
Logged In: YES 
user_id=797196

Hi, I've replicated what had before exactly, the win32 Kernal 
still crashes but the mail is delivered :S, don't ask me why it 
sends now and didn't before, nothing has changed to my 
knowlage.. Anyway if I've done this right it should be 
attached to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 18:47

Message:
Logged In: YES 
user_id=31435

Just attaching tcap.txt.  Note that on Windows, you have to 
end the msg with Ctrl-Z (not the Unixish Ctrl-D in the example 
comments).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 18:45

Message:
Logged In: YES 
user_id=31435

I'll show you what I'm looking for:  attached is the exact code 
I just ran, in smtpex.py, and a screen dump from running it, in 
tcap.txt.  I changed the example to use comcast.net's SMTP 
server.  It worked fine for me on Win98SE.  I was using 
Python 2.2.3, and don't know whether that makes a 
difference.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 18:39

Message:
Logged In: YES 
user_id=31435

I don't understand.  If you're not running an SMTP server on 
localhost, I expect that example to die with

socket.error: (10061, 'Connection refused')

And indeed, that's what it does when I try it on Win98SE.  So 
I conclude you must have changed the example in some way.  
If so, the solution to your problem will be found in the details 
of you changed it.  Nobody can guess that, so please attach 
the code you actually ran.

----------------------------------------------------------------------

Comment By: mark lee smith (netytan)
Date: 2003-06-09 18:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 17:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 15:49:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 07:49:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-757520 ] irreproducable segfault on int(1e100)
Message-ID: <E19VBaP-0005pm-00@sc8-sf-web3.sourceforge.net>

Bugs item #757520, was opened at 2003-06-19 16:19
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757520&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: irreproducable segfault on int(1e100)

Initial Comment:
Segmentation Fault:

 20 >>> i
1e+100
 21 >>> int(i)Segmentation fault
23:16:12:2:gerrit@stopcontact:~/downl$ python
Python 2.3b1+ (#3, Jun 19 2003, 10:34:37)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> i=1e100
  1 >>> int(i)Segmentation fault
23:16:21:2:gerrit@stopcontact:~/downl$ python
Python 2.3b1+ (#3, Jun 19 2003, 10:34:37)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> i=1e100
  1 >>> int(i)
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104L

I'm unable to reproduce this (sorry). I noticed before
that sometimes, the interactive Python interpreter
segfaults irreproducable: only now, it was two times in
succession but not more than two times. I never
encounered this problem while executing Python programs
from scripts.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 09:49

Message:
Logged In: YES 
user_id=80475

Under Windows compiled by MSVC++, I've run this hundred 
thousand times in a loop without a failure. I tried it in a 
script and using the interpreter, so it does appear to be 
specific to gcc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 08:44

Message:
Logged In: YES 
user_id=21627

I suspect this is a bug in the C library. To find out for
sure, one would have to study the relevant assembler code in
glibc in detail.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757520&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 16:00:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 08:00:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-757520 ] irreproducable segfault on int(1e100)
Message-ID: <E19VBl9-0007TY-00@sc8-sf-web1.sourceforge.net>

Bugs item #757520, was opened at 2003-06-19 23:19
Message generated for change (Comment added) made by gerrit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757520&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: irreproducable segfault on int(1e100)

Initial Comment:
Segmentation Fault:

 20 >>> i
1e+100
 21 >>> int(i)Segmentation fault
23:16:12:2:gerrit@stopcontact:~/downl$ python
Python 2.3b1+ (#3, Jun 19 2003, 10:34:37)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> i=1e100
  1 >>> int(i)Segmentation fault
23:16:21:2:gerrit@stopcontact:~/downl$ python
Python 2.3b1+ (#3, Jun 19 2003, 10:34:37)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
  0 >>> i=1e100
  1 >>> int(i)
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104L

I'm unable to reproduce this (sorry). I noticed before
that sometimes, the interactive Python interpreter
segfaults irreproducable: only now, it was two times in
succession but not more than two times. I never
encounered this problem while executing Python programs
from scripts.


----------------------------------------------------------------------

>Comment By: Gerrit Holl (gerrit)
Date: 2003-06-25 17:00

Message:
Logged In: YES 
user_id=13298

Interestingly, the problem does not occur within a script
here, too. Maybe it is in the readline library or something
like that. Pressing <shift>-<Enter> always segfaults for me
(known readline bug). This is the same as <Escape>-O-<Enter>
and the same problem is in Ruby and sh, so this is a
readline bug.  I think this because [int(1e100) for i in
xrange(1000000)] works fine, also on the interactive prompt.
Hmm, would there be a way to test this hypotesis?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 16:49

Message:
Logged In: YES 
user_id=80475

Under Windows compiled by MSVC++, I've run this hundred 
thousand times in a loop without a failure. I tried it in a 
script and using the interpreter, so it does appear to be 
specific to gcc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-21 15:44

Message:
Logged In: YES 
user_id=21627

I suspect this is a bug in the C library. To find out for
sure, one would have to study the relevant assembler code in
glibc in detail.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757520&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 16:13:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 08:13:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-757822 ] Additional index items, other minor details
Message-ID: <E19VBxk-0000mK-00@sc8-sf-web2.sourceforge.net>

Bugs item #757822, was opened at 2003-06-20 06:31
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757822&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: Additional index items, other minor details

Initial Comment:
It seems that various recent language changes have not
made it into any of the indices (super, property,
__slots__, ...).

LibRef:

3.14, first paragraph, last sentence unfinished "...to
avoid confusing."

3.3, first paragraph after XXX:  "Not all objects can
be weakly referenced; those objects which do include
class instances,..."


If I get around to it myself, will try to submit
patches for above :).

Thanks...

Mark

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 10:13

Message:
Logged In: YES 
user_id=80475

super(), property(), classmethod(), object(), staticmethod() 
are now all in the index.  They automatically make it there 
when their functions were documented.

Sadly, __slots__ is not indexed because it is not yet 
documented.

Fixed paragraph 3.14.  See Doc/lib/libpickle.tex 1.42

For paragraph 3.3, it isn't clear what you want changed.  
Please let me know so we can clear this bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757822&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 16:17:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 08:17:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-757821 ] logging module docs
Message-ID: <E19VC1u-0008Qc-00@sc8-sf-web1.sourceforge.net>

Bugs item #757821, was opened at 2003-06-20 06:29
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757821&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module docs

Initial Comment:
http://www.python.org/dev/doc/devel/lib/node297.html

It should be mentioned that it is necessary to import 
"logging.config" to call fileConfig().  The explanation
does not mention the config module so it is confusing
when people try:

import logging
logging.fileConfig(...)



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 10:17

Message:
Logged In: YES 
user_id=80475

Forwarded to Vinay Sajip for comment and repair.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757821&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 16:20:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 08:20:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-758239 ] socket timeout exception unhelpful
Message-ID: <E19VC4I-00008g-00@sc8-sf-web1.sourceforge.net>

Bugs item #758239, was opened at 2003-06-20 20:27
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758239&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Halley (rthalley)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: socket timeout exception unhelpful

Initial Comment:
The new settimeout feature for sockets is great, but
the exception that is raised on timeout, socket.error,
is not very helpful.  It's not
possible to write code which catches and deals with
timeouts as opposed to the multitude of other socket
errors.

Even looking at the additional detail isn't helpful,
because you get errnos like EINPROGRESS or EAGAIN,
because the socket code doesn't deal with timeouts
explicitly when it selects.  Rather, it just lets the
internal_select() return, and then you get an error
when whatever was doing the waiting tries to do its
operation.

I propose that a new exception:

class socket.timeout(socket.error):
    pass

be created, and raised whenever the internal_select
times out (i.e. select() returns 0).

This lets applications catch socket.timeout
specifically if they want to, but also allows existing
code to catch socket.error and get all socket-related
exceptions.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 10:20

Message:
Logged In: YES 
user_id=80475

I agree this would be a useful API change.

Guido, do you concur?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758239&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 16:27:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 08:27:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-744841 ] Python-Profiler bug: Bad call
Message-ID: <E19VCBi-0001XK-00@sc8-sf-web2.sourceforge.net>

Bugs item #744841, was opened at 2003-05-28 06:02
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744841&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Dieter Maurer (dmaurer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-Profiler bug: Bad call

Initial Comment:
There is a timing problem between the call of 
"call_trace(profile_func,...,'return',...)" and 
"reset_exc_info" in Pythons main interpreter loop.

The main loop first calls "call_trace" (at the end of
function execution). With the
standard "profile.Profile" profiler this leads to a pop
of the current frame from the profiler stack while
the current frame is still on the interpreter stack.
Then "reset_exc_info" is called. When this call releases 
an instance with a destructor ("__del__" method), the 
"call_trace(profile_func,...'call',...)" for the destructor 
observes the inconsistency between the profiler and the 
interpreter stack and raises a "Bad call" exception. This 
exception disables profiling effectively. However, the 
exception is later ignored (as we are in a destructor) and 
program execution continues. When the profiling is later 
finished, all time after the exception is accounted for the 
last function, that was on top of the profiler stack when 
profiling was disabled. This can be extremely confusing.

The attached script reproduces the problem. Run it 
through the Python interpreter. When you see an 
"Exception Bad call ... ignored", the interpreter has the 
described problem. We observed the problem in Python 
2.1.3
(on Linux, Solaris and Windows).


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 10:27

Message:
Logged In: YES 
user_id=80475

I've run your script on Py2.2.3 and 2.3b1+ and did not 
observe "Exception Bad cad ... ignored".

Marking this one as already fixed.

----------------------------------------------------------------------

Comment By: Dieter Maurer (dmaurer)
Date: 2003-06-06 03:23

Message:
Logged In: YES 
user_id=265829

Apparently, a colleague observed the bug also in Python 2.2.2.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-28 19:01

Message:
Logged In: YES 
user_id=33168

The good news is that this has been fixed in Python 2.2.x
and beyond.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744841&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 18:43:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 10:43:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-760657 ] Tutorial: executable scripts on Windows
Message-ID: <E19VEJG-0003tV-00@sc8-sf-web4.sourceforge.net>

Bugs item #760657, was opened at 2003-06-25 13: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=760657&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial: executable scripts on Windows

Initial Comment:
The tutorial section "Executable Python Scripts" should
include information on making Python scripts directly
executable on Windows:

1.  Add .py to some environment variable
2.  Associate interpreter with running .py files (???)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760657&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 19:11:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 11:11:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-760475 ] asyncore.py and "handle_error"
Message-ID: <E19VEkN-0000Ze-00@sc8-sf-web1.sourceforge.net>

Bugs item #760475, was opened at 2003-06-25 13:11
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760475&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jesús Cea Avión (jcea)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore.py and "handle_error"

Initial Comment:
When an uncached exception arises in "asyncore", the
method "handle_error" is called. This method calls
"self.close()" when it MUST call "self.handle_close()",
in order to support correctly the "delegation" design
pattern, for example.



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-25 18:11

Message:
Logged In: YES 
user_id=31392

Can you expand on your comments.  I don't know what the
delegation design pattern you refer to is.  Can you provide
an example of why it is necessary that asyncore not call
close()?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760475&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 19:43:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 11:43:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-683486 ] Tutorial: info on Source Code Encoding is missing
Message-ID: <E19VFEn-0006RN-00@sc8-sf-web4.sourceforge.net>

Bugs item #683486, was opened at 2003-02-09 12:50
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683486&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Roman Suzi (rnd0110)
>Assigned to: Martin v. Löwis (loewis)
Summary: Tutorial: info on Source Code Encoding is missing

Initial Comment:
(I propose to add information into Tutorial on how
to specify source code encoding. Please correct
my English and maybe there is better way to 
get a list of possible encodings)



2.2.2  Executable Python Scripts 

...

2.2.3 Source Code Encoding

   It is possible to use encodings different than ASCII
in Python
   source files. The best way to do it is to put one more
   special comment line right after #!-line making
proper encoding
   declaration:
  
# -*- coding: latin-1 -*-

   After that, all characters in the source file will
be treated
   as belonging to latin-1 encoding, and it will be
possible
   to directly write Unicode strings in the selected
encoding.

   List of possible encodings could be found in the
encodings
   subdirectory of Python directory.

   Significant advantage could be had if using utf-8
encoding,
   as it allows to use letters from many languages in
the same
   file.

2.2.4

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 13:43

Message:
Logged In: YES 
user_id=80475

Martin, I think something like the above wording should be 
added to the tutorial.  Do you have any wording suggestions?

* Instead of latin-1, it should list the ISO number.
* The encodings directory is a subdirectory of Lib.
* The last paragraph should be replaced and instead make 
your recommendation to arrange IDLE so that it
always stores files as UTF-8 with BOM.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683486&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 19:57:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 11:57:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-760703 ] SocketHandler and LogRecord don't work well together
Message-ID: <E19VFS3-0001jZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #760703, was opened at 2003-06-25 12:56
Message generated for change (Settings changed) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
>Summary: SocketHandler and LogRecord don't work well together

Initial Comment:
>From the logging module, I'm using the DatagramHandler 
(or SocketHandler) to send log messages via UDP 665.  
When I receive them on the other side, there's no 
elegant way to reconstruct them on the other side.  For 
example,

--- in one python session ---
>>> import logging, logging.handlers
>>> handler = logging.handlers.DatagramHandler
( 'localhost', 695 )
>>> logging.root.addHandler( handler )
>>> logging.root.info( 'test' )

--- and in another ---
>>> from socket import *
>>> import pickle, logging
>>> s = socket( AF_INET, SOCK_DGRAM )
>>> s.bind( ( '', 695 ) )
>>> rec = s.recv( 32768 )[4:] #ignore length for now
>>> rec = pickle.loads( rec )
>>> type( rec )
<type 'dict'>
>>> newRec = logging.LogRecord( '', '', '', 1, '', (), None )
>>> newRec.__dict__ = rec

Because logging.LogRecord is not a dict or derived from 
dict, I have to create a log record using 7 arguments, 
then assign the unpickled dict... which is not pretty to 
say the least.

Furthermore, the documentation dictates that the 
record is pickled, not the record's __dict__.

I changed line 163 in logging.handlers to:
        s = cPickle.dumps( record, 1 )
from
        s = cPickle.dumps(record.__dict__, 1)

And I think this is the way it should be done, both to be 
consistent with the documentation, and to make 
reconstruction on the far end more elegant and intuitive.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 19:56:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 11:56:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-760703 ] SocketHandler and LogRecord don't work well
Message-ID: <E19VFRH-0001h5-00@sc8-sf-web3.sourceforge.net>

Bugs item #760703, was opened at 2003-06-25 12: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=760703&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketHandler and LogRecord don't work well

Initial Comment:
>From the logging module, I'm using the DatagramHandler 
(or SocketHandler) to send log messages via UDP 665.  
When I receive them on the other side, there's no 
elegant way to reconstruct them on the other side.  For 
example,

--- in one python session ---
>>> import logging, logging.handlers
>>> handler = logging.handlers.DatagramHandler
( 'localhost', 695 )
>>> logging.root.addHandler( handler )
>>> logging.root.info( 'test' )

--- and in another ---
>>> from socket import *
>>> import pickle, logging
>>> s = socket( AF_INET, SOCK_DGRAM )
>>> s.bind( ( '', 695 ) )
>>> rec = s.recv( 32768 )[4:] #ignore length for now
>>> rec = pickle.loads( rec )
>>> type( rec )
<type 'dict'>
>>> newRec = logging.LogRecord( '', '', '', 1, '', (), None )
>>> newRec.__dict__ = rec

Because logging.LogRecord is not a dict or derived from 
dict, I have to create a log record using 7 arguments, 
then assign the unpickled dict... which is not pretty to 
say the least.

Furthermore, the documentation dictates that the 
record is pickled, not the record's __dict__.

I changed line 163 in logging.handlers to:
        s = cPickle.dumps( record, 1 )
from
        s = cPickle.dumps(record.__dict__, 1)

And I think this is the way it should be done, both to be 
consistent with the documentation, and to make 
reconstruction on the far end more elegant and intuitive.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 20:06:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 12:06:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-760703 ] SocketHandler and LogRecord don't work well together
Message-ID: <E19VFb5-0002AS-00@sc8-sf-web3.sourceforge.net>

Bugs item #760703, was opened at 2003-06-25 13:56
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketHandler and LogRecord don't work well together

Initial Comment:
>From the logging module, I'm using the DatagramHandler 
(or SocketHandler) to send log messages via UDP 665.  
When I receive them on the other side, there's no 
elegant way to reconstruct them on the other side.  For 
example,

--- in one python session ---
>>> import logging, logging.handlers
>>> handler = logging.handlers.DatagramHandler
( 'localhost', 695 )
>>> logging.root.addHandler( handler )
>>> logging.root.info( 'test' )

--- and in another ---
>>> from socket import *
>>> import pickle, logging
>>> s = socket( AF_INET, SOCK_DGRAM )
>>> s.bind( ( '', 695 ) )
>>> rec = s.recv( 32768 )[4:] #ignore length for now
>>> rec = pickle.loads( rec )
>>> type( rec )
<type 'dict'>
>>> newRec = logging.LogRecord( '', '', '', 1, '', (), None )
>>> newRec.__dict__ = rec

Because logging.LogRecord is not a dict or derived from 
dict, I have to create a log record using 7 arguments, 
then assign the unpickled dict... which is not pretty to 
say the least.

Furthermore, the documentation dictates that the 
record is pickled, not the record's __dict__.

I changed line 163 in logging.handlers to:
        s = cPickle.dumps( record, 1 )
from
        s = cPickle.dumps(record.__dict__, 1)

And I think this is the way it should be done, both to be 
consistent with the documentation, and to make 
reconstruction on the far end more elegant and intuitive.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 14:06

Message:
Logged In: YES 
user_id=80475

Referred to Vinay Sajip.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 20:04:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 12:04:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-696777 ] How to make a class iterable using a member generator.
Message-ID: <E19VFZT-00026C-00@sc8-sf-web3.sourceforge.net>

Bugs item #696777, was opened at 2003-03-03 14:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696777&group_id=5470

Category: Documentation
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: How to make a class iterable using a member generator.

Initial Comment:
This should probably go at the end of 2.2.5 (LibRef). [I 
was trying all possible variations of __iter__ returning 
self, with next() as a method...]

"""If you are designing a class that should be iterable, 
i.e. you want to be able to say "for x in myClass:...", 
and, you also want the convenience of using a member 
function that is a generator to provide the items, your 
class' __iter__() method should return "self.myGenerator
(self)". The object returned from this call is an iterator-
generator that implements both of the required __iter__() 
and next() methods.

Example:
   class Range10:
       def __init__(self): self.scale = 5
       def __iter__(self):
           return Range10.generateItems(self)
       def generateItems(self):
           for i in range(10): yield i * self.scale

There are a couple of subtleties here. First, only "user-
defined functions" are converted to methods when 
accessed through a class or instance, i.e.myObject.foo
() will extract the foo function wrap it up as a method 
object, insert myObject in the argument list and call it 
(LibRef: 3.2/Callable types/User-defined methods). 
[thanks to Alex M. for clarifying this issue for me]

This automatic conversion does not happen for any 
other type of objects defined inside class scope. In our 
case, generateItems() will be a generator-iterator, i.e. 
not a "user-defined function". Thus the conversion to an 
instance method does not happen, and it is left as a 
static method of the class. [this seems like it might be 
a bug to me...].

To get around this irregularity, make sure your __iter__() 
calls generateItems() as a static method, and explictly 
passes self.
"""

-- bjorn


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 14:04

Message:
Logged In: YES 
user_id=80475

Expanded the docs as requested (though much more tersely 
worded).  See Doc/lib/libstdtypes.tex 1.128.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-03-09 12:57

Message:
Logged In: YES 
user_id=593130

As others have posted (with examples) on both c.l.py and 
py-dev, it is both possible and simpler to write __init__ 
itself as a generator function, thereby returning a 
generator-iterator object with the requisite __init_() and 
next() methods.. Since this does not seem to be obvious to 
many people, I would agree that *this* should be 
mentioned in the docs.  All the rest of the discussion about 
access and static methods is irrelevant for this purpose.

>>> from __future__ import generators
>>> class Range10:
...   def __init__(self,scale):
...     self.scale = scale
...   def __iter__(self):
...     scale = self.scale
...     for i in range(10): yield i * scale
...
>>> for i in Range10(4):
...   print i
...
0
4
8
12
16
20
24
28
32
36


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696777&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 20:09:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 12:09:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-760657 ] Tutorial: executable scripts on Windows
Message-ID: <E19VFdo-0002JG-00@sc8-sf-web3.sourceforge.net>

Bugs item #760657, was opened at 2003-06-25 12:43
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760657&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial: executable scripts on Windows

Initial Comment:
The tutorial section "Executable Python Scripts" should
include information on making Python scripts directly
executable on Windows:

1.  Add .py to some environment variable
2.  Associate interpreter with running .py files (???)

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 14:09

Message:
Logged In: YES 
user_id=80475

The procedure varies amoung the different flavors of 
Windows.  On NT, .py can be listed as an executable 
extension.  For all the flavors, the installer updates the 
registry with helps for clicking on file names to get them to 
run but does nothing for command line usage.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760657&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 21:20:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 13:20:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-751612 ] smtplib crashes Windows Kernal.
Message-ID: <E19VGlB-0002l7-00@sc8-sf-web4.sourceforge.net>

Bugs item #751612, was opened at 2003-06-09 22:44
Message generated for change (Comment added) made by netytan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib crashes Windows Kernal.

Initial Comment:
When trying to use the smtplib module (or modules 
which use smtplib i.e. email) the Windows Kenal crashes 
without sending the email. I'm trying to send the email 
through an external mail server but I imagine the problem 
would still exist if I was using a local mailserver.

----------------------------------------------------------------------

>Comment By: mark lee smith (netytan)
Date: 2003-06-25 20:20

Message:
Logged In: YES 
user_id=797196

If you mean the error message "..caused an error in..Windows 
Kernal", you can click ok and it closes most of the time, other 
times the whole machine bails. I've tested it now on Windows 
XP pro and home and it sends straight through. I'm gonna try 
get hold of a 98 box so I can test it but it seems to be just 
my ME box at the moment.

Mark

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 14:30

Message:
Logged In: YES 
user_id=80475

Can this be closed?

----------------------------------------------------------------------

Comment By: mark lee smith (netytan)
Date: 2003-06-11 22:36

Message:
Logged In: YES 
user_id=797196

Will do, I'll try run the script from my box upstairs and one at 
work. Thanks for all your help, at least it's sending email, be it 
you need to send "^D" in that example but with a little 
reworking it should be a problem. Thank's again.

P.S let's blame Microsoft, never did like them, so dodgy lol. If 
I could get away from Windows I would but unfortunatly it's a 
commercial standard.. Ta

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-11 21:36

Message:
Logged In: YES 
user_id=31435

I don't hold out much hope that this will get resolved.  
Windows has tons of bugs (a lot more than Python!), and it's 
not uncommon to find a program (Python-based or otherwise) 
that fails on only one specific Windows box in the world.  For 
example, you could have a corrupted bit in any of the 
thousand Windows DLLs on your box, or you may simply be 
behind in running Windows Update.  Other possibilities include 
that you're running a virus checker (those often interfere with 
normal program operations), or are behind an improperly 
written firewall.

So long as your report is the only one of this nature, there's 
really no hope for resolving it short you digging into it.  I don't 
see any evidence of a bug in Python here (worse, a crash in a 
core OS DLL is prima facia evidence of a bug in the OS!).

If you can, try running the same thing on a friend's Windows 
box.  I bet you won't have any problem there.

----------------------------------------------------------------------

Comment By: mark lee smith (netytan)
Date: 2003-06-11 21:22

Message:
Logged In: YES 
user_id=797196

Ok, I ran your file and it returned the same as when I ran 
mine,  both crashed the Kernal. I think the reason that the 
mail wasn't being sent before was that I forgot to finish the 
message with "^D" although the main problem remains, what 
is the Kernal crashing out :S..  

----------------------------------------------------------------------

Comment By: mark lee smith (netytan)
Date: 2003-06-11 20:53

Message:
Logged In: YES 
user_id=797196

Hi, I've replicated what had before exactly, the win32 Kernal 
still crashes but the mail is delivered :S, don't ask me why it 
sends now and didn't before, nothing has changed to my 
knowlage.. Anyway if I've done this right it should be 
attached to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:47

Message:
Logged In: YES 
user_id=31435

Just attaching tcap.txt.  Note that on Windows, you have to 
end the msg with Ctrl-Z (not the Unixish Ctrl-D in the example 
comments).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:45

Message:
Logged In: YES 
user_id=31435

I'll show you what I'm looking for:  attached is the exact code 
I just ran, in smtpex.py, and a screen dump from running it, in 
tcap.txt.  I changed the example to use comcast.net's SMTP 
server.  It worked fine for me on Win98SE.  I was using 
Python 2.2.3, and don't know whether that makes a 
difference.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 23:39

Message:
Logged In: YES 
user_id=31435

I don't understand.  If you're not running an SMTP server on 
localhost, I expect that example to die with

socket.error: (10061, 'Connection refused')

And indeed, that's what it does when I try it on Win98SE.  So 
I conclude you must have changed the example in some way.  
If so, the solution to your problem will be found in the details 
of you changed it.  Nobody can guess that, so please attach 
the code you actually ran.

----------------------------------------------------------------------

Comment By: mark lee smith (netytan)
Date: 2003-06-09 23:25

Message:
Logged In: YES 
user_id=797196

Im using Python 2.2.2 and the example in smtplib 
documentation originally caused the error. It crashes the 
Kernal on Windows ME and 98, failing to send on Windows XP.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-09 22:51

Message:
Logged In: YES 
user_id=31435

We're going to need more info, and potentially a lot more.  
Start with which version of Python and which flavor of 
Windows.  Lots of people use smtplib on all flavors of 
Windows, and there are no other reports like yours, so it's 
going to turn out to be something very specific to what 
you're doing.  Also. of possible, attach an executable test 
program that reliably triggers the problem for you.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751612&group_id=5470


From noreply@sourceforge.net  Wed Jun 25 23:02:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 25 Jun 2003 15:02:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-760703 ] SocketHandler and LogRecord don't work well together
Message-ID: <E19VILa-00041a-00@sc8-sf-web2.sourceforge.net>

Bugs item #760703, was opened at 2003-06-25 18:56
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketHandler and LogRecord don't work well together

Initial Comment:
>From the logging module, I'm using the DatagramHandler 
(or SocketHandler) to send log messages via UDP 665.  
When I receive them on the other side, there's no 
elegant way to reconstruct them on the other side.  For 
example,

--- in one python session ---
>>> import logging, logging.handlers
>>> handler = logging.handlers.DatagramHandler
( 'localhost', 695 )
>>> logging.root.addHandler( handler )
>>> logging.root.info( 'test' )

--- and in another ---
>>> from socket import *
>>> import pickle, logging
>>> s = socket( AF_INET, SOCK_DGRAM )
>>> s.bind( ( '', 695 ) )
>>> rec = s.recv( 32768 )[4:] #ignore length for now
>>> rec = pickle.loads( rec )
>>> type( rec )
<type 'dict'>
>>> newRec = logging.LogRecord( '', '', '', 1, '', (), None )
>>> newRec.__dict__ = rec

Because logging.LogRecord is not a dict or derived from 
dict, I have to create a log record using 7 arguments, 
then assign the unpickled dict... which is not pretty to 
say the least.

Furthermore, the documentation dictates that the 
record is pickled, not the record's __dict__.

I changed line 163 in logging.handlers to:
        s = cPickle.dumps( record, 1 )
from
        s = cPickle.dumps(record.__dict__, 1)

And I think this is the way it should be done, both to be 
consistent with the documentation, and to make 
reconstruction on the far end more elegant and intuitive.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2003-06-25 22:02

Message:
Logged In: YES 
user_id=308438

The reason a dict is used, rather than a LogRecord, is that a 
user who receives a logging event as a dict does not have to 
have logging in his/her application (this API predates logging 
coming into the Python distribution). I would suggest leaving 
this as is, but how about if I provide a convenience function 
in logging to unpickle a logrecord, say

def makeLogRecord(dict):
    ""Create and return a LogRecord which has the attributes 
of the specified dictionary".

This meets your valid argument about the kludgy 7-arg call, 
while not breaking existing code and not constraining the 
receiver of a logging event in any particular way.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 19:06

Message:
Logged In: YES 
user_id=80475

Referred to Vinay Sajip.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470


From noreply@sourceforge.net  Thu Jun 26 12:44:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 26 Jun 2003 04:44:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-761144 ] tkMessageBox.askyesnocancel missing
Message-ID: <E19VVAv-0005Pg-00@sc8-sf-web1.sourceforge.net>

Bugs item #761144, was opened at 2003-06-26 13: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=761144&group_id=5470

Category: Tkinter
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Peternell (mpeti)
Assigned to: Nobody/Anonymous (nobody)
Summary: tkMessageBox.askyesnocancel missing

Initial Comment:
there's no easy way to make a MessageBox that displays
yes, no and cancel. and askquestion doesn't work:
---
>>> askquestion("hi", "huhu", type=YESNOCANCEL)
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in ?
    askquestion("hi", "huhu", type=YESNOCANCEL)
  File
"C:\Programme\Python22\lib\lib-tk\tkMessageBox.py",
line 91, in askquestion
    return apply(_show, (title, message, QUESTION,
YESNO), options)
TypeError: _show() got multiple values for keyword
argument 'type'
---
so I decided to hack into tkMessageBox.py and added one.

Have a nice day!
Michael

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761144&group_id=5470


From noreply@sourceforge.net  Thu Jun 26 17:02:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 26 Jun 2003 09:02:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-761267 ] Failure in comparing unicode string
Message-ID: <E19VZCP-0007tf-00@sc8-sf-web3.sourceforge.net>

Bugs item #761267, was opened at 2003-06-26 10: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=761267&group_id=5470

Category: Unicode
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Brown (skbrown1975)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Failure in comparing unicode string

Initial Comment:
Received a SystemError: C:\Code\22
\Objects\longobject.c:231: bad argument to internal 
function

The code was "if items[0] == self.InfoShareName:" 
where items is an array of strings and 
self.InfoShareName is a unicode string declared by 
self.InfoShareName = unicode(ShareName)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761267&group_id=5470


From noreply@sourceforge.net  Thu Jun 26 18:45:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 26 Jun 2003 10:45:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-760703 ] SocketHandler and LogRecord don't work well together
Message-ID: <E19VaoI-0004ip-00@sc8-sf-web3.sourceforge.net>

Bugs item #760703, was opened at 2003-06-25 12:56
Message generated for change (Comment added) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketHandler and LogRecord don't work well together

Initial Comment:
>From the logging module, I'm using the DatagramHandler 
(or SocketHandler) to send log messages via UDP 665.  
When I receive them on the other side, there's no 
elegant way to reconstruct them on the other side.  For 
example,

--- in one python session ---
>>> import logging, logging.handlers
>>> handler = logging.handlers.DatagramHandler
( 'localhost', 695 )
>>> logging.root.addHandler( handler )
>>> logging.root.info( 'test' )

--- and in another ---
>>> from socket import *
>>> import pickle, logging
>>> s = socket( AF_INET, SOCK_DGRAM )
>>> s.bind( ( '', 695 ) )
>>> rec = s.recv( 32768 )[4:] #ignore length for now
>>> rec = pickle.loads( rec )
>>> type( rec )
<type 'dict'>
>>> newRec = logging.LogRecord( '', '', '', 1, '', (), None )
>>> newRec.__dict__ = rec

Because logging.LogRecord is not a dict or derived from 
dict, I have to create a log record using 7 arguments, 
then assign the unpickled dict... which is not pretty to 
say the least.

Furthermore, the documentation dictates that the 
record is pickled, not the record's __dict__.

I changed line 163 in logging.handlers to:
        s = cPickle.dumps( record, 1 )
from
        s = cPickle.dumps(record.__dict__, 1)

And I think this is the way it should be done, both to be 
consistent with the documentation, and to make 
reconstruction on the far end more elegant and intuitive.

----------------------------------------------------------------------

>Comment By: Jason R. Coombs (jaraco)
Date: 2003-06-26 11:45

Message:
Logged In: YES 
user_id=599869

Yes, I think that would be suitable as well, but the 
documentation should be likewise changed to indicate what is 
pickled and how to receive it on the other side.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2003-06-25 16:02

Message:
Logged In: YES 
user_id=308438

The reason a dict is used, rather than a LogRecord, is that a 
user who receives a logging event as a dict does not have to 
have logging in his/her application (this API predates logging 
coming into the Python distribution). I would suggest leaving 
this as is, but how about if I provide a convenience function 
in logging to unpickle a logrecord, say

def makeLogRecord(dict):
    ""Create and return a LogRecord which has the attributes 
of the specified dictionary".

This meets your valid argument about the kludgy 7-arg call, 
while not breaking existing code and not constraining the 
receiver of a logging event in any particular way.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 13:06

Message:
Logged In: YES 
user_id=80475

Referred to Vinay Sajip.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470


From noreply@sourceforge.net  Thu Jun 26 18:54:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 26 Jun 2003 10:54:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-761337 ] datetime.strftime fails on trivial format string
Message-ID: <E19Vawm-0007hj-00@sc8-sf-web2.sourceforge.net>

Bugs item #761337, was opened at 2003-06-26 11: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=761337&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.strftime fails on trivial format string

Initial Comment:
Simply put, strftime can't handle the empty string.

>>> import datetime
>>> now = datetime.datetime.utcnow()
>>> now.strftime( '%d' )
'26'
>>> now.strftime( '' )
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
SystemError: C:\Code\23b1
\Objects\stringobject.c:3315: bad argument to internal 
function

This is inconsistent with the docs and the time.strftime 
function.

>>> import time
>>> time.strftime( '', time.gmtime() )
''

Do I need to make any more justification for having the 
empty format string return an empty string?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761337&group_id=5470


From noreply@sourceforge.net  Thu Jun 26 23:24:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 26 Jun 2003 15:24:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-761504 ] Problem building site package bsddb3 on AIX
Message-ID: <E19VfAg-00035V-00@sc8-sf-web2.sourceforge.net>

Bugs item #761504, was opened at 2003-06-26 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=761504&group_id=5470

Category: Distutils
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Wheeler (wheelrl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem building site package bsddb3 on AIX

Initial Comment:
Help.  Trying to build and install bsddb3-4.1.3 on AIX 
4.3.2.  Setup.py produce:

cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
I/mksDev/local/BerkeleyDB.4.1.25/include -
I/mksDev/local/include/python2.2 -c extsrc/_bsddb.c -o 
build/temp.aix-4.3-2.2/_bsddb.o

which the -W options are not valid with IBM's version 5 
compiler.  Removed the -W options and was able to 
compile _bsddb.o.

Linker runs next with:

/usr/local/lib/python2.2/config/ld_so_aix cc -
bI:/usr/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

which uses the wrong prefix, replaced it with:

/mksDev/local/lib/python2.2/config/ld_so_aix cc -
bI:/mksDev/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

now I get:

ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_lock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_signal
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_unlock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_trylock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_wait
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_destroy
ld: 0711-345 Use the -bloadmap or -bnoquiet option to 
obtain more information.

I could really use some help here.  I have successfully 
build the bsddb3 before with a prior version.

Thanks




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761504&group_id=5470


From noreply@sourceforge.net  Thu Jun 26 23:30:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 26 Jun 2003 15:30:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-761504 ] Problem building site package bsddb3 on AIX
Message-ID: <E19VfFo-0007WS-00@sc8-sf-web4.sourceforge.net>

Bugs item #761504, was opened at 2003-06-26 18:24
Message generated for change (Settings changed) made by wheelrl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761504&group_id=5470

Category: Distutils
Group: Python 2.2.2
Status: Open
Resolution: None
>Priority: 9
Submitted By: Richard Wheeler (wheelrl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem building site package bsddb3 on AIX

Initial Comment:
Help.  Trying to build and install bsddb3-4.1.3 on AIX 
4.3.2.  Setup.py produce:

cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
I/mksDev/local/BerkeleyDB.4.1.25/include -
I/mksDev/local/include/python2.2 -c extsrc/_bsddb.c -o 
build/temp.aix-4.3-2.2/_bsddb.o

which the -W options are not valid with IBM's version 5 
compiler.  Removed the -W options and was able to 
compile _bsddb.o.

Linker runs next with:

/usr/local/lib/python2.2/config/ld_so_aix cc -
bI:/usr/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

which uses the wrong prefix, replaced it with:

/mksDev/local/lib/python2.2/config/ld_so_aix cc -
bI:/mksDev/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

now I get:

ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_lock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_signal
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_unlock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_trylock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_wait
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_destroy
ld: 0711-345 Use the -bloadmap or -bnoquiet option to 
obtain more information.

I could really use some help here.  I have successfully 
build the bsddb3 before with a prior version.

Thanks




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761504&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 03:59:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 26 Jun 2003 19:59:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-761504 ] Problem building site package bsddb3 on AIX
Message-ID: <E19VjSg-0002l4-00@sc8-sf-web2.sourceforge.net>

Bugs item #761504, was opened at 2003-06-26 18:24
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761504&group_id=5470

>Category: Build
Group: Python 2.2.2
Status: Open
Resolution: None
>Priority: 5
Submitted By: Richard Wheeler (wheelrl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem building site package bsddb3 on AIX

Initial Comment:
Help.  Trying to build and install bsddb3-4.1.3 on AIX 
4.3.2.  Setup.py produce:

cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
I/mksDev/local/BerkeleyDB.4.1.25/include -
I/mksDev/local/include/python2.2 -c extsrc/_bsddb.c -o 
build/temp.aix-4.3-2.2/_bsddb.o

which the -W options are not valid with IBM's version 5 
compiler.  Removed the -W options and was able to 
compile _bsddb.o.

Linker runs next with:

/usr/local/lib/python2.2/config/ld_so_aix cc -
bI:/usr/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

which uses the wrong prefix, replaced it with:

/mksDev/local/lib/python2.2/config/ld_so_aix cc -
bI:/mksDev/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

now I get:

ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_lock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_signal
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_unlock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_trylock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_wait
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_destroy
ld: 0711-345 Use the -bloadmap or -bnoquiet option to 
obtain more information.

I could really use some help here.  I have successfully 
build the bsddb3 before with a prior version.

Thanks




----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-26 22:59

Message:
Logged In: YES 
user_id=33168

Have you got Python 2.2.x to work on AIX 4.2 or greater?  I
don't believe it works out of the box.

It appears that bsddb requires the pthread library.  You
will need to modify setup.py to add pthread to dblib around
line 444.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761504&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 04:01:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 26 Jun 2003 20:01:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-761267 ] Failure in comparing unicode string
Message-ID: <E19VjUQ-0002nq-00@sc8-sf-web2.sourceforge.net>

Bugs item #761267, was opened at 2003-06-26 12:02
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761267&group_id=5470

Category: Unicode
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Brown (skbrown1975)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Failure in comparing unicode string

Initial Comment:
Received a SystemError: C:\Code\22
\Objects\longobject.c:231: bad argument to internal 
function

The code was "if items[0] == self.InfoShareName:" 
where items is an array of strings and 
self.InfoShareName is a unicode string declared by 
self.InfoShareName = unicode(ShareName)

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-26 23:01

Message:
Logged In: YES 
user_id=33168

Can you attach a file which demonstrates this bug.  I cannot
reproduce it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761267&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 09:16:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 01:16:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-761337 ] datetime.strftime fails on trivial format string
Message-ID: <E19VoOm-0001N6-00@sc8-sf-web3.sourceforge.net>

Bugs item #761337, was opened at 2003-06-26 12:54
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761337&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.strftime fails on trivial format string

Initial Comment:
Simply put, strftime can't handle the empty string.

>>> import datetime
>>> now = datetime.datetime.utcnow()
>>> now.strftime( '%d' )
'26'
>>> now.strftime( '' )
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
SystemError: C:\Code\23b1
\Objects\stringobject.c:3315: bad argument to internal 
function

This is inconsistent with the docs and the time.strftime 
function.

>>> import time
>>> time.strftime( '', time.gmtime() )
''

Do I need to make any more justification for having the 
empty format string return an empty string?

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-27 03:16

Message:
Logged In: YES 
user_id=80475

The interning of short strings violates the refcnt==1 
assumption for _PyString_Resize.

A simple fix is to boost the initial value of "totalnew" by 1. 
Combined with an NULL argument to 
PyString_FromStringAndSize, this assures that resulting 
format string is not interned.  This will remain true even if 
the implementation of PyString_FromStringAndSize changes 
because only the uninitialized strings that can be interned 
are those of zero length.

Fixed and added a test case.  See:
  Modules/datetimemodule.c 1.67
  Lib/test/test_datetime.py 1.45


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761337&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 11:55:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 03:55:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-758239 ] socket timeout exception unhelpful
Message-ID: <E19VqtU-0002WY-00@sc8-sf-web2.sourceforge.net>

Bugs item #758239, was opened at 2003-06-20 21:27
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758239&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Halley (rthalley)
Assigned to: Guido van Rossum (gvanrossum)
Summary: socket timeout exception unhelpful

Initial Comment:
The new settimeout feature for sockets is great, but
the exception that is raised on timeout, socket.error,
is not very helpful.  It's not
possible to write code which catches and deals with
timeouts as opposed to the multitude of other socket
errors.

Even looking at the additional detail isn't helpful,
because you get errnos like EINPROGRESS or EAGAIN,
because the socket code doesn't deal with timeouts
explicitly when it selects.  Rather, it just lets the
internal_select() return, and then you get an error
when whatever was doing the waiting tries to do its
operation.

I propose that a new exception:

class socket.timeout(socket.error):
    pass

be created, and raised whenever the internal_select
times out (i.e. select() returns 0).

This lets applications catch socket.timeout
specifically if they want to, but also allows existing
code to catch socket.error and get all socket-related
exceptions.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-27 06:55

Message:
Logged In: YES 
user_id=6380

I agree too. Raymond, can you prepare a minimal patch?

Given my location at EuroPython, an email with the patch
would be appreciated (in addition to SF upload).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 11:20

Message:
Logged In: YES 
user_id=80475

I agree this would be a useful API change.

Guido, do you concur?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758239&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 11:56:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 03:56:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-758239 ] socket timeout exception unhelpful
Message-ID: <E19VquW-0002YD-00@sc8-sf-web2.sourceforge.net>

Bugs item #758239, was opened at 2003-06-20 21:27
Message generated for change (Settings changed) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758239&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Halley (rthalley)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: socket timeout exception unhelpful

Initial Comment:
The new settimeout feature for sockets is great, but
the exception that is raised on timeout, socket.error,
is not very helpful.  It's not
possible to write code which catches and deals with
timeouts as opposed to the multitude of other socket
errors.

Even looking at the additional detail isn't helpful,
because you get errnos like EINPROGRESS or EAGAIN,
because the socket code doesn't deal with timeouts
explicitly when it selects.  Rather, it just lets the
internal_select() return, and then you get an error
when whatever was doing the waiting tries to do its
operation.

I propose that a new exception:

class socket.timeout(socket.error):
    pass

be created, and raised whenever the internal_select
times out (i.e. select() returns 0).

This lets applications catch socket.timeout
specifically if they want to, but also allows existing
code to catch socket.error and get all socket-related
exceptions.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-27 06:55

Message:
Logged In: YES 
user_id=6380

I agree too. Raymond, can you prepare a minimal patch?

Given my location at EuroPython, an email with the patch
would be appreciated (in addition to SF upload).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 11:20

Message:
Logged In: YES 
user_id=80475

I agree this would be a useful API change.

Guido, do you concur?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758239&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 11:59:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 03:59:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE
Message-ID: <E19VqxS-0002fB-00@sc8-sf-web2.sourceforge.net>

Bugs item #430160, was opened at 2001-06-04 20:09
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470

Category: Windows
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: CGIHTTPServer.py POST bug using IE

Initial Comment:
>From the readme included in the zip:
This set of files shows a bug that occurs when doing 
POST requests via the CGIHTTPServer.py module in 
Python 2.1 The testpost.html file when accessed via 
Internet Explorer 5.5 from webserver.py should show 
this bug. On short POST requests IE will end up doing 
a second POST and then displaying an error message 
while longer POSTs will be followed by a second POST 
and then a GET.

The problem appears to be specific to the interaction 
of IE and the handling of windows sockets in Python in 
the CGIHTTPServer.py module which relies on 
BaseHTTPServer.py, SocketServer.py...

posttestwebserver.py is currently setup to use 
C:\tmp\testpost as the document root, so either move 
the "testpost" folder to C:\tmp or change the 
directory to wherever the testpost folder is located. 
Start the server using the .bat file and bring 
up .html page with something like:
  http://localhost/testpost.html

The bug should occur when you try:
  Test short CGI response with POST
or
  Test long CGI response with POST

The other requests should work fine. The bug will 
occur regardless of whether IE is set to use HTTP/1.0 
or HTTP/1.1. The bug doesn't appear to occur when 
going through a simple proxy. You can also get the bug 
to occur using a remote IE client (either on a LAN or 
over the Net). In addition, it doesn't appear to 
matter whether running with unbuffered binary pipes 
(python -u) or not. I also tested against my modified 
CGIHTTPServer.py See the bug I posted at:
http://sourceforge.net/tracker/?
func=detail&atid=105470&aid=427345&group_id=5470

My configuration:
Windows 2000 Pro, SP2
AMD 1.2GHz
256MB RAM
ActiveStatet Python 2.1 (build 210)
Internet Explorer 5.5 (5.50.4522.1800)

ka
---
Mark Lutz said:
"FWIW, I noticed today (in between lecturing a class) 
that on Windows, Python actually uses a special Python-
coded socket.py library module, not the standard C-
coded socket extension module.  socket.py lives in the 
library directory; it does unique things for closes 
and deletes that may not make sense in all cases 
(e.g., the makefile call generates a class instance, 
not a true file object).  It may also be trying to 
close the underlying socket twice.  I don't have"


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-27 06:59

Message:
Logged In: YES 
user_id=6380

Raymond, can you fix this? Seems simple enough...

----------------------------------------------------------------------

Comment By: Wolfgang Ocker (weoweo)
Date: 2003-06-24 16:58

Message:
Logged In: YES 
user_id=23630

The patch might cause the server to loop endlessly, if the
client has closed the connection. I suggest to change the
patch as follows:

   while select.select([self.rfile], [], [], 0)[0]:
-    waste = self.rfile.read(1)

to

   while select.select([self.rfile], [], [], 0)[0]:
+    if not self.rfile.read(1): break

Maybe this is necessary for the Windows case as well ...

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2003-01-08 13:58

Message:
Logged In: YES 
user_id=88157

Should be fixed by patch 654910 committed today.

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-15 22:25

Message:
Logged In: YES 
user_id=88157

This patch appears to fix the basic CGIHTTPServer behavior, 
at least for Unix and Wiondows platforms, but I'm not yet 
confident of its robustness in the face of Forking or threading 
mixin code. More later ...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 10:57

Message:
Logged In: YES 
user_id=6380

Steve, I'm assigning this bug to you. Feel free to check in
a fix if you think one exists (as long as it doesn't break
on Unix).

----------------------------------------------------------------------

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 15:49

Message:
Logged In: YES 
user_id=247536

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.

not sure what the real fix for this should be?


----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 07:28

Message:
Logged In: YES 
user_id=88157

Please note that I have observed this behavior on Windows
98 using Python 2.0 (#8, Mar  7 2001, 16:04:37) [MSC 32 bit 
(Intel)] using the same build of IE, so it is not a Win2k-
specific problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 12:28:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 04:28:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-761504 ] Problem building site package bsddb3 on AIX
Message-ID: <E19VrP7-0003uB-00@sc8-sf-web2.sourceforge.net>

Bugs item #761504, was opened at 2003-06-26 18:24
Message generated for change (Comment added) made by wheelrl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761504&group_id=5470

Category: Build
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Wheeler (wheelrl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem building site package bsddb3 on AIX

Initial Comment:
Help.  Trying to build and install bsddb3-4.1.3 on AIX 
4.3.2.  Setup.py produce:

cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
I/mksDev/local/BerkeleyDB.4.1.25/include -
I/mksDev/local/include/python2.2 -c extsrc/_bsddb.c -o 
build/temp.aix-4.3-2.2/_bsddb.o

which the -W options are not valid with IBM's version 5 
compiler.  Removed the -W options and was able to 
compile _bsddb.o.

Linker runs next with:

/usr/local/lib/python2.2/config/ld_so_aix cc -
bI:/usr/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

which uses the wrong prefix, replaced it with:

/mksDev/local/lib/python2.2/config/ld_so_aix cc -
bI:/mksDev/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

now I get:

ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_lock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_signal
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_unlock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_trylock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_wait
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_destroy
ld: 0711-345 Use the -bloadmap or -bnoquiet option to 
obtain more information.

I could really use some help here.  I have successfully 
build the bsddb3 before with a prior version.

Thanks




----------------------------------------------------------------------

>Comment By: Richard Wheeler (wheelrl)
Date: 2003-06-27 07:28

Message:
Logged In: YES 
user_id=249546

Thanks for the reply.

Yes, Python 2.2.x runs fine on AIX 4.3.2.  Been using it on aix 
since about March of 2002.  Recently upgraded to 2.2.2.

Finally figured out to add the -lpthread option last night.  
bsddb3-4.1.3 now compliles fine on AIX 4.3.2.  All tests 
passed as well.  

Had to run the complier and linker manually.  DistUtils needs 
some work with --prefix option if folks are going to use it for 
distributing python modules.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-26 22:59

Message:
Logged In: YES 
user_id=33168

Have you got Python 2.2.x to work on AIX 4.2 or greater?  I
don't believe it works out of the box.

It appears that bsddb requires the pthread library.  You
will need to modify setup.py to add pthread to dblib around
line 444.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761504&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 13:26:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 05:26:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-761787 ] readline()/readlines()
Message-ID: <E19VsJE-0002vN-00@sc8-sf-web3.sourceforge.net>

Bugs item #761787, was opened at 2003-06-27 20:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761787&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: full li sail (fullsail)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline()/readlines()

Initial Comment:
At first, I can not speak English very well ,so follow
my description may be not very nicety.

I use python for processing text file(It may contain 
many chinese characters). readline()/readlines() , I use 
them many times, but I found they's result read from hte 
text file is different from text.

I uploaded the files can omit this bug.

I modified the data file, beacause of It contain some 
user information of my work.

run s.py, then view txt\ADSL5.txt, you can 
understand......

and:
My platform:
Win98SE + Python 2.2.2 + PythonWin for py22
Win2000Pro+SP3 + Python 2.2.3 + PythonWin for py22


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761787&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 14:37:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 06:37:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-761830 ] Tutorial: Small bug in Contents page
Message-ID: <E19VtPa-0006iU-00@sc8-sf-web1.sourceforge.net>

Bugs item #761830, was opened at 2003-06-27 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=761830&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominik Kotowicz (dkoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial: Small bug in Contents page

Initial Comment:
In the Content page there are some links used by
Mozilla NavBar. But unfortunatelly there are an error,
because content link path to page named
"contensts.html" - in Tutorial there are no page with
that name and this link should be changed to "tut.html".

This bug is in all versions of tutorial.

Now:
<link rel="first" href="tut.html">
<link rel="contents" href="contents.html" title="Contents">
<link REL="next" HREF="node1.html">

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761830&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 15:58:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 07:58:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-761888 ] popen2.Popen3 and popen2.Popen4 leaks filedescriptors
Message-ID: <E19Vufp-0002Kq-00@sc8-sf-web1.sourceforge.net>

Bugs item #761888, was opened at 2003-06-27 16: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=761888&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Troels Walsted Hansen (troels)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen2.Popen3 and popen2.Popen4 leaks filedescriptors

Initial Comment:
The code below (from Lib/popen2.py) appears to leak no
less then 4 filedescriptors if os.fork() raises an
exception (say "OSError: [Errno 12] Not enough space"
on a Solaris box running out of swap).

Popen3.__init__() appears to leak 6 filedescriptors.

class Popen4(Popen3):
    def __init__(self, cmd, bufsize=-1):
        p2cread, p2cwrite = os.pipe()
        c2pread, c2pwrite = os.pipe()
        self.pid = os.fork()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761888&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 17:07:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 09:07:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-759227 ] improbable __nonzero__ crash
Message-ID: <E19Vvl7-0005ZS-00@sc8-sf-web1.sourceforge.net>

Bugs item #759227, was opened at 2003-06-23 13:45
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
>Assigned to: Jeremy Hylton (jhylton)
Summary: improbable __nonzero__ crash

Initial Comment:
>>> class X(object):
...   def __nonzero__(self):
...     return self
... 
>>> x=X()
>>> not x
Segmentation fault

This is just a stupid artificial exploit of the fact
that PyObject_IsTrue calls the user-defined __nonzero__
and get a Python object whose truth-value itself is
determined by a call to PyObject_IsTrue.

For old-style classes we check that __nonzero__
actually returned an int. This trick was safe, but no
longer is, because it could be a subclass of int with a
custom __nonzero__ again.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-24 20:12

Message:
Logged In: YES 
user_id=31392

I think this patch is too specialized.  It only handles the
contrived case that Armin reported.  It's possible to get
unbounded recursion in a variety of ways.  I don't see why
we should patch the code to deal with a single one.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 17:49

Message:
Logged In: YES 
user_id=80475

Preventing mutually recursive calls is probably not worth it.  
Your simple patch does the trick.  Please do add a test case 
for it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 17:01

Message:
Logged In: YES 
user_id=33168

Note: the patch doesn't address a case of mutual recursion
where 2 or more objects are involved.  That could be fixed
by tying the call into the recursion limit.  Not sure how
difficult that is or if it's worth it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 16:58

Message:
Logged In: YES 
user_id=33168

This is also a 2.2.3 problem.  This seems easy enough to fix
(patch attached), but the question is what should the answer
be?  I made it return 1 (true).  Should it be an exception?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 18:14:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 10:14:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-759227 ] improbable __nonzero__ crash
Message-ID: <E19Vwnq-0000BQ-00@sc8-sf-web3.sourceforge.net>

Bugs item #759227, was opened at 2003-06-23 13:45
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: improbable __nonzero__ crash

Initial Comment:
>>> class X(object):
...   def __nonzero__(self):
...     return self
... 
>>> x=X()
>>> not x
Segmentation fault

This is just a stupid artificial exploit of the fact
that PyObject_IsTrue calls the user-defined __nonzero__
and get a Python object whose truth-value itself is
determined by a call to PyObject_IsTrue.

For old-style classes we check that __nonzero__
actually returned an int. This trick was safe, but no
longer is, because it could be a subclass of int with a
custom __nonzero__ again.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-27 17:14

Message:
Logged In: YES 
user_id=31392

I did a partial fix for this problem by restricting
__nonzero__ to return an int or a bool, as per the language
spec.  The remaining problem is for a subclass of int
returned from __nonzero__.  I think the simplest solution to
this problem is to require __nonzero__ to return exactly an
int -- PyInt_CheckExact() instead of PyInt_Check().  Does
anyone find this restriction unacceptable?


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-24 20:12

Message:
Logged In: YES 
user_id=31392

I think this patch is too specialized.  It only handles the
contrived case that Armin reported.  It's possible to get
unbounded recursion in a variety of ways.  I don't see why
we should patch the code to deal with a single one.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 17:49

Message:
Logged In: YES 
user_id=80475

Preventing mutually recursive calls is probably not worth it.  
Your simple patch does the trick.  Please do add a test case 
for it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 17:01

Message:
Logged In: YES 
user_id=33168

Note: the patch doesn't address a case of mutual recursion
where 2 or more objects are involved.  That could be fixed
by tying the call into the recursion limit.  Not sure how
difficult that is or if it's worth it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 16:58

Message:
Logged In: YES 
user_id=33168

This is also a 2.2.3 problem.  This seems easy enough to fix
(patch attached), but the question is what should the answer
be?  I made it return 1 (true).  Should it be an exception?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 18:14:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 10:14:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-726150 ] Broken links for grammar in docs
Message-ID: <E19Vwnb-0002fv-00@sc8-sf-web2.sourceforge.net>

Bugs item #726150, was opened at 2003-04-23 05:33
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726150&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Broken links for grammar in docs

Initial Comment:
The "test" and "testlist" links at
http://www.python.org/dev/doc/devel/ref/lists.html#tok-
listmaker point
into space.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-06-27 13:14

Message:
Logged In: YES 
user_id=3066

The test and testlist symbols don't need to be "documented",
but they need to appear in the grammar as presented, or
expanded in place.  I've added the definitions since I
dislike really long productions in the way they're presented.

Committed as Doc/ref/ref5.tex 1.76 and 1.53.4.12.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 18:01

Message:
Logged In: YES 
user_id=357491

OK, so it appears test and testlist in the grammar are purely for 
the compiler and not needed for any documentation explicitly.  
They basically cover how to create a chain of tests.  I have no 
clue where they would be put if they were to be documented.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726150&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 18:18:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 10:18:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-552262 ] 'testlist&quot; undefined in grammar
Message-ID: <E19Vws1-0006Cb-00@sc8-sf-web4.sourceforge.net>

Bugs item #552262, was opened at 2002-05-04 11:12
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=552262&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Dan Everhart (deverhart)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 'testlist&quot; undefined in grammar

Initial Comment:
In http://www.python.org/doc/current/ref/grammar.txt 
the production

list_for ::= 
             "for" expression_list "in" testlist
              [list_iter]

refers to the nonterminal 'testlist', which does not 
appear anywhere else in the document.
  

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-06-27 13:18

Message:
Logged In: YES 
user_id=3066

Duplicate of bug #726150.

Fixed in Doc/ref/ref5.tex 1.76 and 1.53.4.12.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=552262&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 18:32:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 10:32:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-757822 ] Additional index items, other minor details
Message-ID: <E19Vx5T-0006qC-00@sc8-sf-web4.sourceforge.net>

Bugs item #757822, was opened at 2003-06-20 06:31
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757822&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: Additional index items, other minor details

Initial Comment:
It seems that various recent language changes have not
made it into any of the indices (super, property,
__slots__, ...).

LibRef:

3.14, first paragraph, last sentence unfinished "...to
avoid confusing."

3.3, first paragraph after XXX:  "Not all objects can
be weakly referenced; those objects which do include
class instances,..."


If I get around to it myself, will try to submit
patches for above :).

Thanks...

Mark

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-27 12:32

Message:
Logged In: YES 
user_id=80475

Added docs and indexing for __metaclass__ and __slots__.

The only thing left is your comment on 3.3 which looks fine 
to me.  Closing bug and marking as fixed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 10:13

Message:
Logged In: YES 
user_id=80475

super(), property(), classmethod(), object(), staticmethod() 
are now all in the index.  They automatically make it there 
when their functions were documented.

Sadly, __slots__ is not indexed because it is not yet 
documented.

Fixed paragraph 3.14.  See Doc/lib/libpickle.tex 1.42

For paragraph 3.3, it isn't clear what you want changed.  
Please let me know so we can clear this bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757822&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 18:34:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 10:34:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-761830 ] Tutorial: Small bug in Contents page
Message-ID: <E19Vx75-0006uH-00@sc8-sf-web4.sourceforge.net>

Bugs item #761830, was opened at 2003-06-27 08:37
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761830&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominik Kotowicz (dkoto)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial: Small bug in Contents page

Initial Comment:
In the Content page there are some links used by
Mozilla NavBar. But unfortunatelly there are an error,
because content link path to page named
"contensts.html" - in Tutorial there are no page with
that name and this link should be changed to "tut.html".

This bug is in all versions of tutorial.

Now:
<link rel="first" href="tut.html">
<link rel="contents" href="contents.html" title="Contents">
<link REL="next" HREF="node1.html">

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761830&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 19:06:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 11:06:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-759227 ] improbable __nonzero__ crash
Message-ID: <E19Vxcc-00056z-00@sc8-sf-web2.sourceforge.net>

Bugs item #759227, was opened at 2003-06-23 13:45
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: improbable __nonzero__ crash

Initial Comment:
>>> class X(object):
...   def __nonzero__(self):
...     return self
... 
>>> x=X()
>>> not x
Segmentation fault

This is just a stupid artificial exploit of the fact
that PyObject_IsTrue calls the user-defined __nonzero__
and get a Python object whose truth-value itself is
determined by a call to PyObject_IsTrue.

For old-style classes we check that __nonzero__
actually returned an int. This trick was safe, but no
longer is, because it could be a subclass of int with a
custom __nonzero__ again.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-27 18:06

Message:
Logged In: YES 
user_id=31392

Fixed as suggested by making PyInt_CheckExact() and
PyBool_Check() the tests on the __nonzero__() return value.
 (bool can't be subclassed.)


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-27 17:14

Message:
Logged In: YES 
user_id=31392

I did a partial fix for this problem by restricting
__nonzero__ to return an int or a bool, as per the language
spec.  The remaining problem is for a subclass of int
returned from __nonzero__.  I think the simplest solution to
this problem is to require __nonzero__ to return exactly an
int -- PyInt_CheckExact() instead of PyInt_Check().  Does
anyone find this restriction unacceptable?


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-24 20:12

Message:
Logged In: YES 
user_id=31392

I think this patch is too specialized.  It only handles the
contrived case that Armin reported.  It's possible to get
unbounded recursion in a variety of ways.  I don't see why
we should patch the code to deal with a single one.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 17:49

Message:
Logged In: YES 
user_id=80475

Preventing mutually recursive calls is probably not worth it.  
Your simple patch does the trick.  Please do add a test case 
for it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 17:01

Message:
Logged In: YES 
user_id=33168

Note: the patch doesn't address a case of mutual recursion
where 2 or more objects are involved.  That could be fixed
by tying the call into the recursion limit.  Not sure how
difficult that is or if it's worth it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 16:58

Message:
Logged In: YES 
user_id=33168

This is also a 2.2.3 problem.  This seems easy enough to fix
(patch attached), but the question is what should the answer
be?  I made it return 1 (true).  Should it be an exception?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 19:28:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 11:28:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-761830 ] Tutorial: Small bug in Contents page
Message-ID: <E19Vxx4-000642-00@sc8-sf-web2.sourceforge.net>

Bugs item #761830, was opened at 2003-06-27 09:37
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761830&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dominik Kotowicz (dkoto)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial: Small bug in Contents page

Initial Comment:
In the Content page there are some links used by
Mozilla NavBar. But unfortunatelly there are an error,
because content link path to page named
"contensts.html" - in Tutorial there are no page with
that name and this link should be changed to "tut.html".

This bug is in all versions of tutorial.

Now:
<link rel="first" href="tut.html">
<link rel="contents" href="contents.html" title="Contents">
<link REL="next" HREF="node1.html">

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-06-27 14:28

Message:
Logged In: YES 
user_id=3066

There was a bug in my extension of one of the tools used in
formatting the documentation.  Now fixed in
Doc/perl/l2hinit.perl 1.74 and 1.58.6.2 (these will be
reflected in Python 2.2.4 and 2.3).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761830&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 19:34:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 11:34:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-729297 ] What's new in Python2.3b1 HTML generation.
Message-ID: <E19Vy3U-0001UK-00@sc8-sf-web4.sourceforge.net>

Bugs item #729297, was opened at 2003-04-28 22:07
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729297&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Alexis Layton (alayton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: What's new in Python2.3b1 HTML generation.

Initial Comment:
Whenever a section name includes a style change, the
llinks generated for it are truncated.

To reproduce:
  Go to section "5. PEP 278: Universal New Line Support"

Notice the next link: "6. PEP 279: The".  The link
should read
"6. PEP 279: The enumerate() Built-In Function."  Similar
problems happen with links for sections 7 and 8.

This problem does not happen in the table of contents
however.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-06-27 14:34

Message:
Logged In: YES 
user_id=3066

This is a couple of things interacting, I think:
1. LaTeX2HTML abbreviates those links to include only a few
words of the section title, not the whole thing.
2. Sometimes markup probably gets counted as words (I'm less
sure about this one).
I'm not inclined to worry about this, as I'm unlikely to
manage to fix it without more work than it's worth.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2003-05-13 10:28

Message:
Logged In: YES 
user_id=11375

I've fixed the section headers in the "What's New" documents to not 
use markup.  Fred, you can either fix the problem or just forget it 
and close the bug.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-29 01:05

Message:
Logged In: YES 
user_id=80475

It looks like it is always grabbing the first word even when 
there is no style change.  Looking back at Py2.2.2, it also 
occurred there.  I'm this it is a TeX macro issue for Fred.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729297&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 20:37:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 12:37:49 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-697575 ] Warn on potentially useless umasks?
Message-ID: <E19Vz2b-0004Ca-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #697575, was opened at 2003-03-04 16:28
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697575&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: A.M. Kuchling (akuchling)
Summary: Warn on potentially useless umasks?

Initial Comment:
I noticed quite by accident today that distutils seems to take into
account the installer's umask setting when spambayes got
installed with these notices:

changing mode of /usr/local/bin/unheader.py to 711
changing mode of /usr/local/bin/hammie.py to 711
changing mode of /usr/local/bin/hammiecli.py to 711
changing mode of /usr/local/bin/hammiesrv.py to 711
...

The root user's umask was 077.  Perhaps distutils should
warn the installer when scripts or modules would be installed
but not readable.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-06-27 14:37

Message:
Logged In: YES 
user_id=44345

It appears this was fixed on CVS head back in November.  Perhaps
I was using 2.2 when I posted this.  Applied to 1.10.26.2 for the
2.2 maintenance branch.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697575&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 22:33:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 14:33:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-760703 ] SocketHandler and LogRecord don't work well together
Message-ID: <E19W0qH-0001lo-00@sc8-sf-web3.sourceforge.net>

Bugs item #760703, was opened at 2003-06-25 13:56
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketHandler and LogRecord don't work well together

Initial Comment:
>From the logging module, I'm using the DatagramHandler 
(or SocketHandler) to send log messages via UDP 665.  
When I receive them on the other side, there's no 
elegant way to reconstruct them on the other side.  For 
example,

--- in one python session ---
>>> import logging, logging.handlers
>>> handler = logging.handlers.DatagramHandler
( 'localhost', 695 )
>>> logging.root.addHandler( handler )
>>> logging.root.info( 'test' )

--- and in another ---
>>> from socket import *
>>> import pickle, logging
>>> s = socket( AF_INET, SOCK_DGRAM )
>>> s.bind( ( '', 695 ) )
>>> rec = s.recv( 32768 )[4:] #ignore length for now
>>> rec = pickle.loads( rec )
>>> type( rec )
<type 'dict'>
>>> newRec = logging.LogRecord( '', '', '', 1, '', (), None )
>>> newRec.__dict__ = rec

Because logging.LogRecord is not a dict or derived from 
dict, I have to create a log record using 7 arguments, 
then assign the unpickled dict... which is not pretty to 
say the least.

Furthermore, the documentation dictates that the 
record is pickled, not the record's __dict__.

I changed line 163 in logging.handlers to:
        s = cPickle.dumps( record, 1 )
from
        s = cPickle.dumps(record.__dict__, 1)

And I think this is the way it should be done, both to be 
consistent with the documentation, and to make 
reconstruction on the far end more elegant and intuitive.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-27 16:33

Message:
Logged In: YES 
user_id=80475

Fixed.  See patch 761519.

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2003-06-26 12:45

Message:
Logged In: YES 
user_id=599869

Yes, I think that would be suitable as well, but the 
documentation should be likewise changed to indicate what is 
pickled and how to receive it on the other side.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2003-06-25 17:02

Message:
Logged In: YES 
user_id=308438

The reason a dict is used, rather than a LogRecord, is that a 
user who receives a logging event as a dict does not have to 
have logging in his/her application (this API predates logging 
coming into the Python distribution). I would suggest leaving 
this as is, but how about if I provide a convenience function 
in logging to unpickle a logrecord, say

def makeLogRecord(dict):
    ""Create and return a LogRecord which has the attributes 
of the specified dictionary".

This meets your valid argument about the kludgy 7-arg call, 
while not breaking existing code and not constraining the 
receiver of a logging event in any particular way.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 14:06

Message:
Logged In: YES 
user_id=80475

Referred to Vinay Sajip.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=760703&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 22:34:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 14:34:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-757821 ] logging module docs
Message-ID: <E19W0r2-0002az-00@sc8-sf-web1.sourceforge.net>

Bugs item #757821, was opened at 2003-06-20 06:29
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757821&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module docs

Initial Comment:
http://www.python.org/dev/doc/devel/lib/node297.html

It should be mentioned that it is necessary to import 
"logging.config" to call fileConfig().  The explanation
does not mention the config module so it is confusing
when people try:

import logging
logging.fileConfig(...)



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-27 16:33

Message:
Logged In: YES 
user_id=80475

Fixed.  See patch 761519.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 10:17

Message:
Logged In: YES 
user_id=80475

Forwarded to Vinay Sajip for comment and repair.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757821&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 23:26:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 15:26:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-762147 ] PackMan needs to be able to install outside site-packages
Message-ID: <E19W1g9-0003kK-00@sc8-sf-web3.sourceforge.net>

Bugs item #762147, was opened at 2003-06-28 00:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762147&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 8
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PackMan needs to be able to install outside site-packages

Initial Comment:
PackMan needs to be able to install system-wide packages 
in /Library/Python/2.3/site-packages, in the event that the 
normal $prefix/lib/python2.3/site-packages is not writeable. 
That directory also needs to be put on sys.path (for 
framework OSX builds only) if it exists, similarly to ~/
Library/Python/2.3/site-packages.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762147&group_id=5470


From noreply@sourceforge.net  Fri Jun 27 23:30:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 15:30:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-762150 ] PackMan database needs stable URL
Message-ID: <E19W1jr-0003sq-00@sc8-sf-web3.sourceforge.net>

Bugs item #762150, was opened at 2003-06-28 00:30
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=762150&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 8
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PackMan database needs stable URL

Initial Comment:
The URL for the database that PackMan uses is currently at 
homepages.cwi.nl, but there is CWI-internal discussion on 
URLs. As this URL is hardcoded into pimp.py it needs to be 
a stable URL. We need either a firm commitment from CWI 
or a location on www.python.org or both. The latter with 
implementing a multiple-URL scheme in pimp.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762150&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 01:04:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 17:04:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-762198 ] bug in signal.signal -- raises SystemError
Message-ID: <E19W3CF-0006kR-00@sc8-sf-web3.sourceforge.net>

Bugs item #762198, was opened at 2003-06-28 00: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=762198&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim McCoy (mccoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in signal.signal -- raises SystemError

Initial Comment:
Summary pretty much says it all.  Using Py2.2.3, win2k 
(sp4), and twisted 1.0.5 and the call that is triggering the 
error is as follows:

signal.signal(signal.SIGINT, self.sigInt)

returns "SystemError: error return without exception set"

The twisted gang has tracked it down to a C error of some 
sort here...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 07:17:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 23:17:22 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-748201 ] time.strptime() should display format and date on error
Message-ID: <E19W91W-0000fo-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #748201, was opened at 2003-06-03 09:14
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=748201&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
>Assigned to: Brett Cannon (bcannon)
Summary: time.strptime() should display format and date on error

Initial Comment:
Hi!

It would be very nice if the ValueError of
time.strptime() would
display the format and the date if there is a mismatch.

Up to now (python 2.2.2) the Error looks like this:
 ValueError: format mismatch
It would be nice if it would look like this:
 format mismatch: str=2002.12.24 format=%Y-%m-%d

 thomas

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 01:17

Message:
Logged In: YES 
user_id=80475

Helpful, informative error messages are certainly a step in 
the right direction.  Referrring to Brett for implementation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=748201&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 07:21:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 23:21:38 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-722498 ] assert could raise other Exceptions
Message-ID: <E19W95e-0000lq-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #722498, was opened at 2003-04-16 09:08
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722498&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: assert could raise other Exceptions

Initial Comment:

how about having 'assert' check its second parameter,
and if it is an instance of Exception, raise that instead
of AssertionError:

  try:
         n = int(argv[i])
         assert 0 <= n <  10, ValueError("n out of range")
   except ValueError,e:
         print "Bad parameter:", str(e)



This is a fair bit tidier than

      if not ( 0 <= n < 10 ): raise ValueError, "n out
of range"

you could also do 'except (ValueError,
AssertionError)", but
the 'except' might not  be so close by, it would be nice to
have assert raise something else.

Having written this, I just realized that assert is
supposed
to go away when '-O' is selected (I never use that, myself)
so maybe this is not quite as useful -- but still quite
free of downside. 

I know nobody wants a new keyword, how about

     assert >> ValueError  , 0 <= n < 10 , n out of range

... which would do the same as the first example but
not be deleted by -O









----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 01:21

Message:
Logged In: YES 
user_id=80475

Closing this one because the idea found no support or 
interest.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-12 12:51

Message:
Logged In: YES 
user_id=80475

I concur with Martin.  While handy, this idea is not 
consistent with the intended purpose for assertions.  Also, 
I don't find the >> notation to be attractive.

I recommend leaving this one out.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-18 11:26

Message:
Logged In: YES 
user_id=21627

I don't like this idea. Assertions are something that you
can take out without changing the interface (and indeed -O
takes them out). They are supposed to never happen, not even
when an application uses a library incorrectly.

If you need to perform correctness checks on parameters,
those checks belong to the API of the function, and should
be documented and implemented with a proper if statement.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722498&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 07:29:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 23:29:03 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-681533 ] Additional string stuff.
Message-ID: <E19W9Cp-0007Ii-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #681533, was opened at 2003-02-06 03:14
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Additional string stuff.

Initial Comment:
In a lot of my programs that mess with strings, I end up 
somewhere making a variable "ascii" via 
(string.maketrans('', '')).  It's just a 256-character string 
comprising the ascii character set. 
 
I use it, oftentimes, simply to be able to turn the 'translate' 
method on strings into a 'delete' method -- if I want to, 
say, remove all the spaces in aString, I'd do 
(aString.translate(ascii, string.whitespace)). 
 
Certainly an ascii variable in the string module couldn't 
hurt, would fit in with ascii_letters, etc. and would at least 
standarize the name of the full ascii set sure to be 
present in many Python programs. 
 
A little further out there, but I think just as useful, would 
be a delete method on strings.  So "foo bar 
baz".delete(string.whitespace) would return "foobarbaz".  
It would be equivalent to "foo bar baz".translate(ascii, 
string.whitespace), or the wildly inefficient: 
 
def delete(s, deleteChars): 
    l = [] 
    for c in s: 
        if c not in deleteChars: 
            l.append(c) 
    return ''.join(l) 
 
Anyway, that's all I can think of.  Do with it what you will. 
 
Jeremy 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 01:29

Message:
Logged In: YES 
user_id=80475

The trend is away from including character strings as 
attributes -- they are instead being replaced with functions 
like str.isascii() or str.iswhitespace().

Also, it is so easy to construct a character list that it is not 
worth cluttering the string API (everything there must be 
documented, duplicated for unicode objects, and duplicated 
again for userstrings).  

Instead for maketrans, I would use something like this:
  rhchars  = ''.join(map(chr, range(65,100)))

So, unless compelling use cases can be found, I recommend 
closing this one.   

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2003-03-10 11:22

Message:
Logged In: YES 
user_id=36166

Just make the interface like the translate method of unicode
objects: it accepts "a mapping of Unicode ordinals to
Unicode ordinals, Unicode strings or None. Unmapped
characters are left untouched. Characters mapped to None are
deleted.".
This would make the str/unicode translate methods consistent
(currently there is no way to call the method that will work
for both).
I have no opinion on whether implementing 1-to-n
translations (like Python2.3 supports for unicode objects)
is worth the trouble for plain strings.
Of course, the table_string[, deletechars] interface should
still be supported for compatibility.


----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-03-05 22:03

Message:
Logged In: YES 
user_id=99508

Ah, yes, you're right.  I never knew ASCII was only 7 bits per 
character.  Perhaps string.all_characters?  I just definitely think 
it should be publically available so there can be some 
consistency between applications that need a string of all 256 
8-bit characters. 

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-05 09:13

Message:
Logged In: YES 
user_id=45365

Note that "ascii" is definitely a bad name, as it means different things to anyone. To Python it usually means "7-bit ASCII" (as in the unicode "ascii" codec). To you it apparently means "8-bit something-or-other".

I have no opinion on whether this feature is a good idea, but if it is I would suggest a name with "any" or "all" in it, and possibly "8bit" too.

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-03-04 13:25

Message:
Logged In: YES 
user_id=99508

What's the status on this? 
 
I checked string.py, and there actually already is a value 
that's the 256 ASCII characters, but it's called _idmap.  Might 
we consider changing the name of that to "ascii"?  I'd be 
happy to make the patch. 
 
Jeremy 

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-02-07 01:47

Message:
Logged In: YES 
user_id=99508

I guess that's what I get for not reading the documentation :) 
 
Oh well, the other two suggestions stand :) 
 
Jeremy 

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-02-07 00:19

Message:
Logged In: YES 
user_id=99508

I guess that's what I get for not reading the documentation :) 
 
Oh well, the other two suggestions stand :) 
 
Jeremy 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-06 21:15

Message:
Logged In: YES 
user_id=31435

Just noting that you can pass None for sep if you want to 
explicitly ask for the default behavior.

>>> "      a  b   c".split(None, 1)
['a', 'b   c']
>>>


----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-02-06 04:19

Message:
Logged In: YES 
user_id=99508

Let me also make one other suggestion:  the split method on a 
string object has, by default, behavior that can't be replicated 
by passing an argument as a separator.  That is, the default 
separated acts like re.split(r'\s+'), but it's impossible to pass 
any value into the method to achieve that same result. 
 
The problem arises when a user wants to use the maxsplit() 
parameter to the method.  Because maxsplit is a positional 
parameter instead of a keyword parameter, the user *must* 
declare a separate to split on, and thus loses his ability to split 
on whitespace-in-general.  If maxsplit was changed from being 
a positional parameter to being a keyword parameter, then a 
programmer wouldn't have to give up the default behavior of 
the split method in order to pass it a maxsplit. 
 
At present, negative maxsplit values don't differ in any way 
from split's default behavior (with no maxsplit parameter given).  
Thus, the keyword maxsplit could default to -1 with no 
breakage of code.  I can't see any place where changing 
maxsplit to a keyword parameter would break any existing 
code 
 
Jeremy 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 07:31:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 23:31:17 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-694374 ] Recursive regular expressions
Message-ID: <E19W9Ez-0007Lu-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #694374, was opened at 2003-02-27 09:00
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694374&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel (kamek)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Recursive regular expressions

Initial Comment:
It would be great if Python's regexps supported recursive 
regular expressions, just like PCRE. For that it'd need 
its formations (?R), (?<name>) and (?P>name).

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 01:31

Message:
Logged In: YES 
user_id=80475

This might be a worthwhile addition to Py2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694374&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 07:36:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 23:36:25 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-697985 ] Move gmtime function from calendar to time module
Message-ID: <E19W9Jx-0007T0-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #697985, was opened at 2003-03-05 08:40
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erland Lewin (erl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Move gmtime function from calendar to time module

Initial Comment:
The gmtime function in the calendar module would be
much more logical to have in the time module, since it
manipulates tm tuples and unix timestamps, which the
other functions in time do, but no other functions in
calendar.

Related to bug #697983


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 01:36

Message:
Logged In: YES 
user_id=80475

Erland, I propose that you close this one.

The time and calendar API's have been around for a good 
while and changes would have a negative impact, even if 
they have some logic to it.

The new datetime module for Py2.3 makes the time module 
obsolete; is organized logically; and should meet most of 
your needs.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-12 19:49

Message:
Logged In: YES 
user_id=31435

Sorry, I don't have time to give to this.  It's certainly not a 
bug report <wink>.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-29 11:22

Message:
Logged In: YES 
user_id=357491

Well then, is there any desire to bother to make this happen?  Or is this just 
a "I hope someone likes this idea enough to implement it" instance in which 
case this should probably be made an RFE.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-05-28 21:59

Message:
Logged In: YES 
user_id=31435

mktime() interprets its argument as local time; timegm() as 
UTC.  Generally speaking,

time.mktime(time.localtime())

returns int(time.time()), and so does

calendar.timegm(time.gmtime())

The OP appears to be right that the time module doesn't 
have an "inverse" for time.gmtime() in this sense.  Then 
again, the time functions inherited from C are generally a 
twisted thicket.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-28 20:50

Message:
Logged In: YES 
user_id=357491

OK, assuming the OP meant calendar.timegm , doesn't time.mktime provide 
the same functionality?  Or is the desire to have it because  it specifies the 
epoch as 1970-01-01?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-05-22 23:47

Message:
Logged In: YES 
user_id=31435

I expect the OP meant the calendar.timegm() function.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 16:46

Message:
Logged In: YES 
user_id=33168

The gmtime function is in time, not calendar.  Did you mean
the opposite that you believe gmtime should be in calendar?
  gmtime comes from the C version which is the purpose of
time, to expose C functions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 07:37:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 23:37:40 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-668905 ] logging module documentation
Message-ID: <E19W9LA-0007Ud-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #668905, was opened at 2003-01-16 00:07
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module documentation

Initial Comment:
I believe the logging module documentation needs to give an 
example of how to simply log to a file. The following example snippet 
could be appropriate: 
 
import logging 
logger = logging.getLogger('myapp') 
hdlr = FileHandler('/var/myapp/debug.log') 
hdlr.setFormatter(Formatter('%(asctime)s %(level)s %(message)s')) 
logger.addHandler(hdlr) 
logger.setLevel(DEBUG) 
 
 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 01:37

Message:
Logged In: YES 
user_id=80475

Reviewed.
Closing RFE.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-25 16:36

Message:
Logged In: YES 
user_id=33168

I just updated the logging documentation.  Could you please
review for accuracy and completeness?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 07:39:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 23:39:13 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-622230 ] def object.new_method(self):
Message-ID: <E19W9Mf-0007XU-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #622230, was opened at 2002-10-12 01:04
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Dan Parisien (mathematician)
Assigned to: Nobody/Anonymous (nobody)
Summary: def object.new_method(self):

Initial Comment:
I want to be able to create functions inside objects 
instead of having to do:<code> 
class x: 
    pass 
def new_method(self): 
    pass 
x.new_method = new_method 
del new_method 
</code> 
I want to do: <code> 
class x: 
    pass 
def x.new_method(self): 
    pass 
</code> 
Why isn't this possible? Wouldn't it be cool? 
 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 01:39

Message:
Logged In: YES 
user_id=80475

Closed due to lack of further development or support.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-12 21:56

Message:
Logged In: YES 
user_id=357491

I am with Raymond and Martin on this; I don't see this being worth the 
hassle of implementing.  Should we reject this or leave it open for 
contemplative thought?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 04:16

Message:
Logged In: YES 
user_id=80475

This is an interesting idea but (from your example) the 
only way to use it is when the names are already known 
statically when writing the code.  And, if you already know 
x and newmethod, why not write:

class x:
    def new_method(self):
        pass

The only use case I can see is if the source for x is 
unaccessible in another module:

from M import x
def x.newmethod(self):
    pass

All in all, this would be a tough sell (and likely require a 
PEP) because the effort to implement it, document it, 
explain it and support it isn't warrented by the two line 
savings over what can already be done.  Further, the 
current one-way-to-do-it is robust, clear, and can work 
dynamically as well as at coding time.

I'm -1 on this one but do think it reflects original creative 
thought.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-11-04 05:29

Message:
Logged In: YES 
user_id=21627

It's simply not possible because nobody has though of that.

I personally would not consider it cool: Python expresses
nesting of definition with indentation, not with full-stop
separators. Unless you implement it yourself, I'd expect
that it is unlilkely that anybody will act on this request
in the coming years.

----------------------------------------------------------------------

Comment By: Dan Parisien (mathematician)
Date: 2002-10-12 01:08

Message:
Logged In: YES 
user_id=118203

Repost with attempted better formatting: 
 
I don't want to do: 
class x: 
&nbsp;&nbsp;&nbsp;&nbsp;pass 
def new_method(self): 
&nbsp;&nbsp;&nbsp;&nbsp;pass 
x.new_method = new_method 
del new_method 
 
I want to do: 
class x: 
&nbsp;&nbsp;&nbsp;&nbsp;pass 
def x.new_method(self): 
&nbsp;&nbsp;&nbsp;&nbsp;pass 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 07:51:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 27 Jun 2003 23:51:36 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-606733 ] Docstring formatter.
Message-ID: <E19W9Ye-0007B6-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #606733, was opened at 2002-09-09 08:58
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=606733&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docstring formatter.

Initial Comment:
I think the code that pydoc uses to format docstrings 
(which is located in inspect.getdoc) should be exposed, 
so that you can in some way pass docstrings directly to 
be formatted, rather than "wrapping" them as a __doc__ 
attribute on a temporary object.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 01:51

Message:
Logged In: YES 
user_id=80475

The hassle of wrapping a __doc__ attribute is small and the 
use case is rare enough that there isn't much of a case for 
changing the module API.

Also, I'm concerned about module cohesion.  The purpose of 
the module is inspecting live objects.  Minor tweaking of 
docstring formatting is only a by-product and not a primary 
function.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=606733&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 08:11:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 00:11:32 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-533281 ] bsddb module needs iterators
Message-ID: <E19W9rw-0003mT-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #533281, was opened at 2002-03-21 15:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=533281&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael McFarland (sidlon)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb module needs iterators

Initial Comment:
  The hash, btree and record classes should have an iterator defined.  
The current first() and next() functions should make this a fairly 
simple change to bsddbmmodule.c.  This would allow:

  dbh = 
dbhash.open('mydb.db', 'r')
  for key in dbh:
    process(key, 
dbh[key])

and eliminate the temptation to use the following, 
which would be inadvisable for large databases:

  for key in 
dbh.keys():



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 02:11

Message:
Logged In: YES 
user_id=80475

Fixed.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-09 09:26

Message:
Logged In: YES 
user_id=21627

This is unlikely to happen. More likely, bsddb will be
deprecated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=533281&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 08:12:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 00:12:44 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-516762 ] have a way to search backwards for re
Message-ID: <E19W9t6-0003o1-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #516762, was opened at 2002-02-12 22:22
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=516762&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: have a way to search backwards for re

Initial Comment:
There doesn't seem to be any reasonable way to search
a string backwards for a regular expression, starting
from a given character position.  I notice that the
underlying C regular expression implemention supports
a direction flag.

I propose adding a direction flag to the search function
on match objects:

r = re.compile(...)
m = re.search(str, startpos=5000, endpos=-1, dir=-1)

would search in str for r, starting at
location 5000 and searching backwards through
location 0 (the beginning of the string).

This is useful in (for example) text editors where
you want to be able to search forwards or backwards,
or if you're parsing an html file and see a </table>
and want to find the matching <table>, etc.

phr


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 15:32

Message:
Logged In: YES 
user_id=21627

Moved to feature requests tracker.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=516762&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 08:15:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 00:15:14 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-481962 ] Make modules callable
Message-ID: <E19W9vW-0003rP-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #481962, was opened at 2001-11-14 23:11
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Thomas Justin Shaw (justinshaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make modules callable

Initial Comment:
Many modules are have the same name as the main class 
they contain.  I.E. 

gnu = Gnuplot.Gnuplot()

Why not make modules callable.  That is if a module 
contains a function called "__init__()" then that 
fucntion gets called whenever the code

x = module(args)

is encountered.

Just an idea.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 02:15

Message:
Logged In: YES 
user_id=80475

On python-dev, Guido vetoed any efforts to make modules 
look more like classes. 

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2003-03-10 11:36

Message:
Logged In: YES 
user_id=36166

It'd be better to do that on `__call__`.  One would expect
`__init__` to be called when the module object is
initialized (which is not really needed because you can
write it in a the top level).
This only makes sense as a complete upgrade of modules to
object capabilities, i.e. `__add__`, `__getitem__`,
`__setattr__` should be implemented then too.  I'm not sure
that's a good idea.
To be precise, the above ideas lose the distinction between
the type and it's instances - these special functions should
only be called for instances of the module but moduels don't
have instances...
An alternative proposal: implement just one magic function,
`__new__`, that if present is called at the end of the
import and the object returned by it is used instead of the
module.  This allows any objects (e.g. class instances with
all their magic) to be exposed as modules.  You can already
do this by installing any object in sys.modules; this would
provide a clean way to do it from inside the module.

----------------------------------------------------------------------

Comment By: Thomas Justin Shaw (justinshaw)
Date: 2003-01-23 19:19

Message:
Logged In: YES 
user_id=135558

The problem with:
from Gnuplot import Gnuplot
is that now you cannot do:
d = Gnuplot.Data()

Yes, I agree "__call__" is more explicit.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-22 23:48

Message:
Logged In: YES 
user_id=80475

I don't think this shortcut gives an advantage over:
     from Gnuplot import Gnuplot
     . . .
     x = Gnuplot(args)




----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2002-06-27 02:51

Message:
Logged In: YES 
user_id=50945

Wouldn't calling a function named "__call__" make more sense
than "__init__"?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 08:23:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 00:23:46 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444984 ] Type comparison
Message-ID: <E19WA3m-000421-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #444984, was opened at 2001-07-26 18:38
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=444984&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Kirill Simonov (kirill_simonov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Type comparison

Initial Comment:

1. Let X and Y be classes or types. Currently
    (X <= Y) == (id(X) <= id(Y)).
It would be more useful if
    (X <= Y) == issubclass(Y, X)

Unresolved issue:
    cmp(X, Y) == ???

2. Similar proposition for classes and instances:
    (x in X) == isinstance(x, X)
3. Proposition for Python 3.0:
    1 < "1" ==> Exception




----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 02:23

Message:
Logged In: YES 
user_id=80475

Closing this one because subclass relationships (even taking 
into account mro) establish an ordering relation only for 
classes in the same family.  

It was a nice thought though.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-12 19:43

Message:
Logged In: YES 
user_id=357491

But you used issubclass quite well for your need.  Is this really worth 
complicating the comparison code?  If you could write a patch to implement 
this you might be able to get it applied.

As for the Python 3 proposition, there has been a discussion of having 
comparisons like that fail or always return false when the types are different.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2001-09-18 13:40

Message:
Logged In: YES 
user_id=292741

Regarding (1); this is an interesting proposal,
the idea is to guarantee that classes sort in such an order
that base classes precede the subclasses. A problem here,
is that the comparison must have a commutative and
transitive property, or it could break all kinds of things; so you
need to do something like:
   X<Y:    if X is a subclass of Y  , then X>Y
              if Y is a subclass of X , then Y>X
             otherwise, compare id(X), id(Y)
The problem is that if A is a subclass of B,
X is a subclass of Y, then A>B, X>Y;
but if it turns out that B>X because 
id(B) > id(X), you would need A>X, A>Y,B>Y
to guarantee the transitive property. What I've
defined above doesn't do that. Rather a
challenge to define a transitive compare
with this property. Is it worth it when you
already have the issubclass() ?

cmp(X,Y) is defined if X<Y and X==Y etc are defined.
I don't see what's unresolved.

(2) no comment, except that it extends the definition
of 'in' to a new and quite different meaning. 

(3) needs more definition. This, I think, comes down
to the same issue as (1); if you are thinking that ideally
1<"2" should be true and 2<"10" should be
true and 4<"1" should be false, and that the
exception should be raised to warn you that this isn't
happening, I would point out that such an
ordering would again be (probably) impractical to
define as being transitive. In any case, "10"<"2"
and you don't want to change that (if you
do, check out my new project 'numacomp').
The current '<' comparison
is designed in such a way that ANY object
can be compared to ANY other object and
the results are transitive and commutative,
if totally arbitrary in many cases. 
If you can't do that with any two objects,
then you can't always compare lists or tuples
(which is done by comparing each member in
sequence). And then where are you?
Often you need the < operator ONLY so you
can sort things, in which case it has to
be defined and transitive, but the quirks
don't matter. So it should remain legal to
compare anything to anything.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=444984&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 08:45:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 00:45:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-745320 ] threads broke on FreeBSD current
Message-ID: <E19WAOj-0004ZS-00@sc8-sf-web2.sourceforge.net>

Bugs item #745320, was opened at 2003-05-29 05:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745320&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Till Plewe (tpx)
Assigned to: Nobody/Anonymous (nobody)
Summary: threads broke on FreeBSD current

Initial Comment:
default configuration builts with the snapshot taken at
05-24-230001 but not with the snapshot from
05-26-230001 (--without-threads builts)

I get the following compiler complaint when trying to
build python_2003-05-26-230001: 

c++  -Wl,--export-dynamic -o python  Modules/python.o 
libpython2.3.a -lutil   -
lm  
libpython2.3.a(posixmodule.o): In function `posix_tmpnam':
Modules/posixmodule.c:5785: warning: tmpnam() possibly
used unsafely; consider u
sing mkstemp()
libpython2.3.a(posixmodule.o): In function `posix_tempnam':
Modules/posixmodule.c:5738: warning: tempnam() possibly
used unsafely; consider 
using mkstemp()
libpython2.3.a(thread.o): In function
`PyThread_start_new_thread':
Python/thread_pthread.h:217: undefined reference to
`pthread_create'
Python/thread_pthread.h:253: undefined reference to
`pthread_detach'
*** Error code 1



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-28 09:45

Message:
Logged In: YES 
user_id=21627

Fixed with patch #758910.

----------------------------------------------------------------------

Comment By: Till Plewe (tpx)
Date: 2003-06-02 04:57

Message:
Logged In: YES 
user_id=782552

adding 

     LIBC=-lkse 

to the Makefile seems to do the trick. Python builds without
any 
further problems (I didn't use autoconf)


----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-01 09:27

Message:
Logged In: YES 
user_id=250749

I think what's missing here is the correct library reference.

I don't have a 5.x box at the moment, so can't check, but as
I recall, there are 2 options at the moment:-
 - libkse;
 - libthr.

Could you check my recollection and try adding the
appropriate library reference to the Makefile to see whether
you get a viable build?

Some autoconf-fu would then be required to make the setting
stick.

As the FreeBSD core team haven't yet designated anything
from the 5.x line as stable, this makes keeping track of the
non-trivial threading changes hard.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745320&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 08:55:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 00:55:04 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-533281 ] bsddb module needs iterators
Message-ID: <E19WAY4-0000yH-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #533281, was opened at 2002-03-21 21:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=533281&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael McFarland (sidlon)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb module needs iterators

Initial Comment:
  The hash, btree and record classes should have an iterator defined.  
The current first() and next() functions should make this a fairly 
simple change to bsddbmmodule.c.  This would allow:

  dbh = 
dbhash.open('mydb.db', 'r')
  for key in dbh:
    process(key, 
dbh[key])

and eliminate the temptation to use the following, 
which would be inadvisable for large databases:

  for key in 
dbh.keys():



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-28 09:55

Message:
Logged In: YES 
user_id=21627

In what way is this fixed? The test program still does not
work...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 09:11

Message:
Logged In: YES 
user_id=80475

Fixed.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-09 16:26

Message:
Logged In: YES 
user_id=21627

This is unlikely to happen. More likely, bsddb will be
deprecated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=533281&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 09:12:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 01:12:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-683486 ] Tutorial: info on Source Code Encoding is missing
Message-ID: <E19WApE-0003kk-00@sc8-sf-web1.sourceforge.net>

Bugs item #683486, was opened at 2003-02-09 18:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683486&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Roman Suzi (rnd0110)
Assigned to: Martin v. Löwis (loewis)
Summary: Tutorial: info on Source Code Encoding is missing

Initial Comment:
(I propose to add information into Tutorial on how
to specify source code encoding. Please correct
my English and maybe there is better way to 
get a list of possible encodings)



2.2.2  Executable Python Scripts 

...

2.2.3 Source Code Encoding

   It is possible to use encodings different than ASCII
in Python
   source files. The best way to do it is to put one more
   special comment line right after #!-line making
proper encoding
   declaration:
  
# -*- coding: latin-1 -*-

   After that, all characters in the source file will
be treated
   as belonging to latin-1 encoding, and it will be
possible
   to directly write Unicode strings in the selected
encoding.

   List of possible encodings could be found in the
encodings
   subdirectory of Python directory.

   Significant advantage could be had if using utf-8
encoding,
   as it allows to use letters from many languages in
the same
   file.

2.2.4

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-28 10:12

Message:
Logged In: YES 
user_id=21627

I have added text in tut.tex 1.188 which was heavily
inspired by Roman's text; thanks for contributing.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 20:43

Message:
Logged In: YES 
user_id=80475

Martin, I think something like the above wording should be 
added to the tutorial.  Do you have any wording suggestions?

* Instead of latin-1, it should list the ISO number.
* The encodings directory is a subdirectory of Lib.
* The last paragraph should be replaced and instead make 
your recommendation to arrange IDLE so that it
always stores files as UTF-8 with BOM.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683486&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 09:21:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 01:21:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-761504 ] Problem building site package bsddb3 on AIX
Message-ID: <E19WAxw-0001eX-00@sc8-sf-web3.sourceforge.net>

Bugs item #761504, was opened at 2003-06-27 00:24
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761504&group_id=5470

Category: Build
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Richard Wheeler (wheelrl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem building site package bsddb3 on AIX

Initial Comment:
Help.  Trying to build and install bsddb3-4.1.3 on AIX 
4.3.2.  Setup.py produce:

cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
I/mksDev/local/BerkeleyDB.4.1.25/include -
I/mksDev/local/include/python2.2 -c extsrc/_bsddb.c -o 
build/temp.aix-4.3-2.2/_bsddb.o

which the -W options are not valid with IBM's version 5 
compiler.  Removed the -W options and was able to 
compile _bsddb.o.

Linker runs next with:

/usr/local/lib/python2.2/config/ld_so_aix cc -
bI:/usr/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

which uses the wrong prefix, replaced it with:

/mksDev/local/lib/python2.2/config/ld_so_aix cc -
bI:/mksDev/local/lib/python2.2/config/python.exp 
build/temp.aix-4.3-2.2/_bsddb.o -
L/mksDev/local/BerkeleyDB.4.1.25/lib -ldb -o build/lib.aix-
4.3-2.2/bsddb3/_bsddb.so

now I get:

ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_lock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_signal
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_unlock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_trylock
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_wait
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutex_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_mutexattr_destroy
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_setpshared
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_cond_init
ld: 0711-317 ERROR: Undefined 
symbol: .pthread_condattr_destroy
ld: 0711-345 Use the -bloadmap or -bnoquiet option to 
obtain more information.

I could really use some help here.  I have successfully 
build the bsddb3 before with a prior version.

Thanks




----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-06-28 10:21

Message:
Logged In: YES 
user_id=21627

Finding BerkelyDB in other location than the standard
install locations is deliberately not supported in setup.py;
you need to edit Modules/Setup for non-standard installations.

As for the original bug: That looks like a BerkeleyDB or AIX
problem to me. Specifying -pthread should not be needed when
linking bsddb.so, instead, libbsdb-4.1.3 should be
self-contained. 

Did you install BerkeleyDB with --enable-shared? If not:
linking static libraries to extension modules is not
supported in setup.py; you have to edit Modules/Setup for
such an installation (on some systems, this is not supported
at all, as the system disallows non-PIC code in shared
libraries).

Also, the 2.2 bsddbmodule.c is not longer recommended for
2.3. So I'm closing this as Won't fix; AIX experts may still
step forward and provide patches in that area.

----------------------------------------------------------------------

Comment By: Richard Wheeler (wheelrl)
Date: 2003-06-27 13:28

Message:
Logged In: YES 
user_id=249546

Thanks for the reply.

Yes, Python 2.2.x runs fine on AIX 4.3.2.  Been using it on aix 
since about March of 2002.  Recently upgraded to 2.2.2.

Finally figured out to add the -lpthread option last night.  
bsddb3-4.1.3 now compliles fine on AIX 4.3.2.  All tests 
passed as well.  

Had to run the complier and linker manually.  DistUtils needs 
some work with --prefix option if folks are going to use it for 
distributing python modules.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-27 04:59

Message:
Logged In: YES 
user_id=33168

Have you got Python 2.2.x to work on AIX 4.2 or greater?  I
don't believe it works out of the box.

It appears that bsddb requires the pthread library.  You
will need to modify setup.py to add pthread to dblib around
line 444.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761504&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 10:30:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 02:30:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-666219 ] AssertionErrors in httplib
Message-ID: <E19WC2H-00078a-00@sc8-sf-web2.sourceforge.net>

Bugs item #666219, was opened at 2003-01-11 14:23
Message generated for change (Comment added) made by showme1949
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Skip Montanaro (montanaro)
Assigned to: Jeremy Hylton (jhylton)
Summary: AssertionErrors in httplib

Initial Comment:
I've recently noticed AssertionErrors being raised by
httplib.LineAndFileWrapper.read().  It happens reliably when the server
exits unexpectedly.  Here's an example of an AssertionError in an 
xmlrpclib client when I kill the server it's talking to:

    Traceback (most recent call last):
      File "qa.py", line 22, in ?
        x = s.query(tmpl, st, en, radius, age)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__
        return self.__send(self.__name, args)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request
        verbose=self.__verbose
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request
        return self._parse_response(h.getfile(), sock)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response
        response = file.read(1024)
      File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read
        assert not self._line_consumed and self._line_left
    AssertionError

I don't see a problem with raising an exception in this situation.  I just
wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code).  If an exception
is being raised because the server went away, I think it would be 
better to raise IncompleteRead.

----------------------------------------------------------------------

Comment By: AC (showme1949)
Date: 2003-06-28 09:30

Message:
Logged In: YES 
user_id=811410


OK, I saw this problem pretty in several programs (mine or
others). So I deed some search, here is a log that shown
self._line_consumed, self._line_left, self._line and
self._line_offset with bittorrent.

It is pretty obvious when the assert happens, we have a empty
self._line before we even start to read. Maybe because the
other end closed on us without sending any data.

A suggusted fix is to append 'and len(self._line) != 0'  to
the end of assert.
-------------- My log on the assert -------
==== line_consumeed, line_left ===
0
0

0
=== self._line, line_offset ===
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 414, in
__bootstrap
    self.run()
  File "/usr/lib/python2.2/threading.py", line 402, in run
    apply(self.__target, self.__args, self.__kwargs)
  File
"/usr/lib/python2.2/site-packages/BitTorrent/Rerequester.py",
line 76, in rer
equest
    r = h.read()
  File "/usr/lib/python2.2/httplib.py", line 1148, in read
    assert not self._line_consumed and self._line_left
AssertionError


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-05-05 16:48

Message:
Logged In: YES 
user_id=44345

[small timeout?]

Not since the changes to the makefile() changes to socket.py (or at least
not always).  If the timeout is shorter than the response time you now can
get a socket.error:

>>> socket.setdefaulttimeout(0.05)
>>> manatee = xmlrpclib.ServerProxy("http://manatee.mojam.com:5007")
>>> manatee.noop()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1021, in __call__
    return self.__send(self.__name, args)
  File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1308, in __request
    verbose=self.__verbose
  File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1056, in request
    errcode, errmsg, headers = h.getreply()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 1019, in getreply
    response = self._conn.getresponse()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 770, in getresponse
    response.begin()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 268, in begin
    version, status, reason = self._read_status()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 230, in _read_status
    line = self.fp.readline()
  File "/Users/skip/local/lib/python2.3/socket.py", line 321, in readline
    data = recv(1)
socket.error: (35, 'Resource temporarily unavailable')

I think you may still get the assertion error if the timeout is sufficient to
allow some of the response to be read, but not all of it (though that's just
a guess).

I suspect we're better off just closing this with either "postponed" or
"won't fix" at this point.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-05-05 16:33

Message:
Logged In: YES 
user_id=31392

We can provoke this error by setting a very small timeout,
right?


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-20 18:43

Message:
Logged In: YES 
user_id=44345

Sorry for the delay on this.  I think I'm closing in on the
problem.  I've been using Tim O'Malley's timeoutsocket
module for quite awhile.  I noticed the same problem today
when using the new timeout feature in the socket module.
Libraries like xmlrpclib use makefile() to get a file object
to play with.  File objects don't play well with timeouts
because the socket is in non-blocking mode.  I think what
happens here is that the first line of HTTPResponse.
_read_status sets line to the empty string because of the
timeout setting.  Tracing through the code which follows
makes it clear that control will wind up in the HTTP/0.9
chunk of code.

Maybe it's worth adding a test for line == "" after the
readline() call:

        line = self.fp.readline()
        if self.debuglevel > 0:
            print "reply:", repr(line)
        if line == "":
            raise BadStatusLine(line)

That would distinguish an error reading from an 0.9 server
(which would return something with that first readline()
call).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-31 14:13

Message:
Logged In: YES 
user_id=44345

No, sorry, I haven't looked more deeply into the problem.  I did investigate
far enough to also see that the code was in the HTTP/0.9 weeds and am
befuddled about why it would be there.  It's using the vanilla xmlrpclib
module at both ends.  I'll try to spend a little time today.

S

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-31 14:07

Message:
Logged In: YES 
user_id=31392

Any more info Skip?


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-14 21:18

Message:
Logged In: YES 
user_id=31392

It's definitely the case that an AssertionError shouldn't be
raised.  It was my intention that the assert never fail.  Do
you know which part of the assert fails?  Perhaps you could
change the assert to print the values of _line_consumed and
_line_left and run some more tests.
I can't figure out how this goes wrong.

Also, do you know when the server is sending an HTTP/0.9
response?  I wonder if there's a bug somewhere else and the
client is guessing the wrong protocol version for the response.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 13:02:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 05:02:35 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-533281 ] bsddb module needs iterators
Message-ID: <E19WEPb-0001QF-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #533281, was opened at 2002-03-21 15:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=533281&group_id=5470

Category: Python Library
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Michael McFarland (sidlon)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb module needs iterators

Initial Comment:
  The hash, btree and record classes should have an iterator defined.  
The current first() and next() functions should make this a fairly 
simple change to bsddbmmodule.c.  This would allow:

  dbh = 
dbhash.open('mydb.db', 'r')
  for key in dbh:
    process(key, 
dbh[key])

and eliminate the temptation to use the following, 
which would be inadvisable for large databases:

  for key in 
dbh.keys():



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 07:02

Message:
Logged In: YES 
user_id=80475

Re-opened. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-28 02:55

Message:
Logged In: YES 
user_id=21627

In what way is this fixed? The test program still does not
work...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 02:11

Message:
Logged In: YES 
user_id=80475

Fixed.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-09 09:26

Message:
Logged In: YES 
user_id=21627

This is unlikely to happen. More likely, bsddb will be
deprecated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=533281&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 15:01:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 07:01:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-761267 ] Failure in comparing unicode string
Message-ID: <E19WGGS-0006i3-00@sc8-sf-web2.sourceforge.net>

Bugs item #761267, was opened at 2003-06-26 18:02
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761267&group_id=5470

Category: Unicode
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Brown (skbrown1975)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Failure in comparing unicode string

Initial Comment:
Received a SystemError: C:\Code\22
\Objects\longobject.c:231: bad argument to internal 
function

The code was "if items[0] == self.InfoShareName:" 
where items is an array of strings and 
self.InfoShareName is a unicode string declared by 
self.InfoShareName = unicode(ShareName)

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-06-28 16:01

Message:
Logged In: YES 
user_id=38388

I can't see how your code could possibly cause the error
you indicate. Please provide an executable example with
real data.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-27 05:01

Message:
Logged In: YES 
user_id=33168

Can you attach a file which demonstrates this bug.  I cannot
reproduce it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761267&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 18:25:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 10:25:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-620190 ] inspect and object instances
Message-ID: <E19WJRu-00010q-00@sc8-sf-web3.sourceforge.net>

Bugs item #620190, was opened at 2002-10-08 12:26
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620190&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Jeremy Hylton (jhylton)
Summary: inspect and object instances

Initial Comment:
inspect.getargspec(NewKlass.aMethod)  fails (which
might technically be OK because the docs only mention
functions, not methods) but I also vaguely seem to
remember that some other operations in the inspect
module only worked for oldstyle classes under 2.2.1.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-28 17:25

Message:
Logged In: YES 
user_id=31392

The simple fix for getargspec() was checked in.  I'm not
going to do anything about the methodness suggestion.  I
don't think Python has a clear notion of which attributes
are methods and which are not.


----------------------------------------------------------------------

Comment By: Alexander Schmolck (aschmolck)
Date: 2003-06-22 17:05

Message:
Logged In: YES 
user_id=559641

a late reply RE: other problems (the notification I received
from SF for a (mysterious) 'settings change' prompted me to
look at this report again).

There doesn't seem to be a straightforwad way to test for
(instance) "methodness".
For example, I think it ought to be easy to get the
instance, class and/or staticmethods of something,
independent of whether it is old-style class, new-style
class or builtin type etc., which to most extents and
purposes is an insignificant implementation detail. For
example, I doubt the following will do what the casual
programmer expects:

>>> inspect.getmembers(foo, inspect.ismethod)

because foo might e.g. be a Numeric.array. The only function
in `inspect` that returns something along those lines that
is useful and understandable to someone who hasn't got the
most exquisite knowledge about python's
old-style/new-style/builin-type, method-wrapper, __slots__
etc. chaos is `classify_class_attrs', only that this doesn't
work for types or classes with __slots__ (at least the
latter ought to be fixed) and also packages together
functionality that I think should exist seperately.


----------------------------------------------------------------------

Comment By: Michael Stone (mbrierst)
Date: 2003-02-11 22:46

Message:
Logged In: YES 
user_id=670441

Well I think this (one line)
patch will make getargspec work with
methods, if anyone wants to apply it.
Did you find any other operations that
don't work?

patch:
Index: Lib/inspect.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/inspect.py,v
retrieving revision 1.41
diff -c -r1.41 inspect.py
*** Lib/inspect.py	19 Jan 2003 13:21:20 -0000	1.41
--- Lib/inspect.py	11 Feb 2003 22:35:41 -0000
***************
*** 16,22 ****
      getmodule() - determine the module that an object came from
      getclasstree() - arrange classes so as to represent their hierarchy
  
!     getargspec(), getargvalues() - get info about function arguments
      formatargspec(), formatargvalues() - format an argument spec
      getouterframes(), getinnerframes() - get info about frames
      currentframe() - get the current stack frame
--- 16,22 ----
      getmodule() - determine the module that an object came from
      getclasstree() - arrange classes so as to represent their hierarchy
  
!     getargspec(), getargvalues() - get info about function or method's arguments
      formatargspec(), formatargvalues() - format an argument spec
      getouterframes(), getinnerframes() - get info about frames
      currentframe() - get the current stack frame
***************
*** 625,636 ****
      return args, varargs, varkw
  
  def getargspec(func):
!     """Get the names and default values of a function's arguments.
  
      A tuple of four things is returned: (args, varargs, varkw, defaults).
      'args' is a list of the argument names (it may contain nested lists).
      'varargs' and 'varkw' are the names of the * and ** arguments or None.
      'defaults' is an n-tuple of the default values of the last n arguments."""
      if not isfunction(func): raise TypeError, 'arg is not a Python function'
      args, varargs, varkw = getargs(func.func_code)
      return args, varargs, varkw, func.func_defaults
--- 625,637 ----
      return args, varargs, varkw
  
  def getargspec(func):
!     """Get the names and default values of a function or method's arguments.
  
      A tuple of four things is returned: (args, varargs, varkw, defaults).
      'args' is a list of the argument names (it may contain nested lists).
      'varargs' and 'varkw' are the names of the * and ** arguments or None.
      'defaults' is an n-tuple of the default values of the last n arguments."""
+     if ismethod(func): func = func.im_func
      if not isfunction(func): raise TypeError, 'arg is not a Python function'
      args, varargs, varkw = getargs(func.func_code)
      return args, varargs, varkw, func.func_defaults


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620190&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 19:24:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 11:24:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-762455 ] Python segfaults when sys.stdout is changed in getattr
Message-ID: <E19WKNW-0004Hh-00@sc8-sf-web1.sourceforge.net>

Bugs item #762455, was opened at 2003-06-29 03: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=762455&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python segfaults when sys.stdout is changed in getattr

Initial Comment:
Reproducible source digest:

import sys 
class StdoutGuard: 
    def __getattr__(self, attr): 
        sys.stdout = sys.__stdout__ 
        raise RuntimeError("Premature access to 
sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


and Backtrace:

(gdb) bt
#0  0x00000002 in ?? ()
#1  0x08055ba6 in PyObject_GetAttrString 
(v=0x814b9e0,
    name=0x2 <Error reading address 0x2: Bad address>) 
at Objects/object.c:1066
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
#3  0x08071493 in eval_frame (f=0x8121c0c) at 
Python/ceval.c:1371
#4  0x080730be in PyEval_EvalCodeEx (co=0x8126500, 
globals=0x2, locals=0x2, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2595
#5  0x080702da in PyEval_EvalCode (co=0x8126500, 
globals=0x812fd0c, locals=0x812fd0c)
    at Python/ceval.c:481
#6  0x08089891 in run_node (n=0x8178a80, 
filename=0xbfbff648 "test.py", globals=0x812fd0c,
    locals=0x812fd0c, flags=0xbfbff4d8) at 
Python/pythonrun.c:1067
#7  0x08088af7 in PyRun_SimpleFileExFlags 
(fp=0x282c3780, filename=0xbfbff648 "test.py", 
closeit=1,
    flags=0xbfbff4d8) at Python/pythonrun.c:673
#8  0x08052a77 in Py_Main (argc=1, argv=0xbfbff538) 
at Modules/main.c:367
#9  0x080525cf in main (argc=2, argv=0xbfbff538) at 
Modules/python.c:10
#10 0x08052505 in _start ()
(gdb) f 2
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
1691            writer = PyObject_GetAttrString(f, "write");
(gdb) p *f
$22 = {ob_refcnt = 1000843696, ob_type = 0x814b9e0}


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 19:26:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 11:26:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-762455 ] Python segfaults when sys.stdout is changed in getattr
Message-ID: <E19WKPT-0004Kx-00@sc8-sf-web1.sourceforge.net>

Bugs item #762455, was opened at 2003-06-29 03:24
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python segfaults when sys.stdout is changed in getattr

Initial Comment:
Reproducible source digest:

import sys 
class StdoutGuard: 
    def __getattr__(self, attr): 
        sys.stdout = sys.__stdout__ 
        raise RuntimeError("Premature access to 
sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


and Backtrace:

(gdb) bt
#0  0x00000002 in ?? ()
#1  0x08055ba6 in PyObject_GetAttrString 
(v=0x814b9e0,
    name=0x2 <Error reading address 0x2: Bad address>) 
at Objects/object.c:1066
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
#3  0x08071493 in eval_frame (f=0x8121c0c) at 
Python/ceval.c:1371
#4  0x080730be in PyEval_EvalCodeEx (co=0x8126500, 
globals=0x2, locals=0x2, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2595
#5  0x080702da in PyEval_EvalCode (co=0x8126500, 
globals=0x812fd0c, locals=0x812fd0c)
    at Python/ceval.c:481
#6  0x08089891 in run_node (n=0x8178a80, 
filename=0xbfbff648 "test.py", globals=0x812fd0c,
    locals=0x812fd0c, flags=0xbfbff4d8) at 
Python/pythonrun.c:1067
#7  0x08088af7 in PyRun_SimpleFileExFlags 
(fp=0x282c3780, filename=0xbfbff648 "test.py", 
closeit=1,
    flags=0xbfbff4d8) at Python/pythonrun.c:673
#8  0x08052a77 in Py_Main (argc=1, argv=0xbfbff538) 
at Modules/main.c:367
#9  0x080525cf in main (argc=2, argv=0xbfbff538) at 
Modules/python.c:10
#10 0x08052505 in _start ()
(gdb) f 2
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
1691            writer = PyObject_GetAttrString(f, "write");
(gdb) p *f
$22 = {ob_refcnt = 1000843696, ob_type = 0x814b9e0}


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2003-06-29 03:26

Message:
Logged In: YES 
user_id=55188

import sys 
class StdoutGuard: 
&nbsp;&nbsp;&nbsp;&nbsp;def __getattr__(self, attr): 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sys.std
out = sys.__stdout__ 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;raise 
RuntimeError("Premature access to sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470


From noreply@sourceforge.net  Sat Jun 28 21:30:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 13:30:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-757542 ] Need to register PythonLauncher as handler for .py
Message-ID: <E19WMLR-0002V8-00@sc8-sf-web2.sourceforge.net>

Bugs item #757542, was opened at 2003-06-19 23:53
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757542&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Need to register PythonLauncher as handler for .py

Initial Comment:
We still need a way to register PythonLauncher as the 
handler for .py, pyw and .pyc documents. PythonLauncher 
itself could do this easily, but that requires people to run 
PythonLauncher at least once. Or we would have to 
arrange for the installer to do it, or (at the very least) the 
IDE.

The latter is difficult because we don't have access to the 
Launch Services API from Python, yet.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-28 22:30

Message:
Logged In: YES 
user_id=45365

Pascal Oberndoerfer tested the new installer on a fresh machine, 
and everything appears to be okay. By default the IDE opens 
python scripts, and PythonLauncher is the second choice. When 
PythonLauncher is run it will also show a (suppressible) warning 
if it isn't the current handler. That's good enough for me.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 23:22

Message:
Logged In: YES 
user_id=45365

Turns out there isn't an API for setting the handler, at least not a 
public one. But PythonLauncher now does test that it is the 
current handler, and shows a (supressible) warning dialog if it 
isn't.

I hope the magic of the installer, combined with the fact that 
PythonLancher advertises itself as being able to handle Python 
documents, will do the trick. I'm leaving this report open until 
that has been confirmed, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757542&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 00:28:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 16:28:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-762147 ] PackMan needs to be able to install outside site-packages
Message-ID: <E19WP7n-0003Ql-00@sc8-sf-web3.sourceforge.net>

Bugs item #762147, was opened at 2003-06-28 00:26
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762147&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PackMan needs to be able to install outside site-packages

Initial Comment:
PackMan needs to be able to install system-wide packages 
in /Library/Python/2.3/site-packages, in the event that the 
normal $prefix/lib/python2.3/site-packages is not writeable. 
That directory also needs to be put on sys.path (for 
framework OSX builds only) if it exists, similarly to ~/
Library/Python/2.3/site-packages.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-29 01:28

Message:
Logged In: YES 
user_id=45365

It turns out this is less of a problem than I feared: site-packages 
is a symlink to a place that is writable. There is still a problem 
when a distutils-based package tries to install extra header files, 
but that will have to be solved after 2.3b2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762147&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 01:51:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 17:51:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-762150 ] PackMan database needs stable URL
Message-ID: <E19WQPH-0005fA-00@sc8-sf-web3.sourceforge.net>

Bugs item #762150, was opened at 2003-06-28 00:30
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762150&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PackMan database needs stable URL

Initial Comment:
The URL for the database that PackMan uses is currently at 
homepages.cwi.nl, but there is CWI-internal discussion on 
URLs. As this URL is hardcoded into pimp.py it needs to be 
a stable URL. We need either a firm commitment from CWI 
or a location on www.python.org or both. The latter with 
implementing a multiple-URL scheme in pimp.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-06-29 02:51

Message:
Logged In: YES 
user_id=45365

The URL is now somewhere under http://www.python.org/
packman. There's nothing there yet, but that can wait for a few 
days.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762150&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 03:48:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 19:48:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-762455 ] Python segfaults when sys.stdout is changed in getattr
Message-ID: <E19WSEk-0006FH-00@sc8-sf-web4.sourceforge.net>

Bugs item #762455, was opened at 2003-06-28 14:24
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.2.3
Status: Open
Resolution: None
>Priority: 6
Submitted By: Hye-Shik Chang (perky)
>Assigned to: Tim Peters (tim_one)
Summary: Python segfaults when sys.stdout is changed in getattr

Initial Comment:
Reproducible source digest:

import sys 
class StdoutGuard: 
    def __getattr__(self, attr): 
        sys.stdout = sys.__stdout__ 
        raise RuntimeError("Premature access to 
sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


and Backtrace:

(gdb) bt
#0  0x00000002 in ?? ()
#1  0x08055ba6 in PyObject_GetAttrString 
(v=0x814b9e0,
    name=0x2 <Error reading address 0x2: Bad address>) 
at Objects/object.c:1066
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
#3  0x08071493 in eval_frame (f=0x8121c0c) at 
Python/ceval.c:1371
#4  0x080730be in PyEval_EvalCodeEx (co=0x8126500, 
globals=0x2, locals=0x2, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2595
#5  0x080702da in PyEval_EvalCode (co=0x8126500, 
globals=0x812fd0c, locals=0x812fd0c)
    at Python/ceval.c:481
#6  0x08089891 in run_node (n=0x8178a80, 
filename=0xbfbff648 "test.py", globals=0x812fd0c,
    locals=0x812fd0c, flags=0xbfbff4d8) at 
Python/pythonrun.c:1067
#7  0x08088af7 in PyRun_SimpleFileExFlags 
(fp=0x282c3780, filename=0xbfbff648 "test.py", 
closeit=1,
    flags=0xbfbff4d8) at Python/pythonrun.c:673
#8  0x08052a77 in Py_Main (argc=1, argv=0xbfbff538) 
at Modules/main.c:367
#9  0x080525cf in main (argc=2, argv=0xbfbff538) at 
Modules/python.c:10
#10 0x08052505 in _start ()
(gdb) f 2
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
1691            writer = PyObject_GetAttrString(f, "write");
(gdb) p *f
$22 = {ob_refcnt = 1000843696, ob_type = 0x814b9e0}


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 22:48

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.  I'm not
entirely sure the comment is accurate.  2.2.3 doesn't crash,
but goes into an infinite loop.  Tim should this go into 2.3b2?

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-06-28 14:26

Message:
Logged In: YES 
user_id=55188

import sys 
class StdoutGuard: 
&nbsp;&nbsp;&nbsp;&nbsp;def __getattr__(self, attr): 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sys.std
out = sys.__stdout__ 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;raise 
RuntimeError("Premature access to sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 04:09:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 20:09:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-761888 ] popen2.Popen3 and popen2.Popen4 leaks filedescriptors
Message-ID: <E19WSYo-000203-00@sc8-sf-web1.sourceforge.net>

Bugs item #761888, was opened at 2003-06-27 10:58
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761888&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Troels Walsted Hansen (troels)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen2.Popen3 and popen2.Popen4 leaks filedescriptors

Initial Comment:
The code below (from Lib/popen2.py) appears to leak no
less then 4 filedescriptors if os.fork() raises an
exception (say "OSError: [Errno 12] Not enough space"
on a Solaris box running out of swap).

Popen3.__init__() appears to leak 6 filedescriptors.

class Popen4(Popen3):
    def __init__(self, cmd, bufsize=-1):
        p2cread, p2cwrite = os.pipe()
        c2pread, c2pwrite = os.pipe()
        self.pid = os.fork()


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 23:09

Message:
Logged In: YES 
user_id=33168

The attached patch should fix the problem, I'd appreciate if
you could test this.  There are 2 files attached, one is a
context diff with whitespace modifications, the other is a
minimal (no whitespace differences) patch to show what's
changed (ie, the try/except).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761888&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 04:10:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 20:10:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-761888 ] popen2.Popen3 and popen2.Popen4 leaks filedescriptors
Message-ID: <E19WSa5-0006j2-00@sc8-sf-web4.sourceforge.net>

Bugs item #761888, was opened at 2003-06-27 10:58
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761888&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Troels Walsted Hansen (troels)
>Assigned to: Tim Peters (tim_one)
Summary: popen2.Popen3 and popen2.Popen4 leaks filedescriptors

Initial Comment:
The code below (from Lib/popen2.py) appears to leak no
less then 4 filedescriptors if os.fork() raises an
exception (say "OSError: [Errno 12] Not enough space"
on a Solaris box running out of swap).

Popen3.__init__() appears to leak 6 filedescriptors.

class Popen4(Popen3):
    def __init__(self, cmd, bufsize=-1):
        p2cread, p2cwrite = os.pipe()
        c2pread, c2pwrite = os.pipe()
        self.pid = os.fork()


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 23:10

Message:
Logged In: YES 
user_id=33168

Tim, for 2.3b2 or 2.3.1?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 23:09

Message:
Logged In: YES 
user_id=33168

The attached patch should fix the problem, I'd appreciate if
you could test this.  There are 2 files attached, one is a
context diff with whitespace modifications, the other is a
minimal (no whitespace differences) patch to show what's
changed (ie, the try/except).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761888&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 04:35:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 20:35:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-758239 ] socket timeout exception unhelpful
Message-ID: <E19WSye-0002VF-00@sc8-sf-web1.sourceforge.net>

Bugs item #758239, was opened at 2003-06-20 20:27
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758239&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bob Halley (rthalley)
Assigned to: Raymond Hettinger (rhettinger)
Summary: socket timeout exception unhelpful

Initial Comment:
The new settimeout feature for sockets is great, but
the exception that is raised on timeout, socket.error,
is not very helpful.  It's not
possible to write code which catches and deals with
timeouts as opposed to the multitude of other socket
errors.

Even looking at the additional detail isn't helpful,
because you get errnos like EINPROGRESS or EAGAIN,
because the socket code doesn't deal with timeouts
explicitly when it selects.  Rather, it just lets the
internal_select() return, and then you get an error
when whatever was doing the waiting tries to do its
operation.

I propose that a new exception:

class socket.timeout(socket.error):
    pass

be created, and raised whenever the internal_select
times out (i.e. select() returns 0).

This lets applications catch socket.timeout
specifically if they want to, but also allows existing
code to catch socket.error and get all socket-related
exceptions.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 22:35

Message:
Logged In: YES 
user_id=80475

Applied patch #760257.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-27 05:55

Message:
Logged In: YES 
user_id=6380

I agree too. Raymond, can you prepare a minimal patch?

Given my location at EuroPython, an email with the patch
would be appreciated (in addition to SF upload).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-25 10:20

Message:
Logged In: YES 
user_id=80475

I agree this would be a useful API change.

Guido, do you concur?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758239&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 04:38:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 20:38:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-762455 ] Python segfaults when sys.stdout is changed in getattr
Message-ID: <E19WT1m-0002ZD-00@sc8-sf-web1.sourceforge.net>

Bugs item #762455, was opened at 2003-06-28 13:24
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Hye-Shik Chang (perky)
Assigned to: Tim Peters (tim_one)
Summary: Python segfaults when sys.stdout is changed in getattr

Initial Comment:
Reproducible source digest:

import sys 
class StdoutGuard: 
    def __getattr__(self, attr): 
        sys.stdout = sys.__stdout__ 
        raise RuntimeError("Premature access to 
sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


and Backtrace:

(gdb) bt
#0  0x00000002 in ?? ()
#1  0x08055ba6 in PyObject_GetAttrString 
(v=0x814b9e0,
    name=0x2 <Error reading address 0x2: Bad address>) 
at Objects/object.c:1066
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
#3  0x08071493 in eval_frame (f=0x8121c0c) at 
Python/ceval.c:1371
#4  0x080730be in PyEval_EvalCodeEx (co=0x8126500, 
globals=0x2, locals=0x2, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2595
#5  0x080702da in PyEval_EvalCode (co=0x8126500, 
globals=0x812fd0c, locals=0x812fd0c)
    at Python/ceval.c:481
#6  0x08089891 in run_node (n=0x8178a80, 
filename=0xbfbff648 "test.py", globals=0x812fd0c,
    locals=0x812fd0c, flags=0xbfbff4d8) at 
Python/pythonrun.c:1067
#7  0x08088af7 in PyRun_SimpleFileExFlags 
(fp=0x282c3780, filename=0xbfbff648 "test.py", 
closeit=1,
    flags=0xbfbff4d8) at Python/pythonrun.c:673
#8  0x08052a77 in Py_Main (argc=1, argv=0xbfbff538) 
at Modules/main.c:367
#9  0x080525cf in main (argc=2, argv=0xbfbff538) at 
Modules/python.c:10
#10 0x08052505 in _start ()
(gdb) f 2
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
1691            writer = PyObject_GetAttrString(f, "write");
(gdb) p *f
$22 = {ob_refcnt = 1000843696, ob_type = 0x814b9e0}


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 22:38

Message:
Logged In: YES 
user_id=80475

This looks like a clean fix to me and ought to go into 2.3b2 
so it can be shaken out further.

Please use filefault.py to create a unittest.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 21:48

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.  I'm not
entirely sure the comment is accurate.  2.2.3 doesn't crash,
but goes into an infinite loop.  Tim should this go into 2.3b2?

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-06-28 13:26

Message:
Logged In: YES 
user_id=55188

import sys 
class StdoutGuard: 
&nbsp;&nbsp;&nbsp;&nbsp;def __getattr__(self, attr): 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sys.std
out = sys.__stdout__ 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;raise 
RuntimeError("Premature access to sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 05:58:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 21:58:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-762455 ] Python segfaults when sys.stdout is changed in getattr
Message-ID: <E19WUGI-0000fG-00@sc8-sf-web4.sourceforge.net>

Bugs item #762455, was opened at 2003-06-28 14:24
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Hye-Shik Chang (perky)
Assigned to: Tim Peters (tim_one)
Summary: Python segfaults when sys.stdout is changed in getattr

Initial Comment:
Reproducible source digest:

import sys 
class StdoutGuard: 
    def __getattr__(self, attr): 
        sys.stdout = sys.__stdout__ 
        raise RuntimeError("Premature access to 
sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


and Backtrace:

(gdb) bt
#0  0x00000002 in ?? ()
#1  0x08055ba6 in PyObject_GetAttrString 
(v=0x814b9e0,
    name=0x2 <Error reading address 0x2: Bad address>) 
at Objects/object.c:1066
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
#3  0x08071493 in eval_frame (f=0x8121c0c) at 
Python/ceval.c:1371
#4  0x080730be in PyEval_EvalCodeEx (co=0x8126500, 
globals=0x2, locals=0x2, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2595
#5  0x080702da in PyEval_EvalCode (co=0x8126500, 
globals=0x812fd0c, locals=0x812fd0c)
    at Python/ceval.c:481
#6  0x08089891 in run_node (n=0x8178a80, 
filename=0xbfbff648 "test.py", globals=0x812fd0c,
    locals=0x812fd0c, flags=0xbfbff4d8) at 
Python/pythonrun.c:1067
#7  0x08088af7 in PyRun_SimpleFileExFlags 
(fp=0x282c3780, filename=0xbfbff648 "test.py", 
closeit=1,
    flags=0xbfbff4d8) at Python/pythonrun.c:673
#8  0x08052a77 in Py_Main (argc=1, argv=0xbfbff538) 
at Modules/main.c:367
#9  0x080525cf in main (argc=2, argv=0xbfbff538) at 
Modules/python.c:10
#10 0x08052505 in _start ()
(gdb) f 2
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
1691            writer = PyObject_GetAttrString(f, "write");
(gdb) p *f
$22 = {ob_refcnt = 1000843696, ob_type = 0x814b9e0}


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-29 00:58

Message:
Logged In: YES 
user_id=33168

I couldn't get the test working.  It always passed, before
and after the fix.  I would like to have a test for this,
but no time now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 23:38

Message:
Logged In: YES 
user_id=80475

This looks like a clean fix to me and ought to go into 2.3b2 
so it can be shaken out further.

Please use filefault.py to create a unittest.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 22:48

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.  I'm not
entirely sure the comment is accurate.  2.2.3 doesn't crash,
but goes into an infinite loop.  Tim should this go into 2.3b2?

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-06-28 14:26

Message:
Logged In: YES 
user_id=55188

import sys 
class StdoutGuard: 
&nbsp;&nbsp;&nbsp;&nbsp;def __getattr__(self, attr): 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sys.std
out = sys.__stdout__ 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;raise 
RuntimeError("Premature access to sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 06:07:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 22:07:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE
Message-ID: <E19WUPZ-0006i5-00@sc8-sf-web2.sourceforge.net>

Bugs item #430160, was opened at 2001-06-04 19:09
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Raymond Hettinger (rhettinger)
Summary: CGIHTTPServer.py POST bug using IE

Initial Comment:
>From the readme included in the zip:
This set of files shows a bug that occurs when doing 
POST requests via the CGIHTTPServer.py module in 
Python 2.1 The testpost.html file when accessed via 
Internet Explorer 5.5 from webserver.py should show 
this bug. On short POST requests IE will end up doing 
a second POST and then displaying an error message 
while longer POSTs will be followed by a second POST 
and then a GET.

The problem appears to be specific to the interaction 
of IE and the handling of windows sockets in Python in 
the CGIHTTPServer.py module which relies on 
BaseHTTPServer.py, SocketServer.py...

posttestwebserver.py is currently setup to use 
C:\tmp\testpost as the document root, so either move 
the "testpost" folder to C:\tmp or change the 
directory to wherever the testpost folder is located. 
Start the server using the .bat file and bring 
up .html page with something like:
  http://localhost/testpost.html

The bug should occur when you try:
  Test short CGI response with POST
or
  Test long CGI response with POST

The other requests should work fine. The bug will 
occur regardless of whether IE is set to use HTTP/1.0 
or HTTP/1.1. The bug doesn't appear to occur when 
going through a simple proxy. You can also get the bug 
to occur using a remote IE client (either on a LAN or 
over the Net). In addition, it doesn't appear to 
matter whether running with unbuffered binary pipes 
(python -u) or not. I also tested against my modified 
CGIHTTPServer.py See the bug I posted at:
http://sourceforge.net/tracker/?
func=detail&atid=105470&aid=427345&group_id=5470

My configuration:
Windows 2000 Pro, SP2
AMD 1.2GHz
256MB RAM
ActiveStatet Python 2.1 (build 210)
Internet Explorer 5.5 (5.50.4522.1800)

ka
---
Mark Lutz said:
"FWIW, I noticed today (in between lecturing a class) 
that on Windows, Python actually uses a special Python-
coded socket.py library module, not the standard C-
coded socket extension module.  socket.py lives in the 
library directory; it does unique things for closes 
and deletes that may not make sense in all cases 
(e.g., the makefile call generates a class instance, 
not a true file object).  It may also be trying to 
close the underlying socket twice.  I don't have"


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-29 00:07

Message:
Logged In: YES 
user_id=80475

Applied to both the Unix and Windows flavors.
Closing bug.  Hopefully it stays dead this time.

See Lib/CGIHTTPServer.py 1.31


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-27 05:59

Message:
Logged In: YES 
user_id=6380

Raymond, can you fix this? Seems simple enough...

----------------------------------------------------------------------

Comment By: Wolfgang Ocker (weoweo)
Date: 2003-06-24 15:58

Message:
Logged In: YES 
user_id=23630

The patch might cause the server to loop endlessly, if the
client has closed the connection. I suggest to change the
patch as follows:

   while select.select([self.rfile], [], [], 0)[0]:
-    waste = self.rfile.read(1)

to

   while select.select([self.rfile], [], [], 0)[0]:
+    if not self.rfile.read(1): break

Maybe this is necessary for the Windows case as well ...

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2003-01-08 13:58

Message:
Logged In: YES 
user_id=88157

Should be fixed by patch 654910 committed today.

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-15 21:25

Message:
Logged In: YES 
user_id=88157

This patch appears to fix the basic CGIHTTPServer behavior, 
at least for Unix and Wiondows platforms, but I'm not yet 
confident of its robustness in the face of Forking or threading 
mixin code. More later ...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 09:57

Message:
Logged In: YES 
user_id=6380

Steve, I'm assigning this bug to you. Feel free to check in
a fix if you think one exists (as long as it doesn't break
on Unix).

----------------------------------------------------------------------

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 15:49

Message:
Logged In: YES 
user_id=247536

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.

not sure what the real fix for this should be?


----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 06:28

Message:
Logged In: YES 
user_id=88157

Please note that I have observed this behavior on Windows
98 using Python 2.0 (#8, Mar  7 2001, 16:04:37) [MSC 32 bit 
(Intel)] using the same build of IE, so it is not a Win2k-
specific problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 06:08:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 22:08:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE
Message-ID: <E19WUQ6-0006iu-00@sc8-sf-web2.sourceforge.net>

Bugs item #430160, was opened at 2001-06-04 19:09
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470

Category: Windows
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Raymond Hettinger (rhettinger)
Summary: CGIHTTPServer.py POST bug using IE

Initial Comment:
>From the readme included in the zip:
This set of files shows a bug that occurs when doing 
POST requests via the CGIHTTPServer.py module in 
Python 2.1 The testpost.html file when accessed via 
Internet Explorer 5.5 from webserver.py should show 
this bug. On short POST requests IE will end up doing 
a second POST and then displaying an error message 
while longer POSTs will be followed by a second POST 
and then a GET.

The problem appears to be specific to the interaction 
of IE and the handling of windows sockets in Python in 
the CGIHTTPServer.py module which relies on 
BaseHTTPServer.py, SocketServer.py...

posttestwebserver.py is currently setup to use 
C:\tmp\testpost as the document root, so either move 
the "testpost" folder to C:\tmp or change the 
directory to wherever the testpost folder is located. 
Start the server using the .bat file and bring 
up .html page with something like:
  http://localhost/testpost.html

The bug should occur when you try:
  Test short CGI response with POST
or
  Test long CGI response with POST

The other requests should work fine. The bug will 
occur regardless of whether IE is set to use HTTP/1.0 
or HTTP/1.1. The bug doesn't appear to occur when 
going through a simple proxy. You can also get the bug 
to occur using a remote IE client (either on a LAN or 
over the Net). In addition, it doesn't appear to 
matter whether running with unbuffered binary pipes 
(python -u) or not. I also tested against my modified 
CGIHTTPServer.py See the bug I posted at:
http://sourceforge.net/tracker/?
func=detail&atid=105470&aid=427345&group_id=5470

My configuration:
Windows 2000 Pro, SP2
AMD 1.2GHz
256MB RAM
ActiveStatet Python 2.1 (build 210)
Internet Explorer 5.5 (5.50.4522.1800)

ka
---
Mark Lutz said:
"FWIW, I noticed today (in between lecturing a class) 
that on Windows, Python actually uses a special Python-
coded socket.py library module, not the standard C-
coded socket extension module.  socket.py lives in the 
library directory; it does unique things for closes 
and deletes that may not make sense in all cases 
(e.g., the makefile call generates a class instance, 
not a true file object).  It may also be trying to 
close the underlying socket twice.  I don't have"


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-29 00:07

Message:
Logged In: YES 
user_id=80475

Applied to both the Unix and Windows flavors.
Closing bug.  Hopefully it stays dead this time.

See Lib/CGIHTTPServer.py 1.31


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-27 05:59

Message:
Logged In: YES 
user_id=6380

Raymond, can you fix this? Seems simple enough...

----------------------------------------------------------------------

Comment By: Wolfgang Ocker (weoweo)
Date: 2003-06-24 15:58

Message:
Logged In: YES 
user_id=23630

The patch might cause the server to loop endlessly, if the
client has closed the connection. I suggest to change the
patch as follows:

   while select.select([self.rfile], [], [], 0)[0]:
-    waste = self.rfile.read(1)

to

   while select.select([self.rfile], [], [], 0)[0]:
+    if not self.rfile.read(1): break

Maybe this is necessary for the Windows case as well ...

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2003-01-08 13:58

Message:
Logged In: YES 
user_id=88157

Should be fixed by patch 654910 committed today.

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-15 21:25

Message:
Logged In: YES 
user_id=88157

This patch appears to fix the basic CGIHTTPServer behavior, 
at least for Unix and Wiondows platforms, but I'm not yet 
confident of its robustness in the face of Forking or threading 
mixin code. More later ...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 09:57

Message:
Logged In: YES 
user_id=6380

Steve, I'm assigning this bug to you. Feel free to check in
a fix if you think one exists (as long as it doesn't break
on Unix).

----------------------------------------------------------------------

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 15:49

Message:
Logged In: YES 
user_id=247536

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.

not sure what the real fix for this should be?


----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 06:28

Message:
Logged In: YES 
user_id=88157

Please note that I have observed this behavior on Windows
98 using Python 2.0 (#8, Mar  7 2001, 16:04:37) [MSC 32 bit 
(Intel)] using the same build of IE, so it is not a Win2k-
specific problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 06:27:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 22:27:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-762455 ] Python segfaults when sys.stdout is changed in getattr
Message-ID: <E19WUj1-0004j4-00@sc8-sf-web1.sourceforge.net>

Bugs item #762455, was opened at 2003-06-28 13:24
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Hye-Shik Chang (perky)
Assigned to: Tim Peters (tim_one)
Summary: Python segfaults when sys.stdout is changed in getattr

Initial Comment:
Reproducible source digest:

import sys 
class StdoutGuard: 
    def __getattr__(self, attr): 
        sys.stdout = sys.__stdout__ 
        raise RuntimeError("Premature access to 
sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


and Backtrace:

(gdb) bt
#0  0x00000002 in ?? ()
#1  0x08055ba6 in PyObject_GetAttrString 
(v=0x814b9e0,
    name=0x2 <Error reading address 0x2: Bad address>) 
at Objects/object.c:1066
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
#3  0x08071493 in eval_frame (f=0x8121c0c) at 
Python/ceval.c:1371
#4  0x080730be in PyEval_EvalCodeEx (co=0x8126500, 
globals=0x2, locals=0x2, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2595
#5  0x080702da in PyEval_EvalCode (co=0x8126500, 
globals=0x812fd0c, locals=0x812fd0c)
    at Python/ceval.c:481
#6  0x08089891 in run_node (n=0x8178a80, 
filename=0xbfbff648 "test.py", globals=0x812fd0c,
    locals=0x812fd0c, flags=0xbfbff4d8) at 
Python/pythonrun.c:1067
#7  0x08088af7 in PyRun_SimpleFileExFlags 
(fp=0x282c3780, filename=0xbfbff648 "test.py", 
closeit=1,
    flags=0xbfbff4d8) at Python/pythonrun.c:673
#8  0x08052a77 in Py_Main (argc=1, argv=0xbfbff538) 
at Modules/main.c:367
#9  0x080525cf in main (argc=2, argv=0xbfbff538) at 
Modules/python.c:10
#10 0x08052505 in _start ()
(gdb) f 2
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
1691            writer = PyObject_GetAttrString(f, "write");
(gdb) p *f
$22 = {ob_refcnt = 1000843696, ob_type = 0x814b9e0}


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-29 00:27

Message:
Logged In: YES 
user_id=80475

filefault.py fails for me before the patch and succeeds after 
the patch.

If you go ahead and apply the patch, I'll write the test.
Do you have an idea which test_*.py is the best place for it?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 23:58

Message:
Logged In: YES 
user_id=33168

I couldn't get the test working.  It always passed, before
and after the fix.  I would like to have a test for this,
but no time now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 22:38

Message:
Logged In: YES 
user_id=80475

This looks like a clean fix to me and ought to go into 2.3b2 
so it can be shaken out further.

Please use filefault.py to create a unittest.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 21:48

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.  I'm not
entirely sure the comment is accurate.  2.2.3 doesn't crash,
but goes into an infinite loop.  Tim should this go into 2.3b2?

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-06-28 13:26

Message:
Logged In: YES 
user_id=55188

import sys 
class StdoutGuard: 
&nbsp;&nbsp;&nbsp;&nbsp;def __getattr__(self, attr): 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sys.std
out = sys.__stdout__ 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;raise 
RuntimeError("Premature access to sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 06:56:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 28 Jun 2003 22:56:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-762455 ] Python segfaults when sys.stdout is changed in getattr
Message-ID: <E19WVAd-00040P-00@sc8-sf-web3.sourceforge.net>

Bugs item #762455, was opened at 2003-06-28 14:24
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Hye-Shik Chang (perky)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Python segfaults when sys.stdout is changed in getattr

Initial Comment:
Reproducible source digest:

import sys 
class StdoutGuard: 
    def __getattr__(self, attr): 
        sys.stdout = sys.__stdout__ 
        raise RuntimeError("Premature access to 
sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


and Backtrace:

(gdb) bt
#0  0x00000002 in ?? ()
#1  0x08055ba6 in PyObject_GetAttrString 
(v=0x814b9e0,
    name=0x2 <Error reading address 0x2: Bad address>) 
at Objects/object.c:1066
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
#3  0x08071493 in eval_frame (f=0x8121c0c) at 
Python/ceval.c:1371
#4  0x080730be in PyEval_EvalCodeEx (co=0x8126500, 
globals=0x2, locals=0x2, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2595
#5  0x080702da in PyEval_EvalCode (co=0x8126500, 
globals=0x812fd0c, locals=0x812fd0c)
    at Python/ceval.c:481
#6  0x08089891 in run_node (n=0x8178a80, 
filename=0xbfbff648 "test.py", globals=0x812fd0c,
    locals=0x812fd0c, flags=0xbfbff4d8) at 
Python/pythonrun.c:1067
#7  0x08088af7 in PyRun_SimpleFileExFlags 
(fp=0x282c3780, filename=0xbfbff648 "test.py", 
closeit=1,
    flags=0xbfbff4d8) at Python/pythonrun.c:673
#8  0x08052a77 in Py_Main (argc=1, argv=0xbfbff538) 
at Modules/main.c:367
#9  0x080525cf in main (argc=2, argv=0xbfbff538) at 
Modules/python.c:10
#10 0x08052505 in _start ()
(gdb) f 2
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
1691            writer = PyObject_GetAttrString(f, "write");
(gdb) p *f
$22 = {ob_refcnt = 1000843696, ob_type = 0x814b9e0}


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-29 01:56

Message:
Logged In: YES 
user_id=31435

I can't make time to analyze the problem, but the comment 
sounds plausible <wink>.

The fix isn't quite right, though:  because w can be NULL, you 
have to use Py_XINCREF and Py_XDECREF instead of 
Py_INCREF and Py_DECREF.  The latter will probably segfault 
when w is NULL.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-29 01:27

Message:
Logged In: YES 
user_id=80475

filefault.py fails for me before the patch and succeeds after 
the patch.

If you go ahead and apply the patch, I'll write the test.
Do you have an idea which test_*.py is the best place for it?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-29 00:58

Message:
Logged In: YES 
user_id=33168

I couldn't get the test working.  It always passed, before
and after the fix.  I would like to have a test for this,
but no time now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 23:38

Message:
Logged In: YES 
user_id=80475

This looks like a clean fix to me and ought to go into 2.3b2 
so it can be shaken out further.

Please use filefault.py to create a unittest.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 22:48

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.  I'm not
entirely sure the comment is accurate.  2.2.3 doesn't crash,
but goes into an infinite loop.  Tim should this go into 2.3b2?

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-06-28 14:26

Message:
Logged In: YES 
user_id=55188

import sys 
class StdoutGuard: 
&nbsp;&nbsp;&nbsp;&nbsp;def __getattr__(self, attr): 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sys.std
out = sys.__stdout__ 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;raise 
RuntimeError("Premature access to sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 10:07:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 02:07:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-762614 ] problem building c extension with minGW on Windows
Message-ID: <E19WY9M-0003d4-00@sc8-sf-web2.sourceforge.net>

Bugs item #762614, was opened at 2003-06-29 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=762614&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fuming Wang (fumingw)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem building c extension with minGW on Windows

Initial Comment:

I am having problems building C extension on Python
2.3b1 on Windows 2000 with latest minGW. The culprit
seems to be calling of Py_None.  Here is a test module,
which builds happily on python 2.2.3.

Here is build options:
 gcc -mno-cygwin -mdll -O -Wall
-Id:\fuming\lib\python\include -c spam.c -o spam.o


 dllwrap -mno-cygwin -mdll -static --dllname spam.pyd
--driver-name gcc --def spam.def -o spam.pyd s
pam.o -s --entry _DllMain@12 --target=i386-mingw32
-Ld:\fuming\lib\python\libs -lpython23


Here is the error message I get on Python 2.3b1:
spam.o(.text+0x60):spam.c: undefined reference to
`_imp___Py_NoneStruct'
spam.o(.text+0x68):spam.c: undefined reference to
`_imp___Py_NoneStruct'
dllwrap: gcc exited with status 1

Here is the source code:


/* c function */
static PyObject *
spam_system(PyObject *self, PyObject *input_str)
{
    char *local_string;
    int length;

    if (!PyArg_ParseTuple(input_str, "s#",
&local_string, &length)) {
        return NULL;
    }

    printf("%s\n", local_string);        
    printf("number of letters = %d\n", length);

    
    Py_INCREF(Py_None);
    return Py_None;
  

    /*
    return Py_BuildValue("i", length);
    */

};

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762614&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 15:57:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 07:57:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-762455 ] Python segfaults when sys.stdout is changed in getattr
Message-ID: <E19WdcS-0001BM-00@sc8-sf-web4.sourceforge.net>

Bugs item #762455, was opened at 2003-06-28 14:24
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
>Resolution: Fixed
>Priority: 5
Submitted By: Hye-Shik Chang (perky)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Python segfaults when sys.stdout is changed in getattr

Initial Comment:
Reproducible source digest:

import sys 
class StdoutGuard: 
    def __getattr__(self, attr): 
        sys.stdout = sys.__stdout__ 
        raise RuntimeError("Premature access to 
sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


and Backtrace:

(gdb) bt
#0  0x00000002 in ?? ()
#1  0x08055ba6 in PyObject_GetAttrString 
(v=0x814b9e0,
    name=0x2 <Error reading address 0x2: Bad address>) 
at Objects/object.c:1066
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
#3  0x08071493 in eval_frame (f=0x8121c0c) at 
Python/ceval.c:1371
#4  0x080730be in PyEval_EvalCodeEx (co=0x8126500, 
globals=0x2, locals=0x2, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2595
#5  0x080702da in PyEval_EvalCode (co=0x8126500, 
globals=0x812fd0c, locals=0x812fd0c)
    at Python/ceval.c:481
#6  0x08089891 in run_node (n=0x8178a80, 
filename=0xbfbff648 "test.py", globals=0x812fd0c,
    locals=0x812fd0c, flags=0xbfbff4d8) at 
Python/pythonrun.c:1067
#7  0x08088af7 in PyRun_SimpleFileExFlags 
(fp=0x282c3780, filename=0xbfbff648 "test.py", 
closeit=1,
    flags=0xbfbff4d8) at Python/pythonrun.c:673
#8  0x08052a77 in Py_Main (argc=1, argv=0xbfbff538) 
at Modules/main.c:367
#9  0x080525cf in main (argc=2, argv=0xbfbff538) at 
Modules/python.c:10
#10 0x08052505 in _start ()
(gdb) f 2
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
1691            writer = PyObject_GetAttrString(f, "write");
(gdb) p *f
$22 = {ob_refcnt = 1000843696, ob_type = 0x814b9e0}


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-29 10:57

Message:
Logged In: YES 
user_id=33168

Checked in as:
 * Python/ceval.c 2.367 & 2.301.4.9

Assigned to Raymond to make a test.

As for the test, in test_descr.specials() there is some
stdout handling at the end of the function (around line
1881).  I don't know of a better place than that.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-29 01:56

Message:
Logged In: YES 
user_id=31435

I can't make time to analyze the problem, but the comment 
sounds plausible <wink>.

The fix isn't quite right, though:  because w can be NULL, you 
have to use Py_XINCREF and Py_XDECREF instead of 
Py_INCREF and Py_DECREF.  The latter will probably segfault 
when w is NULL.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-29 01:27

Message:
Logged In: YES 
user_id=80475

filefault.py fails for me before the patch and succeeds after 
the patch.

If you go ahead and apply the patch, I'll write the test.
Do you have an idea which test_*.py is the best place for it?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-29 00:58

Message:
Logged In: YES 
user_id=33168

I couldn't get the test working.  It always passed, before
and after the fix.  I would like to have a test for this,
but no time now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 23:38

Message:
Logged In: YES 
user_id=80475

This looks like a clean fix to me and ought to go into 2.3b2 
so it can be shaken out further.

Please use filefault.py to create a unittest.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 22:48

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.  I'm not
entirely sure the comment is accurate.  2.2.3 doesn't crash,
but goes into an infinite loop.  Tim should this go into 2.3b2?

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-06-28 14:26

Message:
Logged In: YES 
user_id=55188

import sys 
class StdoutGuard: 
&nbsp;&nbsp;&nbsp;&nbsp;def __getattr__(self, attr): 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sys.std
out = sys.__stdout__ 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;raise 
RuntimeError("Premature access to sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 16:45:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 08:45:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-762455 ] Python segfaults when sys.stdout is changed in getattr
Message-ID: <E19WeMh-0007cT-00@sc8-sf-web2.sourceforge.net>

Bugs item #762455, was opened at 2003-06-28 13:24
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Python segfaults when sys.stdout is changed in getattr

Initial Comment:
Reproducible source digest:

import sys 
class StdoutGuard: 
    def __getattr__(self, attr): 
        sys.stdout = sys.__stdout__ 
        raise RuntimeError("Premature access to 
sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


and Backtrace:

(gdb) bt
#0  0x00000002 in ?? ()
#1  0x08055ba6 in PyObject_GetAttrString 
(v=0x814b9e0,
    name=0x2 <Error reading address 0x2: Bad address>) 
at Objects/object.c:1066
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
#3  0x08071493 in eval_frame (f=0x8121c0c) at 
Python/ceval.c:1371
#4  0x080730be in PyEval_EvalCodeEx (co=0x8126500, 
globals=0x2, locals=0x2, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2595
#5  0x080702da in PyEval_EvalCode (co=0x8126500, 
globals=0x812fd0c, locals=0x812fd0c)
    at Python/ceval.c:481
#6  0x08089891 in run_node (n=0x8178a80, 
filename=0xbfbff648 "test.py", globals=0x812fd0c,
    locals=0x812fd0c, flags=0xbfbff4d8) at 
Python/pythonrun.c:1067
#7  0x08088af7 in PyRun_SimpleFileExFlags 
(fp=0x282c3780, filename=0xbfbff648 "test.py", 
closeit=1,
    flags=0xbfbff4d8) at Python/pythonrun.c:673
#8  0x08052a77 in Py_Main (argc=1, argv=0xbfbff538) 
at Modules/main.c:367
#9  0x080525cf in main (argc=2, argv=0xbfbff538) at 
Modules/python.c:10
#10 0x08052505 in _start ()
(gdb) f 2
#2  0x080a57d2 in PyFile_WriteObject (v=0x817d180, 
f=0x8178a8c, flags=135760524)
    at Objects/fileobject.c:1691
1691            writer = PyObject_GetAttrString(f, "write");
(gdb) p *f
$22 = {ob_refcnt = 1000843696, ob_type = 0x814b9e0}


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-29 10:45

Message:
Logged In: YES 
user_id=80475

Done.
See test_descr.py 1.196

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-29 09:57

Message:
Logged In: YES 
user_id=33168

Checked in as:
 * Python/ceval.c 2.367 & 2.301.4.9

Assigned to Raymond to make a test.

As for the test, in test_descr.specials() there is some
stdout handling at the end of the function (around line
1881).  I don't know of a better place than that.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-29 00:56

Message:
Logged In: YES 
user_id=31435

I can't make time to analyze the problem, but the comment 
sounds plausible <wink>.

The fix isn't quite right, though:  because w can be NULL, you 
have to use Py_XINCREF and Py_XDECREF instead of 
Py_INCREF and Py_DECREF.  The latter will probably segfault 
when w is NULL.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-29 00:27

Message:
Logged In: YES 
user_id=80475

filefault.py fails for me before the patch and succeeds after 
the patch.

If you go ahead and apply the patch, I'll write the test.
Do you have an idea which test_*.py is the best place for it?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 23:58

Message:
Logged In: YES 
user_id=33168

I couldn't get the test working.  It always passed, before
and after the fix.  I would like to have a test for this,
but no time now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 22:38

Message:
Logged In: YES 
user_id=80475

This looks like a clean fix to me and ought to go into 2.3b2 
so it can be shaken out further.

Please use filefault.py to create a unittest.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 21:48

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.  I'm not
entirely sure the comment is accurate.  2.2.3 doesn't crash,
but goes into an infinite loop.  Tim should this go into 2.3b2?

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-06-28 13:26

Message:
Logged In: YES 
user_id=55188

import sys 
class StdoutGuard: 
&nbsp;&nbsp;&nbsp;&nbsp;def __getattr__(self, attr): 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sys.std
out = sys.__stdout__ 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;raise 
RuntimeError("Premature access to sys.stdout.%s" % attr) 
sys.stdout = StdoutGuard() 
print "Oops!"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762455&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 18:55:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 10:55:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-666219 ] AssertionErrors in httplib
Message-ID: <E19WgP2-0003fK-00@sc8-sf-web2.sourceforge.net>

Bugs item #666219, was opened at 2003-01-11 14:23
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Skip Montanaro (montanaro)
Assigned to: Jeremy Hylton (jhylton)
Summary: AssertionErrors in httplib

Initial Comment:
I've recently noticed AssertionErrors being raised by
httplib.LineAndFileWrapper.read().  It happens reliably when the server
exits unexpectedly.  Here's an example of an AssertionError in an 
xmlrpclib client when I kill the server it's talking to:

    Traceback (most recent call last):
      File "qa.py", line 22, in ?
        x = s.query(tmpl, st, en, radius, age)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__
        return self.__send(self.__name, args)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request
        verbose=self.__verbose
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request
        return self._parse_response(h.getfile(), sock)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response
        response = file.read(1024)
      File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read
        assert not self._line_consumed and self._line_left
    AssertionError

I don't see a problem with raising an exception in this situation.  I just
wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code).  If an exception
is being raised because the server went away, I think it would be 
better to raise IncompleteRead.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-29 17:55

Message:
Logged In: YES 
user_id=31392

Thanks for the comment, showme1949.  It's obvious that the
assertion fails in this case.  Fixed by raising an exception
earlier.


----------------------------------------------------------------------

Comment By: AC (showme1949)
Date: 2003-06-28 09:30

Message:
Logged In: YES 
user_id=811410


OK, I saw this problem pretty in several programs (mine or
others). So I deed some search, here is a log that shown
self._line_consumed, self._line_left, self._line and
self._line_offset with bittorrent.

It is pretty obvious when the assert happens, we have a empty
self._line before we even start to read. Maybe because the
other end closed on us without sending any data.

A suggusted fix is to append 'and len(self._line) != 0'  to
the end of assert.
-------------- My log on the assert -------
==== line_consumeed, line_left ===
0
0

0
=== self._line, line_offset ===
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 414, in
__bootstrap
    self.run()
  File "/usr/lib/python2.2/threading.py", line 402, in run
    apply(self.__target, self.__args, self.__kwargs)
  File
"/usr/lib/python2.2/site-packages/BitTorrent/Rerequester.py",
line 76, in rer
equest
    r = h.read()
  File "/usr/lib/python2.2/httplib.py", line 1148, in read
    assert not self._line_consumed and self._line_left
AssertionError


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-05-05 16:48

Message:
Logged In: YES 
user_id=44345

[small timeout?]

Not since the changes to the makefile() changes to socket.py (or at least
not always).  If the timeout is shorter than the response time you now can
get a socket.error:

>>> socket.setdefaulttimeout(0.05)
>>> manatee = xmlrpclib.ServerProxy("http://manatee.mojam.com:5007")
>>> manatee.noop()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1021, in __call__
    return self.__send(self.__name, args)
  File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1308, in __request
    verbose=self.__verbose
  File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1056, in request
    errcode, errmsg, headers = h.getreply()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 1019, in getreply
    response = self._conn.getresponse()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 770, in getresponse
    response.begin()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 268, in begin
    version, status, reason = self._read_status()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 230, in _read_status
    line = self.fp.readline()
  File "/Users/skip/local/lib/python2.3/socket.py", line 321, in readline
    data = recv(1)
socket.error: (35, 'Resource temporarily unavailable')

I think you may still get the assertion error if the timeout is sufficient to
allow some of the response to be read, but not all of it (though that's just
a guess).

I suspect we're better off just closing this with either "postponed" or
"won't fix" at this point.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-05-05 16:33

Message:
Logged In: YES 
user_id=31392

We can provoke this error by setting a very small timeout,
right?


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-20 18:43

Message:
Logged In: YES 
user_id=44345

Sorry for the delay on this.  I think I'm closing in on the
problem.  I've been using Tim O'Malley's timeoutsocket
module for quite awhile.  I noticed the same problem today
when using the new timeout feature in the socket module.
Libraries like xmlrpclib use makefile() to get a file object
to play with.  File objects don't play well with timeouts
because the socket is in non-blocking mode.  I think what
happens here is that the first line of HTTPResponse.
_read_status sets line to the empty string because of the
timeout setting.  Tracing through the code which follows
makes it clear that control will wind up in the HTTP/0.9
chunk of code.

Maybe it's worth adding a test for line == "" after the
readline() call:

        line = self.fp.readline()
        if self.debuglevel > 0:
            print "reply:", repr(line)
        if line == "":
            raise BadStatusLine(line)

That would distinguish an error reading from an 0.9 server
(which would return something with that first readline()
call).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-31 14:13

Message:
Logged In: YES 
user_id=44345

No, sorry, I haven't looked more deeply into the problem.  I did investigate
far enough to also see that the code was in the HTTP/0.9 weeds and am
befuddled about why it would be there.  It's using the vanilla xmlrpclib
module at both ends.  I'll try to spend a little time today.

S

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-31 14:07

Message:
Logged In: YES 
user_id=31392

Any more info Skip?


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-14 21:18

Message:
Logged In: YES 
user_id=31392

It's definitely the case that an AssertionError shouldn't be
raised.  It was my intention that the assert never fail.  Do
you know which part of the assert fails?  Perhaps you could
change the assert to print the values of _line_consumed and
_line_left and run some more tests.
I can't figure out how this goes wrong.

Also, do you know when the server is sending an HTTP/0.9
response?  I wonder if there's a bug somewhere else and the
client is guessing the wrong protocol version for the response.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 19:53:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 11:53:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-683658 ] PyErr_Warn may cause import deadlock
Message-ID: <E19WhIg-0002lh-00@sc8-sf-web3.sourceforge.net>

Bugs item #683658, was opened at 2003-02-10 00:26
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683658&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 7
Submitted By: Mark Hammond (mhammond)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyErr_Warn may cause import deadlock

Initial Comment:
PyErr_Warn() does an implicit import.  Thus, if
PyErr_Warn() is called on a thread while the main
thread holds the import lock, and the main thread then
subsequently waits for the child thread, Python will
deadlock.  The builtin 'apply' now calls PyErr_Warn(),
so simply calling 'apply' on another thread may cause
the deadlock.

Attaching a sample case.  Executing 'python -c "import
hang_apply"' will cause Python to deadlock.  Commenting
out the call to "apply" in that file will prevent the
deadlock (even though the apply() in question is
effectively a no-op)

The example is a little contrived, but is extracted
from real code of mine that saw this hang.  The code
path is:

* Main thread acquires import lock to import the module.
* Module import spawns a new thread.  This new thread
calls apply()
* builtin_apply() calls PyErr_Warn
* PyErr_Warn does an import of the warnings module, and
attempts to acquire the import lock.
* Main thread still waiting for child thread to
complete, but still holds import lock.

Note that removing the call to PyErr_Warn() in
builtin_apply also solves this particular hang -
however, it seems like this is a potential time bomb. 
A potential solution would be to prevent PyErr_Warn
from doing an import - this would mean importing
'warnings' at startup, and keeping a static reference
in errors.c.  Other thoughts welcome.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-29 18:53

Message:
Logged In: YES 
user_id=31392

Did this get resolved for 2.3 or delayed to 2.4?


----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-25 20:30

Message:
Logged In: YES 
user_id=92689

Well, since you said the issue needs to be revisited anyway, I'll just leave it at moving the warnings.py import after initsite().

What I don't like is that warnings.py is imported preemptively to begin with, not just with -S. Whether that's resolvable I don't know, but if it is, it would be better than not importing warnings.py with -S.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-25 20:20

Message:
Logged In: YES 
user_id=6380

OK, implement that.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-25 18:58

Message:
Logged In: YES 
user_id=92689

Only if PyErr_Warn() would still also attempt to do the import if PyModule_WarningsModule is NULL. But that means that deadlocks can still occur when -S is used. But I _do_ like it that no file system imports are done by Python itself with -S. And I actually don't like it at all that warnings.py always gets imported, even if it's never needed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-25 18:31

Message:
Logged In: YES 
user_id=6380

OK, as a stopgap measure that sounds like a good idea.

(I wonder if -S should also suppress loading warnings? Or is
that too drastic?)


----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-25 18:27

Message:
Logged In: YES 
user_id=92689

Additional info regarding the current situation (with the patch in place):
if warnings.py can't be imported before site.py is run, _all_ warnings issued from C will be printed to stderr, even if warnings.py _can_ be imported later.

I think it's fair to assume that any warning issued during the import of site.py signifies that something is pretty broken, so having them dumped to stderr isn't all that bad.

If you and Mark agree, I'll move the import of warnings.py to after initsite().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-25 17:44

Message:
Logged In: YES 
user_id=6380

Good point. But loading site.py first means that warnings
issued as a result of importing site.py are not handled
properly (they will be dumped to stderr, which is better
than nothing). Well, I have to revisit this anyway; I'll
make sure to take this issue into account as well.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-25 17:20

Message:
Logged In: YES 
user_id=92689

Here's an issue with the patch I just ran into: it seems this patch causes the first Python module to be imported to be warnings.py instead of site.py. This means site.py doesn't have full control of the import mechanism anymore, as all modules loaded by warnings.py will already be loaded. Can't the PyModule_WarningsModule global be set _after_ site.py has run?

Use case: I'm building standalone applications in which the import bootstrapping happens in a custom site.py, assuming it will be the first Python module that will be imported. It sets up sys.path appropriately. Now it turns out that when my site.py gets run (eg.) os.py is already loaded from my system-wide installation, instead of from the zip file embedded in the application. This means I can't reliably test whether my built app really works when there's no Python installation available.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-19 16:36

Message:
Logged In: YES 
user_id=6380

I'm not happy with this solution, since it breaks for
multiple interpreters. So keeping this open. Will think
about what to do instead after 2.3a2 is released.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-19 00:42

Message:
Logged In: YES 
user_id=14198

Checking in a patch that avoids the import, thereby avoiding
the hang.  As suggested, the "linecache" import in warnings
had to be moved.

Even though I checked it in, I attach the patch here, and
have assigned it to Guido for review.  If happy, just mark
it as closed.

/cvsroot/python/python/dist/src/Python/errors.c,v  <--  errors.c
new revision: 2.76; previous revision: 2.75
/cvsroot/python/python/dist/src/Python/pythonrun.c,v  <-- 
pythonrun.c
new revision: 2.178; previous revision: 2.177
/cvsroot/python/python/dist/src/Lib/warnings.py,v  <-- 
warnings.py
new revision: 1.19; previous revision: 1.18


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-15 23:17

Message:
Logged In: YES 
user_id=14198

Yes, the linecache import was the problem.  I abandonded
that approach mainly to avoid yet another import at startup.
 Should 'warnings' get new features, all required imports in
the future will also need to be imported at process startup.
 It also struck me as a time bomb.

I will make an alternative patch that moves the imports.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-15 21:01

Message:
Logged In: YES 
user_id=6380

Oh, and the import of linecache by warnings can be put at
the top of warnings, if that's an issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-15 15:46

Message:
Logged In: YES 
user_id=6380

No time to review everything here, but maybe PyErr_Warn
should not do an import? The import could be done at startup
time (when site.py is also imported) and saved in the
interpreter state.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-15 05:02

Message:
Logged In: YES 
user_id=14198

The best I can come up with here is exposing the import lock
to the C API, with a "wait" flag.

This will allow a C function to reliably determine if an
"import" work block, or acquire the lock if not.  It can
then complete its import before releasing the lock.  If the
import would block, then it can take whatever action is
necessary - in the case of PyErr_Warn, it dumps the warning
to stdout.

Attaching a patch.  It exposes (to the core, but not in
headers) two functions:

extern int PyImport_LockImport(int wait);
extern void PyImport_UnlockImport(void);

PyErr_Warn then uses these.

If we do go this route, it makes sense to make these
functions truly public (ie, add them to the headers), and
cleanup import.c appropriately.  I didn't do this in the
interests of keeping the patch small so it can be easily
digested.

Comments?  Other ideas?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-14 05:16

Message:
Logged In: YES 
user_id=14198

This simple strategy doesn't work - avoiding the import of
'warnings' works fine, until 'warnings' imports 'linecache'!

I'll look at how we can simply throw the warning away if a
deadlock would occur.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-11 23:23

Message:
Logged In: YES 
user_id=33168

I can't think of any other/better solution.  Any idea if
there are there other ticking bombs like this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683658&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 20:14:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 12:14:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-683658 ] PyErr_Warn may cause import deadlock
Message-ID: <E19WhdZ-0003dt-00@sc8-sf-web3.sourceforge.net>

Bugs item #683658, was opened at 2003-02-10 01:26
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683658&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Remind
>Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyErr_Warn may cause import deadlock

Initial Comment:
PyErr_Warn() does an implicit import.  Thus, if
PyErr_Warn() is called on a thread while the main
thread holds the import lock, and the main thread then
subsequently waits for the child thread, Python will
deadlock.  The builtin 'apply' now calls PyErr_Warn(),
so simply calling 'apply' on another thread may cause
the deadlock.

Attaching a sample case.  Executing 'python -c "import
hang_apply"' will cause Python to deadlock.  Commenting
out the call to "apply" in that file will prevent the
deadlock (even though the apply() in question is
effectively a no-op)

The example is a little contrived, but is extracted
from real code of mine that saw this hang.  The code
path is:

* Main thread acquires import lock to import the module.
* Module import spawns a new thread.  This new thread
calls apply()
* builtin_apply() calls PyErr_Warn
* PyErr_Warn does an import of the warnings module, and
attempts to acquire the import lock.
* Main thread still waiting for child thread to
complete, but still holds import lock.

Note that removing the call to PyErr_Warn() in
builtin_apply also solves this particular hang -
however, it seems like this is a potential time bomb. 
A potential solution would be to prevent PyErr_Warn
from doing an import - this would mean importing
'warnings' at startup, and keeping a static reference
in errors.c.  Other thoughts welcome.


----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2003-06-29 21:14

Message:
Logged In: YES 
user_id=92689

This is from the CVS log of pythonrun.c:

revision 2.179
date: 2003/02/25 20:25:12;  author: jvr;  state: Exp;  lines: +2 -2
Addendum to #683658:
import warnings.py _after_ site.py has run. This ensures that 
site.py is again the first .py to be imported, giving it back full 
control over sys.path.

I'm quite confident this is good enough for 2.3, but the issue 
should be revisited at some point, so I'm not sure we should close 
this bug. I'll lower the priority.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-29 20:53

Message:
Logged In: YES 
user_id=31392

Did this get resolved for 2.3 or delayed to 2.4?


----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-25 21:30

Message:
Logged In: YES 
user_id=92689

Well, since you said the issue needs to be revisited anyway, I'll just leave it at moving the warnings.py import after initsite().

What I don't like is that warnings.py is imported preemptively to begin with, not just with -S. Whether that's resolvable I don't know, but if it is, it would be better than not importing warnings.py with -S.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-25 21:20

Message:
Logged In: YES 
user_id=6380

OK, implement that.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-25 19:58

Message:
Logged In: YES 
user_id=92689

Only if PyErr_Warn() would still also attempt to do the import if PyModule_WarningsModule is NULL. But that means that deadlocks can still occur when -S is used. But I _do_ like it that no file system imports are done by Python itself with -S. And I actually don't like it at all that warnings.py always gets imported, even if it's never needed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-25 19:31

Message:
Logged In: YES 
user_id=6380

OK, as a stopgap measure that sounds like a good idea.

(I wonder if -S should also suppress loading warnings? Or is
that too drastic?)


----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-25 19:27

Message:
Logged In: YES 
user_id=92689

Additional info regarding the current situation (with the patch in place):
if warnings.py can't be imported before site.py is run, _all_ warnings issued from C will be printed to stderr, even if warnings.py _can_ be imported later.

I think it's fair to assume that any warning issued during the import of site.py signifies that something is pretty broken, so having them dumped to stderr isn't all that bad.

If you and Mark agree, I'll move the import of warnings.py to after initsite().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-25 18:44

Message:
Logged In: YES 
user_id=6380

Good point. But loading site.py first means that warnings
issued as a result of importing site.py are not handled
properly (they will be dumped to stderr, which is better
than nothing). Well, I have to revisit this anyway; I'll
make sure to take this issue into account as well.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-25 18:20

Message:
Logged In: YES 
user_id=92689

Here's an issue with the patch I just ran into: it seems this patch causes the first Python module to be imported to be warnings.py instead of site.py. This means site.py doesn't have full control of the import mechanism anymore, as all modules loaded by warnings.py will already be loaded. Can't the PyModule_WarningsModule global be set _after_ site.py has run?

Use case: I'm building standalone applications in which the import bootstrapping happens in a custom site.py, assuming it will be the first Python module that will be imported. It sets up sys.path appropriately. Now it turns out that when my site.py gets run (eg.) os.py is already loaded from my system-wide installation, instead of from the zip file embedded in the application. This means I can't reliably test whether my built app really works when there's no Python installation available.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-19 17:36

Message:
Logged In: YES 
user_id=6380

I'm not happy with this solution, since it breaks for
multiple interpreters. So keeping this open. Will think
about what to do instead after 2.3a2 is released.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-19 01:42

Message:
Logged In: YES 
user_id=14198

Checking in a patch that avoids the import, thereby avoiding
the hang.  As suggested, the "linecache" import in warnings
had to be moved.

Even though I checked it in, I attach the patch here, and
have assigned it to Guido for review.  If happy, just mark
it as closed.

/cvsroot/python/python/dist/src/Python/errors.c,v  <--  errors.c
new revision: 2.76; previous revision: 2.75
/cvsroot/python/python/dist/src/Python/pythonrun.c,v  <-- 
pythonrun.c
new revision: 2.178; previous revision: 2.177
/cvsroot/python/python/dist/src/Lib/warnings.py,v  <-- 
warnings.py
new revision: 1.19; previous revision: 1.18


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-16 00:17

Message:
Logged In: YES 
user_id=14198

Yes, the linecache import was the problem.  I abandonded
that approach mainly to avoid yet another import at startup.
 Should 'warnings' get new features, all required imports in
the future will also need to be imported at process startup.
 It also struck me as a time bomb.

I will make an alternative patch that moves the imports.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-15 22:01

Message:
Logged In: YES 
user_id=6380

Oh, and the import of linecache by warnings can be put at
the top of warnings, if that's an issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-15 16:46

Message:
Logged In: YES 
user_id=6380

No time to review everything here, but maybe PyErr_Warn
should not do an import? The import could be done at startup
time (when site.py is also imported) and saved in the
interpreter state.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-15 06:02

Message:
Logged In: YES 
user_id=14198

The best I can come up with here is exposing the import lock
to the C API, with a "wait" flag.

This will allow a C function to reliably determine if an
"import" work block, or acquire the lock if not.  It can
then complete its import before releasing the lock.  If the
import would block, then it can take whatever action is
necessary - in the case of PyErr_Warn, it dumps the warning
to stdout.

Attaching a patch.  It exposes (to the core, but not in
headers) two functions:

extern int PyImport_LockImport(int wait);
extern void PyImport_UnlockImport(void);

PyErr_Warn then uses these.

If we do go this route, it makes sense to make these
functions truly public (ie, add them to the headers), and
cleanup import.c appropriately.  I didn't do this in the
interests of keeping the patch small so it can be easily
digested.

Comments?  Other ideas?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-14 06:16

Message:
Logged In: YES 
user_id=14198

This simple strategy doesn't work - avoiding the import of
'warnings' works fine, until 'warnings' imports 'linecache'!

I'll look at how we can simply throw the warning away if a
deadlock would occur.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-12 00:23

Message:
Logged In: YES 
user_id=33168

I can't think of any other/better solution.  Any idea if
there are there other ticking bombs like this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683658&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 21:29:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 13:29:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-762855 ] ioctl only accepts 1024 byte arguments
Message-ID: <E19Wio8-0000Qy-00@sc8-sf-web2.sourceforge.net>

Bugs item #762855, was opened at 2003-06-29 22: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=762855&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Penz (robertpenz)
Assigned to: Nobody/Anonymous (nobody)
Summary: ioctl only accepts 1024 byte arguments

Initial Comment:
Hi! 
 
The buffer in /python/dist/src/Modules/fcntlmodule.c 
ist hardcoded to 1024 byte. It would be cool if would be dynamic 
allocated or at least make it 10k big. 
 
my argnument has an size of 1816 byte 
 
        char buf[1024]; 
..... 
                       if (len > sizeof buf) { 
                               PyErr_SetString(PyExc_ValueError, 
                                       "ioctl string arg too long"); 
                               return NULL; 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762855&group_id=5470


From noreply@sourceforge.net  Sun Jun 29 23:17:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 15:17:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-762891 ] "del p[key]" on proxy object raises SystemError()
Message-ID: <E19WkUf-0001sJ-00@sc8-sf-web1.sourceforge.net>

Bugs item #762891, was opened at 2003-06-29 18: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=762891&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Muller (mikemuller)
Assigned to: Nobody/Anonymous (nobody)
Summary: "del p[key]" on proxy object raises SystemError()

Initial Comment:
Attempting to perform a __delitem__ on a proxy object
raises the SystemError "null argument to internal
routine".  Example code:

-------------------------------------------------------
import weakref

class Foo:
   def __delitem__(self, accessor):
      print 'deleting %s' % accessor

g = Foo()
f = weakref.proxy(g)
del f[0]

-------------------------------------------------------

The problem appears to be that proxy_setitem() in
weakrefobject.c indiscriminately calls
PyObject_SetItem() on the proxied object without
checking to see if the "value" parameter is NULL, as it
is when it is called from a __delitem__ on the proxy.

I have uploaded a patch that fixes the problem.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762891&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 01:14:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 17:14:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-762891 ] "del p[key]" on proxy object raises SystemError()
Message-ID: <E19WmIy-0002Ue-00@sc8-sf-web4.sourceforge.net>

Bugs item #762891, was opened at 2003-06-29 17:17
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762891&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Muller (mikemuller)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: "del p[key]" on proxy object raises SystemError()

Initial Comment:
Attempting to perform a __delitem__ on a proxy object
raises the SystemError "null argument to internal
routine".  Example code:

-------------------------------------------------------
import weakref

class Foo:
   def __delitem__(self, accessor):
      print 'deleting %s' % accessor

g = Foo()
f = weakref.proxy(g)
del f[0]

-------------------------------------------------------

The problem appears to be that proxy_setitem() in
weakrefobject.c indiscriminately calls
PyObject_SetItem() on the proxied object without
checking to see if the "value" parameter is NULL, as it
is when it is called from a __delitem__ on the proxy.

I have uploaded a patch that fixes the problem.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762891&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 01:47:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 17:47:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball
Message-ID: <E19WmpW-0003NE-00@sc8-sf-web4.sourceforge.net>

Bugs item #728051, was opened at 2003-04-27 00:23
Message generated for change (Comment added) made by zenzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Test failures on Linux, Python 2.3b1 tarball

Initial Comment:
"make test" resulted in:

test test_tempfile failed -- Traceback (most recent
call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports
failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
264, in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

test test_time failed -- Traceback (most recent call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_time.py", line
107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST


----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-30 10:47

Message:
Logged In: YES 
user_id=46639

I've re-uploaded the tzset configure.in patch as:
    http://www.python.org/sf/728051

The version in this bug report looks mangled.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-06-16 11:58

Message:
Logged In: YES 
user_id=56214

Here are the gory details of the tempfile test:

[admin@pilot Python-2.3b1]$ ./python -c "from test import
test_tempfile; test_tempfile.test_main()"
test_exports (test.test_tempfile.test_exports) ... ok
test_get_six_char_str
(test.test_tempfile.test__RandomNameSequence) ... ok
test_many (test.test_tempfile.test__RandomNameSequence) ... ok
test_supports_iter
(test.test_tempfile.test__RandomNameSequence) ... ok
test_nonempty_list
(test.test_tempfile.test__candidate_tempdir_list) ... ok
test_wanted_dirs
(test.test_tempfile.test__candidate_tempdir_list) ... ok
test_retval (test.test_tempfile.test__get_candidate_names)
... ok
test_same_thing
(test.test_tempfile.test__get_candidate_names) ... ok
test_basic (test.test_tempfile.test__mkstemp_inner) ... ok
test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok
test_choose_directory
(test.test_tempfile.test__mkstemp_inner) ... ok
test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok
fd 3 is open in childtest_noinherit
(test.test_tempfile.test__mkstemp_inner) ... FAIL
test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok
test_sane_template (test.test_tempfile.test_gettempprefix)
... ok
test_usable_template (test.test_tempfile.test_gettempprefix)
... ok
test_directory_exists (test.test_tempfile.test_gettempdir)
... ok
test_directory_writable (test.test_tempfile.test_gettempdir)
... ok
test_same_thing (test.test_tempfile.test_gettempdir) ... ok
test_basic (test.test_tempfile.test_mkstemp) ... ok
test_choose_directory (test.test_tempfile.test_mkstemp) ... ok
test_basic (test.test_tempfile.test_mkdtemp) ... ok
test_basic_many (test.test_tempfile.test_mkdtemp) ... ok
test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok
test_mode (test.test_tempfile.test_mkdtemp) ... ok
test_basic (test.test_tempfile.test_mktemp) ... ok
test_many (test.test_tempfile.test_mktemp) ... ok
test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok
test_creates_named
(test.test_tempfile.test_NamedTemporaryFile) ... ok
test_del_on_close
(test.test_tempfile.test_NamedTemporaryFile) ... ok
test_multiple_close
(test.test_tempfile.test_NamedTemporaryFile) ... ok
test_basic (test.test_tempfile.test_TemporaryFile) ... ok
test_has_no_name (test.test_tempfile.test_TemporaryFile) ... ok
test_multiple_close (test.test_tempfile.test_TemporaryFile)
... ok

======================================================================
FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264,
in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

----------------------------------------------------------------------
Ran 34 tests in 0.217s

FAILED (failures=1)
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 651, in test_main
    test_support.run_suite(suite)
  File "/home/admin/Python-2.3b1/Lib/test/test_support.py",
line 229, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264,
in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-16 10:53

Message:
Logged In: YES 
user_id=46639

Hmm... no file upload button for me in this topic.
Here is a configure.in patch which should stop time.tzset
being build on Redhat 6, and other platforms with this 'problem'
(being that although tzset() may do something useful, it
doesn't do what is documented or called multiple times by the
same process)


Index: dist/src/configure.in
=======================================
============================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.418
diff -c -c -r1.418 configure.in
*** dist/src/configure.in       14 Jun 2003 21:03:05 -0000      
1.418
--- dist/src/configure.in       16 Jun 2003 00:43:24 -0000
***************
*** 2706,2723 ****
  #include <time.h>
  int main()
  {
        int gmt_hour;
        int eastern_hour;
!       time_t now;
!       now = time((time_t*)NULL);
        putenv("TZ=UTC+0");
        tzset();
!       gmt_hour = localtime(&now)->tm_hour;
        putenv("TZ=EST+5EDT,M4.1.0,M10.5.0");
        tzset();
!       eastern_hour = localtime(&now)->tm_hour;
!       if (eastern_hour == gmt_hour)
            exit(1);
        exit(0);
  }
  ],
--- 2706,2737 ----
  #include <time.h>
  int main()
  {
+       /* Note that we need to ensure that not only does tzset(3)
+          do 'something' with localtime, but it works as 
documented
+          in the library reference and as expected by the test 
suite. */
        int gmt_hour;
        int eastern_hour;
!       int aus_hour;
!       time_t xmas = 1040774400;
! 
        putenv("TZ=UTC+0");
        tzset();
!       gmt_hour = localtime(&xmas)->tm_hour;
!       if (gmt_hour != 0)
!           exit(1);
! 
        putenv("TZ=EST+5EDT,M4.1.0,M10.5.0");
        tzset();
!       eastern_hour = localtime(&xmas)->tm_hour;
!       if (eastern_hour != 19)
!           exit(1);
! 
!       putenv("TZ=AEST-10AEDT-11,M10.5.0,M3.5.0");
!       tzset();
!       aus_hour = localtime(&xmas)->tm_hour;
!       if (aus_hour != 11)
            exit(1);
+ 
        exit(0);
  }
  ],

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-11 10:42

Message:
Logged In: YES 
user_id=357491

Sure thing.  =)  Execute this line from a terminal:

python2.3 -c "from test import test_tempfile; 
test_tempfile.test_main()"

All it is doing is importing the test_tempfile module from the test 
package and then executing test_tempfile.test_main() which 
runs all the tests.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-06-11 08:56

Message:
Logged In: YES 
user_id=56214

I don't know.  Tell me how to run the test on its own, and
I'll tell you.  :)


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-11 08:04

Message:
Logged In: YES 
user_id=357491

How about the test_tempfile failure?  Does that occur when you 
run the test on its own?

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-05-25 23:21

Message:
Logged In: YES 
user_id=56214

Here's the tz info; I'll email you the 'man tzset' separately.

[admin@pilot Python-2.3a1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[admin@pilot Python-2.3a1]$ cd ../Python-2.3b1
[admin@pilot Python-2.3b1]$ ./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c
'import time;print time.tzname,time.timezone,time.altzone'
('EST', 'EDT') 18000 14400
[admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne'
./python -c 'import time;print
time.tzname,time.timezone,time.altzone'
('EST', 'EST') -36000 -39600
[

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-05-22 10:41

Message:
Logged In: YES 
user_id=46639

This is from my patch.

Phillip - can you please upload a copy of 'man tzset' on that Redhat box
or email it to zen@shangri-la.dropbear.id.au.

I'd also like to see the output of:
    python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='US/Eastern' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'
    env TZ='Australia/Melbourne' \
        python -c 'import time;print time.tzname,time.timezone,time.altzone'

I'm thinking that tzset(3) and the time libraries are not fully functional on 
this earlier version of Redhat, possibly by not handling southern hemisphere 
daylight savings. If so, it needs to be detected during configuration.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-05 01:00

Message:
Logged In: YES 
user_id=21627

Neal, it appears you have checked in the test for the AEST
zone. Can you analyse the test_time failure in more detail?

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2003-05-04 23:19

Message:
Logged In: YES 
user_id=56214

It's an ISP-supplied variant of RedHat 6.2.  I see
'libc-2.1.3.so' in the /lib directory, so I assume that's
the version. Running 'strings' on it, I find:

GNU C Library stable release version 2.1.3, by Roland
McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software
Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release).
Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07.
Available extensions:
        GNU libio by Per Bothner
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        BIND-4.9.7-REL
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton 
        linuxthreads-0.8 by Xavier Leroy
        libthread_db work sponsored by Alpha Processor Inc


Python identifies itself as:

Python 2.3b1 (#1, Apr 26 2003, 10:02:40) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I just tested 2.3a1 andr 2.3a2 to confirm where the errors
began.  2.3a1 doesn't show either error.  2.3a2 has the
tempfile problem, but not the time problem.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 22:42

Message:
Logged In: YES 
user_id=21627

What operating system distribution specifically did you use?
What C library does this system use?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 04:18:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 20:18:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-762985 ] str.split seems to eat exception
Message-ID: <E19WpBy-0001td-00@sc8-sf-web1.sourceforge.net>

Bugs item #762985, was opened at 2003-06-30 05: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=762985&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Gerhard Häring (ghaering)
Assigned to: Gerhard Häring (ghaering)
Summary: str.split seems to eat exception

Initial Comment:
comp.lang.python posting from Bill C. Wong (Message-ID:
<7sNLa.30264$Kg7.14786@nwrdny01.gnilink.net>)

################################
def func( s ):
    s1, s2 = s.split( ' ', 1 )
    try:
        raise s1
    except "aaaa":
        print 'except "aaaa"'
    except:
        print 'except:'

s = "aaaa "
func( s )
################################
If I manually assign s1 with s1 = "aaaa", then it works
fine! What am I doing wrong here?

----

Indeed if after the line s1, s2 = s.split you insert a line

s1 = "aaaaa"

then a different except clause is executed. Confirmed
with both Python 2.2.3 and Python 2.3beta2. This smells
like a bug to me.

Assigning to me and trying to investigate further.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762985&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 04:31:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 20:31:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-762985 ] str.split seems to eat exception
Message-ID: <E19WpOB-0004OA-00@sc8-sf-web2.sourceforge.net>

Bugs item #762985, was opened at 2003-06-30 05:18
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762985&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
>Resolution: Invalid
>Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Gerhard Häring (ghaering)
Summary: str.split seems to eat exception

Initial Comment:
comp.lang.python posting from Bill C. Wong (Message-ID:
<7sNLa.30264$Kg7.14786@nwrdny01.gnilink.net>)

################################
def func( s ):
    s1, s2 = s.split( ' ', 1 )
    try:
        raise s1
    except "aaaa":
        print 'except "aaaa"'
    except:
        print 'except:'

s = "aaaa "
func( s )
################################
If I manually assign s1 with s1 = "aaaa", then it works
fine! What am I doing wrong here?

----

Indeed if after the line s1, s2 = s.split you insert a line

s1 = "aaaaa"

then a different except clause is executed. Confirmed
with both Python 2.2.3 and Python 2.3beta2. This smells
like a bug to me.

Assigning to me and trying to investigate further.

----------------------------------------------------------------------

>Comment By: Gerhard Häring (ghaering)
Date: 2003-06-30 05:31

Message:
Logged In: YES 
user_id=163326

Ok, from http://python.org/doc/current/ref/try.html about
the except clause:

"""Note that the object identities must match, i.e. it must
be the same object, not just an object with the same value."""

Please can somebody confirm this and if so, close the bug
report?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762985&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 04:45:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 20:45:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-762990 ] Awful Grammar in Python Tutorial
Message-ID: <E19Wpc2-0007hy-00@sc8-sf-web4.sourceforge.net>

Bugs item #762990, was opened at 2003-06-29 22: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=762990&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt Dresner (omega697)
Assigned to: Nobody/Anonymous (nobody)
Summary: Awful Grammar in Python Tutorial

Initial Comment:
I hate to say this, as I try to be reserved about
grammar-bulliness, but one of my uber-pet peeves is the
use of "obviate the need for."  Obviate already means
"remove the need for."  In chapter 9 (at the end of
paragraph 9.1) of the python tutorial I was aghast to
find the sentence, "For example, passing an object is
cheap since only a pointer is passed by the
implementation; and if a function modifies an object
passed as an argument, the caller will see the change
-- this obviates the need for two different argument
passing mechanisms as in Pascal."

Either "obviates having two different argument passing
mechanisms" or "prevents the need for two different
argument passing mechanisms."

:o)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762990&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 05:22:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 21:22:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-762891 ] "del p[key]" on proxy object raises SystemError()
Message-ID: <E19WqBK-0000AS-00@sc8-sf-web4.sourceforge.net>

Bugs item #762891, was opened at 2003-06-29 17:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762891&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Michael Muller (mikemuller)
Assigned to: Raymond Hettinger (rhettinger)
Summary: "del p[key]" on proxy object raises SystemError()

Initial Comment:
Attempting to perform a __delitem__ on a proxy object
raises the SystemError "null argument to internal
routine".  Example code:

-------------------------------------------------------
import weakref

class Foo:
   def __delitem__(self, accessor):
      print 'deleting %s' % accessor

g = Foo()
f = weakref.proxy(g)
del f[0]

-------------------------------------------------------

The problem appears to be that proxy_setitem() in
weakrefobject.c indiscriminately calls
PyObject_SetItem() on the proxied object without
checking to see if the "value" parameter is NULL, as it
is when it is called from a __delitem__ on the proxy.

I have uploaded a patch that fixes the problem.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-29 23:22

Message:
Logged In: YES 
user_id=80475

Applied as:

Objects/weakrefobject.c 1.12
Lib/test/test_weakref.py 1.27

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762891&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 05:28:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 21:28:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-762990 ] Awful Grammar in Python Tutorial
Message-ID: <E19WqHG-0000KP-00@sc8-sf-web4.sourceforge.net>

Bugs item #762990, was opened at 2003-06-29 22:45
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762990&group_id=5470

Category: Documentation
Group: Not a Bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kurt Dresner (omega697)
Assigned to: Nobody/Anonymous (nobody)
Summary: Awful Grammar in Python Tutorial

Initial Comment:
I hate to say this, as I try to be reserved about
grammar-bulliness, but one of my uber-pet peeves is the
use of "obviate the need for."  Obviate already means
"remove the need for."  In chapter 9 (at the end of
paragraph 9.1) of the python tutorial I was aghast to
find the sentence, "For example, passing an object is
cheap since only a pointer is passed by the
implementation; and if a function modifies an object
passed as an argument, the caller will see the change
-- this obviates the need for two different argument
passing mechanisms as in Pascal."

Either "obviates having two different argument passing
mechanisms" or "prevents the need for two different
argument passing mechanisms."

:o)

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-29 23:28

Message:
Logged In: YES 
user_id=80475

Fixed.  See Doc/tut/tut.tex 1.191
Hope you feel better now :-)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762990&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 05:29:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 21:29:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-748928 ] last threads fixes broke linker
Message-ID: <E19WqIP-0000Ld-00@sc8-sf-web4.sourceforge.net>

Bugs item #748928, was opened at 2003-06-04 11:25
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: last threads fixes broke linker

Initial Comment:
In current cvs, -pthread and -ieee is properly set for
OSF1/Tru64Unix. Unfortunately, -ieee is somewhat passed
to linker:

building '_curses' extension
cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/mnt/python/dist/src/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/python/dist/src/Include -I/mnt/python/dist/src
-c /mnt/python/dist/src/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved * -ieee -std -Olimit 1500
-DNDEBUG -O -I. -I./Include
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
ld:
-ieee: Unknown flag
ld: Usage: ld [options] file [...]
building '_curses_panel' extension


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 00:29

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  When I test with the current CVS
(2.3b2) on Tru64 5.1, I don't get many flags passed to ld,
but my cc line looks the same.  Can you make sure you have a
clean copy of configure from CVS?  Also, do a make clean and
./configure.

cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/net/boa/scratch1/nnorwitz/python/dist/src/./Include
-I/usr/local/include
-I/net/boa/scratch1/nnorwitz/python/dist/src/Include
-I/net/boa/scratch1/nnorwitz/python/dist/src -c
/net/boa/scratch1/nnorwitz/python/dist/src/Modules/_cursesmodule.c
-o build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/usr/local/lib -lcurses -ltermcap -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so


----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 17:30

Message:
Logged In: YES 
user_id=696559

Get free account on testing machine at
http://www.testdrive.compaq.com/

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 16:38

Message:
Logged In: YES 
user_id=21627

I see; -ieee is indeed passed to ld. I am a programmer, but
I cannot develop on Tru64. So we have to wait until a
programmer with access to Tru64 shows up.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 09:29

Message:
Logged In: YES 
user_id=696559

Actually, I don't know why -ieee is needed, I'm not a
programmer, sorry. The manpage cc(1) says:

  -ieee
      Ensure support of all portable features of the IEEE
Standard for Binary
      Floating-Point Arithmetic (ANSI/IEEE Std 754-1985),
including the
      treatment of denormalized numbers, NaNs, and
infinities and the han-
      dling of error cases. This option also sets the
_IEEE_FP C preprocessor
      macro.

      If your program must use IEEE signaling features that
are not portable
      across different IEEE implementations, see the ieee(3)
reference page
      for a discussion of how to access them under the Tru64
UNIX operating
      system.



Yes, -ieee is not listed in mapage for ld(1). I do not have
an access to that machine probably for a whole week, but are
you sure the -ieee is not in teh generated Makefiles passed
inside some variable to linker directly?



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 02:40

Message:
Logged In: YES 
user_id=21627

Is it not the case that cc(1) supports -ieee? If so, why
does it then pass the option to ld?

Perhaps it depends on the cc version whether -ieee is
supported? Perhaps the compiler should be invoked with a
different name?

Please don't make us guess as to how your operating system
works. If you can contribute to a solution, that would be
much appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 06:08:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 22:08:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-763007 ] dl module not installed with 2.2.3
Message-ID: <E19WqtV-0003s0-00@sc8-sf-web3.sourceforge.net>

Bugs item #763007, was opened at 2003-06-30 00:08
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=763007&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Messmore (salmo)
Assigned to: Nobody/Anonymous (nobody)
Summary: dl module not installed with 2.2.3

Initial Comment:
I'm running Redhat 7.3 on an older PII.  I was
attemping to try out the python bindings for gstreamer
when I discovered my build of python 2.2.3 was lacking
the 'dl' module.  I've installed RPMS built from the
SRPMS available on the python.org site (with the
non-redhat9 spec file).  Looking around I have not
found a reason for this, nor a way to go about fixing
it, so I assume it is a bug.  Whenever I try to run a
gst-python example I get an ImportError stating the the
dl module does not exist, as well as when I try to run
test_dl.py in my /usr/lib/python2.2/test/ directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 07:24:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 23:24:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-763023 ]  difflib.py: line 528 in ratio() zero division not caught
Message-ID: <E19Ws58-0006kM-00@sc8-sf-web1.sourceforge.net>

Bugs item #763023, was opened at 2003-06-30 06: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=763023&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary:  difflib.py: line 528 in ratio() zero division not caught

Initial Comment:
2.2.3 and 2.3b1:

>>> from difflib import * 
>>> s = SequenceMatcher(None, [], []) 
>>> s.ratio() 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
    File "/usr/lib/python2.2/difflib.py", line 528, in
ratio 
        return 2.0 * matches / (len(self.a) + len(self.b)) 
      ZeroDivisionError: float division 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 07:37:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 23:37:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-763026 ] AssertionError in httplib.py
Message-ID: <E19WsIV-0006Wi-00@sc8-sf-web3.sourceforge.net>

Bugs item #763026, was opened at 2003-06-30 06: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=763026&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: AssertionError in httplib.py

Initial Comment:
[forwarded from http://bugs.debian.org/192452]

When running bittorrent for a few hours, I start seeing
this assertion fire in
httplib.py from the Python 2.2 libraries:

Exception in thread Thread-20:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 414, in
__bootstrap
    self.run()
  File "/usr/lib/python2.2/threading.py", line 402, in run
    apply(self.__target, self.__args, self.__kwargs)
  File
"/usr/lib/python2.2/site-packages/BitTorrent/Rerequester.py",
line 76, in rerequest
    r = h.read()
  File "/usr/lib/python2.2/httplib.py", line 1140, in read
    assert not self._line_consumed and self._line_left
AssertionError

can be reproduced with 2.3 as well.

I do see this assertition triggered in another context:

- make a request
- when the request returns, the result code is 200
- trying to read the data returned triggers the assertion

I found out the server sider crashes/is crashed, so
probably no data is returned. maybe httplib could be a
bit more robust or throw a correct exception.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763026&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 07:59:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 29 Jun 2003 23:59:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-763032 ] tut/contents.html does not exist
Message-ID: <E19WsdJ-0007Hx-00@sc8-sf-web3.sourceforge.net>

Bugs item #763032, was opened at 2003-06-30 06:59
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=763032&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: tut/contents.html does not exist

Initial Comment:
2.2.3 and 2.3:

generating the html tutorial doesn't create
tut/contents.html, although it's referenced by other
tut/* pages.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 08:19:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 00:19:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-763043 ] unable to specify another compiler
Message-ID: <E19Wsww-0000Cl-00@sc8-sf-web1.sourceforge.net>

Bugs item #763043, was opened at 2003-06-30 07: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=763043&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: unable to specify another compiler

Initial Comment:
[forwarded from http://bugs.debian.org/197537]

Assume, python was built using `gcc' (version 3.3), but
an extension module needs to be built using `gcc-2.95',
because the library it depends on is still built by
g++-2.95, which has another ABI than g++-3.3.

I'm unable (or fail to see how) I can overwrite the
compiler used by distutils.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763043&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 08:33:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 00:33:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux
Message-ID: <E19WtAe-0003EQ-00@sc8-sf-web2.sourceforge.net>

Bugs item #763047, was opened at 2003-06-30 11:33
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=763047&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_strptime fails on Linux

Initial Comment:
Python 2.3b2+ (#1, Jun 30 2003, 10:50:39)
Linux version 2.4.18-19.7asp

test_strptime
test test_strptime failed -- Traceback (most recent
call last):
  File
"/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py",
line 312, in test_timezone
    "LocaleTime().timezone has duplicate values but "
  File
"/home/dima/src/other/python/dist/src/Lib/unittest.py",
line 268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: LocaleTime().timezone has duplicate
values but timzone value not set to -1

1 test failed:
    test_strptime


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 08:47:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 00:47:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k
Message-ID: <E19WtNz-0003ni-00@sc8-sf-web2.sourceforge.net>

Bugs item #763052, was opened at 2003-06-30 10: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=763052&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_winsound, test_strptime fails in win2k

Initial Comment:
Hello,

D:\apps\Python23>python -c "from test import
test_winsound;test_winsound.test_ma
in()"
test_errors (test.test_winsound.BeepTest) ... ok
test_extremes (test.test_winsound.BeepTest) ... ok
test_increasingfrequency (test.test_winsound.BeepTest)
... ok
test_asterisk (test.test_winsound.MessageBeepTest) ... ok
test_default (test.test_winsound.MessageBeepTest) ... ok
test_exclamation (test.test_winsound.MessageBeepTest)
... ok
test_hand (test.test_winsound.MessageBeepTest) ... ok
test_ok (test.test_winsound.MessageBeepTest) ... ok
test_question (test.test_winsound.MessageBeepTest) ... ok
test_alias_asterisk (test.test_winsound.PlaySoundTest)
... ok
test_alias_exclamation
(test.test_winsound.PlaySoundTest) ... ok
test_alias_exit (test.test_winsound.PlaySoundTest) ... ok
test_alias_fallback (test.test_winsound.PlaySoundTest)
... ok
test_alias_hand (test.test_winsound.PlaySoundTest) ... ok
test_alias_nofallback
(test.test_winsound.PlaySoundTest) ... ok
test_alias_question (test.test_winsound.PlaySoundTest)
... ok
test_errors (test.test_winsound.PlaySoundTest) ... ok
test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL

======================================================================
FAIL: test_stopasync (test.test_winsound.PlaySoundTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\lib\test\test_winsound.py",
line 94, in test_stopasync
    'SystemQuestion', winsound.SND_ALIAS |
winsound.SND_NOSTOP
  File "D:\apps\Python23\lib\unittest.py", line 285, in
failUnlessRaises
    raise self.failureException, excName
AssertionError: RuntimeError

----------------------------------------------------------------------
Ran 18 tests in 6.199s

FAILED (failures=1)
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "D:\apps\Python23\lib\test\test_winsound.py",
line 99, in test_main
    test_support.run_unittest(BeepTest,
MessageBeepTest, PlaySoundTest)
  File "D:\apps\Python23\lib\test\test_support.py",
line 259, in run_unittest
    run_suite(suite, testclass)
  File "D:\apps\Python23\lib\test\test_support.py",
line 247, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "D:\apps\Python23\lib\test\test_winsound.py",
line 94, in test_stopasync
    'SystemQuestion', winsound.SND_ALIAS |
winsound.SND_NOSTOP
  File "D:\apps\Python23\lib\unittest.py", line 285, in
failUnlessRaises
    raise self.failureException, excName
AssertionError: RuntimeError

----------------------------
D:\apps\Python23>python -c "from test import
test_strptime; test_strptime.test_m
ain()"
test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok
test_by_hand_input
(test.test_strptime.LocaleTime_Tests) ... ok
test_date_time (test.test_strptime.LocaleTime_Tests) ... ok
test_lang (test.test_strptime.LocaleTime_Tests) ... ok
test_month (test.test_strptime.LocaleTime_Tests) ... ok
test_timezone (test.test_strptime.LocaleTime_Tests) ... ok
test_unknowntimezone
(test.test_strptime.LocaleTime_Tests) ... ok
test_weekday (test.test_strptime.LocaleTime_Tests) ... ok
test_blankpattern (test.test_strptime.TimeRETests) ... ok
test_compile (test.test_strptime.TimeRETests) ... ok
test_getitem (test.test_strptime.TimeRETests) ... ok
test_matching_with_escapes
(test.test_strptime.TimeRETests) ... ok
test_pattern (test.test_strptime.TimeRETests) ... ok
test_pattern_escaping (test.test_strptime.TimeRETests)
... ok
test_TypeError (test.test_strptime.StrptimeTests) ... ok
test_caseinsensitive (test.test_strptime.StrptimeTests)
... ok
test_date (test.test_strptime.StrptimeTests) ... ok
test_date_time (test.test_strptime.StrptimeTests) ... ok
test_day (test.test_strptime.StrptimeTests) ... ok
test_defaults (test.test_strptime.StrptimeTests) ... ok
test_hour (test.test_strptime.StrptimeTests) ... ok
test_julian (test.test_strptime.StrptimeTests) ... ok
test_minute (test.test_strptime.StrptimeTests) ... ok
test_month (test.test_strptime.StrptimeTests) ... ok
test_percent (test.test_strptime.StrptimeTests) ... ok
test_second (test.test_strptime.StrptimeTests) ... ok
test_time (test.test_strptime.StrptimeTests) ... ok
test_timezone (test.test_strptime.StrptimeTests) ... FAIL
test_unconverteddata (test.test_strptime.StrptimeTests)
... ok
test_weekday (test.test_strptime.StrptimeTests) ... ok
test_year (test.test_strptime.StrptimeTests) ... ok
test_twelve_noon_midnight
(test.test_strptime.Strptime12AMPMTests) ... ok
test_all_julian_days (test.test_strptime.JulianTests)
... ok
test_day_of_week_calculation
(test.test_strptime.CalculationTests) ... ok
test_gregorian_calculation
(test.test_strptime.CalculationTests) ... ok
test_julian_calculation
(test.test_strptime.CalculationTests) ... ok

======================================================================
FAIL: test_timezone (test.test_strptime.StrptimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\lib\test\test_strptime.py",
line 312, in test_timezone
    "LocaleTime().timezone has duplicate values but "
  File "D:\apps\Python23\lib\unittest.py", line 268, in
failUnless
    if not expr: raise self.failureException, msg
AssertionError: LocaleTime().timezone has duplicate
values but timzone value not
 set to -1

----------------------------------------------------------------------
Ran 36 tests in 0.330s

FAILED (failures=1)
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "D:\apps\Python23\lib\test\test_strptime.py",
line 421, in test_main
    CalculationTests
  File "D:\apps\Python23\lib\test\test_support.py",
line 259, in run_unittest
    run_suite(suite, testclass)
  File "D:\apps\Python23\lib\test\test_support.py",
line 247, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "D:\apps\Python23\lib\test\test_strptime.py",
line 312, in test_timezone
    "LocaleTime().timezone has duplicate values but "
  File "D:\apps\Python23\lib\unittest.py", line 268, in
failUnless
    if not expr: raise self.failureException, msg
AssertionError: LocaleTime().timezone has duplicate
values but timzone value not
 set to -1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 10:36:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 02:36:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-762985 ] str.split seems to eat exception
Message-ID: <E19Wv4q-00089j-00@sc8-sf-web2.sourceforge.net>

Bugs item #762985, was opened at 2003-06-30 05:18
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762985&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Gerhard Häring (ghaering)
Summary: str.split seems to eat exception

Initial Comment:
comp.lang.python posting from Bill C. Wong (Message-ID:
<7sNLa.30264$Kg7.14786@nwrdny01.gnilink.net>)

################################
def func( s ):
    s1, s2 = s.split( ' ', 1 )
    try:
        raise s1
    except "aaaa":
        print 'except "aaaa"'
    except:
        print 'except:'

s = "aaaa "
func( s )
################################
If I manually assign s1 with s1 = "aaaa", then it works
fine! What am I doing wrong here?

----

Indeed if after the line s1, s2 = s.split you insert a line

s1 = "aaaaa"

then a different except clause is executed. Confirmed
with both Python 2.2.3 and Python 2.3beta2. This smells
like a bug to me.

Assigning to me and trying to investigate further.

----------------------------------------------------------------------

>Comment By: Gerhard Häring (ghaering)
Date: 2003-06-30 11:36

Message:
Logged In: YES 
user_id=163326

Other people confirmed on comp.lang.python that the cause of
this is indeed misuse of string exceptions. Closing.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2003-06-30 05:31

Message:
Logged In: YES 
user_id=163326

Ok, from http://python.org/doc/current/ref/try.html about
the except clause:

"""Note that the object identities must match, i.e. it must
be the same object, not just an object with the same value."""

Please can somebody confirm this and if so, close the bug
report?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762985&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 12:08:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 04:08:18 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-748201 ] time.strptime() should display format and date on error
Message-ID: <E19WwWA-0003ll-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #748201, was opened at 2003-06-03 16:14
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=748201&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Brett Cannon (bcannon)
Summary: time.strptime() should display format and date on error

Initial Comment:
Hi!

It would be very nice if the ValueError of
time.strptime() would
display the format and the date if there is a mismatch.

Up to now (python 2.2.2) the Error looks like this:
 ValueError: format mismatch
It would be nice if it would look like this:
 format mismatch: str=2002.12.24 format=%Y-%m-%d

 thomas

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-30 13:08

Message:
Logged In: YES 
user_id=89016

Maybe time.strptime() should use a subclass of ValueError,
with proper attributes.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 08:17

Message:
Logged In: YES 
user_id=80475

Helpful, informative error messages are certainly a step in 
the right direction.  Referrring to Brett for implementation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=748201&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 13:03:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 05:03:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k
Message-ID: <E19WxN8-0003J3-00@sc8-sf-web3.sourceforge.net>

Bugs item #763052, was opened at 2003-06-30 09:47
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
>Assigned to: Brett Cannon (bcannon)
Summary: test_winsound, test_strptime fails in win2k

Initial Comment:
Hello,

D:\apps\Python23>python -c "from test import
test_winsound;test_winsound.test_ma
in()"
test_errors (test.test_winsound.BeepTest) ... ok
test_extremes (test.test_winsound.BeepTest) ... ok
test_increasingfrequency (test.test_winsound.BeepTest)
... ok
test_asterisk (test.test_winsound.MessageBeepTest) ... ok
test_default (test.test_winsound.MessageBeepTest) ... ok
test_exclamation (test.test_winsound.MessageBeepTest)
... ok
test_hand (test.test_winsound.MessageBeepTest) ... ok
test_ok (test.test_winsound.MessageBeepTest) ... ok
test_question (test.test_winsound.MessageBeepTest) ... ok
test_alias_asterisk (test.test_winsound.PlaySoundTest)
... ok
test_alias_exclamation
(test.test_winsound.PlaySoundTest) ... ok
test_alias_exit (test.test_winsound.PlaySoundTest) ... ok
test_alias_fallback (test.test_winsound.PlaySoundTest)
... ok
test_alias_hand (test.test_winsound.PlaySoundTest) ... ok
test_alias_nofallback
(test.test_winsound.PlaySoundTest) ... ok
test_alias_question (test.test_winsound.PlaySoundTest)
... ok
test_errors (test.test_winsound.PlaySoundTest) ... ok
test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL

======================================================================
FAIL: test_stopasync (test.test_winsound.PlaySoundTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\lib\test\test_winsound.py",
line 94, in test_stopasync
    'SystemQuestion', winsound.SND_ALIAS |
winsound.SND_NOSTOP
  File "D:\apps\Python23\lib\unittest.py", line 285, in
failUnlessRaises
    raise self.failureException, excName
AssertionError: RuntimeError

----------------------------------------------------------------------
Ran 18 tests in 6.199s

FAILED (failures=1)
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "D:\apps\Python23\lib\test\test_winsound.py",
line 99, in test_main
    test_support.run_unittest(BeepTest,
MessageBeepTest, PlaySoundTest)
  File "D:\apps\Python23\lib\test\test_support.py",
line 259, in run_unittest
    run_suite(suite, testclass)
  File "D:\apps\Python23\lib\test\test_support.py",
line 247, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "D:\apps\Python23\lib\test\test_winsound.py",
line 94, in test_stopasync
    'SystemQuestion', winsound.SND_ALIAS |
winsound.SND_NOSTOP
  File "D:\apps\Python23\lib\unittest.py", line 285, in
failUnlessRaises
    raise self.failureException, excName
AssertionError: RuntimeError

----------------------------
D:\apps\Python23>python -c "from test import
test_strptime; test_strptime.test_m
ain()"
test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok
test_by_hand_input
(test.test_strptime.LocaleTime_Tests) ... ok
test_date_time (test.test_strptime.LocaleTime_Tests) ... ok
test_lang (test.test_strptime.LocaleTime_Tests) ... ok
test_month (test.test_strptime.LocaleTime_Tests) ... ok
test_timezone (test.test_strptime.LocaleTime_Tests) ... ok
test_unknowntimezone
(test.test_strptime.LocaleTime_Tests) ... ok
test_weekday (test.test_strptime.LocaleTime_Tests) ... ok
test_blankpattern (test.test_strptime.TimeRETests) ... ok
test_compile (test.test_strptime.TimeRETests) ... ok
test_getitem (test.test_strptime.TimeRETests) ... ok
test_matching_with_escapes
(test.test_strptime.TimeRETests) ... ok
test_pattern (test.test_strptime.TimeRETests) ... ok
test_pattern_escaping (test.test_strptime.TimeRETests)
... ok
test_TypeError (test.test_strptime.StrptimeTests) ... ok
test_caseinsensitive (test.test_strptime.StrptimeTests)
... ok
test_date (test.test_strptime.StrptimeTests) ... ok
test_date_time (test.test_strptime.StrptimeTests) ... ok
test_day (test.test_strptime.StrptimeTests) ... ok
test_defaults (test.test_strptime.StrptimeTests) ... ok
test_hour (test.test_strptime.StrptimeTests) ... ok
test_julian (test.test_strptime.StrptimeTests) ... ok
test_minute (test.test_strptime.StrptimeTests) ... ok
test_month (test.test_strptime.StrptimeTests) ... ok
test_percent (test.test_strptime.StrptimeTests) ... ok
test_second (test.test_strptime.StrptimeTests) ... ok
test_time (test.test_strptime.StrptimeTests) ... ok
test_timezone (test.test_strptime.StrptimeTests) ... FAIL
test_unconverteddata (test.test_strptime.StrptimeTests)
... ok
test_weekday (test.test_strptime.StrptimeTests) ... ok
test_year (test.test_strptime.StrptimeTests) ... ok
test_twelve_noon_midnight
(test.test_strptime.Strptime12AMPMTests) ... ok
test_all_julian_days (test.test_strptime.JulianTests)
... ok
test_day_of_week_calculation
(test.test_strptime.CalculationTests) ... ok
test_gregorian_calculation
(test.test_strptime.CalculationTests) ... ok
test_julian_calculation
(test.test_strptime.CalculationTests) ... ok

======================================================================
FAIL: test_timezone (test.test_strptime.StrptimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\lib\test\test_strptime.py",
line 312, in test_timezone
    "LocaleTime().timezone has duplicate values but "
  File "D:\apps\Python23\lib\unittest.py", line 268, in
failUnless
    if not expr: raise self.failureException, msg
AssertionError: LocaleTime().timezone has duplicate
values but timzone value not
 set to -1

----------------------------------------------------------------------
Ran 36 tests in 0.330s

FAILED (failures=1)
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "D:\apps\Python23\lib\test\test_strptime.py",
line 421, in test_main
    CalculationTests
  File "D:\apps\Python23\lib\test\test_support.py",
line 259, in run_unittest
    run_suite(suite, testclass)
  File "D:\apps\Python23\lib\test\test_support.py",
line 247, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "D:\apps\Python23\lib\test\test_strptime.py",
line 312, in test_timezone
    "LocaleTime().timezone has duplicate values but "
  File "D:\apps\Python23\lib\unittest.py", line 268, in
failUnless
    if not expr: raise self.failureException, msg
AssertionError: LocaleTime().timezone has duplicate
values but timzone value not
 set to -1

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-30 14:03

Message:
Logged In: YES 
user_id=89016

The most likely reason for the winsound failure is, that
your "SystemQuestion" sound has already finished before the
second one starts, so there will be no RuntimeError exception.

Checked in a fix as:
Lib/test/test_winsound.py 1.6

Assigning to Brett Cannon for the strptime stuff.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 13:04:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 05:04:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux
Message-ID: <E19WxOx-0003R5-00@sc8-sf-web3.sourceforge.net>

Bugs item #763047, was opened at 2003-06-30 09:33
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
>Assigned to: Brett Cannon (bcannon)
Summary: test_strptime fails on Linux

Initial Comment:
Python 2.3b2+ (#1, Jun 30 2003, 10:50:39)
Linux version 2.4.18-19.7asp

test_strptime
test test_strptime failed -- Traceback (most recent
call last):
  File
"/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py",
line 312, in test_timezone
    "LocaleTime().timezone has duplicate values but "
  File
"/home/dima/src/other/python/dist/src/Lib/unittest.py",
line 268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: LocaleTime().timezone has duplicate
values but timzone value not set to -1

1 test failed:
    test_strptime


----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-30 14:04

Message:
Logged In: YES 
user_id=89016

This might be a duplicate of 763052, which reported to same
error under Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 13:35:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 05:35:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed
Message-ID: <E19Wxs9-00042S-00@sc8-sf-web3.sourceforge.net>

Bugs item #763153, was opened at 2003-06-30 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=763153&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Torsten Will (towi)
Assigned to: Nobody/Anonymous (nobody)
Summary: unit test test_time failed

Initial Comment:
=== ERROR MASSAGE ===

$ make test
...
test test_time failed -- Traceback (most recent call last):
  File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py",
line 107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST
...

=========== SYSTEM ===========

$ cat /proc/version 
Linux version 2.4.19 (root@haplo) (gcc version 2.95.3
20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 14:34:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 06:34:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-763190 ] Sudden death with SIGSEGV in RtlEnterCriticalSection
Message-ID: <E19WynZ-0002jN-00@sc8-sf-web2.sourceforge.net>

Bugs item #763190, was opened at 2003-06-30 15: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=763190&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Maria Martinsdotter (dehex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sudden death with SIGSEGV in RtlEnterCriticalSection

Initial Comment:
Environment:
Python 2.2.2
win32all-150
Win2000 Server
Dell server
2 CPU Pentuim 4 emulating 4 CPU's.

Application:
Service with many (50-150) threads.

Problem:
The entire service exits unexepectedly with only a brief 
reference made by Dr.Watson indicating the Windows 
equivalent of SIGSEGV in RtlEnterCriticalSection.

Side info:
Known to have happened once, we believe it may have 
happened three times in total but the two extra did not 
leave even a Dr.Watson trace.

The known occurrence can be connected to our use of a 
timer where the action routine restarts the timer.
The two extra's occurred at a point in time that connect 
the problem event to the timer expiration.

The application have been used for five months, 
runnning around the clock. The customer installation 
currently use five instances of the base software, only 
configuration differs.
It is arbitrary which instance fail.

We have no means to trigger the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 15:21:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 07:21:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors
Message-ID: <E19WzXa-00081t-00@sc8-sf-web4.sourceforge.net>

Bugs item #728330, was opened at 2003-04-27 02:21
Message generated for change (Comment added) made by rwgk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 9
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: IRIX, 2.3b1, socketmodule.c compilation errors

Initial Comment:
Python release:
  2.3b1
Platform:
  IRIX 6.5
  MIPSpro Compilers: Version 7.3.1.2m
Commands used:
  ./configure --prefix=/usr/local_cci/Python-2.3b1t
  make

The socket module fails to compile. The output from 
the compiler is attached.


----------------------------------------------------------------------

>Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-06-30 07:21

Message:
Logged In: YES 
user_id=71407

The socket module still fails to compile with Python 
2.3b2, in addition to two other extensions. The full make 
log is attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-21 23:47

Message:
Logged In: YES 
user_id=21627

I think it would be best if detect presence of
inet_aton/inet_pton. Is IPv6 support possible on this
system? Then it would be best if that was detected, as well.

If it is not possible to detect aton/pton/ipv6, what is the
problem with not using them?

I'd like to have a look at the relevant headers (in
particular to understand the duplicate definition of
_SGIAPI), indeed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-21 16:35

Message:
Logged In: YES 
user_id=33168

Argh!!!  This is a nightmare.  The attached hack ^h^h^h
patch fixes the problem, but ...

_SGIAPI needs to be defined (~192 in socketmodule.c) in
order to get the prototypes for inet_aton, inet_pton.  But
_SGIAPI can't be defined in the standard header files
because XOPEN_SOURCE is defined.

Martin, do you have any other suggestions?  I don't see how
to do this right within configure.  If you want I can send
you the header file(s).

----------------------------------------------------------------------

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 10:41

Message:
Logged In: YES 
user_id=150999

I had the same problem compiling socket on Irix.
We did find that on our system ENABLE_IPV6 is not define and
all the error are cause by that.
  
System that do not enable IPV6 are not well supported with
the socketmodule.c code.
We were able to compile socket after making few change in
the code: 
I am not sure if I did it right but it compile.
I will post my patch but I do not see any place to attach my
file
example: See line 2794,2800

+ #ifdef ENABLE_IPV6
        char packed[MAX(sizeof(struct in_addr),
sizeof(struct in6_addr))];
+ #else
+       char packed[sizeof(struct in_addr)];
+ #endif

I am not sure how to post the patch or file.


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-05-05 11:44

Message:
Logged In: YES 
user_id=71407

This is not in my area of expertise, but I've tried a couple of 
(probably stupid) things:

#include <standards.h> in socketmodule.c instead of #define 
_SGIAPI.
This resulted in even more errors.

./configure --disable-ipv6
Same errors as before.

I am lost here. Sorry. But you still have ssh access to 
rattler.lbl.gov if that helps. Accounts for other Python developers 
are a possibility.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 05:39

Message:
Logged In: YES 
user_id=21627

Can you analyse these compiler errors in more detail,
please? What, in your opinion, is causing these problems,
and how would you correct them?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 15:59:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 07:59:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-763026 ] AssertionError in httplib.py
Message-ID: <E19X089-0004h9-00@sc8-sf-web1.sourceforge.net>

Bugs item #763026, was opened at 2003-06-30 06:37
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763026&group_id=5470

Category: Python Library
Group: Python 2.2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Jeremy Hylton (jhylton)
Summary: AssertionError in httplib.py

Initial Comment:
[forwarded from http://bugs.debian.org/192452]

When running bittorrent for a few hours, I start seeing
this assertion fire in
httplib.py from the Python 2.2 libraries:

Exception in thread Thread-20:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 414, in
__bootstrap
    self.run()
  File "/usr/lib/python2.2/threading.py", line 402, in run
    apply(self.__target, self.__args, self.__kwargs)
  File
"/usr/lib/python2.2/site-packages/BitTorrent/Rerequester.py",
line 76, in rerequest
    r = h.read()
  File "/usr/lib/python2.2/httplib.py", line 1140, in read
    assert not self._line_consumed and self._line_left
AssertionError

can be reproduced with 2.3 as well.

I do see this assertition triggered in another context:

- make a request
- when the request returns, the result code is 200
- trying to read the data returned triggers the assertion

I found out the server sider crashes/is crashed, so
probably no data is returned. maybe httplib could be a
bit more robust or throw a correct exception.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-30 14:59

Message:
Logged In: YES 
user_id=31392

Duplicate of 666219, and fixed in Python 2.3b2.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763026&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:01:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:01:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-763032 ] tut/contents.html does not exist
Message-ID: <E19X0AC-0004re-00@sc8-sf-web1.sourceforge.net>

Bugs item #763032, was opened at 2003-06-30 06:59
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tut/contents.html does not exist

Initial Comment:
2.2.3 and 2.3:

generating the html tutorial doesn't create
tut/contents.html, although it's referenced by other
tut/* pages.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:13:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:13:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-763190 ] Sudden death with SIGSEGV in RtlEnterCriticalSection
Message-ID: <E19X0LX-0005L7-00@sc8-sf-web1.sourceforge.net>

Bugs item #763190, was opened at 2003-06-30 09:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Maria Martinsdotter (dehex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sudden death with SIGSEGV in RtlEnterCriticalSection

Initial Comment:
Environment:
Python 2.2.2
win32all-150
Win2000 Server
Dell server
2 CPU Pentuim 4 emulating 4 CPU's.

Application:
Service with many (50-150) threads.

Problem:
The entire service exits unexepectedly with only a brief 
reference made by Dr.Watson indicating the Windows 
equivalent of SIGSEGV in RtlEnterCriticalSection.

Side info:
Known to have happened once, we believe it may have 
happened three times in total but the two extra did not 
leave even a Dr.Watson trace.

The known occurrence can be connected to our use of a 
timer where the action routine restarts the timer.
The two extra's occurred at a point in time that connect 
the problem event to the timer expiration.

The application have been used for five months, 
runnning around the clock. The customer installation 
currently use five instances of the base software, only 
configuration differs.
It is arbitrary which instance fail.

We have no means to trigger the problem.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 11:13

Message:
Logged In: YES 
user_id=33168

Are there any other C/Extension modules used which are not
from the standard python distribution?  Can you make a self
contained test case?

I encourage you to test with 2.3 beta 2.  There were some
thread changes which could affect this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:15:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:15:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed
Message-ID: <E19X0Nj-00083I-00@sc8-sf-web2.sourceforge.net>

Bugs item #763153, was opened at 2003-06-30 08:35
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Torsten Will (towi)
Assigned to: Nobody/Anonymous (nobody)
Summary: unit test test_time failed

Initial Comment:
=== ERROR MASSAGE ===

$ make test
...
test test_time failed -- Traceback (most recent call last):
  File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py",
line 107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST
...

=========== SYSTEM ===========

$ cat /proc/version 
Linux version 2.4.19 (root@haplo) (gcc version 2.95.3
20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 11:15

Message:
Logged In: YES 
user_id=33168

What OS are you using?  Redhat 6.2, perhaps?  Can you test
patch 762934?  http://python.org/sf/762934

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:19:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:19:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-763023 ]  difflib.py: line 528 in ratio() zero division not caught
Message-ID: <E19X0Rj-0002j9-00@sc8-sf-web3.sourceforge.net>

Bugs item #763023, was opened at 2003-06-30 02:24
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Raymond Hettinger (rhettinger)
Summary:  difflib.py: line 528 in ratio() zero division not caught

Initial Comment:
2.2.3 and 2.3b1:

>>> from difflib import * 
>>> s = SequenceMatcher(None, [], []) 
>>> s.ratio() 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
    File "/usr/lib/python2.2/difflib.py", line 528, in
ratio 
        return 2.0 * matches / (len(self.a) + len(self.b)) 
      ZeroDivisionError: float division 


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 11:19

Message:
Logged In: YES 
user_id=33168

This affects 2.3 as well (line 614).  The return line can be
wrapped with try/except ZeroDivisionError.  Raymond, should
0.0 be returned in this case?  Should something else be done?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:22:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:22:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-763007 ] dl module not installed with 2.2.3
Message-ID: <E19X0U0-0002rn-00@sc8-sf-web3.sourceforge.net>

Bugs item #763007, was opened at 2003-06-30 01:08
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Messmore (salmo)
Assigned to: Nobody/Anonymous (nobody)
Summary: dl module not installed with 2.2.3

Initial Comment:
I'm running Redhat 7.3 on an older PII.  I was
attemping to try out the python bindings for gstreamer
when I discovered my build of python 2.2.3 was lacking
the 'dl' module.  I've installed RPMS built from the
SRPMS available on the python.org site (with the
non-redhat9 spec file).  Looking around I have not
found a reason for this, nor a way to go about fixing
it, so I assume it is a bug.  Whenever I try to run a
gst-python example I get an ImportError stating the the
dl module does not exist, as well as when I try to run
test_dl.py in my /usr/lib/python2.2/test/ directory.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 11:22

Message:
Logged In: YES 
user_id=33168

What is the error when building dlmodule.c?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:27:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:27:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-759525 ] inspect.getmembers broken (?)
Message-ID: <E19X0Z4-0003AR-00@sc8-sf-web4.sourceforge.net>

Bugs item #759525, was opened at 2003-06-23 18:43
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759525&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 1
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getmembers broken (?)

Initial Comment:
inspect.getmembers currently uses `dir` to obtain a
list of an object's "members", which omits certain
things such as methods of the metaclass, e.g:

  >>> 'mro' in dict(inspect.getmembers(int))
  0

Since I can't find a description of what exactly
constitutes a "member", it is not strictly possible to
tell whether this is the intended behavior, but then
the documentation should be updated in this case to
clarify the semantics more.

It currently seems quite hard to answer seemingly
innocuous questions such as "What are the methods of
class/type X?" with introspection. 

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-30 11:27

Message:
Logged In: YES 
user_id=6380

This is unclear indeed -- inspect is definitely underspecified.

It *is* clearly defined that dir() doesn't return metaclass
attributes when the argument is a class.

To find out the metaclass arguments, simply use
dir(int.__class__).

I'll leave this open, but I expect that at best some
documentation clarification will come out of this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759525&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:30:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:30:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-763023 ]  difflib.py: line 528 in ratio() zero division not caught
Message-ID: <E19X0cD-0003Po-00@sc8-sf-web3.sourceforge.net>

Bugs item #763023, was opened at 2003-06-30 01:24
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Neal Norwitz (nnorwitz)
Summary:  difflib.py: line 528 in ratio() zero division not caught

Initial Comment:
2.2.3 and 2.3b1:

>>> from difflib import * 
>>> s = SequenceMatcher(None, [], []) 
>>> s.ratio() 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
    File "/usr/lib/python2.2/difflib.py", line 528, in
ratio 
        return 2.0 * matches / (len(self.a) + len(self.b)) 
      ZeroDivisionError: float division 


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-30 10:30

Message:
Logged In: YES 
user_id=80475

When the denominator is zero, it means that both sequences 
are of zero-length; therefore, the two sequences are equal, 
so the return value should be 1.0.

The try / except ZeroDivision error approach look good.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 10:19

Message:
Logged In: YES 
user_id=33168

This affects 2.3 as well (line 614).  The return line can be
wrapped with try/except ZeroDivisionError.  Raymond, should
0.0 be returned in this case?  Should something else be done?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:34:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:34:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-763023 ]  difflib.py: line 528 in ratio() zero division not caught
Message-ID: <E19X0fm-0003b1-00@sc8-sf-web3.sourceforge.net>

Bugs item #763023, was opened at 2003-06-30 01:24
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Neal Norwitz (nnorwitz)
Summary:  difflib.py: line 528 in ratio() zero division not caught

Initial Comment:
2.2.3 and 2.3b1:

>>> from difflib import * 
>>> s = SequenceMatcher(None, [], []) 
>>> s.ratio() 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
    File "/usr/lib/python2.2/difflib.py", line 528, in
ratio 
        return 2.0 * matches / (len(self.a) + len(self.b)) 
      ZeroDivisionError: float division 


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-30 10:34

Message:
Logged In: YES 
user_id=80475

One other thought.  The same fix should be made to all three 
ratio methods (including quick and real-quick).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-30 10:30

Message:
Logged In: YES 
user_id=80475

When the denominator is zero, it means that both sequences 
are of zero-length; therefore, the two sequences are equal, 
so the return value should be 1.0.

The try / except ZeroDivision error approach look good.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 10:19

Message:
Logged In: YES 
user_id=33168

This affects 2.3 as well (line 614).  The return line can be
wrapped with try/except ZeroDivisionError.  Raymond, should
0.0 be returned in this case?  Should something else be done?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:46:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:46:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-761144 ] tkMessageBox.askyesnocancel missing
Message-ID: <E19X0qx-0004Bd-00@sc8-sf-web4.sourceforge.net>

Bugs item #761144, was opened at 2003-06-26 07:44
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761144&group_id=5470

Category: Tkinter
Group: Python 2.2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Michael Peternell (mpeti)
Assigned to: Nobody/Anonymous (nobody)
Summary: tkMessageBox.askyesnocancel missing

Initial Comment:
there's no easy way to make a MessageBox that displays
yes, no and cancel. and askquestion doesn't work:
---
>>> askquestion("hi", "huhu", type=YESNOCANCEL)
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in ?
    askquestion("hi", "huhu", type=YESNOCANCEL)
  File
"C:\Programme\Python22\lib\lib-tk\tkMessageBox.py",
line 91, in askquestion
    return apply(_show, (title, message, QUESTION,
YESNO), options)
TypeError: _show() got multiple values for keyword
argument 'type'
---
so I decided to hack into tkMessageBox.py and added one.

Have a nice day!
Michael

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-30 11:46

Message:
Logged In: YES 
user_id=6380

I'm rejecting this.

You can do this easily enough by using the Dialog class
directly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761144&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:55:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:55:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-761787 ] readline()/readlines()
Message-ID: <E19X10F-0007Te-00@sc8-sf-web1.sourceforge.net>

Bugs item #761787, was opened at 2003-06-27 08:26
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761787&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raise L. Sail (fullsail)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline()/readlines()

Initial Comment:
At first, I can not speak English very well ,so follow
my description may be not very nicety.

I use python for processing text file(It may contain 
many chinese characters). readline()/readlines() , I use 
them many times, but I found they's result read from hte 
text file is different from text.

I uploaded the files can omit this bug.

I modified the data file, beacause of It contain some 
user information of my work.

run s.py, then view txt\ADSL5.txt, you can 
understand......

and:
My platform:
Win98SE + Python 2.2.2 + PythonWin for py22
Win2000Pro+SP3 + Python 2.2.3 + PythonWin for py22


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-30 11:55

Message:
Logged In: YES 
user_id=6380

Sorry, I don't understand the problem.

Can you explain what in the output file you expected to be
different?

Can you perhaps create a smaller example that shows the
difference between what you expected and what you got?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761787&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 16:57:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 08:57:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-761888 ] popen2.Popen3 and popen2.Popen4 leaks filedescriptors
Message-ID: <E19X122-0004cZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #761888, was opened at 2003-06-27 10:58
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761888&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Troels Walsted Hansen (troels)
Assigned to: Tim Peters (tim_one)
Summary: popen2.Popen3 and popen2.Popen4 leaks filedescriptors

Initial Comment:
The code below (from Lib/popen2.py) appears to leak no
less then 4 filedescriptors if os.fork() raises an
exception (say "OSError: [Errno 12] Not enough space"
on a Solaris box running out of swap).

Popen3.__init__() appears to leak 6 filedescriptors.

class Popen4(Popen3):
    def __init__(self, cmd, bufsize=-1):
        p2cread, p2cwrite = os.pipe()
        c2pread, c2pwrite = os.pipe()
        self.pid = os.fork()


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-30 11:57

Message:
Logged In: YES 
user_id=6380

I haven't reviewed the code or the fix, but as a bugfix this
could go into 2.3.

The two patch files are confusing -- why two?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 23:10

Message:
Logged In: YES 
user_id=33168

Tim, for 2.3b2 or 2.3.1?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-28 23:09

Message:
Logged In: YES 
user_id=33168

The attached patch should fix the problem, I'd appreciate if
you could test this.  There are 2 files attached, one is a
context diff with whitespace modifications, the other is a
minimal (no whitespace differences) patch to show what's
changed (ie, the try/except).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761888&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 17:08:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 09:08:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-762614 ] problem building c extension with minGW on Windows
Message-ID: <E19X1CM-0002KF-00@sc8-sf-web2.sourceforge.net>

Bugs item #762614, was opened at 2003-06-29 05:07
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762614&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Fuming Wang (fumingw)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem building c extension with minGW on Windows

Initial Comment:

I am having problems building C extension on Python
2.3b1 on Windows 2000 with latest minGW. The culprit
seems to be calling of Py_None.  Here is a test module,
which builds happily on python 2.2.3.

Here is build options:
 gcc -mno-cygwin -mdll -O -Wall
-Id:\fuming\lib\python\include -c spam.c -o spam.o


 dllwrap -mno-cygwin -mdll -static --dllname spam.pyd
--driver-name gcc --def spam.def -o spam.pyd s
pam.o -s --entry _DllMain@12 --target=i386-mingw32
-Ld:\fuming\lib\python\libs -lpython23


Here is the error message I get on Python 2.3b1:
spam.o(.text+0x60):spam.c: undefined reference to
`_imp___Py_NoneStruct'
spam.o(.text+0x68):spam.c: undefined reference to
`_imp___Py_NoneStruct'
dllwrap: gcc exited with status 1

Here is the source code:


/* c function */
static PyObject *
spam_system(PyObject *self, PyObject *input_str)
{
    char *local_string;
    int length;

    if (!PyArg_ParseTuple(input_str, "s#",
&local_string, &length)) {
        return NULL;
    }

    printf("%s\n", local_string);        
    printf("number of letters = %d\n", length);

    
    Py_INCREF(Py_None);
    return Py_None;
  

    /*
    return Py_BuildValue("i", length);
    */

};

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-30 12:08

Message:
Logged In: YES 
user_id=6380

This must be a problem in minGW, not in Python. Please go
ask the minGW developers for help.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762614&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 17:06:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 09:06:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-762198 ] bug in signal.signal -- raises SystemError
Message-ID: <E19X1Am-00082r-00@sc8-sf-web1.sourceforge.net>

Bugs item #762198, was opened at 2003-06-27 20:04
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim McCoy (mccoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in signal.signal -- raises SystemError

Initial Comment:
Summary pretty much says it all.  Using Py2.2.3, win2k 
(sp4), and twisted 1.0.5 and the call that is triggering the 
error is as follows:

signal.signal(signal.SIGINT, self.sigInt)

returns "SystemError: error return without exception set"

The twisted gang has tracked it down to a C error of some 
sort here...


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-30 12:06

Message:
Logged In: YES 
user_id=6380

I don't have Win2K, but on Win98 I can't reproduce it.

The bug report is pretty incomplete -- the call doesn't seem
to need Twisted, so what I tried was this:

>>> from signal import *
>>> signal(SIGINT, lambda *a: None)

This returns the previous handler as it should.

So please, send more precise data about the problem, or be
ignored.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 17:48:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 09:48:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-748928 ] last threads fixes broke linker
Message-ID: <E19X1po-0007Ao-00@sc8-sf-web4.sourceforge.net>

Bugs item #748928, was opened at 2003-06-04 17:25
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: last threads fixes broke linker

Initial Comment:
In current cvs, -pthread and -ieee is properly set for
OSF1/Tru64Unix. Unfortunately, -ieee is somewhat passed
to linker:

building '_curses' extension
cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/mnt/python/dist/src/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/python/dist/src/Include -I/mnt/python/dist/src
-c /mnt/python/dist/src/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved * -ieee -std -Olimit 1500
-DNDEBUG -O -I. -I./Include
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
ld:
-ieee: Unknown flag
ld: Usage: ld [options] file [...]
building '_curses_panel' extension


----------------------------------------------------------------------

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-30 18:48

Message:
Logged In: YES 
user_id=696559

So, for me the problem with -ieee is fixed in current cvs too.
I still do have problems building the ncurses part(I use
ncurses 5.3). But the ncurses I've reported as another bug
report. So this report can be closed. Thanks.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 06:29

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  When I test with the current CVS
(2.3b2) on Tru64 5.1, I don't get many flags passed to ld,
but my cc line looks the same.  Can you make sure you have a
clean copy of configure from CVS?  Also, do a make clean and
./configure.

cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/net/boa/scratch1/nnorwitz/python/dist/src/./Include
-I/usr/local/include
-I/net/boa/scratch1/nnorwitz/python/dist/src/Include
-I/net/boa/scratch1/nnorwitz/python/dist/src -c
/net/boa/scratch1/nnorwitz/python/dist/src/Modules/_cursesmodule.c
-o build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/usr/local/lib -lcurses -ltermcap -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so


----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 23:30

Message:
Logged In: YES 
user_id=696559

Get free account on testing machine at
http://www.testdrive.compaq.com/

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 22:38

Message:
Logged In: YES 
user_id=21627

I see; -ieee is indeed passed to ld. I am a programmer, but
I cannot develop on Tru64. So we have to wait until a
programmer with access to Tru64 shows up.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:29

Message:
Logged In: YES 
user_id=696559

Actually, I don't know why -ieee is needed, I'm not a
programmer, sorry. The manpage cc(1) says:

  -ieee
      Ensure support of all portable features of the IEEE
Standard for Binary
      Floating-Point Arithmetic (ANSI/IEEE Std 754-1985),
including the
      treatment of denormalized numbers, NaNs, and
infinities and the han-
      dling of error cases. This option also sets the
_IEEE_FP C preprocessor
      macro.

      If your program must use IEEE signaling features that
are not portable
      across different IEEE implementations, see the ieee(3)
reference page
      for a discussion of how to access them under the Tru64
UNIX operating
      system.



Yes, -ieee is not listed in mapage for ld(1). I do not have
an access to that machine probably for a whole week, but are
you sure the -ieee is not in teh generated Makefiles passed
inside some variable to linker directly?



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:40

Message:
Logged In: YES 
user_id=21627

Is it not the case that cc(1) supports -ieee? If so, why
does it then pass the option to ld?

Perhaps it depends on the cc version whether -ieee is
supported? Perhaps the compiler should be invoked with a
different name?

Please don't make us guess as to how your operating system
works. If you can contribute to a solution, that would be
much appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 17:51:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 09:51:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-748928 ] last threads fixes broke linker
Message-ID: <E19X1sG-0006zo-00@sc8-sf-web3.sourceforge.net>

Bugs item #748928, was opened at 2003-06-04 11:25
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: last threads fixes broke linker

Initial Comment:
In current cvs, -pthread and -ieee is properly set for
OSF1/Tru64Unix. Unfortunately, -ieee is somewhat passed
to linker:

building '_curses' extension
cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/mnt/python/dist/src/./Include
-I/software/@sys/usr/include -I/usr/local/include
-I/mnt/python/dist/src/Include -I/mnt/python/dist/src
-c /mnt/python/dist/src/Modules/_cursesmodule.c -o
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved * -ieee -std -Olimit 1500
-DNDEBUG -O -I. -I./Include
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so
ld:
-ieee: Unknown flag
ld: Usage: ld [options] file [...]
building '_curses_panel' extension


----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-30 12:48

Message:
Logged In: YES 
user_id=696559

So, for me the problem with -ieee is fixed in current cvs too.
I still do have problems building the ncurses part(I use
ncurses 5.3). But the ncurses I've reported as another bug
report. So this report can be closed. Thanks.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 00:29

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  When I test with the current CVS
(2.3b2) on Tru64 5.1, I don't get many flags passed to ld,
but my cc line looks the same.  Can you make sure you have a
clean copy of configure from CVS?  Also, do a make clean and
./configure.

cc -pthread -DNDEBUG -O -ieee -std -Olimit 1500 -I.
-I/net/boa/scratch1/nnorwitz/python/dist/src/./Include
-I/usr/local/include
-I/net/boa/scratch1/nnorwitz/python/dist/src/Include
-I/net/boa/scratch1/nnorwitz/python/dist/src -c
/net/boa/scratch1/nnorwitz/python/dist/src/Modules/_cursesmodule.c
-o build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o
-L/usr/local/lib -lcurses -ltermcap -o
build/lib.osf1-V5.1-alpha-2.3/_curses.so


----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 17:30

Message:
Logged In: YES 
user_id=696559

Get free account on testing machine at
http://www.testdrive.compaq.com/

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 16:38

Message:
Logged In: YES 
user_id=21627

I see; -ieee is indeed passed to ld. I am a programmer, but
I cannot develop on Tru64. So we have to wait until a
programmer with access to Tru64 shows up.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 09:29

Message:
Logged In: YES 
user_id=696559

Actually, I don't know why -ieee is needed, I'm not a
programmer, sorry. The manpage cc(1) says:

  -ieee
      Ensure support of all portable features of the IEEE
Standard for Binary
      Floating-Point Arithmetic (ANSI/IEEE Std 754-1985),
including the
      treatment of denormalized numbers, NaNs, and
infinities and the han-
      dling of error cases. This option also sets the
_IEEE_FP C preprocessor
      macro.

      If your program must use IEEE signaling features that
are not portable
      across different IEEE implementations, see the ieee(3)
reference page
      for a discussion of how to access them under the Tru64
UNIX operating
      system.



Yes, -ieee is not listed in mapage for ld(1). I do not have
an access to that machine probably for a whole week, but are
you sure the -ieee is not in teh generated Makefiles passed
inside some variable to linker directly?



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 02:40

Message:
Logged In: YES 
user_id=21627

Is it not the case that cc(1) supports -ieee? If so, why
does it then pass the option to ld?

Perhaps it depends on the cc version whether -ieee is
supported? Perhaps the compiler should be invoked with a
different name?

Please don't make us guess as to how your operating system
works. If you can contribute to a solution, that would be
much appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748928&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 18:01:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 10:01:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-763362 ] test_posixpath failed
Message-ID: <E19X221-0007Nm-00@sc8-sf-web3.sourceforge.net>

Bugs item #763362, was opened at 2003-06-30 19:01
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=763362&group_id=5470

Category: Demos and Tools
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_posixpath failed

Initial Comment:
I get the following with current cvs on Tru64Unix 5.1A:


test_posix
test_posixpath
test test_posixpath failed -- Traceback (most recent
call last):
  File
"/mnt/python/dist/src/Lib/test/test_posixpath.py", line
343, in test_expanduser
    posixpath.expanduser("~/")
  File "/mnt/python/dist/src/Lib/unittest.py", line
292, in failUnlessEqual
    raise self.failureException, \
AssertionError: '//' != '/'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763362&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 18:13:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 10:13:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-763032 ] tut/contents.html does not exist
Message-ID: <E19X2Dd-0008Ap-00@sc8-sf-web4.sourceforge.net>

Bugs item #763032, was opened at 2003-06-30 02:59
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tut/contents.html does not exist

Initial Comment:
2.2.3 and 2.3:

generating the html tutorial doesn't create
tut/contents.html, although it's referenced by other
tut/* pages.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-06-30 13:13

Message:
Logged In: YES 
user_id=3066

This was fixed in time for the Python 2.3 beta 2 release;
please update your copy of the formatting tools.  In
particular, Doc/perl/l2hinit.perl needs to be updated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 18:24:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 10:24:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs a last distribution
Message-ID: <E19X2OJ-0008Ff-00@sc8-sf-web3.sourceforge.net>

Bugs item #748926, was opened at 2003-06-04 17:23
Message generated for change (Comment added) made by mmokrejs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken ncurses support in current cvs a last distribution

Initial Comment:
I found configure looks for ncurses.h instead of
ncurses/ncurses.h. Please note that newer version of
ncurses have moved ncurses.h to a subdirectory ncurses/.

Even after fixing configure and
Modules/_curses_panel.c, I get:

cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 506: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addch (const chtype);      
                 /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 507: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchnstr (const chtype *,
int);             /* generated */
---------------------------^
cc: Error: /software/@sys/usr/include/ncurses/curses.h,
line 508: Missing identifier. (parnoident)
extern NCURSES_EXPORT(int) addchstr (const chtype *); 
                 /* generated */
---------------------------^

Any ideas?

----------------------------------------------------------------------

>Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-30 19:24

Message:
Logged In: YES 
user_id=696559

Hi,
  so the problem is that I have to manually specify
-I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses under BASECFLAGS in
src/Makefile. If I set these includes on CPPFLAGS, they're
used only for building the python core, not the modules.

  I believe the configure should test for both:

<ncurses.h>
<ncurses/ncurses.h>

ncurses-5.3 and newer install into $prefix/include/ncurses/
instead of former $prefix/include/.

This change should be reflected by the configure script.


I believe the dist/src/Modules/_curses_panel.c calling
panel.h should be adjusted properly. It is not a must as
long as configure will set -I$pref/include
-I$pref/include/ncurses.



----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 23:37

Message:
Logged In: YES 
user_id=696559

Second reply(I have to add I'll retry once more, but I
believe the whole story is python used to compile fine with
older ncurses, which placed headers into include/ . Newer
versions place headers into include/ncurses/ subdirectory,
and that is not expected. I do not have the gcc problem with
gcc fixincludes as the machine was recently installed and
there were always ncurses 5.0 and above installed.):

> Hi Thomas,
>   but I use cc from DEC?DIGITAL/COMPAQ/HP, so it shouldn't
see those
> "fixed" headers, right?

no - gcc is the one that "fixes" headers.  It is unlikely
that your $CFLAGS
or $CPPFLAGS has an explicit
        -I/usr/lib/gcc-lib/i386-linux/3.0.4/include

Then it sounds like a variation of the other sort of
problem:  compiler finds
one of the headers, but not all.  The message seems to
indicate that the
compiler did not find a definition for NCURSES_EXPORT, which
is defined in
ncurses_dll.h

What I'd look for: since most applications do not distinguish
        #include <ncurses/curses.h>
and
        #include <curses.h>
by ifdef's is that your options have only
        -I/software/@sys/usr/include/ncurses
rather than
        -I/software/@sys/usr/include
        -I/software/@sys/usr/include/ncurses
Since the ncurses headers (unctrl.h, term.h) will have a
line like
        #include <ncurses/curses.h>
it really needs both -I options.  (Specifying both still
does not work around
the gcc fixincludes problem - that's why I remember that one
first).
 
> > (It's "fixing" a place which is providing a typedef if
it doesn't exist).
> > I modified the ifdef's to avoid this problem.  The quick
fix is to remove
> > curses.h from gcc's fixed-includes.  The reason why
NCURSES_EXPORT is not
> > defined is because gcc finds the wrong curses.h and
doesn't find ncurses_dll.h
> > because its fixed-include forces it into the wrong
search path.
> >
> > If it's not that - perhaps more info.  (Perhaps just
setting $CPPFLAGS in
> > the environment is needed).
> 
> But the message
> 
> cc: Error: /software/@sys/usr/include/ncurses/curses.h,
> line 506: Missing identifier. (parnoident)
> extern NCURSES_EXPORT(int) addch (const chtype);
> /* generated */
> ---------------------------^
> cc: Error: /software/@sys/usr/include/ncurses/curses.h,
> line 507: Missing identifier. (parnoident)
> extern NCURSES_EXPORT(int) addchnstr (const chtype *,
> int); /* generated */
> ---------------------------^
> cc: Error: /software/@sys/usr/include/ncurses/curses.h,
> line 508: Missing identifier. (parnoident)
> extern NCURSES_EXPORT(int) addchstr (const chtype *);
> /* generated */
> ---------------------------^
> 
> confirms that CPPFLAGS or CFLAGS point to the location
where ncurses are
> installed! Maybe the problem is that ncurses/ncurses.h are
stored as
> ncurses/curses.h?
> 


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-17 22:35

Message:
Logged In: YES 
user_id=21627

I see. This seems to be either a bug in ncurses, or in gcc.
Closing as third-party.

----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 16:10

Message:
Logged In: YES 
user_id=696559

I asked the developer of ncurses. This is his first reply.

From: Thomas Dickey <dickey@herndon4.his.com>

My guess (because I've seen it a few times)
is that it's a system where someone installed a new version
of gcc. Its fixincludes script was modified a year or two
ago with the effect of putting a copy of curses.h into gcc's
so-called fixed-include files, e.g.,

        /usr/lib/gcc-lib/i386-linux/3.0.4/include

(It's "fixing" a place which is providing a typedef if it
doesn't exist). I modified the ifdef's to avoid this
problem.  The quick fix is to remove curses.h from gcc's
fixed-includes.  The reason why NCURSES_EXPORT is not
defined is because gcc finds the wrong curses.h and doesn't
find ncurses_dll.h because its fixed-include forces it into
the wrong search path.

If it's not that - perhaps more info.  (Perhaps just setting
$CPPFLAGS in the environment is needed).


----------------------------------------------------------------------

Comment By: Martin Mokrejs (mmokrejs)
Date: 2003-06-17 15:00

Message:
Logged In: YES 
user_id=696559

Sorry, I'm not aprogrammer, should I attach some of the
headers files distributed by ncurses?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-06-14 08:50

Message:
Logged In: YES 
user_id=21627

Can you report how NCURSES_EXPORT is defined on your system?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 18:56:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 10:56:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed
Message-ID: <E19X2sy-0007gR-00@sc8-sf-web2.sourceforge.net>

Bugs item #763153, was opened at 2003-06-30 14:35
Message generated for change (Comment added) made by towi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Torsten Will (towi)
Assigned to: Nobody/Anonymous (nobody)
Summary: unit test test_time failed

Initial Comment:
=== ERROR MASSAGE ===

$ make test
...
test test_time failed -- Traceback (most recent call last):
  File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py",
line 107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST
...

=========== SYSTEM ===========

$ cat /proc/version 
Linux version 2.4.19 (root@haplo) (gcc version 2.95.3
20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003



----------------------------------------------------------------------

>Comment By: Torsten Will (towi)
Date: 2003-06-30 19:56

Message:
Logged In: YES 
user_id=269193

suse 7.1 or 7.2. kernel 2.19.
i cannot apply the patch just now, but i will try tomorrow.

tt.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 17:15

Message:
Logged In: YES 
user_id=33168

What OS are you using?  Redhat 6.2, perhaps?  Can you test
patch 762934?  http://python.org/sf/762934

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 22:09:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 14:09:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-763032 ] tut/contents.html does not exist
Message-ID: <E19X5tr-0008KW-00@sc8-sf-web2.sourceforge.net>

Bugs item #763032, was opened at 2003-06-30 06:59
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tut/contents.html does not exist

Initial Comment:
2.2.3 and 2.3:

generating the html tutorial doesn't create
tut/contents.html, although it's referenced by other
tut/* pages.


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2003-06-30 21:09

Message:
Logged In: YES 
user_id=60903

I'm confused. This is what I got from the 2.3b2 tarball ...

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-06-30 17:13

Message:
Logged In: YES 
user_id=3066

This was fixed in time for the Python 2.3 beta 2 release;
please update your copy of the formatting tools.  In
particular, Doc/perl/l2hinit.perl needs to be updated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 22:13:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 14:13:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-759525 ] inspect.getmembers broken (?)
Message-ID: <E19X5yJ-0006eH-00@sc8-sf-web1.sourceforge.net>

Bugs item #759525, was opened at 2003-06-23 22:43
Message generated for change (Comment added) made by aschmolck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759525&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 1
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getmembers broken (?)

Initial Comment:
inspect.getmembers currently uses `dir` to obtain a
list of an object's "members", which omits certain
things such as methods of the metaclass, e.g:

  >>> 'mro' in dict(inspect.getmembers(int))
  0

Since I can't find a description of what exactly
constitutes a "member", it is not strictly possible to
tell whether this is the intended behavior, but then
the documentation should be updated in this case to
clarify the semantics more.

It currently seems quite hard to answer seemingly
innocuous questions such as "What are the methods of
class/type X?" with introspection. 

----------------------------------------------------------------------

>Comment By: Alexander Schmolck (aschmolck)
Date: 2003-06-30 21:13

Message:
Logged In: YES 
user_id=559641

A documentation clarification seems like a perfectly fine
solution to me. 

I know that I could use ``dir(type(int)`` but the problem I
have is not so much that I can't at all find out what I want
by introspection, but rather that I often can't do so in a
clean and reliable manner that is likely to work in future
releases (and dir's doc explicitly states that its behavior
can't be relied to stay stable across releases). Currently
trying to do metaprogramming in python can sometimes be
frustrating, because in the absence of clearly defined
semantics for important things it is often a noninutitive
(e.g. inspect.ismethod(str.find)) trial-and-error procedure
("oops, that didn't work because it was a ... (new-style
class/old-style class/builtin type/class with
__slots__/<dict-proxy> etc.)") that's unlikely to yield
particularly robust solutions.
Obviously vagueness allows more leeway for future
improvements, but I still think it would be nice if there at
least were a uniform and relatively well-defined way to get
at an object's attributes and a clarified getmembers could
fit the bill.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-30 15:27

Message:
Logged In: YES 
user_id=6380

This is unclear indeed -- inspect is definitely underspecified.

It *is* clearly defined that dir() doesn't return metaclass
attributes when the argument is a class.

To find out the metaclass arguments, simply use
dir(int.__class__).

I'll leave this open, but I expect that at best some
documentation clarification will come out of this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759525&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 23:00:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 15:00:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-763190 ] Sudden death with SIGSEGV in RtlEnterCriticalSection
Message-ID: <E19X6hH-000509-00@sc8-sf-web4.sourceforge.net>

Bugs item #763190, was opened at 2003-06-30 15:34
Message generated for change (Comment added) made by dehex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Maria Martinsdotter (dehex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sudden death with SIGSEGV in RtlEnterCriticalSection

Initial Comment:
Environment:
Python 2.2.2
win32all-150
Win2000 Server
Dell server
2 CPU Pentuim 4 emulating 4 CPU's.

Application:
Service with many (50-150) threads.

Problem:
The entire service exits unexepectedly with only a brief 
reference made by Dr.Watson indicating the Windows 
equivalent of SIGSEGV in RtlEnterCriticalSection.

Side info:
Known to have happened once, we believe it may have 
happened three times in total but the two extra did not 
leave even a Dr.Watson trace.

The known occurrence can be connected to our use of a 
timer where the action routine restarts the timer.
The two extra's occurred at a point in time that connect 
the problem event to the timer expiration.

The application have been used for five months, 
runnning around the clock. The customer installation 
currently use five instances of the base software, only 
configuration differs.
It is arbitrary which instance fail.

We have no means to trigger the problem.

----------------------------------------------------------------------

>Comment By: Maria Martinsdotter (dehex)
Date: 2003-07-01 00:00

Message:
Logged In: YES 
user_id=807857

Apart from what we initially reported, no extensions are used. 
It is all pure Python and the only part of win32all used is the 
support for running it as a service.

We are aware of the enhancements provided by 2.3 beta but 
let it suffice to say that the customer is picky.

We have not been able to reproduce the problem in our test 
environment, however the hardware is not as sophisticated.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 17:13

Message:
Logged In: YES 
user_id=33168

Are there any other C/Extension modules used which are not
from the standard python distribution?  Can you make a self
contained test case?

I encourage you to test with 2.3 beta 2.  There were some
thread changes which could affect this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 23:01:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 15:01:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-763032 ] tut/contents.html does not exist
Message-ID: <E19X6ij-00024j-00@sc8-sf-web2.sourceforge.net>

Bugs item #763032, was opened at 2003-06-30 02:59
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Open
Resolution: Fixed
>Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tut/contents.html does not exist

Initial Comment:
2.2.3 and 2.3:

generating the html tutorial doesn't create
tut/contents.html, although it's referenced by other
tut/* pages.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-06-30 18:01

Message:
Logged In: YES 
user_id=3066

Re-opened so I won't forget to look at this later; hopefully
tonight.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-06-30 17:09

Message:
Logged In: YES 
user_id=60903

I'm confused. This is what I got from the 2.3b2 tarball ...

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-06-30 13:13

Message:
Logged In: YES 
user_id=3066

This was fixed in time for the Python 2.3 beta 2 release;
please update your copy of the formatting tools.  In
particular, Doc/perl/l2hinit.perl needs to be updated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470


From noreply@sourceforge.net  Mon Jun 30 23:29:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 30 Jun 2003 15:29:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-763023 ]  difflib.py: line 528 in ratio() zero division not caught
Message-ID: <E19X79p-0003Ck-00@sc8-sf-web2.sourceforge.net>

Bugs item #763023, was opened at 2003-06-30 02:24
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Neal Norwitz (nnorwitz)
Summary:  difflib.py: line 528 in ratio() zero division not caught

Initial Comment:
2.2.3 and 2.3b1:

>>> from difflib import * 
>>> s = SequenceMatcher(None, [], []) 
>>> s.ratio() 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
    File "/usr/lib/python2.2/difflib.py", line 528, in
ratio 
        return 2.0 * matches / (len(self.a) + len(self.b)) 
      ZeroDivisionError: float division 


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-06-30 18:29

Message:
Logged In: YES 
user_id=31435

Heh.  How a ZeroDivisionError coming out of a method named 
*ratio* can be a surprise is beyond me <wink>.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-30 11:34

Message:
Logged In: YES 
user_id=80475

One other thought.  The same fix should be made to all three 
ratio methods (including quick and real-quick).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-30 11:30

Message:
Logged In: YES 
user_id=80475

When the denominator is zero, it means that both sequences 
are of zero-length; therefore, the two sequences are equal, 
so the return value should be 1.0.

The try / except ZeroDivision error approach look good.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 11:19

Message:
Logged In: YES 
user_id=33168

This affects 2.3 as well (line 614).  The return line can be
wrapped with try/except ZeroDivisionError.  Raymond, should
0.0 be returned in this case?  Should something else be done?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470


From python-bugs@shopip.com  Sun Jun 29 05:39:11 2003
From: python-bugs@shopip.com (Python Bugs)
Date: Sat, 28 Jun 2003 21:39:11 -0700 (PDT)
Subject: [Python-bugs-list] SMTPLIB bug with STARTTLS
In-Reply-To: <20030629021801.7245.10664.Mailman@mail.python.org>
Message-ID: <Pine.BSO.4.44.0306281921410.582-100000@shopip.com>

smtplib.starttls() needs to include does_esmtp=0. Without this, the
"size=" suffix on MAIL FROM lines causes server errors since the MTA
defaults to HELO mode. This is also necessary in order to conform to RFC
2487 section 5.2, which states after TLS is started, all prior knowledge
(including esmtp capability) must be discarded. Patch follows:


--- /usr/local/lib/python2.3/smtplib.py.orig	Sat Apr 12 09:54:24 2003
+++ /usr/local/lib/python2.3/smtplib.py	Sat Jun 28 12:38:12 2003
@@ -597,6 +597,7 @@
             sslobj = socket.ssl(self.sock, keyfile, certfile)
             self.sock = SSLFakeSocket(self.sock, sslobj)
             self.file = SSLFakeFile(sslobj)
+            self.does_esmtp=0 #RFC 2487 sec. 5.2 compliance
         return (resp, reply)

     def sendmail(self, from_addr, to_addrs, msg, mail_options=[],