From noreply at sourceforge.net  Mon Sep  1 02:02:05 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 04:02:14 2003
Subject: [Python-bugs-list] [ python-Bugs-797447 ]
	locale.setlocale(locale.LC_ALL, "de") raises exception
Message-ID: <E19tjdV-0007to-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Otten (potten)
Assigned to: Martin v. L?wis (loewis)
Summary: locale.setlocale(locale.LC_ALL, "de") raises exception

Initial Comment:
Python 2.3 (#1, Jul 30 2003, 11:19:43) 
[GCC 3.2] on linux2 
Type "help", "copyright", "credits" or "license" for more 
information. 
>>> import locale as lo 
>>> lo.setlocale(lo.LC_ALL, 'de') 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "/usr/local/lib/python2.3/locale.py", line 381, in 
setlocale 
    return _setlocale(category, locale) 
locale.Error: locale setting not supported 
 
The above was taken from the example section of the 
locale module documentation. 
 
But this works: 
 
>>> lo.setlocale(lo.LC_ALL, 'de_DE') 
'de_DE' 
>>> 
 
So the error message should at least be changed to 
"unknown/unsupported locale" and the documentation 
example updated to 'de_DE' instead of 'de'. 
 
However, if there are no side effects, I'd prefer to 
change the locale.setlocale() implementation to always 
normalize() the locale: 
 
def setlocale(category, locale=None): 
    if locale: 
        if type(locale) is not type(""): 
            # convert to string 
            locale = _build_localename(locale) 
        locale = normalize(locale) 
    return _setlocale(category, locale) 
 

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

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-09-01 20:02

Message:
Logged In: YES 
user_id=552329

Just my 2c, but I would agree that a wording change to 
either "unsupported locale setting" or "%s locale setting not 
supported" with the attempted locale would be much clearer.

No opinion on (2) :)

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

Comment By: Peter Otten (potten)
Date: 2003-09-01 09:37

Message:
Logged In: YES 
user_id=703365

(1) I read "locale setting not supported" and understood (not 
being a native speaker) "(any) locale setting not supported", 
whereas "unknown/unsupported locale" would make it clear 
you can set a locale but not the one that was requested. 
 
(2) I would expect setlocale(..., "de") and setlocale(..., 
("de", None)) to either both fail or both succeed, but 
currently only the latter form works; thus the proposed 
change in the code. 
 
I hope this clarifies the issue and you will reconsider. 

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-01 05:00

Message:
Logged In: YES 
user_id=21627

I fail to see the bug. "locale setting not supported" is
exactly identical, in its meaning, with "unsupported locale".

Changing the example to de_DE won't help much, either, since
the next system might support "de" but not "de_DE", or it
might support "de_DE.ISO-8859-1" only. Locale names are not
standardized.

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

Comment By: Peter Otten (potten)
Date: 2003-08-30 19:29

Message:
Logged In: YES 
user_id=703365

I forgot to mention that the following also works: 
 
>>> import locale 
>>> locale.setlocale(locale.LC_ALL, ("de", None)) 
'de_DE.ISO8859-1' 
>>> 
 
So the it really seems to be an implementation rather than a 
documentation issue. 

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

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

From noreply at sourceforge.net  Mon Sep  1 04:41:17 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 06:41:21 2003
Subject: [Python-bugs-list] [ python-Bugs-798473 ] inconsistent behavior of
	map and imap
Message-ID: <E19tm7Z-0001sk-00@sc8-sf-web1.sourceforge.net>

Bugs item #798473, was opened at 2003-09-01 19: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=798473&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent behavior of map and imap

Initial Comment:
If you pass sequences to map and imap and
the sizes of sequences are not equal,
map and imap don't behave the same way.

The code below is a simple example.
The size of seq1 and seq2 is not equal.

>>> seq1 = [0, 1, 2]
>>> seq2 = ['a', 'b']
>>> import itertools
>>> for x,y in map(None, seq1, seq2):print x,y
...
0 a
1 b
2 None
>>> for x,y in itertools.imap(None, seq1, 
seq2):print x,y
...
0 a
1 b

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

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

From noreply at sourceforge.net  Mon Sep  1 04:41:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 06:41:30 2003
Subject: [Python-bugs-list] [ python-Bugs-774546 ] popen does not like
	filenames with spaces
Message-ID: <E19tm7c-0003Kn-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Philippe Fremy (pfremy)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen does not like filenames with spaces

Initial Comment:
The argument for the target executable are passed as a 
string to popen. The problem is that with filenames which 
contains spaces, the argument breaking routine will fail 
and create two arguments for one filename. 
 
It would be more convenient if one could pass the 
argument to popen as a list of string. 
 
 

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

>Comment By: Philippe Fremy (pfremy)
Date: 2003-09-01 12:41

Message:
Logged In: YES 
user_id=233844

I was trying to use python as a shell replacement for simple 
scripts, but I was disapppointed by the poor level of support of 
python for those things. 
 
In my case, the list of files was pulled from a command and 
passed to another one. 
 
I have some suggestions on how to improve python shell 
scripting capability. Right now, as soon as you want to do 
something a little bit complicated, like feeding a program (let's 
say grep) from the output of another program and checking the 
output and the exit status is quite complicated. 
 
For such an interface to be good, it has to provide _very_ easy 
way to: 
- read stdout from a command 
- provide stdin to a command 
- read exit status of a command. 
- pipe a command into another one 
 
Let's say I want to run the equivalent of 
find . -name '*.cpp' | grep -i toto 
 
My suggested interface to run a simple command would be as 
following: 
cmd( "find", ".", "-name", "*.cpp")  
 
This defines a command to be run. To be versatile, this would 
have to accept although the following format: 
 
cmd( [ "find", ".", "-name", "*.cpp" ] ) 
cmd( "find", [  ".", "-name", "*.cpp" ] ) 
which are slightly different ways of spawning a command. I think 
all these three ways have a usage pattern. 
 
To actually execute the command, you woud do: 
cmd( "find", ".", "-name", "*.cpp" ).go() 
 
This create an object which has  
 
 
 
To run it, you just apply the go() method: 
 
cmd( "find", ".", "*.cpp" ).go() 
 
This could return a tuple (stdout, stderr, return_code) 
 
Now, if you want to pipe a command into another one, we can 
either override the operator | or write it manually. My initial 
command would become: 
cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" 
) 
 
I dislike using a syntax like cmd().pipe( cmd ) because piping 
multiple commands would required parenthesis nesting which 
does not look nice. The goal is to reach the simplicity of shell 
scripting. 
 
To execute the previous command, one would simple again use 
the go() method: 
 
(stdout, stderr, ret_status) = cmd( "find", ".", "-name", "*.cpp" 
).pipe().cmd( "grep", "-i", "toto" ).go() 
 
Here for my suggestion. It might be more appropriate to post it 
to a mailing list, to get more feedback ? 
 
I am sorry, I am very busy now and won't have time to 
implement this myself. 
 
 
 
 

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

Comment By: Andrew Gaul (gaul)
Date: 2003-08-19 14:17

Message:
Logged In: YES 
user_id=139865

Yes, it works.  This is also the same behaviour as
os.system.  os.popen2 allows one to pass either a quoted
string or a sequence of strings (pfremy's suggested
behaviour).  It would be nice to have consistent
functionality, and using a sequence would be easier when
providing a list of files to be operated on.  I am willing
to provide a patch if this is the desired functionality.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-21 01:03

Message:
Logged In: YES 
user_id=80475

Does it work for you if the filename is quoted:  "thrill 
seeker.txt" ?

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

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

From noreply at sourceforge.net  Mon Sep  1 06:34:48 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 08:34:52 2003
Subject: [Python-bugs-list] [ python-Feature Requests-798520 ] os.popen with
	invalid mode differs on Windows and POSIX
Message-ID: <E19tntQ-00064W-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #798520, was opened at 2003-09-01 07:34
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=798520&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Gaul (gaul)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen with invalid mode differs on Windows and POSIX

Initial Comment:
On Windows, os.popen with an invalid mode throw a
ValueError and on POSIX systems it throws an OSError.

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.popen('dir', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: popen() arg 2 must be 'r' or 'w'

Python 2.3 (#167, Sep  1 2003, 06:38:18)
[GCC 3.0.4] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.popen('ls', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 22] Invalid argument

Additionally, the ValueError message is incorrect; arg
2 can be 'r', 'rb', 'rt', 'w', 'wb', or 'wt'.

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

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

From noreply at sourceforge.net  Mon Sep  1 10:32:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 12:32:55 2003
Subject: [Python-bugs-list] [ python-Bugs-798652 ] Clarify trailing comma in
	func arg list
Message-ID: <E19trbn-0001gh-00@sc8-sf-web2.sourceforge.net>

Bugs item #798652, was opened at 2003-09-01 12: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=798652&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Terry J. Reedy (tjreedy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clarify trailing comma in func arg list

Initial Comment:
Current Ref Man 5.3.4 Calls says after grammar:
"A trailing comma may be present after an argument 
list but does not affect the semantics. "
But this is not true if arg list ends with *expr or **expr:

>>> dict(*l,) # any function will do since not called
  File "<stdin>", line 1
    dict(*l,)
            ^ # points at ')'
SyntaxError: invalid syntax
>>> dict(**d,)
  File "<stdin>", line 1
    dict(**d,)
            ^ # points at ','
SyntaxError: invalid syntax

Suggestion: "If an argument list does *not* end with 
*expr or **expr, a trailing comma may be added 
without affecting the semantics."

The same exception applies to function defs as well as 
calls, but 7.5 Function definitions does not have a 
statement such as above.  However, the production for 
parameter_list does end with 'defparameter [","]'.  I 
suggest that this be the first of the parenthesized 
alternatives, as it logically should be, rather than the 
last, so it flows better and so that no one (ignorant 
that '[]' binds tighter than '|') could possible think that 
the '[,]' applies to the * and ** parts.  IE: change 

parameter_list  ::=  (defparameter ",")* 
    ("*" identifier [, "**" identifier] 
    | "**" identifier | defparameter [","]) 

to

parameter_list  ::=  (defparameter ",")* 
    (defparameter [","]
    |'*' identifier [, "**" identifier] 
    | "**" identifier)

Squeezing out a line is a suboptimazation.

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

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

From noreply at sourceforge.net  Mon Sep  1 10:38:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 12:38:34 2003
Subject: [Python-bugs-list] [ python-Bugs-798473 ] inconsistent behavior of
	map and imap
Message-ID: <E19trhF-00021U-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent behavior of map and imap

Initial Comment:
If you pass sequences to map and imap and
the sizes of sequences are not equal,
map and imap don't behave the same way.

The code below is a simple example.
The size of seq1 and seq2 is not equal.

>>> seq1 = [0, 1, 2]
>>> seq2 = ['a', 'b']
>>> import itertools
>>> for x,y in map(None, seq1, seq2):print x,y
...
0 a
1 b
2 None
>>> for x,y in itertools.imap(None, seq1, 
seq2):print x,y
...
0 a
1 b

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 11:38

Message:
Logged In: YES 
user_id=80475

This difference was intended and is considered a feature:

1. It allows imap() to be used with infinite iterators.

2. None fill-in is rarely useful (how many functions respond 
well to having arguments suddendy switch to None?).

3. If needed, None padding is easy to add:
     for x,y in imap(None, seq1, chain(seq2, repeat(None)))


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

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

From noreply at sourceforge.net  Mon Sep  1 10:39:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 12:40:15 2003
Subject: [Python-bugs-list] [ python-Bugs-798254 ] doctest crash
Message-ID: <E19triY-00025I-00@sc8-sf-web2.sourceforge.net>

Bugs item #798254, was opened at 2003-08-31 15:26
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798254&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: doctest crash

Initial Comment:
This code:

class A: 
        def f(self): pass 
 
class C(A): 
        g = A.f 
 
import doctest, sys 
doctest.testmod(sys.modules[__name__])

crashes with the following diagnostic:

Traceback (most recent call last): 
  File "<stdin>", line 8, in ? 
  File "/lib/python2.3/doctest.py", line 1147, in testmod 
    f, t = tester.rundict(m.__dict__, name, m) 
  File "/lib/python2.3/doctest.py", line 907, in rundict 
    f2, t2 = self.__runone(value, name + "." + thisname) 
  File "/lib/python2.3/doctest.py", line 1068, in __runone 
    return self.rundoc(target, name) 
  File "/lib/python2.3/doctest.py", line 827, in rundoc 
    f2, t2 = self.run__test__(d, name) 
  File "/lib/python2.3/doctest.py", line 936, in 
run__test__ 
    raise TypeError("Tester.run__test__: values in " 
TypeError: Tester.run__test__: values in dict must be 
strings, functions or classes; <unbound method A.f> 


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

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

From noreply at sourceforge.net  Mon Sep  1 10:51:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 12:51:37 2003
Subject: [Python-bugs-list] [ python-Bugs-798274 ] absolute import patch
	breaks external users of test.regrtest
Message-ID: <E19trtr-0004aM-00@sc8-sf-web3.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicholas Riley (nriley)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: absolute import patch breaks external users of test.regrtest

Initial Comment:
I've built a test system using Python's test.regrtest 
mechanism, and it worked very well under Python 2.2.  In 
Python 2.3, the output looks like this:

test_inttypes
test_inttypes skipped -- No module named test_inttypes
test_string
test_unittest
test_unittest skipped -- No module named test_unittest
[...]

I've tracked the problem down to a change made about a 
year ago.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/
python/dist/src/Lib/test/regrtest.py.diff?r1=1.91&r2=1.92

test.regrtest is finding the modules, but is failing to import 
them because it is prepending 'test.' to the module names, 
in a mistaken assumption that all tests will be in a package 
named test.

As it happened, I had my test modules inside a directory 
named 'test', and I tried making the directory a module and 
futzing with sys.path to get it to work, but now 
test.regrtest can't find the system implementation of 
test.test_support.  I've also now got the problem of 
namespace pollution - the "test_string" above is Python's 
version, not my version with the same name.

So, it appears non-Python users of test.regrtest are broken 
by this change in Python 2.3.  I was pretty careful to make 
sure that I was doing something supported - the docstring 
for test.regrtest.main explicitly refers to non-Python test 
suite users - and ran into some weird cases like test.* not 
being installed on Mac OS X by default, but it worked very 
well otherwise.

One potential solution would be that if 'testdir' is specified, 
test.regrtest.main() does not attempt to prepend 'test.' to 
the module names.  This seems to match pretty well with 
the spirit of the documentation for that method.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 11:51

Message:
Logged In: YES 
user_id=80475

Barry, this was your change.
Would you take a look at this bug report?

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

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

From noreply at sourceforge.net  Mon Sep  1 11:37:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 13:37:46 2003
Subject: [Python-bugs-list] [ python-Bugs-798058 ] IDLE / PyOS_InputHook
Message-ID: <E19tscO-00009R-00@sc8-sf-web1.sourceforge.net>

Bugs item #798058, was opened at 2003-08-31 03:45
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798058&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michiel de Hoon (mdehoon)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE / PyOS_InputHook

Initial Comment:
[This bug report is a follow-up of a discussion with
Matthew Cowler of help@python]

I noticed an inconsistency with the usage of the
PyOS_InputHook variable between Python 2.3's IDLE and
Python run from the (DOS or linux) command prompt. This
problem does not occur with earlier versions of Python.
First I will describe the problem, then why it is
important to me.

The PyOS_InputHook variable can be used to install a
callback function that gets called periodically (via
readline's rl_event_hook) when Python is waiting for
terminal input. When Python is run as a terminal
application (from the DOS or linux command prompt),
PyOS_InputHook is NULL initially. Python C extension
modules can set PyOS_InputHook to a function which is
to be called periodically. This works with Python 2.3
and older versions.

In Python 2.2, IDLE makes use of the PyOS_InputHook
variable, presumably to get messages delivered to the
Tkinter window. Python C extension modules that are
loaded from IDLE find that PyOS_InputHook is not NULL,
and therefore cannot specify a different callback
function via PyOS_InputHook, as that would freeze the
Tkinter window.

Now on Python 2.2, in practice that is not a problem.
IDLE in Python 2.2 runs in a single thread. This thread
contains a message loop (probably hidden in the Tk
library) that takes care of the messages destined for
the Tk window. If we open an additional (non-Tk) window
from our C extension module, then its messages also get
processed by Tk's message loop as it is running in the
same thread. So we don't need an additional message
loop for our non-Tk window, and we don't need to change
PyOS_InputHook.

In Python 2.3, IDLE works differently, as it talks to
its interactive interpreter on the TCP/IP loopback
interface and does not make use of PyOS_InputHook. If I
import my C extension module from IDLE, it shows that
PyOS_InputHook is NULL. In addition, multithreading is
now used, with three threads on Windows and two on
Linux and Mac OS X. (I am not sure where the additional
thread on Windows is coming from). In particular, the C
extension module and Tk's message loop are running in
separate threads. So if I open a non-Tk window from my
C extension module, its messages are not handled by
Tk's message loop.

The solution would be to have a message loop in my C
extension module also, which is how the C extension
module works when Python is run as a terminal
application. As PyOS_InputHook is NULL (both with and
without IDLE) when I import my extension module, I can
point it to a message loop in the extension module
without causing havoc. However, whereas Python without
IDLE calls the function specified by PyOS_InputHook
correctly, Python with IDLE fails to call
PyOS_InputHook. Hence, with IDLE I am stuck in a thread
without a message loop, and no way to provide a message
loop of my own.

If I run IDLE with the "-n" command-line argument to
disable running Python code in a sub-process, there is
only one thread, and I can use that thread's message
loop without problems.

Would it be possible in Python 2.3 to have
PyOS_InputHook called also if IDLE / Tkinter is
running? I would think that that no longer interferes
with the correct operation of Tkinter / IDLE, as after
importing IDLE, PyOS_InputHook is NULL anyway.


This problem is important to me because of the
Windows-port of Pygist (gist scientific plotting
package for Python), which I codeveloped several months
ago. The core graphics routines of Pygist are written
in C for performance reasons. Pygist does not work with
Python 2.3 with IDLE, while it does work with Python
2.2 with IDLE. There are no problems with Python 2.3
run from the DOS command prompt, nor with PythonWin or
PyShell.

The problem with Python 2.3 with IDLE is that the
graphics window no longer receives its messages. In
usual Windows programs, there is one message loop,
which looks like

while (GetMessage(&msg, NULL, 0, 0))
{ TranslateMessage(&msg);
  DispatchMessage(&msg);
}

In Python 2.2 with IDLE, we use Tk's message loop to
get messages delivered to the Pygist graphics window.
When running Python 2.2 and Python 2.3 as a terminal
application, we start our own message loop in the C
extension module and point to it using PyOS_InputHook.
With Python 2.3 with IDLE, Tk's message loop is in a
separate thread, so we can't use it, while at the same
time PyOS_InputHook is being ignored. Hence Pygist's
graphics window freezes.

Note that Pygist is different from many other plotting
packages for Python, as it returns to the Python prompt
after opening a graphics Window (allowing you to modify
the window interactively). So the trick is to let both
the Python interpreter and the graphics window receive
their messages.


With regards,

Michiel de Hoon, University of Tokyo.

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

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

From noreply at sourceforge.net  Mon Sep  1 16:44:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 18:44:32 2003
Subject: [Python-bugs-list] [ python-Bugs-798473 ] inconsistent behavior of
	map and imap
Message-ID: <E19txPQ-0004cn-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent behavior of map and imap

Initial Comment:
If you pass sequences to map and imap and
the sizes of sequences are not equal,
map and imap don't behave the same way.

The code below is a simple example.
The size of seq1 and seq2 is not equal.

>>> seq1 = [0, 1, 2]
>>> seq2 = ['a', 'b']
>>> import itertools
>>> for x,y in map(None, seq1, seq2):print x,y
...
0 a
1 b
2 None
>>> for x,y in itertools.imap(None, seq1, 
seq2):print x,y
...
0 a
1 b

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

>Comment By: George Yoshida (quiver)
Date: 2003-09-02 07:44

Message:
Logged In: YES 
user_id=671362

I should have read the Library Reference more carefully.
It documents the difference of map and imap in detail.

Thanks for taking time off to reply to my post.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-02 01:38

Message:
Logged In: YES 
user_id=80475

This difference was intended and is considered a feature:

1. It allows imap() to be used with infinite iterators.

2. None fill-in is rarely useful (how many functions respond 
well to having arguments suddendy switch to None?).

3. If needed, None padding is easy to add:
     for x,y in imap(None, seq1, chain(seq2, repeat(None)))


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

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

From noreply at sourceforge.net  Mon Sep  1 19:31:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 21:31:18 2003
Subject: [Python-bugs-list] [ python-Bugs-798876 ] windows sys.path contains
	nonexistant directory
Message-ID: <E19u00o-00024A-00@sc8-sf-web2.sourceforge.net>

Bugs item #798876, was opened at 2003-09-01 20: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=798876&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows sys.path contains nonexistant directory

Initial Comment:
Starting in python 2.3, sys.path on Windows contains 
the nonexistant directory "c:\python23\lib\plat-win".

I don't know if this is really a bug, since we can no 
longer assume that an entry in sys.path exists or is a 
physical directory.  Still, it seems like each entry in 
sys.path should be able to resolve to SOMETHING.

I would've flagged this low priority if I had the capability.

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

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

From noreply at sourceforge.net  Mon Sep  1 19:31:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 21:31:44 2003
Subject: [Python-bugs-list] [ python-Bugs-798876 ] windows sys.path contains
	nonexistant directory
Message-ID: <E19u018-0005VS-00@sc8-sf-web1.sourceforge.net>

Bugs item #798876, was opened at 2003-09-01 20:31
Message generated for change (Settings changed) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798876&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 1
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows sys.path contains nonexistant directory

Initial Comment:
Starting in python 2.3, sys.path on Windows contains 
the nonexistant directory "c:\python23\lib\plat-win".

I don't know if this is really a bug, since we can no 
longer assume that an entry in sys.path exists or is a 
physical directory.  Still, it seems like each entry in 
sys.path should be able to resolve to SOMETHING.

I would've flagged this low priority if I had the capability.

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

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

From noreply at sourceforge.net  Mon Sep  1 19:40:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 21:40:04 2003
Subject: [Python-bugs-list] [ python-Bugs-798876 ] windows sys.path contains
	nonexistant directory
Message-ID: <E19u09I-0003tq-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 4
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows sys.path contains nonexistant directory

Initial Comment:
Starting in python 2.3, sys.path on Windows contains 
the nonexistant directory "c:\python23\lib\plat-win".

I don't know if this is really a bug, since we can no 
longer assume that an entry in sys.path exists or is a 
physical directory.  Still, it seems like each entry in 
sys.path should be able to resolve to SOMETHING.

I would've flagged this low priority if I had the capability.

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

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

Message:
Logged In: YES 
user_id=31435

Strange.  I see it under Python 2.1.3 too.  So it's not a new 
thing, but somehow 2.2.3 managed to get rid of it temporarily 
<wink>.  Boosting the priority to 4, since it's at least a 
mystery!

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

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

From noreply at sourceforge.net  Mon Sep  1 20:15:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 22:16:02 2003
Subject: [Python-bugs-list] [ python-Bugs-798254 ] doctest crash
Message-ID: <E19u0hI-0001s5-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Raymond Hettinger (rhettinger)
Summary: doctest crash

Initial Comment:
This code:

class A: 
        def f(self): pass 
 
class C(A): 
        g = A.f 
 
import doctest, sys 
doctest.testmod(sys.modules[__name__])

crashes with the following diagnostic:

Traceback (most recent call last): 
  File "<stdin>", line 8, in ? 
  File "/lib/python2.3/doctest.py", line 1147, in testmod 
    f, t = tester.rundict(m.__dict__, name, m) 
  File "/lib/python2.3/doctest.py", line 907, in rundict 
    f2, t2 = self.__runone(value, name + "." + thisname) 
  File "/lib/python2.3/doctest.py", line 1068, in __runone 
    return self.rundoc(target, name) 
  File "/lib/python2.3/doctest.py", line 827, in rundoc 
    f2, t2 = self.run__test__(d, name) 
  File "/lib/python2.3/doctest.py", line 936, in 
run__test__ 
    raise TypeError("Tester.run__test__: values in " 
TypeError: Tester.run__test__: values in dict must be 
strings, functions or classes; <unbound method A.f> 


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 21:15

Message:
Logged In: YES 
user_id=80475

Applied patch #798269

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

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

From noreply at sourceforge.net  Mon Sep  1 20:43:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 22:44:10 2003
Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during
	program shutdown
Message-ID: <E19u18z-0006S6-00@sc8-sf-web3.sourceforge.net>

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

Category: Tkinter
>Group: Python 2.2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Doug Henderson (djhender)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fatal Python Error during program shutdown

Initial Comment:
The windows builds of versions 2.0 and 2.1a2 contain an intermittent bug which often appears when a script using Tkinter stops by calling self.tk.quit() and sometimes (less often) appears following a <Destroy> event or call to a ?.destory() function.
Under Windows 98SE, this results in a GPF.
Under Windows 2000, a message to the console window shows "Fatal Python Error", "PyEval_RestoreThread NULL tstate".

The following script demonstrates the problem:
---------------------
# BugDemo.py

from Tkinter import *

class BugDemo(Frame):
    def __init__(self, parent):
        Frame.__init__(self, parent)
        Button(self, text='Hi', command=self.hi).pack()
        Button(self, text='Quit', command=self.tk.quit).pack()
    def hi(self):
        print "hi"

bd = BugDemo(Tk())
bd.pack()
bd.mainloop()
----------------------
Execute in console window: "c:> python BugDemo.py"
Test this by 1) clicking Quit button 2) clicking Hi button, then Quit button.
Test 1: The script runs successfully most of the time. I found I had to minimize and restore its window to make it fail regularly.
Test 2: I need to click Hi button before clicking the Quit button. Then it failed about half the time.

The problem appears to occur after the script has completed, during some kind of cleanup perhaps. The more useful error message on the Win2k machine may help to locate the problem.

Problem also manifests using the PythonWare 2.0 release on Win98.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 21:43

Message:
Logged In: YES 
user_id=80475

FWIW, the bug demos fail under Py2.2.3 but were fixed for 
Py2.3.  Since it is unlikely that there will be a Py2.2.4, am 
closing this bug and marking as fixed.

Thanks for the report and the short demo scripts.

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

Comment By: Dennis Benzinger (dcbbcd)
Date: 2003-07-19 10:36

Message:
Logged In: YES 
user_id=826043

Python reliably crashes on Win XP - SP1 with the following
test program too:

import Tkinter
tk = Tkinter.Tk()
quit_btn = Tkinter.Button(tk, text='quit', 
                          #command=tk.quit)  # This crashs
                          command=tk.destroy)  # This works
       
quit_btn.pack()
Tkinter.mainloop()

The error message is something like (bad english translation):
The instruction in "0x77f4b2ab" points to "0x00000028". The
memory can't be read.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-07 09:58

Message:
Logged In: YES 
user_id=6380

idiscovery, when you say "PythonWin" do you actually mean
Pythonwin (a Win32-specific Python IDE, part of Mark
Hammond's win32all)?  Or do you simple mean "Python under
Windows", as installed by the Python installer you get from
python.org? This difference is significant; I would not
expect Tkinter apps to work well using Pythonwin, because it
has its own Win32 event loop.

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

Comment By: Doug Henderson (djhender)
Date: 2002-11-04 13:12

Message:
Logged In: YES 
user_id=148444

I modified my BugDemo program to change the last 3 lines to

root = Tk()
bd = BugDemo(root)
bd.pack()
bd.mainloop()
root.destory()

This did not resolve the problem under Win98SE Python 2.2.1.
Both Python 2.2.1 and 2.2.2 use Tk/tcl 8.3. I have seen
comments that indicate that this is a known problem in stock
8.3 which is fixed in 8.4.

I also tested using the other two scripts presented
elsewhere among the comments to this bug report. These tests
also hang, even with the added root.destroy() statement.

I no longer have access to a Win2k machine, so I cannot test
there.


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

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 01:52

Message:
Logged In: YES 
user_id=33229

I know I'm a Python newbie but I know Tcl well and I think I know 
at least part of what's going on. Looking specifically at nobody's
2002-04-22 14:21 code, I see that this uses mainloop and quit
in a way that many Python books and examples do, as if quit()
will "Quit the Tcl interpreter. All widgets will be destroyed."

But if you look at MainLoop and Quit in _tkinter.c you see that
Quit just sets a variable that causes MainLoop to end - it
doesn't destroy anything nor quit the interpreter. 

IMHO all Tkinter programs need a root.destroy() after root.mainloop()
If you change nobody's program to add a root.destroy() it runs fine under
PythonWin.

The "bug" is in the documentation of quit() in Tkinter.py

    def quit(self):
        """Quit the Tcl interpreter. All widgets will be destroyed."""
        self.tk.quit()

The comment should read
         """Quit the main event loop. It is up to you to call root.destroy() after."""

If I'm right the documentation for Tkinter in the library reference should be
changed too; there should be a root.destroy() at the end of
            http://www.python.org/doc/2.2.1/lib/node503.html

If I'm right then I'll stick my neck out a little further: Tkinter's mainloop and quit
should be dropped from _tkinter.c and replaced with the following idiom
and usage:

In Tkinter.py declare a class variable in Misc: _exit = -1 and change in Misc
TCL_ALL_EVENTS		= 0
    def quit(self):
        """Quit the Tcl interpreter. All widgets will be destroyed."""
        self._exit = 0
    def mainloop(self):
        """Loop until we call quit()"""
        while self._exit < 0:
            try:
                self.root.tk.dooneevent(TCL_ALL_EVENTS)
            except SystemExit:
                #print 'Exit'
                self.exit = 1
                break
            except 
               # do something intelligent with errors or interrupts

I believe this is more transparent and more open to creativity.
I have experimented (all my code is like this now) and feel 
that there is no performance penalty to looping in Python.

In addition it avoids the 20msec sleep in _tkinter.mainloop()
that is an abomination. 

It would also allow people to think more clearly about what happens
when you have 2 Tk() instances, in which case you have 2 Tcl
interpeters. It may make you move _exit to be an instance
variable of the Tk class. In any event you'll be able to see what's
going on.






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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-22 09:21

Message:
Logged In: NO 

I confirm the behaviour for:
WinNT 4.0 SP5
tested with Python 2.2Beta1 (ActiveState)
tested with Python 2.2.1.222 (ActiveState)

PythonWinIDE will hang when the following program 
is "quit"ted.

But will "quit" normally when run standalone (not within 
PythonWinIDE):

# 
# 

from Tkinter import *
from tkMessageBox import *

class App:
    def __init__(self, winRoot):
        frame = Frame(winRoot)
        frame.pack()

        self.btnQuit = Button(frame, text="QUIT", 
bg="blue", foreground="light blue", command=frame.quit)
        self.btnQuit.pack(side=LEFT)

        self.btnHiThere = Button(frame, text="Hi 
there!",command=self.sayHiThere)
        self.btnHiThere.pack(side=LEFT)

    def sayHiThere(self):
        showinfo("Greeting", "Hi There")
        
        

if __name__ == "__main__":
    root = Tk()
    test = App(root)
    root.mainloop()




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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:49

Message:
Logged In: YES 
user_id=31392

Unassign as it appears that effbot isn't going to look at 
it.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-18 06:13

Message:
Logged In: NO 

i won't to be a hacker

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 02:30

Message:
Logged In: NO 

Note:
I am running Windows98
ActivePython 2.1
Even with console apps in python this same error appears
I tried using another Distribution of Python for win32, 
PythonWare20

So this leads me to believe that some lib is missing on 
win98. Because at work I use Win95, and Installed 
ActivePython 2.1, and it works fine and dandy


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

Comment By: Joel Gould (joelgould)
Date: 2001-03-24 11:52

Message:
Logged In: YES 
user_id=20954

I also see a GPF on shutdown under Windows 98 using 
Tkinter.  I tested this using the PythonWare 2.0 release as 
well.

I have attached a very simple Tkinter program.  When I run 
this on my Windows 98 SE machine, a crash occurs when the 
program exits.  Without the MainDialog class it works OK.  
Without the Pmw initialization call it works OK.  But as 
written it will crash around 75% of the time.

(1) run the program
(2) press the Test Button
(3) click Cancel in the file open dialog (you do not need 
to select a file)
(4) click the close button in the upper right corner
-->  Boom

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

import Tkinter
import tkFileDialog
import Pmw

def action():
    tkFileDialog.askopenfilename(filetypes=[('All','*')])

class MainDialog:
    def __init__(self,parent):
        Tkinter.Button(parent,text='Test 
Button',command=action).pack()

root = Pmw.initialise()
dialog = MainDialog(root)
root.mainloop()

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

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 18:34

Message:
Assigned to /F, under the theory he can confirm that "this kind of thing" is still a general problem with Tk we can't do anything about.

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

Comment By: Doug Henderson (djhender)
Date: 2001-02-06 00:30

Message:
See also #116289 (and my comment to it) which describes what often happened to my 'real' programs which lead to developing the above BugDemo script. My 'real' programs were developed over the last two years or so, and worked in Jan 2000 with 1.5.2. I upgraded the Python version recently, and then started working on these programs again. It was "WTF is wrong with my code", until I found the same problem showing up in the small test cases.

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

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

From noreply at sourceforge.net  Mon Sep  1 20:47:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 22:47:21 2003
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in
	modules
Message-ID: <E19u1CI-0006YN-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 2
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Skip Montanaro (montanaro)
Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 21:47

Message:
Logged In: YES 
user_id=80475

Some efforts were made to remove many bare excepts prior 
to Py2.3a1.  Briefly scanning those that remain, it looks like 
many of them are appropriate or best left alone.

I recommend that this bug be closed unless someone sees 
something specific that demands a change.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-16 18:30

Message:
Logged In: YES 
user_id=357491

threading.py is clear.  It's blanket exceptions are for printing debug  output 
since exceptions in threads don't get passed back to the original frame 
anyway.

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

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-13 22:15

Message:
Logged In: YES 
user_id=44345

checked in fileinput.py (v 1.15) with three except:'s tightened up.  The 
comment in the code about IOError notwithstanding, I don't see how any 
of the three situations would have caught anything other than OSError.


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

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-12 14:58

Message:
Logged In: YES 
user_id=44345

Note that this particular item was expected to be an ongoing item, with 
no obvious closure.   Some of the bare excepts will have subtle 
ramifications, and it's not always obvious what specific exceptions 
should be caught.  I've made a few changes to my local source tree 
which I should check in.

Rather than opening new tracker items, I believe those with checkin 
privileges should correct those flaws they identify and attach a comment 
which will alert those monitoring the item.  Those people without checkin 
privileges should just attach a patch with a note.

Skip


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

Comment By: Martin v. L?wis (loewis)
Date: 2002-08-12 02:22

Message:
Logged In: YES 
user_id=21627

My proposal would be to track this under a different issue:
Terry, if you volunteer, please produce a new list of
offenders (perhaps in an attachment to the report so it can
be updated), and attach any fixes that you have to that report.

People with CVS write access can then apply those patches
and delete them from the report.

If you do so, please post the new issue number in this
report, so we have a link.

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

Comment By: Terry J. Reedy (tjreedy)
Date: 2002-08-11 13:16

Message:
Logged In: YES 
user_id=593130

Remove types.py from the list.  As distributed with 2.2.1, it 
has 5 'except xxxError:' statements but no offending bare 
except:'s.

Skip (or anyone else): if/when you pursue this, I volunteer 
to do occasional sleuthing and send reports with 
suggestions and/or questions.  Example: getpass.py has 
one 'offense':
   try:
        fd = sys.stdin.fileno()
    except:
        return default_getpass(prompt)
According to lib doc 2.2.8 File Objects (as I interpret) fileno
() should either work without exception or *not* be 
implemented. Suggestion: insert AttributeError .  Question: 
do we protect against pseudofile objects that ignore doc 
and have fake .fileno() that raises NotImplementedError or 
whatever?


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

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-23 01:02

Message:
Logged In: YES 
user_id=44345

as partial fix, checked in changes for the following
modules:

  mimetools.py (1.24)
  popen2.py (1.23)
  quopripy (1.19)
  CGIHTTPServer.py (1.22)


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

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-20 16:24

Message:
Logged In: YES 
user_id=44345

Here is a context diff with proposed changes for the
following modules: CGIHTTPServer, cgi, cmd, code, 
fileinput, httplib, inspect, locale, mimetools, popen2,
quopri


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

Comment By: Martin v. L?wis (loewis)
Date: 2001-08-11 10:06

Message:
Logged In: YES 
user_id=21627

Fixed urllib in 1.131 and types in 1.19.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-04 02:11

Message:
Logged In: YES 
user_id=3066

Fixed modules mhlib and rfc822 (SF is having a problem
generating the checkin emails, though).

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 14:40

Message:
Logged In: YES 
user_id=3066

OK, I've fixed up a few more modules:

anydbm
chunk
formatter
htmllib
mailcap
pre
pty

I made one change to asyncore as well, but other bare except
clauses remain there; I'm not sufficiently familiar with
that code to just go digging into those.

I also fixed an infraction in pstats, but left others for now.

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 03:14

Message:
Logged In: YES 
user_id=31435

Ping's intent is that pydoc work under versions of Python 
as early as 1.5.2, so that sys._getframe is off-limits in 
pydoc and its supporting code (like inspect.py).

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

Comment By: Martin v. L?wis (loewis)
Date: 2001-04-23 02:32

Message:
Logged In: YES 
user_id=21627

For inspect.py, why is it necessary to keep the old code at
all? My proposal: remove currentframe altogether, and do
currentframe = sys._getframe
unconditionally.

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-22 09:52

Message:
Logged In: YES 
user_id=32065

I submitted a 4th patch. I'm starting to run out of easy
cases...

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-04-19 04:15

Message:
Logged In: YES 
user_id=44345

I believe the following patch is correct for the try/except
in inspect.currentframe.  Note that it fixes two problems. 
One, it avoids a bare except.  Two, it gets rid of a string
argument to the raise statement (string exceptions are now
deprecated, right?).

*** /tmp/skip/inspect.py	Thu Apr 19 04:13:36 2001
--- /tmp/skip/inspect.py.~1.16~	Thu Apr 19 04:13:36 2001
***************
*** 643,650 ****
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         1/0
!     except ZeroDivisionError:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe
--- 643,650 ----
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         raise 'catch me'
!     except:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe


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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 10:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 12:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

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

Comment By: Walter D?rwald (doerwalter)
Date: 2001-04-11 12:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


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

Comment By: Walter D?rwald (doerwalter)
Date: 2001-04-11 12:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 10:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 05:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

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

Comment By: Martin v. L?wis (loewis)
Date: 2001-03-30 01:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

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

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

From noreply at sourceforge.net  Mon Sep  1 20:53:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 22:53:06 2003
Subject: [Python-bugs-list] [ python-Bugs-450803 ] smtpd.py needs
	documentation
Message-ID: <E19u1Hx-0006gA-00@sc8-sf-web3.sourceforge.net>

Bugs item #450803, was opened at 2001-08-14 09:18
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Barry A. Warsaw (bwarsaw)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: smtpd.py needs documentation

Initial Comment:
smtpd.py needs documentation for the standard library

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

Comment By: Moshe Zadka (moshez)
Date: 2002-06-11 04:48

Message:
Logged In: YES 
user_id=11645

Here's something you can use as a start, Barry.


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

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

From noreply at sourceforge.net  Mon Sep  1 20:54:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 22:54:25 2003
Subject: [Python-bugs-list] [ python-Bugs-467924 ] Improve the ZipFile
	Interface
Message-ID: <E19u1JE-0006hH-00@sc8-sf-web3.sourceforge.net>

Bugs item #467924, was opened at 2001-10-04 10:54
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467924&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Greg Ward (gward)
Summary: Improve the ZipFile Interface

Initial Comment:
There exist two methods to write to a ZipFile

     write(self, filename, arcname=None, compress_type=None)  
     writestr(self, zinfo, bytes)

but only one to read from it

     read(self, name)

Additionally, the two 'write's behave differently with respect to compression.

---
(a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, 
     but 'read' is not the reverse operation. 'read' should be called 'readstr' since it 
     much better matches to 'writestr'.

(b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, 
     or into the ZipFile? It would be more obvious if ZipFile has 4 methods which 
     pair-wise fit together:

     writestr (self, zinfo, bytes)
          # same as now
     readstr (self, name)
          # returns bytes (as string), currently called 'read'
          # 'read' could still live but should be deprecated
     add (self, filename, arcname=None, compress_type=None)
          # currently 'write'
          # 'write' could still live but should be deprecated
     extract (self, name, filename, arcname=None)
          # new, desired functionality

(c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was 
     passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via 
     zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( 
     It should not do that! It rather should:
     - allow more parameters in the signature of the constructor
        to also pass the compression type (and some other attributes, too)
     - default to 'None', so that 'writestr' can see this, and then take 
        the default from the 'ZipFile' instance.





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

Comment By: Matt Zimmerman (mzimmerman)
Date: 2003-07-31 09:22

Message:
Logged In: YES 
user_id=196786

It would also be very useful to be able to have ZipFile
read/write the uncompressed file data from/to a file-like
object, instead of just strings and files (respectively).

I would like to use this module to work with zip files
containing large files, but this is unworkable because the
current implementation would use excessive amounts of memory.

Currently, read() reads all of the compressed data into
memory, then uncompresses it into memory.  For files which
may be hundreds of megabytes compressed, this is undesirable.

Likewise for write(), I would like to be able to stream data
into a zip file, passing in a ZipInfo to specify the
metadata as is done with writestr().

The implementation of this functionality is quite
straightforward, but I am not sure whether (or how) the
interface should change.  Some other parts of the library
allow for a file object to be passed to the same interface
which accepts a filename.  The object is examined to see if
it has the necessary read/write methods and if not, it is
assumed to be a filename.  Would this be the correct way to
do it?

I, too, am a bit irked by the lack of symmetry exhibited by
read vs. write/writestr, and think that the interface
suggested above would be a significant improvement.

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

Comment By: Just van Rossum (jvr)
Date: 2003-01-05 15:54

Message:
Logged In: YES 
user_id=92689

In Python 2.3, writestr() has an enhanced signature: the
first arg may now also be an archive name, in which case the
correct default settings are used (ie. the compression value
is taken from the file). See patch #651621.

extract() could be moderately useful (although I don't
understand the 'arcname' arg, how's that different from
'name'?) but would have to deal with file modes (bin/text).
The file mode isn't in the archive so would have to
(optionally) be supplied by the caller.

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

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

From noreply at sourceforge.net  Mon Sep  1 20:59:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 22:59:49 2003
Subject: [Python-bugs-list] [ python-Bugs-560286 ] Add docs for 'basestring'
Message-ID: <E19u1OU-0006qu-00@sc8-sf-web3.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Add docs for 'basestring'

Initial Comment:
Please document the new built-in abstract type
'string'.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 20:23

Message:
Logged In: YES 
user_id=33168

Updated summary, since string was changed to basestring.

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

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

From noreply at sourceforge.net  Mon Sep  1 21:03:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 23:03:55 2003
Subject: [Python-bugs-list] [ python-Bugs-453515 ] filecmp.dircmp case
	sensitivity bug
Message-ID: <E19u1SF-00071D-00@sc8-sf-web3.sourceforge.net>

Bugs item #453515, was opened at 2001-08-20 16:39
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453515&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Rik Kabel (ving)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: filecmp.dircmp case sensitivity bug

Initial Comment:
(warning: python newbie submission)

Platforms: W2K w/Activestate 2.1.1 (same library source found in 2.0 and 2.11 on NetBSD).

filecmp.dircmp performs incorrect filename comparisons when building lists of common and 
directory-unique files. In particular, it sets a dictionary key to the filename (and value to 1) for 
each file in the right-hand tree, and looks for matching names (has_key). This fails on 
case-insensitive platforms when the names are equivalent except for case.

A simple workaround would be to use os.path.normcase() around the filenames before storing and 
comparing, but this is not case-preserving. Case preservation is to be preferred.

A case-preserving workaround might use os.path.normcase() for the dictionary entry keys, but 
store the unchanged filename as the value, and use that value when constructing the list from the 
dictionary.

-- 
Rik      creating tomorrow's legacy systems, today


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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-02-05 15:30

Message:
Logged In: YES 
user_id=11375

Snatching this bug.  See bug #680494 for a test suite for filecmp.py.
Once that's checked in, I'll look into this one.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-06 16:14

Message:
Logged In: YES 
user_id=3066

I've attached a preliminary patch for this, completely
untested.  Problems:

- We don't have any tests for the filecmp module.
- Im not running Windows, so I can't test this in an environment
  similar to that for which the bug was reported.

If someone can create a test case for this, and test the
patch, that would really help.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 13:12

Message:
Logged In: YES 
user_id=6380

While this was reported as an ActivePython bug, the problem
is the same with filecmp.py in CVS, so I'm unassigning this
from Paul (it's not like Paul's track record of responding
to bug reports is so great :-).


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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-28 10:34

Message:
Logged In: YES 
user_id=31392

Can you look at this, Paul?


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

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

From noreply at sourceforge.net  Mon Sep  1 21:06:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 23:06:25 2003
Subject: [Python-bugs-list] [ python-Bugs-658254 ] Accept None for
	time.ctime() and friends
Message-ID: <E19u1Uo-00075s-00@sc8-sf-web3.sourceforge.net>

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

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Accept None for time.ctime() and friends

Initial Comment:
Several functions in the time module can have the time
value they operate on omitted to indicate the current
time, but they do not accept None as equivalent to
omitting the value.  It should be equivalent.

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

Comment By: Christopher Blunck (blunck2)
Date: 2003-01-06 22:43

Message:
Logged In: YES 
user_id=531881

see patch 663482

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

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

From noreply at sourceforge.net  Mon Sep  1 21:08:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 23:08:50 2003
Subject: [Python-bugs-list] [ python-Bugs-654783 ] doctest and exception
	messages
Message-ID: <E19u1XA-0007BD-00@sc8-sf-web3.sourceforge.net>

Bugs item #654783, was opened at 2002-12-16 14:23
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aahz (aahz)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: doctest and exception messages

Initial Comment:
doctest should include information something like this:

    doctest docstrings should not rely on the text of internal Python
    exceptions.  Notice the way factorial() uses its own error messages
    with the standard Python exceptions.  The internal messages can
    change even in bugfix releases (as in 2.2.1 to 2.2.2).


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

Comment By: Tim Peters (tim_one)
Date: 2003-04-25 14:08

Message:
Logged In: YES 
user_id=31435

Back to Aahz.  I don't mind if you change this -- edit the docs 
and check it in.

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

Comment By: Tim Peters (tim_one)
Date: 2002-12-16 18:39

Message:
Logged In: YES 
user_id=31435

It could, but it shouldn't:  error msgs in docs that don't match 
reality are also an insult to users.  doctest should grow some 
sort of option here, though, as its uses outgrew its original 
purposes.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2002-12-16 17:01

Message:
Logged In: YES 
user_id=35752

Couldn't doctest be modified so that it only compares the
exception
name only?

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

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

From noreply at sourceforge.net  Mon Sep  1 21:54:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  1 23:54:41 2003
Subject: [Python-bugs-list] [ python-Bugs-798274 ] absolute import patch
	breaks external users of test.regrtest
Message-ID: <E19u2FW-0005CW-00@sc8-sf-web4.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicholas Riley (nriley)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: absolute import patch breaks external users of test.regrtest

Initial Comment:
I've built a test system using Python's test.regrtest 
mechanism, and it worked very well under Python 2.2.  In 
Python 2.3, the output looks like this:

test_inttypes
test_inttypes skipped -- No module named test_inttypes
test_string
test_unittest
test_unittest skipped -- No module named test_unittest
[...]

I've tracked the problem down to a change made about a 
year ago.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/
python/dist/src/Lib/test/regrtest.py.diff?r1=1.91&r2=1.92

test.regrtest is finding the modules, but is failing to import 
them because it is prepending 'test.' to the module names, 
in a mistaken assumption that all tests will be in a package 
named test.

As it happened, I had my test modules inside a directory 
named 'test', and I tried making the directory a module and 
futzing with sys.path to get it to work, but now 
test.regrtest can't find the system implementation of 
test.test_support.  I've also now got the problem of 
namespace pollution - the "test_string" above is Python's 
version, not my version with the same name.

So, it appears non-Python users of test.regrtest are broken 
by this change in Python 2.3.  I was pretty careful to make 
sure that I was doing something supported - the docstring 
for test.regrtest.main explicitly refers to non-Python test 
suite users - and ran into some weird cases like test.* not 
being installed on Mac OS X by default, but it worked very 
well otherwise.

One potential solution would be that if 'testdir' is specified, 
test.regrtest.main() does not attempt to prepend 'test.' to 
the module names.  This seems to match pretty well with 
the spirit of the documentation for that method.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-01 23:54

Message:
Logged In: YES 
user_id=12800

IIRC, this patch was necessary because some tests required
absolute imports and we cannot mix relative and absolute
imports in the test suite.  IMO, regrtest's primary mission
in life is to support Python's test suite and any other use
is secondary (for example, it isn't documented in the
standard library manual).  OTOH, you might think about
contributing a patch that allows regrtest to be used outside
the Python test suite, but doesn't break the absolute import
requirement while in the test suite.  (You might also
consider adding some standard lib documentation to your
patch <wink>).

The other problems you mention are inherent in Python's
import machinery.  If you have two packages named "test" on
your sys.path, Python will not by default search them both
for submodules.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 12:51

Message:
Logged In: YES 
user_id=80475

Barry, this was your change.
Would you take a look at this bug report?

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

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

From noreply at sourceforge.net  Mon Sep  1 23:48:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 01:48:21 2003
Subject: [Python-bugs-list] [ python-Bugs-453515 ] filecmp.dircmp case
	sensitivity bug
Message-ID: <E19u41V-0003ys-00@sc8-sf-web3.sourceforge.net>

Bugs item #453515, was opened at 2001-08-20 16:39
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453515&group_id=5470

Category: Python Library
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rik Kabel (ving)
Assigned to: Raymond Hettinger (rhettinger)
Summary: filecmp.dircmp case sensitivity bug

Initial Comment:
(warning: python newbie submission)

Platforms: W2K w/Activestate 2.1.1 (same library source found in 2.0 and 2.11 on NetBSD).

filecmp.dircmp performs incorrect filename comparisons when building lists of common and 
directory-unique files. In particular, it sets a dictionary key to the filename (and value to 1) for 
each file in the right-hand tree, and looks for matching names (has_key). This fails on 
case-insensitive platforms when the names are equivalent except for case.

A simple workaround would be to use os.path.normcase() around the filenames before storing and 
comparing, but this is not case-preserving. Case preservation is to be preferred.

A case-preserving workaround might use os.path.normcase() for the dictionary entry keys, but 
store the unchanged filename as the value, and use that value when constructing the list from the 
dictionary.

-- 
Rik      creating tomorrow's legacy systems, today


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-02 00:48

Message:
Logged In: YES 
user_id=80475

Fixed.

See:
   Lib/filecmp.py 1.17 and 1.16.10.1
   Lib/test/test_filecmp 1.3 and 1.2.8.1

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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-02-05 15:30

Message:
Logged In: YES 
user_id=11375

Snatching this bug.  See bug #680494 for a test suite for filecmp.py.
Once that's checked in, I'll look into this one.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-06 16:14

Message:
Logged In: YES 
user_id=3066

I've attached a preliminary patch for this, completely
untested.  Problems:

- We don't have any tests for the filecmp module.
- Im not running Windows, so I can't test this in an environment
  similar to that for which the bug was reported.

If someone can create a test case for this, and test the
patch, that would really help.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 13:12

Message:
Logged In: YES 
user_id=6380

While this was reported as an ActivePython bug, the problem
is the same with filecmp.py in CVS, so I'm unassigning this
from Paul (it's not like Paul's track record of responding
to bug reports is so great :-).


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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-28 10:34

Message:
Logged In: YES 
user_id=31392

Can you look at this, Paul?


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

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

From noreply at sourceforge.net  Tue Sep  2 05:40:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 07:40:16 2003
Subject: [Python-bugs-list] [ python-Bugs-799088 ] distutils ignored LDFLAGS
	in Makefile
Message-ID: <E19u9W7-0000ZT-00@sc8-sf-web1.sourceforge.net>

Bugs item #799088, was opened at 2003-09-02 13: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=799088&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils ignored LDFLAGS in Makefile

Initial Comment:
Distutils ignores the LDFLAGS variable in the Python
Makefile. This is bad, since LDFLAGS typically contains
the -L linker flag telling the linker where to look for
extra libraries.

A possible patch is attached (if the checkbox works
this time :-)


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

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

From noreply at sourceforge.net  Tue Sep  2 05:59:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 07:59:43 2003
Subject: [Python-bugs-list] [ python-Bugs-701751 ] WINDOW in py_curses.h
	needs ncurses-devel
Message-ID: <E19u9ow-0000l7-00@sc8-sf-web4.sourceforge.net>

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

Category: Build
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: A.M. Kuchling (akuchling)
Summary: WINDOW in py_curses.h needs ncurses-devel

Initial Comment:
When trying to build 2.2.2 (Mandrake 9.1 Linux), I got
errors when trying to compile _cursesmodule.c. This is
because py_curses uses WINDOW.

Ultimately, I traced this to my configuration: I had a
curses.h file (from somewhere), I had ncurses 5.2
installed (part of the standard Mandrake RPM-based
installation), but I didn't have libncurses-devel
installed. I installed that RPM and the modules
compiled (and tested) correctly.

The "configure" program didn't catch this problem.
Python compiled and ran anyway, but I would expect that
the requirement for an obscure "devel" package ought to
be flagged, either in the README or in the configure
script.

I'd submit a fix, but I don't know what the behavior is
*supposed* to be. What I see from the output of
"configure" is that configure *still* didn't find the
"ncurses.h" file, even though the compiler caught it later.

Logs of this compile on request.



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

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-02 07:59

Message:
Logged In: YES 
user_id=11375

It's unclear that this is a bug; the configure script looks for ncurses.h, and 
uses curses.h if it isn't found.  It may not have found ncurses.h because 
attempting to compile with that header file failed for some other reason, 
other than it not existing.  In any case, it's Mandrake's problem if it 
includes header files that don't work.

 


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

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

From noreply at sourceforge.net  Tue Sep  2 06:31:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 08:31:14 2003
Subject: [Python-bugs-list] [ python-Bugs-799104 ] CPPFLAGS should not be
	aded to ldshard command
Message-ID: <E19uAJQ-0004Je-00@sc8-sf-web1.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: CPPFLAGS should not be aded to ldshard command

Initial Comment:
CPPFLAGS contains flags for the C preprocessor.  It has
no business being added to the ldshared command (this
is in sysconfig.py).  In fact, it may be harmful since
the ldshared command may well be ld with some flags
which typically does not understand cpp flags.

Irix where the ldshared command is "ld  -shared -all"
is a good example of where it is plain wrong to add
CPPFLAGS.

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

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

From noreply at sourceforge.net  Tue Sep  2 08:49:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 10:49:36 2003
Subject: [Python-bugs-list] [ python-Bugs-797844 ] csv.DictWriter --
	inconsistent doc & code
Message-ID: <E19uCT5-0004bX-00@sc8-sf-web2.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Florent Rougon (frougon)
>Assigned to: Skip Montanaro (montanaro)
Summary: csv.DictWriter -- inconsistent doc & code

Initial Comment:
csv.DictWriter has similar problems as csv.DictReader
as described in bug #792558.

The signature of csv.DictWriter.__init__ is:

    def __init__(self, f, fieldnames, restval="",
extrasaction="raise",
                 dialect="excel", *args):

but the docs says:

class DictWriter(csvfile, fieldnames[, restval=""[,
extrasaction='raise'[, dialect='excel'[, fmtparam]]]])

Problems:

1. f != csvfile
2. The constructor does not accept **arguments, which
is a problem to pass along the (one or several)
fmtparam mentioned in the doc.


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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-02 09:49

Message:
Logged In: YES 
user_id=44345

I'm probably the right person for the DictWriter class.  I've been
off the net or basically swamped much of the time lately what
with the stupid virus crap and a house move.  I'll try to get to
it this week sometime.

S


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-30 15:51

Message:
Logged In: YES 
user_id=33168

Andrew are you the right person to look at this and 797853?

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

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

From noreply at sourceforge.net  Tue Sep  2 12:11:56 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 14:12:17 2003
Subject: [Python-bugs-list] [ python-Bugs-793822 ] gc.get_referrers() is
	inherently dangerous
Message-ID: <E19uFdE-0002Du-00@sc8-sf-web3.sourceforge.net>

Bugs item #793822, was opened at 2003-08-23 17:17
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793822&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: gc.get_referrers() is inherently dangerous

Initial Comment:
gc.get_referrers() can be used to crash any Python
interpreter because it allows the user to obtain
objects which are still under construction.

Here is an example where an iterator can use it to
obtain a tuple while it is still being populated by the
'tuple' built-in function. The following example
triggers a SystemError, but as the tuple 't' is at the
moment still full of null values it can easily generate
segfaults instead.

from gc import get_referrers

def iter():
    tag = object()
    yield tag   # 'tag' gets stored in the result tuple
    lst = [x for x in get_referrers(tag)
           if isinstance(x, tuple)]
    t = lst[0]  # this *is* the result tuple
    print t     # full of nulls !

tuple(iter())

Unless someone has more ideas than me as to how to
prevent this problem, I'd suggest that
gc.get_referrers() should be deemed 'officially
dangerous' in the docs.


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

>Comment By: Armin Rigo (arigo)
Date: 2003-09-02 18:11

Message:
Logged In: YES 
user_id=4771

Here is the doc patch (attached).

A clean solution to this problem would involve delaying GC
registration, which I think would imply changes in the C
API. It is probably not worth it. I don't think it would be
a problem for the GC not to be able to browse through
objects still under constructions because such objects are
never part of a dead cycle anyway, and probably not part of
a cycle at all until later mutated.

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

Comment By: Tim Peters (tim_one)
Date: 2003-08-31 23:36

Message:
Logged In: YES 
user_id=31435

Martin, it's easy to transform the example into one that 
crashes.  For example, adding "print t[3]" as the last line of 
the iter() function causes it to die with a segfault on my box.  
Virtually anything that fetches a NULL from the tuple will try 
to Py_INCREF it (that's all "t[3]" does), and that's an instant 
NULL-pointer dereferencing death.

That said, it would be more helpful <wink> if Armin submitted 
a doc patch.  The introspective features of the gc module are 
intended to be used by consenting adults facing hard 
debugging problems, and I don't care if they can be tricked 
into blowing up.  I agree the docs should point out the 
possibility, though.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-08-31 17:18

Message:
Logged In: YES 
user_id=21627

I see no harm in your example. Even though the tuple has
NULLs in it, is in a stable state. The lesson learned is
that an object should become gc-tracked only if it is in a
stable state, as gc-tracking means to expose references to
the object. This is true independent of get_referrers, as
gc-tracking means that tp_traverse might be called for the
object, so it *has* to be in a stable state.

I fail to see how the example "crashes" the Python
interpreter. I causes a SystemError when the tuple is
resized, that's all. There are many ways to cause a
SystemError, including

raise SystemError

I recommend not to declare a function as "dangerous" in the
docs. Instead, the actual problem should be explained, both
in the GC part of the C API, and in gc module docs (for both
get_referrers, and get_objects).

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

Comment By: Armin Rigo (arigo)
Date: 2003-08-28 13:23

Message:
Logged In: YES 
user_id=4771

But it would be very difficult to fix the code base to avoid
the problem. The 'tuple' constructor was only an example; it
is actually a quite common pattern everywhere in the C code
base of both the core and extension modules. Expecting an
object not to be seen before you first hand it out is
extremely common, and get_referrers() breaks that
assumption. Hence the claim that the problem really lies in
get_referrers().

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

Comment By: Denis S. Otkidach (ods)
Date: 2003-08-28 07:35

Message:
Logged In: YES 
user_id=63454

I guess it's dangerous to make object that is not properly 
initialized reachable from other code. Even if it's reachable 
with get_referrers() only. There is no danger in 
get_referrers() itself.

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

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

From noreply at sourceforge.net  Tue Sep  2 12:23:47 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 14:23:52 2003
Subject: [Python-bugs-list] [ python-Bugs-798046 ] select module doesn't
	allow any iterable.
Message-ID: <E19uFoh-0003If-00@sc8-sf-web4.sourceforge.net>

Bugs item #798046, was opened at 2003-08-31 07:31
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798046&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: select module doesn't allow any iterable.

Initial Comment:
The select module only allows lists, not any 
iterable.  While this may slightly increase efficiency 
for the select.select() function itself, for many 
applications passing select.select a sets.Set would 
probably be much more efficient (i.e., when things 
are being added/removed from the readable or 
writable lists quite often, the O(n) removal of lists 
would certainly be worse than the O(1) removal of 
sets.) 

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

Comment By: Armin Rigo (arigo)
Date: 2003-09-02 18:23

Message:
Logged In: YES 
user_id=4771

Using select.poll() instead of select.select() might be a
good alternative, at least on platforms that support it, if
the sets are getting large enough for you to want to avoid
having to build lists explicitely as in :

    select.select(list(a), list(b), list(c))


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

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

From noreply at sourceforge.net  Tue Sep  2 14:11:02 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 16:11:08 2003
Subject: [Python-bugs-list] [ python-Bugs-794140 ] cygwin builds do not embed
Message-ID: <E19uHUU-0000mS-00@sc8-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alejandro Lopez-Valencia (dradul)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin builds do not embed

Initial Comment:
As an example case, try to build a copy of vim with an 
embeded python interpreter:

"""
indow.o   objects/if_python.o objects/py_config.o     
objects/netbeans.o  object
s/version.o       -lncurses   -liconv -lintl   -
L/usr/lib/python2.3/config -lpyt
hon2.3 -lutil -lm
objects/py_config.o(.data+0x4):config.c: referencia a 
`_initthread' sin definir
objects/py_config.o(.data+0xc):config.c: referencia a 
`_initsignal' sin definir
objects/py_config.o(.data+0x14):config.c: referencia a 
`_initposix' sin definir
objects/py_config.o(.data+0x1c):config.c: referencia a 
`_initerrno' sin definir
objects/py_config.o(.data+0x24):config.c: referencia a 
`_init_sre' sin definir
objects/py_config.o(.data+0x2c):config.c: referencia a 
`_init_codecs' sin defini
r
"""

As you can see, it doesn't embed. 

I have tracked down the failure to a problem in the 
LDSHARED defaults provided by configure.in. The default 
supplied is:

LDSHARED="gcc -shared -Wl,--enable-auto-image-
base";;

but this *does not* work. As per Cygwin documentation 
on the creation of DLLs, this works (already tested 
compiling vim under the same conditions):

LDSHARED="gcc -shared -Wl,--enable-auto-image-base -
Wl,--export-all-symbols -Wl,--enable-auto-import";;

As a side note, please notice that this problem, proper 
user of GNU ld flags under win32, has a direct impact on 
the possible success of a true Mingw32 port (which I 
expect eagerly).


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

>Comment By: Jason Tishler (jlt63)
Date: 2003-09-02 12:11

Message:
Logged In: YES 
user_id=86216

Please try again with the second patch applied too.  The
combination of them seem to work for me.

> I have tested it against the release23-maint CVS branch,
>and unfortunately it doesn't work.. 

BTW, it would have been helpful it you indicated that the
first patch eliminated all but 3 link errors.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 07:31

Message:
Logged In: YES 
user_id=86216

What do you get when you execute the following?

$ objdump -p libpython2.3.dll | fgrep '] init'

Are you building vim against the newly built Python?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 07:13

Message:
Logged In: YES 
user_id=659006

I have tested it against the release23-maint CVS branch, and
unfortunately it doesn't work.. 

*Sigh* I mentioned the autotools because I didn't see the
patch at first (the wonders of top posting, who designed
this bug-tracker?). But now... I think we need an export
symbols definition file... :-(


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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 06:12

Message:
Logged In: YES 
user_id=86216

> Yes, I am willing to test it.

Thanks. Are you willing to build against Python CVS? Or,
do you need me to provide you with replacements for
libpython2.3.dll.a and libpython2.3.dll?

> Yet... Don't you think you are complicating the issue, the
> autotool files and your life, too much?

I don't think so. Note that my approach does not affect
any autotools files.

> There are no obvious security issues involved and...

IIRC, exporting all symbols under Win32 can cause
multiple definition link errors.

> Anyway, it's your ballgame, it's your call.

I appreciate your willingness to acquiesce.

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 05:06

Message:
Logged In: YES 
user_id=659006

Yes, I am willing to test it.

Yet... Don't you think you are complicating the issue, the
autotool files and your life, too much? There are no obvious
security issues involved and the procedure only adds extra
text to the DATA segment in the DLLs, there are no changes
in the actual object code; it won't become a hybrid
DLL/implib such as cygwin1.dll! Take any Unix shared library
(Linux, Solaris, BSD, whatever), and it is already exporting
*all symbols*, how else would you be able to link to them?
There are no import libs, that's a Windows/MacOS Classic
abomination as far as I am concerned :-)

Anyway, it's your ballgame, it's your call.

Cheers


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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-26 05:46

Message:
Logged In: YES 
user_id=86216

I would prefer to just export the missing symbols than
all of them which is unnecessary and possibly problematic.

The attached patch (against Python CVS) exports the
following additionally symbols:

$ objdump -p libpython2.3.dll | fgrep '] init'
        [ 794] init_codecs
        [ 795] init_sre
        [ 796] init_symtable
        [ 797] initerrno
        [ 798] initposix
        [ 799] initsignal
        [ 800] initthread
        [ 801] initxxsubtype
        [ 802] initzipimport

Does the above meet your needs? Are you willing to test
your vim build against it?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:05

Message:
Logged In: YES 
user_id=659006

Opps!

Sorry, my link fell down in the middle of submitting the form. 

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:00

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 
besides having slightly bigger dlls, and the possibility to 
extract symbol definitions and create import libraries out of 
plugins, perhaps even linking extensoins directly (as in writing 
derivative extensions from, say, Numeric).

Adding -Wl,--enable-auto-import doesn't modify the defaults 
but hushes the linker, less perturbing line noise in stderr.

On giving you an example, I only use python under cygwin 
and having just managed to build my first embedded vim, I'm 
starting to experiment. There are some reasonable examples 
in vim's documentation (see ':h if_pyth.txt'). This works for 
me:

1. Type a line of text. Leave cursor on line.
2. Enter command mode and type:
    python import vim; vim.current.line = vim.current.line.upper
()

And about your "Huh?", this is the python bug tracker last 
time I checked. The issue is a GNU ld/Win32 issue, not 
necessarily exclusive to Cygwin. I am leaving a hint for future 
developers.

Cheers.


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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 02:57

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 
besides having slightly bigger dlls, and the possibility to 
extract symbol definitions and create import libraries out of 
plugins, perhaps even linking extensoins directly (as in writing 
derivative extensions from, say, Numeric).

Adding -Wl,--enable-auto-import doesn't modify the defaults 
but hushes the linker, less perturbing line noise in stderr.

On giving you an example, I only use python under cygwin 
and having just managed to build my first embedded vim, I'm 
starting to experiment. There are some reasonable examples 
in vim's documentation (see ':h if_pyth.txt'). This works for 
me:

1. Type a line of text. Leave cursor on line.
2. Enter command mode and type:
    python import vim; vim.current.line = vim.current.line.upper
()

And about your "Huh?", this is the python bug tracker last 
time I checked. The issue is a GNU ld/Win32 issue, not 
necessarily exclusive to Cygwin. I am leaving a hint for future 
developers.

Cheers.


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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-25 10:32

Message:
Logged In: YES 
user_id=86216

AFAICT, changing LDSHARED will affect building extensions
too. So, I am very hesitant to change its definition without
fully understanding the ramifications. Note that Cygwin
Python extensions have been working for almost three
years now. Additionally, I WAG that there are many more
people building extensions than embedding.

> LDSHARED="gcc -shared -Wl,--enable-auto-image-base
> -Wl,--export-all-symbols -Wl,--enable-auto-import";;

I can understand why adding "-Wl,--export-all-symbols"
fixes the above link errors. However, I don't understand
why "-Wl,--enable-auto-import" would help. IIRC, it
defaults to enabled anyway. Does vim with an 
embeded python interpreter build without this option?

Can you provide me a small embedded example so I
can do some testing? Using vim seems a bit unwieldy.

> As a side note, please notice that this problem, proper 
> user of GNU ld flags under win32, has a direct impact on 
> the possible success of a true Mingw32 port (which I 
> expect eagerly).

Huh? How is this related to the report Cygwin problem?

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

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

From noreply at sourceforge.net  Tue Sep  2 14:16:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 16:16:18 2003
Subject: [Python-bugs-list] [ python-Bugs-799369 ] documentation for
	sys.platform is unclear
Message-ID: <E19uHZX-0000pG-00@sc8-sf-web4.sourceforge.net>

Bugs item #799369, was opened at 2003-09-02 22: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=799369&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: documentation for sys.platform is unclear

Initial Comment:
The use of sys.platform is very risky, because it is
not at all clear what the possible values are.  For
example, on Mac OS X "darwin" is used, but this can
only be discovered by trying it out and asking Jack
when another value will be used.

Another problem is that the examples given include a
number, which suggests that an OS version number might
be included here.  Is that only a major version number?
 And why doesn't Mac OS X report "macosx10.2"?

Suggestion: Add a list of known values and for what
platforms they are used.

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

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

From noreply at sourceforge.net  Tue Sep  2 15:58:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  2 17:58:40 2003
Subject: [Python-bugs-list] [ python-Bugs-799428 ] tk_focusNext() fails
Message-ID: <E19uJAa-00058W-00@sc8-sf-web2.sourceforge.net>

Bugs item #799428, was opened at 2003-09-02 17: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=799428&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Perry Greenfield (perrygreenfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: tk_focusNext() fails

Initial Comment:
Calls to the widget method tk_focusNext() fail with
"unsubscriptable object" error. Looking at the Tkinter.py 
code for the routine shows this statement:

name = self.tk.call('tk_focusNext', self._w)

(line 433)

which used to return a string in 2.2 but now returns
a "cmdName object". When this is passed to 
self._nametowidget(name), it fails when it tries to
subscript name (line 1006) since the object does
not support indexing. Perhaps str(name) or
name.string is more appropriate now? (when
that change is made, it works--well, I tested
name.string and that worked)

Perry Greenfield (perry@stsci.edu)

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

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

From noreply at sourceforge.net  Thu Sep  4 13:04:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:13:12 2003
Subject: [Python-bugs-list] [ python-Bugs-603724 ] setting file buffer size
	is unreliable
Message-ID: <E19uzPG-0003SV-00@sc8-sf-web1.sourceforge.net>

Bugs item #603724, was opened at 2002-09-03 00:37
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603724&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeremy Yallop (yallop)
Assigned to: Nobody/Anonymous (nobody)
Summary: setting file buffer size is unreliable

Initial Comment:
The description of open() (ie file()) says:



   "If the buffering argument is given, 0 means

unbuffered, 1 means line buffered, and larger numbers

specify the buffer size."



PyFile_SetBufSize() passes the requested buffer size on

to setvbuf(), with NULL as setvbuf()'s second

parameter.  The C89 standard doesn't guarantee any

change to the buffer size when the second parameter is

NULL, and some stdio implementations (legitimately)

ignore the size parmater in such circumstances.  C99's

gives more guidelines, but nothing that can be relied upon:



   "If buf is not a null pointer, the array it points

to may be used instead of a buffer allocated by the

setvbuf function and the argument size     specifies

the size of the array; otherwise, size may determine

the size of  buffer allocated by the setvbuf function."

(7.19.5.6)



(What good is "may" to anyone?)



The result of all this is that



  fd = open('file', 'w', 8)



will not have the desired (and documented) effect

(flushing the output buffer every 8 characters) on some

platforms, so either the documentation of open() or the

code (PyFile_SetBufSize()) should be fixed.



The same problems exist with setbuf() as well.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-04 21:04

Message:
Logged In: YES 
user_id=21627

Fixed with #788249, in



fileobject.h 2.33

fileobject.c 2.181

fileobject.h 2.32.8.1

NEWS 1.831.4.33

fileobject.c 2.179.8.1



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

Comment By: Andrew Gaul (gaul)
Date: 2003-08-22 10:48

Message:
Logged In: YES 
user_id=139865

See patch 788249 for a fix.

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

Comment By: Martin v. L?wis (loewis)
Date: 2002-09-12 10:12

Message:
Logged In: YES 
user_id=21627

I see, it appears indeed that the size argument is unused on

Linux.



Any volunteers to come up with a patch?

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

Comment By: Jeremy Yallop (yallop)
Date: 2002-09-11 22:49

Message:
Logged In: YES 
user_id=479330

Debian on x86 with glibc-2.2.5 (which I believe uses Per

Bothner's libio) ignores the size parameter when the buffer

parameter is NULL.  I've attached a demonstration program

which calls setvbuf with a size of 2 and with either NULL or

a static buffer (depending on argc). Run it and kill (with

Ctrl-C or whatever) before it's finished.



Alternatively, the effect can be observed in python by

something like



  >>> fd = open('file', 'write', 2)

  >>> fd.write('Hello, world.\n')

  >>>

  Ctrl-Z

  [1]+  Stopped                 python

  $ killall -9 python

  $ cat file

  $



PS I'm not sure declaring Debian as unsupported would be

very popular :-).

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

Comment By: Martin v. L?wis (loewis)
Date: 2002-09-11 18:56

Message:
Logged In: YES 
user_id=21627

Can you please report which systems ignore the setvbuf call?



Python makes loads of assumptions about systems which are

not backed by any standard. On systems which meet Python's

expectation, Python behaves as documented.



On systems which don't meet the expectations, we have two

options

a) declare the system as unsupported, or

b) fix the implementation for the specific system to meet

the documentation.



So in the abstract, I don't see a bug here - setting the

buffer size *is* reliable on Linux and Windows and many

other supported systems.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-09-04 00:35

Message:
Logged In: YES 
user_id=31392

The C99 rationale has a helpful comment on the subject of

setvbuf():



  C90 was not clear about what, if anything, the size

argument means

  when buf is a null pointer.  Existing practice is mixed: some

  implementations ignore it completely, other

implementations use it as

  guidance for determining the size of the buffer allocated

by setvbuf.

  C9X gives warning that size might be ignored in this case,

so portable

  programs must be sure to supply a reasonable value.



I'd be mostly inclined to change the documentation to say

that the buffer is under control of the C library and that

Python does whatever setvbuf() does.  Or however we write

the C99 weasel words in Python docstring-ease.



Thankfully, Linux and Windows both have sane setvbuf()

implementations.



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

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

From noreply at sourceforge.net  Thu Sep  4 12:48:42 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:13:47 2003
Subject: [Python-bugs-list] [ python-Bugs-698282 ] __file__ attribute
	missing from dynamicly loaded module
Message-ID: <E19uz9u-0002SZ-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David C. Sweeton (dsweeton)
Assigned to: Nobody/Anonymous (nobody)
Summary: __file__ attribute missing from dynamicly loaded module

Initial Comment:
Only the first instanceof a dynamically loaded module 

gets the __file__ attribute. It is missing from all later 

instances.



The problem is in importdl.c in the function 

_PyImport_LoadDynamicModule. The first time a 

module is loaded a copy of its module dictionary is 

made by a call to _PyImport_FixupExtension. After that 

copy was made, _PyImport_LoadDynamicModule adds 

the _file__ attribute to the original module dictionary. 

Thus the first instance of the module has the 

__file__attribute.



Later when another instance of the module loads, its 

module dictionary is duplicated from the copy of the 

dictionary from the first instance. The problem is that 

when that copy was made, the __file__ attribute was not 

yet there. Thus the later instance of the module does 

not have the __file__ attribute.



The required fix is in importdl.c and consists of simply 

moving the call of _PyImport_FixupExtension to a point 

just after the __file__ attribute is added, instead of just 

before it. I have tested this fix and it solves the problem.



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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-04 20:48

Message:
Logged In: YES 
user_id=21627

This is fixed with patch 794826, in importdl.c  2.71 and

2.70.14.1, NEWS 1.831.4.31.

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

Comment By: Shack Toms (shacktoms)
Date: 2003-08-25 20:04

Message:
Logged In: YES 
user_id=603293

This only appears to be a problem when embedding multiple 

python interpreters in a single application, when more than 

one interpreter does an import that refers to the __file__ 

attribute.   Maybe this would also be a problem for the 

Apache mod_python?  In any case, I have a cdiff file based 

on revision 2.70 of importdl.c.   I hope it can be incorporated.

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

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

From noreply at sourceforge.net  Thu Sep  4 09:16:21 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:14:58 2003
Subject: [Python-bugs-list] [ python-Bugs-800432 ] color highlighting not
	working on EDIT windows
Message-ID: <E19uvqP-0005wV-00@sc8-sf-web4.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: F. Javier Jarava Jarava (developjavier)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: color highlighting not working on EDIT windows

Initial Comment:
ON idle 1.0/python 2.3/Tk 8.4:



When starting IDLE "normally" (ie: with Shell window),

and using File->New Window (Ctrl-N) to get a new Edit

window, syntax higlihting is off until the contents of

the file are saved with a .py extension.



BUT, when starting IDLE after configuring it to start

with a EDIT window, syntax highlighting is ON for that

first window (although not for any other new Edit windows)



The behaviour happens both on IDLE as shipped with the

python.org 2.3 installer and with cygwin's idle:

(idle 1.0, Python 2.3 (#1, Aug  5 2003, 09:49:11)

[GCC 3.2 20020927 (prerelease)] on cygwin) - started

with -n switch to avoid the "missing menus" bug on cygwin)



On idle 0.8 (as shipped with ActiveState ActivePython

2.2.2 Build 224) syntax highlighting is ON in edit

("new") windows.

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

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

From noreply at sourceforge.net  Thu Sep  4 07:03:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:15:20 2003
Subject: [Python-bugs-list] [ python-Bugs-800432 ] color highlighting not
	working on EDIT windows
Message-ID: <E19utm5-0002G0-00@sc8-sf-web2.sourceforge.net>

Bugs item #800432, was opened at 2003-09-04 15: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=800432&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: F. Javier Jarava Jarava (developjavier)
Assigned to: Nobody/Anonymous (nobody)
Summary: color highlighting not working on EDIT windows

Initial Comment:
ON idle 1.0/python 2.3/Tk 8.4:



When starting IDLE "normally" (ie: with Shell window),

and using File->New Window (Ctrl-N) to get a new Edit

window, syntax higlihting is off until the contents of

the file are saved with a .py extension.



BUT, when starting IDLE after configuring it to start

with a EDIT window, syntax highlighting is ON for that

first window (although not for any other new Edit windows)



The behaviour happens both on IDLE as shipped with the

python.org 2.3 installer and with cygwin's idle:

(idle 1.0, Python 2.3 (#1, Aug  5 2003, 09:49:11)

[GCC 3.2 20020927 (prerelease)] on cygwin) - started

with -n switch to avoid the "missing menus" bug on cygwin)



On idle 0.8 (as shipped with ActiveState ActivePython

2.2.2 Build 224) syntax highlighting is ON in edit

("new") windows.

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

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

From noreply at sourceforge.net  Thu Sep  4 06:01:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:15:32 2003
Subject: [Python-bugs-list] [ python-Bugs-794140 ] cygwin builds do not embed
Message-ID: <E19usoC-0007TW-00@sc8-sf-web2.sourceforge.net>

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

Category: Build
>Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alejandro Lopez-Valencia (dradul)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin builds do not embed

Initial Comment:
As an example case, try to build a copy of vim with an 

embeded python interpreter:



"""

indow.o   objects/if_python.o objects/py_config.o     

objects/netbeans.o  object

s/version.o       -lncurses   -liconv -lintl   -

L/usr/lib/python2.3/config -lpyt

hon2.3 -lutil -lm

objects/py_config.o(.data+0x4):config.c: referencia a 

`_initthread' sin definir

objects/py_config.o(.data+0xc):config.c: referencia a 

`_initsignal' sin definir

objects/py_config.o(.data+0x14):config.c: referencia a 

`_initposix' sin definir

objects/py_config.o(.data+0x1c):config.c: referencia a 

`_initerrno' sin definir

objects/py_config.o(.data+0x24):config.c: referencia a 

`_init_sre' sin definir

objects/py_config.o(.data+0x2c):config.c: referencia a 

`_init_codecs' sin defini

r

"""



As you can see, it doesn't embed. 



I have tracked down the failure to a problem in the 

LDSHARED defaults provided by configure.in. The default 

supplied is:



LDSHARED="gcc -shared -Wl,--enable-auto-image-

base";;



but this *does not* work. As per Cygwin documentation 

on the creation of DLLs, this works (already tested 

compiling vim under the same conditions):



LDSHARED="gcc -shared -Wl,--enable-auto-image-base -

Wl,--export-all-symbols -Wl,--enable-auto-import";;



As a side note, please notice that this problem, proper 

user of GNU ld flags under win32, has a direct impact on 

the possible success of a true Mingw32 port (which I 

expect eagerly).



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

>Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 04:01

Message:
Logged In: YES 
user_id=86216

> python import vim; vim.current.line = vim.current.line.upper

()



The above example works fine with embed2.diff applied.



I tested (builing Python) under Red Hat Linux 8.0 too.



Commited as:

Include/pyport.h 2.63

Modules/gcmodule.c 2.72

Python/import.c 2.223

Python/marshal.c 1.75

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

Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 03:51

Message:
Logged In: YES 
user_id=86216

I should have mentioned that the patch assumes Python's

builtin modules are only written in C (not C++). If this

assumption is incorrect, then I will add the standard

__cplusplus/extern "C" idiom.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 03:37

Message:
Logged In: YES 
user_id=86216

Combined the original two patches into one and refreshed

against current CVS.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-09-02 12:11

Message:
Logged In: YES 
user_id=86216

Please try again with the second patch applied too.  The

combination of them seem to work for me.



> I have tested it against the release23-maint CVS branch,

>and unfortunately it doesn't work.. 



BTW, it would have been helpful it you indicated that the

first patch eliminated all but 3 link errors.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 07:31

Message:
Logged In: YES 
user_id=86216

What do you get when you execute the following?



$ objdump -p libpython2.3.dll | fgrep '] init'



Are you building vim against the newly built Python?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 07:13

Message:
Logged In: YES 
user_id=659006

I have tested it against the release23-maint CVS branch, and

unfortunately it doesn't work.. 



*Sigh* I mentioned the autotools because I didn't see the

patch at first (the wonders of top posting, who designed

this bug-tracker?). But now... I think we need an export

symbols definition file... :-(



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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 06:12

Message:
Logged In: YES 
user_id=86216

> Yes, I am willing to test it.



Thanks. Are you willing to build against Python CVS? Or,

do you need me to provide you with replacements for

libpython2.3.dll.a and libpython2.3.dll?



> Yet... Don't you think you are complicating the issue, the

> autotool files and your life, too much?



I don't think so. Note that my approach does not affect

any autotools files.



> There are no obvious security issues involved and...



IIRC, exporting all symbols under Win32 can cause

multiple definition link errors.



> Anyway, it's your ballgame, it's your call.



I appreciate your willingness to acquiesce.

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 05:06

Message:
Logged In: YES 
user_id=659006

Yes, I am willing to test it.



Yet... Don't you think you are complicating the issue, the

autotool files and your life, too much? There are no obvious

security issues involved and the procedure only adds extra

text to the DATA segment in the DLLs, there are no changes

in the actual object code; it won't become a hybrid

DLL/implib such as cygwin1.dll! Take any Unix shared library

(Linux, Solaris, BSD, whatever), and it is already exporting

*all symbols*, how else would you be able to link to them?

There are no import libs, that's a Windows/MacOS Classic

abomination as far as I am concerned :-)



Anyway, it's your ballgame, it's your call.



Cheers



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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-26 05:46

Message:
Logged In: YES 
user_id=86216

I would prefer to just export the missing symbols than

all of them which is unnecessary and possibly problematic.



The attached patch (against Python CVS) exports the

following additionally symbols:



$ objdump -p libpython2.3.dll | fgrep '] init'

        [ 794] init_codecs

        [ 795] init_sre

        [ 796] init_symtable

        [ 797] initerrno

        [ 798] initposix

        [ 799] initsignal

        [ 800] initthread

        [ 801] initxxsubtype

        [ 802] initzipimport



Does the above meet your needs? Are you willing to test

your vim build against it?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:05

Message:
Logged In: YES 
user_id=659006

Opps!



Sorry, my link fell down in the middle of submitting the form. 

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:00

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).



Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.



On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:



1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()



And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.



Cheers.



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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 02:57

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).



Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.



On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:



1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()



And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.



Cheers.



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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-25 10:32

Message:
Logged In: YES 
user_id=86216

AFAICT, changing LDSHARED will affect building extensions

too. So, I am very hesitant to change its definition without

fully understanding the ramifications. Note that Cygwin

Python extensions have been working for almost three

years now. Additionally, I WAG that there are many more

people building extensions than embedding.



> LDSHARED="gcc -shared -Wl,--enable-auto-image-base

> -Wl,--export-all-symbols -Wl,--enable-auto-import";;



I can understand why adding "-Wl,--export-all-symbols"

fixes the above link errors. However, I don't understand

why "-Wl,--enable-auto-import" would help. IIRC, it

defaults to enabled anyway. Does vim with an 

embeded python interpreter build without this option?



Can you provide me a small embedded example so I

can do some testing? Using vim seems a bit unwieldy.



> As a side note, please notice that this problem, proper 

> user of GNU ld flags under win32, has a direct impact on 

> the possible success of a true Mingw32 port (which I 

> expect eagerly).



Huh? How is this related to the report Cygwin problem?

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

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

From noreply at sourceforge.net  Tue Sep  2 22:54:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:20:20 2003
Subject: [Python-bugs-list] [ python-Bugs-797447 ]
	locale.setlocale(locale.LC_ALL, "de") raises exception
Message-ID: <E19uPex-0002Zp-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Peter Otten (potten)
Assigned to: Martin v. L?wis (loewis)
Summary: locale.setlocale(locale.LC_ALL, "de") raises exception

Initial Comment:
Python 2.3 (#1, Jul 30 2003, 11:19:43) 
[GCC 3.2] on linux2 
Type "help", "copyright", "credits" or "license" for more 
information. 
>>> import locale as lo 
>>> lo.setlocale(lo.LC_ALL, 'de') 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "/usr/local/lib/python2.3/locale.py", line 381, in 
setlocale 
    return _setlocale(category, locale) 
locale.Error: locale setting not supported 
 
The above was taken from the example section of the 
locale module documentation. 
 
But this works: 
 
>>> lo.setlocale(lo.LC_ALL, 'de_DE') 
'de_DE' 
>>> 
 
So the error message should at least be changed to 
"unknown/unsupported locale" and the documentation 
example updated to 'de_DE' instead of 'de'. 
 
However, if there are no side effects, I'd prefer to 
change the locale.setlocale() implementation to always 
normalize() the locale: 
 
def setlocale(category, locale=None): 
    if locale: 
        if type(locale) is not type(""): 
            # convert to string 
            locale = _build_localename(locale) 
        locale = normalize(locale) 
    return _setlocale(category, locale) 
 

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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-03 06:54

Message:
Logged In: YES 
user_id=21627

This bug is now fixed in



liblocale.tex 1.35

_localemodule.c 2.41

_localemodule.c 2.40.4.1

NEWS 1.831.4.28

liblocale.tex 1.33.10.2



by changing the error message, and changing the example to

read de_DE.

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

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-09-01 10:02

Message:
Logged In: YES 
user_id=552329

Just my 2c, but I would agree that a wording change to 

either "unsupported locale setting" or "%s locale setting not 

supported" with the attempted locale would be much clearer.



No opinion on (2) :)

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

Comment By: Peter Otten (potten)
Date: 2003-08-31 23:37

Message:
Logged In: YES 
user_id=703365

(1) I read "locale setting not supported" and understood (not 
being a native speaker) "(any) locale setting not supported", 
whereas "unknown/unsupported locale" would make it clear 
you can set a locale but not the one that was requested. 
 
(2) I would expect setlocale(..., "de") and setlocale(..., 
("de", None)) to either both fail or both succeed, but 
currently only the latter form works; thus the proposed 
change in the code. 
 
I hope this clarifies the issue and you will reconsider. 

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-08-31 19:00

Message:
Logged In: YES 
user_id=21627

I fail to see the bug. "locale setting not supported" is

exactly identical, in its meaning, with "unsupported locale".



Changing the example to de_DE won't help much, either, since

the next system might support "de" but not "de_DE", or it

might support "de_DE.ISO-8859-1" only. Locale names are not

standardized.

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

Comment By: Peter Otten (potten)
Date: 2003-08-30 09:29

Message:
Logged In: YES 
user_id=703365

I forgot to mention that the following also works: 
 
>>> import locale 
>>> locale.setlocale(locale.LC_ALL, ("de", None)) 
'de_DE.ISO8859-1' 
>>> 
 
So the it really seems to be an implementation rather than a 
documentation issue. 

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

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

From noreply at sourceforge.net  Thu Sep  4 15:26:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:26:40 2003
Subject: [Python-bugs-list] [ python-Bugs-727692 ] Documentation formatting
	bugs
Message-ID: <E19v1cb-0002mC-00@sc8-sf-web2.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L?wis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Documentation formatting bugs

Initial Comment:
I found that some of my changes get incorrectly 

formatted, but I don't know how to fix them. Assigning to 

Fred in the hope that he knows the proper incantations.



- HTML version of 4.9.2 (standard encodings):

The table is incorrect in the lines that have an empty 

Aliases column (e.g. cp874). The Alias ought to be 

empty, and "Thai" ought to occur in the third column



- HTML version of 4.9.3 (encodings.IDNA)

The first paragraph starts with a bogus "P>"



- HTML of whatsnew, 17, "Support for internationalized 

domain names": The first line of Python prints as a 

guillemet, not as ">>" Notice that I used a non-

preformatted enviroment so that I could output c-cedilla.



- Postscript version of 4.9.2: the table is overfull in its 

width. It would be ok to wrap the aliases lists as much 

as necessary

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-04 17:26

Message:
Logged In: YES 
user_id=3066

Fixed table generation in HTML that caused cells to be

dropped in the standard encodings table in

Doc/perl/python.perl revision 1.140.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-30 11:06

Message:
Logged In: YES 
user_id=3066

- Standard encodings table: ouch!  I'll see what I can do

about this, but it'll take more time than I can spend right now.



- encodings.idna documentation:  That's a bug in the

formatting software; hopefully I'll be able to fix it. 

Worked around it for now (Doc/lib/libcodecs.tex 1.20).



- What's New document: I've worked around the problem so the

interactive prompt shows up properly, but an extraneous

space is generated at the beginning of the line; not sure

why (Doc/whatsnew/whatsnew23.tex 1.144).



- Postscript:  I expect the PDF to exhibit the same problem.

 This is a general problem for tables with a lot of

horizontal-mode material in LaTeX; I don't know how to work

around this (yet).

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

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

From noreply at sourceforge.net  Thu Sep  4 05:51:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:29:45 2003
Subject: [Python-bugs-list] [ python-Bugs-794140 ] cygwin builds do not embed
Message-ID: <E19use0-0004kw-00@sc8-sf-web1.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alejandro Lopez-Valencia (dradul)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin builds do not embed

Initial Comment:
As an example case, try to build a copy of vim with an 

embeded python interpreter:



"""

indow.o   objects/if_python.o objects/py_config.o     

objects/netbeans.o  object

s/version.o       -lncurses   -liconv -lintl   -

L/usr/lib/python2.3/config -lpyt

hon2.3 -lutil -lm

objects/py_config.o(.data+0x4):config.c: referencia a 

`_initthread' sin definir

objects/py_config.o(.data+0xc):config.c: referencia a 

`_initsignal' sin definir

objects/py_config.o(.data+0x14):config.c: referencia a 

`_initposix' sin definir

objects/py_config.o(.data+0x1c):config.c: referencia a 

`_initerrno' sin definir

objects/py_config.o(.data+0x24):config.c: referencia a 

`_init_sre' sin definir

objects/py_config.o(.data+0x2c):config.c: referencia a 

`_init_codecs' sin defini

r

"""



As you can see, it doesn't embed. 



I have tracked down the failure to a problem in the 

LDSHARED defaults provided by configure.in. The default 

supplied is:



LDSHARED="gcc -shared -Wl,--enable-auto-image-

base";;



but this *does not* work. As per Cygwin documentation 

on the creation of DLLs, this works (already tested 

compiling vim under the same conditions):



LDSHARED="gcc -shared -Wl,--enable-auto-image-base -

Wl,--export-all-symbols -Wl,--enable-auto-import";;



As a side note, please notice that this problem, proper 

user of GNU ld flags under win32, has a direct impact on 

the possible success of a true Mingw32 port (which I 

expect eagerly).



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

>Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 03:51

Message:
Logged In: YES 
user_id=86216

I should have mentioned that the patch assumes Python's

builtin modules are only written in C (not C++). If this

assumption is incorrect, then I will add the standard

__cplusplus/extern "C" idiom.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 03:37

Message:
Logged In: YES 
user_id=86216

Combined the original two patches into one and refreshed

against current CVS.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-09-02 12:11

Message:
Logged In: YES 
user_id=86216

Please try again with the second patch applied too.  The

combination of them seem to work for me.



> I have tested it against the release23-maint CVS branch,

>and unfortunately it doesn't work.. 



BTW, it would have been helpful it you indicated that the

first patch eliminated all but 3 link errors.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 07:31

Message:
Logged In: YES 
user_id=86216

What do you get when you execute the following?



$ objdump -p libpython2.3.dll | fgrep '] init'



Are you building vim against the newly built Python?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 07:13

Message:
Logged In: YES 
user_id=659006

I have tested it against the release23-maint CVS branch, and

unfortunately it doesn't work.. 



*Sigh* I mentioned the autotools because I didn't see the

patch at first (the wonders of top posting, who designed

this bug-tracker?). But now... I think we need an export

symbols definition file... :-(



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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 06:12

Message:
Logged In: YES 
user_id=86216

> Yes, I am willing to test it.



Thanks. Are you willing to build against Python CVS? Or,

do you need me to provide you with replacements for

libpython2.3.dll.a and libpython2.3.dll?



> Yet... Don't you think you are complicating the issue, the

> autotool files and your life, too much?



I don't think so. Note that my approach does not affect

any autotools files.



> There are no obvious security issues involved and...



IIRC, exporting all symbols under Win32 can cause

multiple definition link errors.



> Anyway, it's your ballgame, it's your call.



I appreciate your willingness to acquiesce.

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 05:06

Message:
Logged In: YES 
user_id=659006

Yes, I am willing to test it.



Yet... Don't you think you are complicating the issue, the

autotool files and your life, too much? There are no obvious

security issues involved and the procedure only adds extra

text to the DATA segment in the DLLs, there are no changes

in the actual object code; it won't become a hybrid

DLL/implib such as cygwin1.dll! Take any Unix shared library

(Linux, Solaris, BSD, whatever), and it is already exporting

*all symbols*, how else would you be able to link to them?

There are no import libs, that's a Windows/MacOS Classic

abomination as far as I am concerned :-)



Anyway, it's your ballgame, it's your call.



Cheers



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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-26 05:46

Message:
Logged In: YES 
user_id=86216

I would prefer to just export the missing symbols than

all of them which is unnecessary and possibly problematic.



The attached patch (against Python CVS) exports the

following additionally symbols:



$ objdump -p libpython2.3.dll | fgrep '] init'

        [ 794] init_codecs

        [ 795] init_sre

        [ 796] init_symtable

        [ 797] initerrno

        [ 798] initposix

        [ 799] initsignal

        [ 800] initthread

        [ 801] initxxsubtype

        [ 802] initzipimport



Does the above meet your needs? Are you willing to test

your vim build against it?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:05

Message:
Logged In: YES 
user_id=659006

Opps!



Sorry, my link fell down in the middle of submitting the form. 

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:00

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).



Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.



On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:



1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()



And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.



Cheers.



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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 02:57

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).



Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.



On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:



1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()



And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.



Cheers.



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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-25 10:32

Message:
Logged In: YES 
user_id=86216

AFAICT, changing LDSHARED will affect building extensions

too. So, I am very hesitant to change its definition without

fully understanding the ramifications. Note that Cygwin

Python extensions have been working for almost three

years now. Additionally, I WAG that there are many more

people building extensions than embedding.



> LDSHARED="gcc -shared -Wl,--enable-auto-image-base

> -Wl,--export-all-symbols -Wl,--enable-auto-import";;



I can understand why adding "-Wl,--export-all-symbols"

fixes the above link errors. However, I don't understand

why "-Wl,--enable-auto-import" would help. IIRC, it

defaults to enabled anyway. Does vim with an 

embeded python interpreter build without this option?



Can you provide me a small embedded example so I

can do some testing? Using vim seems a bit unwieldy.



> As a side note, please notice that this problem, proper 

> user of GNU ld flags under win32, has a direct impact on 

> the possible success of a true Mingw32 port (which I 

> expect eagerly).



Huh? How is this related to the report Cygwin problem?

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

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

From noreply at sourceforge.net  Thu Sep  4 05:37:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:34:25 2003
Subject: [Python-bugs-list] [ python-Bugs-794140 ] cygwin builds do not embed
Message-ID: <E19usQx-000485-00@sc8-sf-web1.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alejandro Lopez-Valencia (dradul)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin builds do not embed

Initial Comment:
As an example case, try to build a copy of vim with an 

embeded python interpreter:



"""

indow.o   objects/if_python.o objects/py_config.o     

objects/netbeans.o  object

s/version.o       -lncurses   -liconv -lintl   -

L/usr/lib/python2.3/config -lpyt

hon2.3 -lutil -lm

objects/py_config.o(.data+0x4):config.c: referencia a 

`_initthread' sin definir

objects/py_config.o(.data+0xc):config.c: referencia a 

`_initsignal' sin definir

objects/py_config.o(.data+0x14):config.c: referencia a 

`_initposix' sin definir

objects/py_config.o(.data+0x1c):config.c: referencia a 

`_initerrno' sin definir

objects/py_config.o(.data+0x24):config.c: referencia a 

`_init_sre' sin definir

objects/py_config.o(.data+0x2c):config.c: referencia a 

`_init_codecs' sin defini

r

"""



As you can see, it doesn't embed. 



I have tracked down the failure to a problem in the 

LDSHARED defaults provided by configure.in. The default 

supplied is:



LDSHARED="gcc -shared -Wl,--enable-auto-image-

base";;



but this *does not* work. As per Cygwin documentation 

on the creation of DLLs, this works (already tested 

compiling vim under the same conditions):



LDSHARED="gcc -shared -Wl,--enable-auto-image-base -

Wl,--export-all-symbols -Wl,--enable-auto-import";;



As a side note, please notice that this problem, proper 

user of GNU ld flags under win32, has a direct impact on 

the possible success of a true Mingw32 port (which I 

expect eagerly).



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

>Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 03:37

Message:
Logged In: YES 
user_id=86216

Combined the original two patches into one and refreshed

against current CVS.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-09-02 12:11

Message:
Logged In: YES 
user_id=86216

Please try again with the second patch applied too.  The

combination of them seem to work for me.



> I have tested it against the release23-maint CVS branch,

>and unfortunately it doesn't work.. 



BTW, it would have been helpful it you indicated that the

first patch eliminated all but 3 link errors.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 07:31

Message:
Logged In: YES 
user_id=86216

What do you get when you execute the following?



$ objdump -p libpython2.3.dll | fgrep '] init'



Are you building vim against the newly built Python?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 07:13

Message:
Logged In: YES 
user_id=659006

I have tested it against the release23-maint CVS branch, and

unfortunately it doesn't work.. 



*Sigh* I mentioned the autotools because I didn't see the

patch at first (the wonders of top posting, who designed

this bug-tracker?). But now... I think we need an export

symbols definition file... :-(



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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 06:12

Message:
Logged In: YES 
user_id=86216

> Yes, I am willing to test it.



Thanks. Are you willing to build against Python CVS? Or,

do you need me to provide you with replacements for

libpython2.3.dll.a and libpython2.3.dll?



> Yet... Don't you think you are complicating the issue, the

> autotool files and your life, too much?



I don't think so. Note that my approach does not affect

any autotools files.



> There are no obvious security issues involved and...



IIRC, exporting all symbols under Win32 can cause

multiple definition link errors.



> Anyway, it's your ballgame, it's your call.



I appreciate your willingness to acquiesce.

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 05:06

Message:
Logged In: YES 
user_id=659006

Yes, I am willing to test it.



Yet... Don't you think you are complicating the issue, the

autotool files and your life, too much? There are no obvious

security issues involved and the procedure only adds extra

text to the DATA segment in the DLLs, there are no changes

in the actual object code; it won't become a hybrid

DLL/implib such as cygwin1.dll! Take any Unix shared library

(Linux, Solaris, BSD, whatever), and it is already exporting

*all symbols*, how else would you be able to link to them?

There are no import libs, that's a Windows/MacOS Classic

abomination as far as I am concerned :-)



Anyway, it's your ballgame, it's your call.



Cheers



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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-26 05:46

Message:
Logged In: YES 
user_id=86216

I would prefer to just export the missing symbols than

all of them which is unnecessary and possibly problematic.



The attached patch (against Python CVS) exports the

following additionally symbols:



$ objdump -p libpython2.3.dll | fgrep '] init'

        [ 794] init_codecs

        [ 795] init_sre

        [ 796] init_symtable

        [ 797] initerrno

        [ 798] initposix

        [ 799] initsignal

        [ 800] initthread

        [ 801] initxxsubtype

        [ 802] initzipimport



Does the above meet your needs? Are you willing to test

your vim build against it?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:05

Message:
Logged In: YES 
user_id=659006

Opps!



Sorry, my link fell down in the middle of submitting the form. 

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:00

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).



Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.



On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:



1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()



And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.



Cheers.



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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 02:57

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).



Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.



On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:



1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()



And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.



Cheers.



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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-25 10:32

Message:
Logged In: YES 
user_id=86216

AFAICT, changing LDSHARED will affect building extensions

too. So, I am very hesitant to change its definition without

fully understanding the ramifications. Note that Cygwin

Python extensions have been working for almost three

years now. Additionally, I WAG that there are many more

people building extensions than embedding.



> LDSHARED="gcc -shared -Wl,--enable-auto-image-base

> -Wl,--export-all-symbols -Wl,--enable-auto-import";;



I can understand why adding "-Wl,--export-all-symbols"

fixes the above link errors. However, I don't understand

why "-Wl,--enable-auto-import" would help. IIRC, it

defaults to enabled anyway. Does vim with an 

embeded python interpreter build without this option?



Can you provide me a small embedded example so I

can do some testing? Using vim seems a bit unwieldy.



> As a side note, please notice that this problem, proper 

> user of GNU ld flags under win32, has a direct impact on 

> the possible success of a true Mingw32 port (which I 

> expect eagerly).



Huh? How is this related to the report Cygwin problem?

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

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

From noreply at sourceforge.net  Tue Sep  2 23:16:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 17:59:16 2003
Subject: [Python-bugs-list] [ python-Bugs-788378 ] Unsupported 'locale'
	setting causes Idle to crash on startup
Message-ID: <E19uQ00-0005gK-00@sc8-sf-web3.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andre Posumentov (aposumentov)
Assigned to: Martin v. L?wis (loewis)
Summary: Unsupported 'locale' setting causes Idle to crash on startup

Initial Comment:
If the 'LANG' environment variable is set to an 

unsupported value, Idle crashes on startup.



The error occurs in IOBinding.py, as follows:



Traceback (most recent call last):

  File "Resources/__argvemulator_idle", line 4, in ?

    execfile(os.path.join(os.path.split(__file__)[0], 

"idle"))

  File "Resources/idle", line 4, in ?

    import idlelib.PyShell

  File "/Applications/MacPython-2.3/IDLE.app/

Contents/Resources/idlelib/PyShell.py", line 22, in ?

    from EditorWindow import EditorWindow, 

fixwordbreaks

  File "/Applications/MacPython-2.3/IDLE.app/

Contents/Resources/idlelib/EditorWindow.py", line 39, 

in ?

    class EditorWindow:

  File "/Applications/MacPython-2.3/IDLE.app/

Contents/Resources/idlelib/EditorWindow.py", line 43, 

in EditorWindow

    from IOBinding import IOBinding

  File "/Applications/MacPython-2.3/IDLE.app/

Contents/Resources/idlelib/IOBinding.py", line 31, in ?

    locale.setlocale(locale.LC_CTYPE, "")

  File "/Library/Frameworks/Python.framework/

Versions/2.3/lib/python2.3/locale.py", line 381, in 

setlocale

    return _setlocale(category, locale)

locale.Error: locale setting not supported





Here are the offending lines in IOBinding.py:



try:

    import locale

    locale.setlocale(locale.LC_CTYPE, "")

except ImportError:

    pass



As it's not an 'ImportError'...



The error is reproducible on Mac OS X 10.2.6, running  

MacPython-2.3.  I have not been able to test on other   

operating systems.



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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-03 07:16

Message:
Logged In: YES 
user_id=21627

This is now fixed in IOBinding.py 1.21 and 1.19.8.2, NEWS

1.831.4.29.

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

Comment By: Andre Posumentov (aposumentov)
Date: 2003-08-14 13:48

Message:
Logged In: YES 
user_id=677286



>> except (ImportError, locale.Error):



I've tested the change on my system, and it looks good.  

No crashing on startup, and everything else seems to 

function as it should.





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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-08-14 06:49

Message:
Logged In: YES 
user_id=149084

I suppose the right thing to do here is



except (ImportError, locale.Error):



Is that correct?

I'm going to be away for a few days....

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

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

From noreply at sourceforge.net  Wed Sep  3 07:29:41 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 18:22:20 2003
Subject: [Python-bugs-list] [ python-Bugs-799428 ] tk_focusNext() fails
Message-ID: <E19uXhd-0003j9-00@sc8-sf-web3.sourceforge.net>

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

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Perry Greenfield (perrygreenfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: tk_focusNext() fails

Initial Comment:
Calls to the widget method tk_focusNext() fail with

"unsubscriptable object" error. Looking at the Tkinter.py 

code for the routine shows this statement:



name = self.tk.call('tk_focusNext', self._w)



(line 433)



which used to return a string in 2.2 but now returns

a "cmdName object". When this is passed to 

self._nametowidget(name), it fails when it tries to

subscript name (line 1006) since the object does

not support indexing. Perhaps str(name) or

name.string is more appropriate now? (when

that change is made, it works--well, I tested

name.string and that worked)



Perry Greenfield (perry@stsci.edu)

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

>Comment By: Perry Greenfield (perrygreenfield)
Date: 2003-09-03 09:29

Message:
Logged In: YES 
user_id=252130

Presumably the same problem exists with tk_focusPrev.

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

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

From noreply at sourceforge.net  Wed Sep  3 02:15:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 19:11:43 2003
Subject: [Python-bugs-list] [ python-Bugs-799088 ] distutils ignored LDFLAGS
	in Makefile
Message-ID: <E19uSnb-0004Ad-00@sc8-sf-web1.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils ignored LDFLAGS in Makefile

Initial Comment:
Distutils ignores the LDFLAGS variable in the Python

Makefile. This is bad, since LDFLAGS typically contains

the -L linker flag telling the linker where to look for

extra libraries.



A possible patch is attached (if the checkbox works

this time :-)



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

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-09-03 10:15

Message:
Logged In: YES 
user_id=43607

This solution is fine with me.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-03 07:24

Message:
Logged In: YES 
user_id=21627

I think this is incorrect: LDFLAGS should *not* be used by

distutils. Instead, LDSHARED should incorporate LDFLAGS

where needed. Atleast that is what is done on a number of

platforms (*BSD, Darwin, ...). If your proposed route is

taken, these incorporations would need to be undone, AFAICT.

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

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

From noreply at sourceforge.net  Tue Sep  2 23:24:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 19:34:11 2003
Subject: [Python-bugs-list] [ python-Bugs-799088 ] distutils ignored LDFLAGS
	in Makefile
Message-ID: <E19uQ7g-0005M1-00@sc8-sf-web1.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils ignored LDFLAGS in Makefile

Initial Comment:
Distutils ignores the LDFLAGS variable in the Python

Makefile. This is bad, since LDFLAGS typically contains

the -L linker flag telling the linker where to look for

extra libraries.



A possible patch is attached (if the checkbox works

this time :-)



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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-03 07:24

Message:
Logged In: YES 
user_id=21627

I think this is incorrect: LDFLAGS should *not* be used by

distutils. Instead, LDSHARED should incorporate LDFLAGS

where needed. Atleast that is what is done on a number of

platforms (*BSD, Darwin, ...). If your proposed route is

taken, these incorporations would need to be undone, AFAICT.

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

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

From noreply at sourceforge.net  Thu Sep  4 17:46:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 19:46:52 2003
Subject: [Python-bugs-list] [ python-Bugs-800796 ] Difference between hash()
	and __hash__()
Message-ID: <E19v3o5-0007bc-00@sc8-sf-web1.sourceforge.net>

Bugs item #800796, was opened at 2003-09-04 23:46
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=800796&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Fleiter (fleiter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Difference between hash() and __hash__()

Initial Comment:


Raymond told me in comp.lang.python to submit

this bug, he is working on a fix.



>>> s = slice(None,5)

>>> s.__hash__()

136748064

>>> hash(s)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

TypeError: unhashable type



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

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

From noreply at sourceforge.net  Wed Sep  3 06:15:47 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 19:47:58 2003
Subject: [Python-bugs-list] [ python-Bugs-736407 ] Problem With
	email.MIMEText Package
Message-ID: <E19uWY7-00084q-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Abel (judasiscariot)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Problem With email.MIMEText Package

Initial Comment:
Problem with email.MIMEText.  I created a MIMEText

message (following the example in the documentation). 

The problem occurs when as_string() is called.  This is

the traceback:



  File "/usr/local/lib/python2.3/email/Message.py",

line 113, in as_string

    g.flatten(self, unixfrom=unixfrom)

  File "/usr/local/lib/python2.3/email/Generator.py",

line 102, in flatten

    self._write(msg)

  File "/usr/local/lib/python2.3/email/Generator.py",

line 137, in _write

    self._write_headers(msg)

  File "/usr/local/lib/python2.3/email/Generator.py",

line 183, in _write_headers

    header_name=h, continuation_ws='\t').encode()

  File "/usr/local/lib/python2.3/email/Header.py", line

415, in encode

    return self._encode_chunks(newchunks, maxlinelen)

  File "/usr/local/lib/python2.3/email/Header.py", line

375, in _encode_chunks

    _max_append(chunks, s, maxlinelen, extra)

  File "/usr/local/lib/python2.3/email/quopriMIME.py",

line 84, in _max_append

    L.append(s.lstrip())

AttributeError: 'list' object has no attribute 'lstrip'



I'm using 2.3b1, on RH9.  The same piece of code works

with 2.2.2.



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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-03 08:15

Message:
Logged In: YES 
user_id=12800

Sorry, but you're going to have to work harder at trying to

boil down the buggy code.  When I run ServerMonitor.py, I

get an immediate traceback



Traceback (most recent call last):

  File "ServerMonitor.py", line 18, in ?

    import ThreadUtils, NetMon

ImportError: No module named ThreadUtils



Here's one thing you can try to do: catch the exception in

your code, then pickle the Message object up and post the

pickle.  I can at least reconstitute the pickle and look at

the structure.



Also, I'm guessing the problem is somewhere in ProcessMail()

in PostITControl.py.  Be sure that the mailBody argument is

a string and nothing else.

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

Comment By: John Abel (judasiscariot)
Date: 2003-05-21 04:16

Message:
Logged In: YES 
user_id=221478

The Config.ini will need to modifying to suit your machine

settings.  Run the ServerMonitor.py, and then run

PostITControl.py.  PostITControl.py crashes when trying to

send a mail.

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

Comment By: John Abel (judasiscariot)
Date: 2003-05-21 04:13

Message:
Logged In: YES 
user_id=221478

Sorry, been trying to narrow the code down.  If I have a

bare minimum script, it works, yet the original still fails.

 I'll upload the required files (3).

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-19 15:59

Message:
Logged In: YES 
user_id=12800

I'm moving this to Pending since wthout more information I

can't help. This starts the 14 day clock ticking.  After 2

weeks this bug report will be closed, unless someone follows

up with more information.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-15 10:07

Message:
Logged In: YES 
user_id=12800

Sorry, the attached code sample is incomplete.  It is not

sufficient for me to reproduce the problem.



Please boil down your example to a self-contained -- but as

small as possible -- example.

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

Comment By: John Abel (judasiscariot)
Date: 2003-05-15 05:32

Message:
Logged In: YES 
user_id=221478

Sorry, forgot the comment.  When running the script using

python2.2 (email 2.4.3), I don't receive any errors, mail

gets sent.  It only seems to happen with 2.3b.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-13 11:45

Message:
Logged In: YES 
user_id=12800

Can you upload the exact code that you wrote that caused

this crash?  Please don't paste it.

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

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

From noreply at sourceforge.net  Thu Sep  4 17:49:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 19:50:23 2003
Subject: [Python-bugs-list] [ python-Bugs-800796 ] Difference between hash()
	and __hash__()
Message-ID: <E19v3rT-0007jF-00@sc8-sf-web1.sourceforge.net>

Bugs item #800796, was opened at 2003-09-04 23:46
Message generated for change (Settings changed) made by fleiter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800796&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Fleiter (fleiter)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Difference between hash() and __hash__()

Initial Comment:


Raymond told me in comp.lang.python to submit

this bug, he is working on a fix.



>>> s = slice(None,5)

>>> s.__hash__()

136748064

>>> hash(s)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

TypeError: unhashable type



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

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

From noreply at sourceforge.net  Thu Sep  4 17:52:49 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 19:52:56 2003
Subject: [Python-bugs-list] [ python-Bugs-800796 ] Difference between hash()
	and __hash__()
Message-ID: <E19v3uD-0002Pm-00@sc8-sf-web4.sourceforge.net>

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

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Fleiter (fleiter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Difference between hash() and __hash__()

Initial Comment:


Raymond told me in comp.lang.python to submit

this bug, he is working on a fix.



>>> s = slice(None,5)

>>> s.__hash__()

136748064

>>> hash(s)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

TypeError: unhashable type



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

>Comment By: Stefan Fleiter (fleiter)
Date: 2003-09-04 23:52

Message:
Logged In: YES 
user_id=502578



Terry J. Reedy commented in comp.lang.python:

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

Ref Manual 5.3.3 Slicings says nothing about hashability. 

If not

hashable, in spite of being mutable, "Slices are not

hashable" could

be added at end.



Ref Manual 3.3.1 Basic customization, __hash__( self) entry says

"Called for the key object for dictionary operations, and by the

built-in function hash() "



This implies to me that if there is a __hash__() method,

then hash()

will call it.  If not true, then a 'maybe' could be added.



Lif Maual 2.1 Built-in Functions, hash( object) says only

"Return the hash value of the object (if it has one)."

If having __hash__() does not mean 'has one', then what does.



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

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

From noreply at sourceforge.net  Tue Sep  2 21:16:22 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 21:03:28 2003
Subject: [Python-bugs-list] [ python-Bugs-780996 ] pynche does not start
Message-ID: <E19uO86-0008BP-00@sc8-sf-web2.sourceforge.net>

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

Category: Demos and Tools
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: pynche does not start

Initial Comment:
On a Red Hat 9 box with python 2.3 compiled:



-bash-2.05b# python

/usr/lib/python2.3/site-packages/pynche/pynche 

Traceback (most recent call last):

  File

"/usr/lib/python2.3/site-packages/pynche/pynche", line

7, in ?

    Main.main()

  File

"/usr/lib/python2.3/site-packages/pynche/Main.py", line

220, in main

    dbfile=dbfile)

  File

"/usr/lib/python2.3/site-packages/pynche/Main.py", line

130, in build

    dbfile = s.optiondb()['DBFILE']

KeyError: 'DBFILE'





By looking at the constructor for Switchboard, if

~/.pynche is missing, then self.__optiondb is the empty

hash.



Copying a .pynche file from an older python makes

pynche happy again.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-02 23:16

Message:
Logged In: YES 
user_id=12800

Fixed in Main.py 2.23 (and backported)

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

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

From noreply at sourceforge.net  Tue Sep  2 22:09:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 21:46:11 2003
Subject: [Python-bugs-list] [ python-Bugs-794466 ] email module param
	parsing bug
Message-ID: <E19uOxq-0001Jl-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Stuart D. Gathman (customdesigned)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email module param parsing bug

Initial Comment:
Run the included test program in Python 2.2.2 or 2.3.  

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

$ python2 testemail.py

[('image/pjpeg', ''), ('name', '"Jim&amp'), ('&amp',

''), ('Jill"', '')]

[('image/pjpeg', ''), ('name', 'Jim&amp;&amp;Jill')]



The first answer is wrong.  The second is correct.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-03 00:09

Message:
Logged In: YES 
user_id=12800

Accepted your fix of _parseparamv().  Thanks!



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

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

From noreply at sourceforge.net  Thu Sep  4 20:02:12 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 22:02:25 2003
Subject: [Python-bugs-list] [ python-Bugs-800824 ] test_dumbdbm failing
Message-ID: <E19v5vQ-0003JX-00@sc8-sf-web1.sourceforge.net>

Bugs item #800824, was opened at 2003-09-04 19: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=800824&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_dumbdbm failing

Initial Comment:
Getting the following failures:



test_close_twice (__main__.DumbDBMTestCase) ... ok

test_dumbdbm_creation (__main__.DumbDBMTestCase) ... 

ok

test_dumbdbm_keys (__main__.DumbDBMTestCase) ... 

ERROR

test_dumbdbm_modification (__main__.DumbDBMTestCase) 

... ERROR

test_dumbdbm_read (__main__.DumbDBMTestCase) ... 

ERROR

test_random (__main__.DumbDBMTestCase) ... ERROR

test_write_write_read (__main__.DumbDBMTestCase) ... 

ERROR





They all error out with the same problem:



Traceback (most recent call last):

  File "Lib/test/test_dumbdbm.py", line 73, in 

test_write_write_read

    f = dumbdbm.open(_fname)

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

dumbdbm.py", line 232, in open

    return _Database(file, mode)

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

dumbdbm.py", line 73, in __init__

    self._update()

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

dumbdbm.py", line 84, in _update

    key, pos_and_siz_pair = eval(line)

TypeError: expected string without null bytes





test_whichdb is also failing for essentially the same reason 

although it is hidden under some executed code:



test_whichdb_dbm (__main__.WhichDBTestCase) ... ok

test_whichdb_dumbdbm (__main__.WhichDBTestCase) ... 

FAIL



=====================================

=================================

FAIL: test_whichdb_dumbdbm (__main__.WhichDBTestCase)

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

--

Traceback (most recent call last):

  File "Lib/test/test_whichdb.py", line 56, in 

test_whichdb_name

    self.assertEqual(name, whichdb.whichdb(_fname))

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

unittest.py", line 292, in failUnlessEqual

    raise self.failureException, \

AssertionError: 'dumbdbm' != None





If I run the test by hand by copy-n-paste in the interpreter I 

get the same error as above about null bytes.



Now I compile with --enable-unicode=ucs4, if that has 

anything to do with it.



This is all on OS X 10.2.6 .

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

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

From noreply at sourceforge.net  Tue Sep  2 21:35:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 22:10:12 2003
Subject: [Python-bugs-list] [ python-Bugs-737947 ] Failed assert in
	stringobject.c
Message-ID: <E19uOQY-0002R4-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
>Priority: 5
Submitted By: Fernando P?rez (fer_perez)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Failed assert in stringobject.c

Initial Comment:
Here's how to reproduce the problem:



[~]> cat test.py

import readline

readline.get_completer_delims()



[~]> echo 'execfile("test.py");print 10' | python

python: Objects/stringobject.c:111:

PyString_FromString: Assertion `str !=((void *)0)' failed.

Abort



This was tested with 2.2.1 under RedHat 8.0. On c.l.py,

a Mandrake 9.0 (py2.2.2) user reported a segfault with

the same.



Martin reported not seeing the problem with 2.3b1. 

However, others suggested still filing it for a

possible backport, and also in case the fix was accidental.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-02 23:35

Message:
Logged In: YES 
user_id=12800

I obviously didn't get to this for 2.2.3.  Reassigning to

Fred who threatened to be the 2.2.4 RM.



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

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

Message:
Logged In: YES 
user_id=33168

Barry, should this be handled for 2.2.3?

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

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

Message:
Logged In: YES 
user_id=33168

revision 2.54 in Modules/readline.c fixed this problem. 

Patch #512981: Update readline input stream on sys.stdin/out

change.



The patch must be modified for 2.2.3 because there is an API

change.

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

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

From noreply at sourceforge.net  Thu Sep  4 20:18:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 22:18:49 2003
Subject: [Python-bugs-list] [ python-Bugs-800828 ] Doc bug in PEP-0278
Message-ID: <E19v6BR-00072y-00@sc8-sf-web4.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doc bug in PEP-0278

Initial Comment:
PEP 278 suggests that the proper way to test for 

universal newline support is 'hasattr

(sys.stdout, "newline")'  However, this doesn't work too 

well when sys.stdout is overridden.  One big example of 

this is PythonWin's sys.stdout, which doesn't have an 

newlines attribute even when it is supported by 

python23.dll.



Testing 'hasattr(file, "newlines")' seems to be a more 

reliable way to test.

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

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

From noreply at sourceforge.net  Thu Sep  4 20:23:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 22:23:57 2003
Subject: [Python-bugs-list] [ python-Bugs-800828 ] Doc bug in PEP-0278
Message-ID: <E19v6GM-0000na-00@sc8-sf-web3.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Jack Jansen (jackjansen)
Summary: Doc bug in PEP-0278

Initial Comment:
PEP 278 suggests that the proper way to test for 

universal newline support is 'hasattr

(sys.stdout, "newline")'  However, this doesn't work too 

well when sys.stdout is overridden.  One big example of 

this is PythonWin's sys.stdout, which doesn't have an 

newlines attribute even when it is supported by 

python23.dll.



Testing 'hasattr(file, "newlines")' seems to be a more 

reliable way to test.

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

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

From noreply at sourceforge.net  Thu Sep  4 19:53:12 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 22:25:06 2003
Subject: [Python-bugs-list] [ python-Bugs-791542 ] test_threading
Message-ID: <E19v5mi-0006HB-00@sc8-sf-web4.sourceforge.net>

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

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Shawn Leard (sleard1)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_threading

Initial Comment:


Due the problems reported with version 2.3 I thought I

would give version 2.2.3 a shot. The problem I am

having here is no matter what switches I pass configure

to disable threading it still tries to test them and as

a result the make test fails.



168 tests OK.

1 test failed:

    test_threading

24 tests skipped:

    test_al test_asynchat test_bsddb test_cd test_cl

test_curses

    test_dl test_email_codecs test_fork1 test_gl

test_imgfile

    test_linuxaudiodev test_minidom test_openpty

test_pyexpat

    test_queue test_sax test_socket_ssl

test_socketserver test_thread

    test_threaded_import test_threadedtempfile test_winreg

    test_winsound



--------



./configure --prefix=/usr/local --with-gnu-ld

--with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld

--enable-nls   --with-included-gettext --with-fpectl

--with-threads=no --without-threads --disable-threads

--with-gnu-as



--------



mars$ /files/local/src/Python-2.2.3/python

test_threading.py

Traceback (most recent call last):

  File "test_threading.py", line 7, in ?

    import threading

  File

"/files/local/src/Python-2.2.3/Lib/threading.py", line

5, in ?

    import thread

ImportError: No module named thread



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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-04 18:53

Message:
Logged In: YES 
user_id=357491

In order to better debug this, can you state what the line says 

when test_threading fails; e.g., "test_sunaudiodev skipped -- ..."?



The test will be run regardless of whether you compiled with 

threads or not, but it should be listed as a skip instead of a 

failure.

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

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

From noreply at sourceforge.net  Wed Sep  3 02:14:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 23:35:54 2003
Subject: [Python-bugs-list] [ python-Bugs-799104 ] CPPFLAGS should not be
	aded to ldshard command
Message-ID: <E19uSmL-000458-00@sc8-sf-web1.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: CPPFLAGS should not be aded to ldshard command

Initial Comment:
CPPFLAGS contains flags for the C preprocessor.  It has

no business being added to the ldshared command (this

is in sysconfig.py).  In fact, it may be harmful since

the ldshared command may well be ld with some flags

which typically does not understand cpp flags.



Irix where the ldshared command is "ld  -shared -all"

is a good example of where it is plain wrong to add

CPPFLAGS.

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

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-09-03 10:14

Message:
Logged In: YES 
user_id=43607

I maintain that CPPFLAGS has no business being part of

LDSHARED.  LDSHARED is used at link time only, and the C

preprocessor is not in any way involved in that step.



If you can come up with a better way of creating shared

libraries on Irix, be my guest.  The current way has served

us well for many years.  Looking at configure.in, it's

mostly gcc based systems that use gcc to do the linking of

shared libraries.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-03 07:19

Message:
Logged In: YES 
user_id=21627

OTOH, it also seems wrong that, on Irix, ldshared is "ld

-shared -all". ld should never be used directly.

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

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

From noreply at sourceforge.net  Tue Sep  2 23:19:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep  4 23:50:32 2003
Subject: [Python-bugs-list] [ python-Bugs-799104 ] CPPFLAGS should not be
	aded to ldshard command
Message-ID: <E19uQ30-0003jM-00@sc8-sf-web4.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: CPPFLAGS should not be aded to ldshard command

Initial Comment:
CPPFLAGS contains flags for the C preprocessor.  It has

no business being added to the ldshared command (this

is in sysconfig.py).  In fact, it may be harmful since

the ldshared command may well be ld with some flags

which typically does not understand cpp flags.



Irix where the ldshared command is "ld  -shared -all"

is a good example of where it is plain wrong to add

CPPFLAGS.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-03 07:19

Message:
Logged In: YES 
user_id=21627

OTOH, it also seems wrong that, on Irix, ldshared is "ld

-shared -all". ld should never be used directly.

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

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

From noreply at sourceforge.net  Fri Sep  5 00:59:49 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 03:00:00 2003
Subject: [Python-bugs-list] [ python-Bugs-800899 ] Making "|" directive from
	REs a bit clearer
Message-ID: <E19vAZR-0004w4-00@sc8-sf-web1.sourceforge.net>

Bugs item #800899, was opened at 2003-09-05 08: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=800899&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Making "|" directive from REs a bit clearer

Initial Comment:
Let's take a look, Library Reference, 4.2.1 Regular 

Expression Syntax says:



   "|"

           A|B, where A and B can be arbitrary REs, creates a 

regular

           expression that will match either A or B.

           [...]

!!here_starts_the_darkness!!

           REs separated by "|" are tried from left to right, and 

the

           first one that allows the complete pattern to match 

is considered

           the accepted branch. This means that if A matches, 

B will never

           be tested, even if it would produce a longer overall 

match.

!!here_ends_the_darkness!!



It's not as clear as it can be. For more information take a 

look at: 

<http://mail.python.org/pipermail/python-dev/2003-September/037924.html>



Here's a proposal from Terry Reedy for changing those 

lines from darkness ;-)



"""As the target string is scanned, REs separated by "|" are 

tried from

left to right.  When one pattern completely matches, that 

branch is

accepted.  This means that once A matches, B will not be 

tested

further, even if it would produce a longer overall match."""





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

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

From noreply at sourceforge.net  Fri Sep  5 02:00:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 04:00:32 2003
Subject: [Python-bugs-list] [ python-Feature Requests-800926 ] Python
	version numbers in headers/footers PDF documentation
Message-ID: <E19vBW8-00035o-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #800926, was opened at 2003-09-05 08:00
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=800926&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python version numbers in headers/footers PDF documentation

Initial Comment:
To avoid much confusion with swathes of printouts that

I have lying around, it would be really useful to get a

little header or footer saying "Python Library

Reference v. 2.3" or "Python Language Reference

v.2.4beta". The HTML versions already have this, but it

would be nice to have it in the hard copy versions.

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

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

From noreply at sourceforge.net  Fri Sep  5 02:04:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 04:04:45 2003
Subject: [Python-bugs-list] [ python-Feature Requests-800929 ]
	Module-specific PDFs
Message-ID: <E19vBaC-0007YN-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #800929, was opened at 2003-09-05 08:04
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=800929&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module-specific PDFs

Initial Comment:
I regularly find myself printing out individual module

documentation, and at the moment, the only way I've

found is by printing out the relevant pages from the

full library docs, which is confusing, as the name of

the module this printout pertains to is not immediately

obvious at the top of the front page. I'm wondering if

it would be possible to do invidual PDFs of each

module's documentation, downloadable, say, from the

HTML documentation pages for that modules.

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

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

From noreply at sourceforge.net  Fri Sep  5 07:45:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 09:45:33 2003
Subject: [Python-bugs-list] [ python-Bugs-799369 ] documentation for
	sys.platform is unclear
Message-ID: <E19vGto-000202-00@sc8-sf-web3.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: documentation for sys.platform is unclear

Initial Comment:
The use of sys.platform is very risky, because it is

not at all clear what the possible values are.  For

example, on Mac OS X "darwin" is used, but this can

only be discovered by trying it out and asking Jack

when another value will be used.



Another problem is that the examples given include a

number, which suggests that an OS version number might

be included here.  Is that only a major version number?

 And why doesn't Mac OS X report "macosx10.2"?



Suggestion: Add a list of known values and for what

platforms they are used.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-09-05 15:45

Message:
Logged In: YES 
user_id=45365

A first step would be to document that for Unix the value is based 

on the information returned by "uname" *at the time of building 

Python*, mapped to lowercase and with some cruft removed.



For other platforms for which the value is known (Windows, 

MacOS9) we could document the actual values.

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

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

From noreply at sourceforge.net  Fri Sep  5 08:40:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 10:40:12 2003
Subject: [Python-bugs-list] [ python-Bugs-800796 ] Difference between hash()
	and __hash__()
Message-ID: <E19vHkn-0003NF-00@sc8-sf-web4.sourceforge.net>

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

>Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stefan Fleiter (fleiter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Difference between hash() and __hash__()

Initial Comment:


Raymond told me in comp.lang.python to submit

this bug, he is working on a fix.



>>> s = slice(None,5)

>>> s.__hash__()

136748064

>>> hash(s)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

TypeError: unhashable type



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-05 09:40

Message:
Logged In: YES 
user_id=80475

Fixed.  Now, they both raise TypeError.



See Objects/sliceobject.c 2.21.16.1 and 2.22.



Thanks for the bug report.

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

Comment By: Stefan Fleiter (fleiter)
Date: 2003-09-04 18:52

Message:
Logged In: YES 
user_id=502578



Terry J. Reedy commented in comp.lang.python:

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

Ref Manual 5.3.3 Slicings says nothing about hashability. 

If not

hashable, in spite of being mutable, "Slices are not

hashable" could

be added at end.



Ref Manual 3.3.1 Basic customization, __hash__( self) entry says

"Called for the key object for dictionary operations, and by the

built-in function hash() "



This implies to me that if there is a __hash__() method,

then hash()

will call it.  If not true, then a 'maybe' could be added.



Lif Maual 2.1 Built-in Functions, hash( object) says only

"Return the hash value of the object (if it has one)."

If having __hash__() does not mean 'has one', then what does.



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

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

From noreply at sourceforge.net  Fri Sep  5 13:03:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 15:03:24 2003
Subject: [Python-bugs-list] [ python-Bugs-801306 ] Bad RE in scanf example
Message-ID: <E19vLrP-0005DK-00@sc8-sf-web2.sourceforge.net>

Bugs item #801306, was opened at 2003-09-05 14: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=801306&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jimm Domingo (jimm_domingo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad RE in scanf example

Initial Comment:
In section 4.2.6 "Examples" of the Python Library

Reference, the regular expression for scanf format

tokens %e, %E, %f, %g does not allow an optional sign

in the exponent.  The RE should be:



  [-+]?(\d+(\.\d*)?|\d*\.\d+)([eE][-+]?\d+)?



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

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

From noreply at sourceforge.net  Fri Sep  5 14:21:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 16:21:26 2003
Subject: [Python-bugs-list] [ python-Bugs-801342 ] Bug (documentation or
	real, your choice) in random.sample.
Message-ID: <E19vN51-00057B-00@sc8-sf-web3.sourceforge.net>

Bugs item #801342, was opened at 2003-09-05 16: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=801342&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: Bug (documentation or real, your choice) in random.sample.

Initial Comment:
First, the bug: 
 
>>> s 
Set([1, 2, 4, 5, 6, 34]) 
>>> random.sample(s, 1) 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "/usr/lib/python2.3/random.py", line 266, in 
sample 
    result[i] = selected[j] = population[j] 
TypeError: unindexable object 
 
The interesting thing is this: 
 
>>> random.sample(s, 4) 
[6, 4, 2, 5] 
 
So it works when the sample size is sufficiently 
large, but not when it's small relative to the size of 
the population. 
 
Now, the documentation: 
 
>>> print random.sample.__doc__ 
Chooses k unique random elements from a 
population sequence. 
<snip> 
 
I think either the documentation needs to be 
changed to indicate that the sequence must be 
indexable, or the behavior when the sample is 
small relative to the population should be changed 
to allow non-indexable sequences. 

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

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

From noreply at sourceforge.net  Fri Sep  5 14:26:30 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 16:26:32 2003
Subject: [Python-bugs-list] [ python-Bugs-801342 ] Bug (documentation or
	real, your choice) in random.sample.
Message-ID: <E19vNA6-0005Mb-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Bug (documentation or real, your choice) in random.sample.

Initial Comment:
First, the bug: 
 
>>> s 
Set([1, 2, 4, 5, 6, 34]) 
>>> random.sample(s, 1) 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "/usr/lib/python2.3/random.py", line 266, in 
sample 
    result[i] = selected[j] = population[j] 
TypeError: unindexable object 
 
The interesting thing is this: 
 
>>> random.sample(s, 4) 
[6, 4, 2, 5] 
 
So it works when the sample size is sufficiently 
large, but not when it's small relative to the size of 
the population. 
 
Now, the documentation: 
 
>>> print random.sample.__doc__ 
Chooses k unique random elements from a 
population sequence. 
<snip> 
 
I think either the documentation needs to be 
changed to indicate that the sequence must be 
indexable, or the behavior when the sample is 
small relative to the population should be changed 
to allow non-indexable sequences. 

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

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

From noreply at sourceforge.net  Fri Sep  5 14:28:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 16:29:02 2003
Subject: [Python-bugs-list] [ python-Bugs-801349 ] New slice behaviour. Bug
	or feature?
Message-ID: <E19vNCV-0002RY-00@sc8-sf-web1.sourceforge.net>

Bugs item #801349, was opened at 2003-09-05 15: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=801349&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: New slice behaviour.  Bug or feature?

Initial Comment:
Using a slice of x[:None] returns the whole list.  I would 

thing that if this sort of statement is valid, it should 

return an empty list, like x[:0].  In 2.2, you'll get an 

error with this statement.



This bit me when I was using None as a sentinel.



I'll be able to write a patch when I find out what the 

desired behaviour is (fine as-is, None should behave as 

0, it should throw an error, or other) assuming sf's cvs is 

playing nice.





Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.



C:\Documents and Settings\grant>c:\python23\python

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

[1, 2, 3, 4]

>>> ^Z





C:\Documents and Settings\grant>c:\python22\python

'import site' failed; use -v for traceback

Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit 

(Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

TypeError: sequence index must be integer

>>> ^Z





C:\Documents and Settings\grant>

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

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

From noreply at sourceforge.net  Fri Sep  5 15:28:57 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 17:29:02 2003
Subject: [Python-bugs-list] [ python-Bugs-801306 ] Bad RE in scanf example
Message-ID: <E19vO8X-00052l-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jimm Domingo (jimm_domingo)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Bad RE in scanf example

Initial Comment:
In section 4.2.6 "Examples" of the Python Library

Reference, the regular expression for scanf format

tokens %e, %E, %f, %g does not allow an optional sign

in the exponent.  The RE should be:



  [-+]?(\d+(\.\d*)?|\d*\.\d+)([eE][-+]?\d+)?



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

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

From noreply at sourceforge.net  Fri Sep  5 15:45:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 17:45:18 2003
Subject: [Python-bugs-list] [ python-Bugs-801342 ] Bug (documentation or
	real, your choice) in random.sample.
Message-ID: <E19vOOH-0003Tw-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Bug (documentation or real, your choice) in random.sample.

Initial Comment:
First, the bug: 
 
>>> s 
Set([1, 2, 4, 5, 6, 34]) 
>>> random.sample(s, 1) 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "/usr/lib/python2.3/random.py", line 266, in 
sample 
    result[i] = selected[j] = population[j] 
TypeError: unindexable object 
 
The interesting thing is this: 
 
>>> random.sample(s, 4) 
[6, 4, 2, 5] 
 
So it works when the sample size is sufficiently 
large, but not when it's small relative to the size of 
the population. 
 
Now, the documentation: 
 
>>> print random.sample.__doc__ 
Chooses k unique random elements from a 
population sequence. 
<snip> 
 
I think either the documentation needs to be 
changed to indicate that the sequence must be 
indexable, or the behavior when the sample is 
small relative to the population should be changed 
to allow non-indexable sequences. 

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-05 16:45

Message:
Logged In: YES 
user_id=80475

This isn't a bug, documentation or otherwise.  The docs 

specified that the population argument be a sequence 

(meaning that it defines __len__ and is indexable).



However, I do see the usefulness of taking samples of sets, 

so I fixed-up the code to accept sets, dictionaries, files, and 

other iterables defining __len__() that aren't indexable.



See:  Lib/random.py 1.51.8.2

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

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

From noreply at sourceforge.net  Fri Sep  5 16:15:42 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 18:15:48 2003
Subject: [Python-bugs-list] [ python-Bugs-775012 ] No syntax hilite on new
	file until saved as *.py
Message-ID: <E19vOrm-0001oq-00@sc8-sf-web3.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
Status: Open
>Resolution: Accepted
>Priority: 4
Submitted By: Andy Jewell (cybervegan)
Assigned to: Kurt B. Kaiser (kbk)
Summary: No syntax hilite on new file until saved as *.py

Initial Comment:
python 2.3c1, on windows xp, uk english.



When typing or pasting into a new text window, no 

syntax highlighting appears until the file is saved with 

a .py name.



I know it doesn't make sense to python-syntax highlight 

a non-python file, but shouldn't it default to 

highlighting?  



IDLE never used to do this - I assume it's a quirk of 

IDLEfork (maybe intentional behaviour i suppose).

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 17:15

Message:
Logged In: YES 
user_id=149084

The following from GvR on IDLEfork Bug 763524 30Jun03:



"I've been using the latest version from Python CVS on

Win9: quite intensively over the last week. Some

observations:



- When reusing a blank untitled window to edit a Text

file, it keeps using Python coloring.



- When saving a Python with a non-Python extension

(e.g. .txt), it keeps the coloring.



- When switching off coloring by saving an untitle

buffer as a non-Python extension (e.g. .txt), it keeps

existing coloring.



- When opening a file reuses a blank untitled window,

it doesn't set the focus on the window."

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

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

From noreply at sourceforge.net  Fri Sep  5 17:13:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 19:13:05 2003
Subject: [Python-bugs-list] [ python-Bugs-775061 ] 2 problems with IDLE
Message-ID: <E19vPlE-0000Tj-00@sc8-sf-web1.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
Status: Open
>Resolution: Accepted
>Priority: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Kurt B. Kaiser (kbk)
Summary: 2 problems with IDLE

Initial Comment:
Lib/idlelib/idle.py should use #!/usr/bin/env python

not /usr/bin/python so the user can modify their path

to execute the correct version of python.



In Lib/idlelib/rpc.py around line 623, svr.register

(svr is an RPCServer instance)  is called, but there is

no register method AFAICT.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 18:13

Message:
Logged In: YES 
user_id=149084

I use (from the idlelib dir):

../../python ./PyShell.py

to start an uninstalled IDLE for testing.



There is a more elaborate idle.py in IDLEfork which allows

starting an uninstalled IDLEfork from anywhere in the file

system.  Maybe something like that would be useful to

someone? It's not useful to me, I either use the above,

or call my installed version (which is the latest official

release) from outside that directory.  There is always an

installed IDLE now.



I recommend removing the idle script from 

idlelib, since it is actually installed from Tools/scripts.

The files there uniformly start with #! /usr/bin/env python.

Exceptions: gprof2html.py, parseentities.py



Without objection, I'm going to remove idlelib/idle.



As far as the RPCServer issue goes, this is defunct test

code.  I'll comment it out for now. A proper unit test of

the rpc.py module is needed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-21 21:19

Message:
Logged In: YES 
user_id=33168

Hmmm, I do remember something about distutils rewriting the

line, but I'm not sure.  My problem was that I was running

an uninstalled version in the CVS tree:

  ./Lib/idlelib/idle



Perhaps this isn't a bug.  RPCServer still appears to be a

problem either way.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-21 17:43

Message:
Logged In: YES 
user_id=21627

I fail to see the first problem. Shouldn't distutils replace

the path in #! with sys.exec_prefix? /usr/bin/env should

*not* be used, as this might be a different python than the

one IDLE was installed for.

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

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

From noreply at sourceforge.net  Fri Sep  5 17:17:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 19:17:11 2003
Subject: [Python-bugs-list] [ python-Bugs-780887 ] recent-files defaulted to
	strange place and bad permissions
Message-ID: <E19vPpC-0000aN-00@sc8-sf-web1.sourceforge.net>

Bugs item #780887, was opened at 2003-07-31 09:48
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780887&group_id=5470

Category: IDLE
Group: Python 2.3
>Status: Pending
Resolution: None
>Priority: 3
Submitted By: Lloyd Hugh Allen (lha2)
Assigned to: Kurt B. Kaiser (kbk)
Summary: recent-files defaulted to strange place and bad permissions

Initial Comment:
After a non-admin install of Python 2.3 with Python 2.2 

admin-installed, I got:



C:\Python23\Lib\idlelib>c:\python23\python idle.py

Traceback (most recent call last):

  File "idle.py", line 23, in ?

    idlelib.PyShell.main()

  File "C:\Python23\lib\idlelib\PyShell.py", line 1277, in 

main

    flist.pyshell = PyShell(flist)

  File "C:\Python23\lib\idlelib\PyShell.py", line 721, in 

__init__

    OutputWindow.__init__(self, flist, None, None)

  File "C:\Python23\lib\idlelib\OutputWindow.py", line 16, 

in __init__

    EditorWindow.__init__(self, *args)

  File "C:\Python23\lib\idlelib\EditorWindow.py", line 181, 

in __init__

    self.UpdateRecentFilesList()

  File "C:\Python23\lib\idlelib\EditorWindow.py", line 580, 

in UpdateRecentFilesList

    RFfile=open(self.recentFilesPath,'r')

IOError: [Errno13] Permission denied: 'F:\.idlerc\recent-

files.lst'



======

I have a login to a university server, and the F drive is 

the user drive. I don't recall specifying that anything 

should be kept on the F drive, and would prefer that 

recent files be kept on the local machine.



Changing my own permissions to .idlerc to allow full 

permissions, and to apply these permissions to contents, 

worked and resolved the problem, except that multiple 

users use the same network drive and will now share 

recent files.



Idle 1.0 under the brand-spanking-new Python2.3, with 

Windows XP Professional 5.1.2600 Service Pack 1 Build 

2600.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 18:17

Message:
Logged In: YES 
user_id=149084

No response from OP, change status to Pending.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-08-13 23:58

Message:
Logged In: YES 
user_id=149084

What are the vaules of

HOME

HOMEDRIVE

USERPROFILE

on your machine?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-08-03 13:23

Message:
Logged In: YES 
user_id=21627

IDLE first tries %HOME%, then %HOMEDRIVE%/%HOMEPATH%

The latter is the system convention, so IDLE should follow it.



So setting the HOME environment variable should fix this

problem.



Is this a sufficient solution?

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

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

From noreply at sourceforge.net  Fri Sep  5 17:26:17 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 19:26:20 2003
Subject: [Python-bugs-list] [ python-Bugs-783887 ] Tab / Space Configuration
	Does Not Work in IDLE
Message-ID: <E19vPy5-0002fv-00@sc8-sf-web4.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 3
Submitted By: Andy Huibers (ahuibers)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Tab / Space Configuration Does Not Work in IDLE

Initial Comment:
On Python 2.3/IDLE 1.0, when I go from the editor to:



Options->Configure Idle->Font/Tabs



And set it to "Tab key inserts tabs" what actually 

happens is that the tab key inserts spaces (4 spaces).



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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 18:26

Message:
Logged In: YES 
user_id=149084

I can reproduce this on XP and Linux.



Of course, everyone should use 4 spaces :)

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

Comment By: Andy Huibers (ahuibers)
Date: 2003-08-06 14:09

Message:
Logged In: YES 
user_id=838612

Mmm.. I re-installed the Windows Python-2.3 installer EXE on 

a fresh PC and I have the problem, even when I hit "Apply" 

and "OK".

It is not a big deal of course, but would be nice if it worked..

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-06 00:17

Message:
Logged In: YES 
user_id=80475

I cannot reproduce the problem.



This may be a silly question, but did you click Apply after 

changing the setting?

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

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

From noreply at sourceforge.net  Fri Sep  5 17:51:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 19:51:22 2003
Subject: [Python-bugs-list] [ python-Bugs-790162 ] a bug in IDLE on Python
	2.3 i think
Message-ID: <E19vQMD-0001qt-00@sc8-sf-web1.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
Status: Open
>Resolution: Works For Me
>Priority: 3
Submitted By: Ricardo Nunes Cerqueira (caifas1800)
Assigned to: Kurt B. Kaiser (kbk)
Summary: a bug in IDLE on Python 2.3 i think

Initial Comment:
Hi, my name is Ricardo and i think there is a bug in

the new

release of Python 2.3. When i open a .py file with

IDLE(after

opening IDLE i open another .py file with it) the

second window

does not close after clicking the respective button,

only the first(when i click the first window of IDLE)

that has no code inserted, after trying to close the

group(2

windows) only the first (the first IDLE window with no code

inserted) closes leaving the other with code inserted open.

i'm using Python 2.3 on Windows XP under an Intel PIII

1000EB FC-PGA. What i described happens after i open

Python win then i open IDLE and then i open a .py file

with IDLE, and when i try to close the .py and i can't.

thanks

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 18:51

Message:
Logged In: YES 
user_id=149084

Assuming that IDLE is configured to open a shell (the

default action), then opening a .py file and closing

that .py window works for me.



Assuming that IDLE is configured to open an edit window,

it comes up empty.  If you then open a .py, the empty

window is replaced with the whatever.py file and can be

closed.  Works for me.



Assuming you start python, and then in the interactive

window "import idle", the windows open and close correctly,

as far as I can tell.  I'm using XP / SP 1 / P4 2.4



Please provide (in short sentences) a precise recipe

to reproduce your problem.

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

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

From noreply at sourceforge.net  Fri Sep  5 19:31:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 21:31:33 2003
Subject: [Python-bugs-list] [ python-Bugs-801349 ] New slice behaviour. Bug
	or feature?
Message-ID: <E19vRvC-0008CU-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Michael Hudson (mwh)
Summary: New slice behaviour.  Bug or feature?

Initial Comment:
Using a slice of x[:None] returns the whole list.  I would 

thing that if this sort of statement is valid, it should 

return an empty list, like x[:0].  In 2.2, you'll get an 

error with this statement.



This bit me when I was using None as a sentinel.



I'll be able to write a patch when I find out what the 

desired behaviour is (fine as-is, None should behave as 

0, it should throw an error, or other) assuming sf's cvs is 

playing nice.





Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.



C:\Documents and Settings\grant>c:\python23\python

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

[1, 2, 3, 4]

>>> ^Z





C:\Documents and Settings\grant>c:\python22\python

'import site' failed; use -v for traceback

Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit 

(Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

TypeError: sequence index must be integer

>>> ^Z





C:\Documents and Settings\grant>

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-05 21:31

Message:
Logged In: YES 
user_id=33168

Michael, do you think happened with your extended slice changes?

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

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

From noreply at sourceforge.net  Fri Sep  5 20:04:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 22:04:41 2003
Subject: [Python-bugs-list] [ python-Bugs-775061 ] 2 problems with IDLE
Message-ID: <E19vSRJ-0005pK-00@sc8-sf-web1.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Kurt B. Kaiser (kbk)
Summary: 2 problems with IDLE

Initial Comment:
Lib/idlelib/idle.py should use #!/usr/bin/env python

not /usr/bin/python so the user can modify their path

to execute the correct version of python.



In Lib/idlelib/rpc.py around line 623, svr.register

(svr is an RPCServer instance)  is called, but there is

no register method AFAICT.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 21:04

Message:
Logged In: YES 
user_id=149084

My idea on how to resolve this:

remove the "idle" script from idlelib and

remove the shebang from idlelib/idle.py so

it has to be called explicitly.  Any objections?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 18:13

Message:
Logged In: YES 
user_id=149084

I use (from the idlelib dir):

../../python ./PyShell.py

to start an uninstalled IDLE for testing.



There is a more elaborate idle.py in IDLEfork which allows

starting an uninstalled IDLEfork from anywhere in the file

system.  Maybe something like that would be useful to

someone? It's not useful to me, I either use the above,

or call my installed version (which is the latest official

release) from outside that directory.  There is always an

installed IDLE now.



I recommend removing the idle script from 

idlelib, since it is actually installed from Tools/scripts.

The files there uniformly start with #! /usr/bin/env python.

Exceptions: gprof2html.py, parseentities.py



Without objection, I'm going to remove idlelib/idle.



As far as the RPCServer issue goes, this is defunct test

code.  I'll comment it out for now. A proper unit test of

the rpc.py module is needed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-21 21:19

Message:
Logged In: YES 
user_id=33168

Hmmm, I do remember something about distutils rewriting the

line, but I'm not sure.  My problem was that I was running

an uninstalled version in the CVS tree:

  ./Lib/idlelib/idle



Perhaps this isn't a bug.  RPCServer still appears to be a

problem either way.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-21 17:43

Message:
Logged In: YES 
user_id=21627

I fail to see the first problem. Shouldn't distutils replace

the path in #! with sys.exec_prefix? /usr/bin/env should

*not* be used, as this might be a different python than the

one IDLE was installed for.

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

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

From noreply at sourceforge.net  Fri Sep  5 20:08:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 22:08:34 2003
Subject: [Python-bugs-list] [ python-Bugs-801486 ] markup
	error(lib/libtest.tex)
Message-ID: <E19vSV5-0003Qr-00@sc8-sf-web2.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: markup error(lib/libtest.tex)

Initial Comment:
Library Reference of test.testsupport seems to fail 

translating to HTML document.



The subsection title is something odd.

  5.4.1 [test.testsupport]test.test_support -- -- 

Utility functions for tests 



I guess this part is intended to look like this:

  5.4.1 test.test_support -- -- Utility functions for 

tests 



The corresponding tex source is as follows:



\subsection{\module[test.testsupport]

{test.test_support} ---

            --- Utility functions for tests}

\declaremodule[test.testsupport]{standard}

{test.test_support}



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

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

From noreply at sourceforge.net  Fri Sep  5 20:10:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 22:10:59 2003
Subject: [Python-bugs-list] [ python-Bugs-775061 ] 2 problems with IDLE
Message-ID: <E19vSXP-00060D-00@sc8-sf-web1.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Kurt B. Kaiser (kbk)
Summary: 2 problems with IDLE

Initial Comment:
Lib/idlelib/idle.py should use #!/usr/bin/env python

not /usr/bin/python so the user can modify their path

to execute the correct version of python.



In Lib/idlelib/rpc.py around line 623, svr.register

(svr is an RPCServer instance)  is called, but there is

no register method AFAICT.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-05 22:10

Message:
Logged In: YES 
user_id=33168

No objection from me.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 22:04

Message:
Logged In: YES 
user_id=149084

My idea on how to resolve this:

remove the "idle" script from idlelib and

remove the shebang from idlelib/idle.py so

it has to be called explicitly.  Any objections?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 19:13

Message:
Logged In: YES 
user_id=149084

I use (from the idlelib dir):

../../python ./PyShell.py

to start an uninstalled IDLE for testing.



There is a more elaborate idle.py in IDLEfork which allows

starting an uninstalled IDLEfork from anywhere in the file

system.  Maybe something like that would be useful to

someone? It's not useful to me, I either use the above,

or call my installed version (which is the latest official

release) from outside that directory.  There is always an

installed IDLE now.



I recommend removing the idle script from 

idlelib, since it is actually installed from Tools/scripts.

The files there uniformly start with #! /usr/bin/env python.

Exceptions: gprof2html.py, parseentities.py



Without objection, I'm going to remove idlelib/idle.



As far as the RPCServer issue goes, this is defunct test

code.  I'll comment it out for now. A proper unit test of

the rpc.py module is needed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-21 22:19

Message:
Logged In: YES 
user_id=33168

Hmmm, I do remember something about distutils rewriting the

line, but I'm not sure.  My problem was that I was running

an uninstalled version in the CVS tree:

  ./Lib/idlelib/idle



Perhaps this isn't a bug.  RPCServer still appears to be a

problem either way.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-21 18:43

Message:
Logged In: YES 
user_id=21627

I fail to see the first problem. Shouldn't distutils replace

the path in #! with sys.exec_prefix? /usr/bin/env should

*not* be used, as this might be a different python than the

one IDLE was installed for.

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

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

From noreply at sourceforge.net  Fri Sep  5 21:50:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep  5 23:50:37 2003
Subject: [Python-bugs-list] [ python-Bugs-520325 ] Double underscore needs
	clarification
Message-ID: <E19vU5o-00063l-00@sc8-sf-web2.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Wayne C. Smith (wcsmith)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Double underscore needs clarification

Initial Comment:
Double underscore (DU) is pervasive in Python but

nowhere is clearly explained.  In print and onscreen

from formatted html it is visually ambiguous because

the DUs run together to appear as one.  The table in

2.3.2 of the Reference Manual 2.3a0 2/4/02 presents the

contrast with single underscore but it is subtle.  The

usage of DU should be clarified in accompanying text

and perhaps mentioned again in the Library Reference.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-05 23:50

Message:
Logged In: YES 
user_id=3066

I've substantially elaborated the explanations at that point

in the reference manual in Doc/ref/ref2.tex:



Python 2.2.4:  revision 1.34.6.8

Python 2.3.1:  revision 1.48.10.1

Python 2.4:  revision 1.49



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

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

From noreply at sourceforge.net  Fri Sep  5 22:40:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 00:40:55 2003
Subject: [Python-bugs-list] [ python-Bugs-801486 ] markup
	error(lib/libtest.tex)
Message-ID: <E19vUsV-0003Gg-00@sc8-sf-web4.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: markup error(lib/libtest.tex)

Initial Comment:
Library Reference of test.testsupport seems to fail 

translating to HTML document.



The subsection title is something odd.

  5.4.1 [test.testsupport]test.test_support -- -- 

Utility functions for tests 



I guess this part is intended to look like this:

  5.4.1 test.test_support -- -- Utility functions for 

tests 



The corresponding tex source is as follows:



\subsection{\module[test.testsupport]

{test.test_support} ---

            --- Utility functions for tests}

\declaremodule[test.testsupport]{standard}

{test.test_support}



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-05 23:40

Message:
Logged In: YES 
user_id=80475

Fixed!



Thanks for the report.

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

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

From noreply at sourceforge.net  Fri Sep  5 22:44:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 00:44:40 2003
Subject: [Python-bugs-list] [ python-Bugs-792649 ] RESET_ERROR is not
	defined(logging module)
Message-ID: <E19vUw8-0003Mr-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: RESET_ERROR is not defined(logging module)

Initial Comment:
ConfigStreamHandler class(logging/config.py) has the 

following code in its handle method:



    except socket.error, e:

        if type(e.args) != types.TupleType:

            raise

        else:

            errcode = e.args[0]

            if errcode != RESET_ERROR:

                raise



However, RESET_ERROR is not defined.

So if the handle method catches socket.error, this will 

raise NameError.

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

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

From noreply at sourceforge.net  Fri Sep  5 22:52:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 00:52:21 2003
Subject: [Python-bugs-list] [ python-Bugs-800824 ] test_dumbdbm failing
Message-ID: <E19vV3a-0003ZO-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
>Assigned to: Martin v. L?wis (loewis)
Summary: test_dumbdbm failing

Initial Comment:
Getting the following failures:



test_close_twice (__main__.DumbDBMTestCase) ... ok

test_dumbdbm_creation (__main__.DumbDBMTestCase) ... 

ok

test_dumbdbm_keys (__main__.DumbDBMTestCase) ... 

ERROR

test_dumbdbm_modification (__main__.DumbDBMTestCase) 

... ERROR

test_dumbdbm_read (__main__.DumbDBMTestCase) ... 

ERROR

test_random (__main__.DumbDBMTestCase) ... ERROR

test_write_write_read (__main__.DumbDBMTestCase) ... 

ERROR





They all error out with the same problem:



Traceback (most recent call last):

  File "Lib/test/test_dumbdbm.py", line 73, in 

test_write_write_read

    f = dumbdbm.open(_fname)

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

dumbdbm.py", line 232, in open

    return _Database(file, mode)

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

dumbdbm.py", line 73, in __init__

    self._update()

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

dumbdbm.py", line 84, in _update

    key, pos_and_siz_pair = eval(line)

TypeError: expected string without null bytes





test_whichdb is also failing for essentially the same reason 

although it is hidden under some executed code:



test_whichdb_dbm (__main__.WhichDBTestCase) ... ok

test_whichdb_dumbdbm (__main__.WhichDBTestCase) ... 

FAIL



=====================================

=================================

FAIL: test_whichdb_dumbdbm (__main__.WhichDBTestCase)

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

--

Traceback (most recent call last):

  File "Lib/test/test_whichdb.py", line 56, in 

test_whichdb_name

    self.assertEqual(name, whichdb.whichdb(_fname))

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

unittest.py", line 292, in failUnlessEqual

    raise self.failureException, \

AssertionError: 'dumbdbm' != None





If I run the test by hand by copy-n-paste in the interpreter I 

get the same error as above about null bytes.



Now I compile with --enable-unicode=ucs4, if that has 

anything to do with it.



This is all on OS X 10.2.6 .

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-05 23:52

Message:
Logged In: YES 
user_id=80475

Martin, this appears to be caused by your recent patch to 

fileobject.c and fileobject.h.



FYI, it only fails when run with python_d.

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

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

From noreply at sourceforge.net  Sat Sep  6 07:08:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 09:08:30 2003
Subject: [Python-bugs-list] [ python-Bugs-801631 ] file.truncate fault on
	windows
Message-ID: <E19vcnh-0000mb-00@sc8-sf-web4.sourceforge.net>

Bugs item #801631, was opened at 2003-09-06 13: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=801631&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: simon place (psi-man)
Assigned to: Tim Peters (tim_one)
Summary: file.truncate fault on windows

Initial Comment:
>manual says file.truncate leave the pointer unmoved, 



>>> f=file('test.dat', 'wb') to make things easier

>>> f.write('1234567890')

>>> f.close()

>>> f=file('test.dat','rb+')

>>> f.read(5)

>>>'12345'

>>> f.tell()

>>>5L

>>> f.truncate()

>>> f.tell()

>>>10L





>>>( PythonWin 2.3 (#46, Jul 29 2003, 18:54:32) [MSC

v.1200 32 bit (Intel)] on win32. )





Seems it's a Windows only bug.  On a 2.4.3 linux,

libc-2.2.5 the final

statement produces 5L (and the file is only 5 bytes

long).  Same on

another 2.4.19 libc-2.2.5, and a 2.4.21 libc-2.3.1

Linux, all with a

recent Python 2.4a0 .  

reproduce on Windows.

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

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

From noreply at sourceforge.net  Sat Sep  6 08:58:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 10:58:37 2003
Subject: [Python-bugs-list] [ python-Bugs-788183 ] build fails on Tru64 Unix
	(osf1V5)
Message-ID: <E19veWF-0005Ym-00@sc8-sf-web3.sourceforge.net>

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

Category: Build
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: build fails on Tru64 Unix (osf1V5)

Initial Comment:
the build on an alpha (Tru64 Unix) machine fails when

compiling Modules/posixModule.c; it complains about

stat and lstat, which HP has defined as _F64_stat and

_F64_lstat. HP claims that they automatically convert

them to stat and lstat for portability but my guess is

that the Python #define STAT code overrides this and so

it fails. Changing it to expliciltly reference

_F64_stat and _F64_lstat solves the problem. In the

same module, plock() and unsetenv() are referenced but

neither are found in the include files on the box.

Setting the HAVE_PLOCk and HAVE_UNSETENV macros

properly solves this problem (why didn't configure

detect this?)



Finally, once everything is done, distutils does not

include -lpthread in the list of libraries needed for link.



If you have any questions about these issues, let me know.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-06 16:58

Message:
Logged In: YES 
user_id=21627

See http://python.org/sf/524600

You are probably using gcc, and this is a compiler bug.

Closing it as third-party. I believe a newer gcc version

should fix this; if not, you should use the system compiler.

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

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

From noreply at sourceforge.net  Sat Sep  6 10:29:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 12:29:46 2003
Subject: [Python-bugs-list] [ python-Bugs-801631 ] file.truncate fault on
	windows
Message-ID: <E19vfwQ-0006gF-00@sc8-sf-web1.sourceforge.net>

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

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: simon place (psi-man)
Assigned to: Tim Peters (tim_one)
Summary: file.truncate fault on windows

Initial Comment:
>manual says file.truncate leave the pointer unmoved, 



>>> f=file('test.dat', 'wb') to make things easier

>>> f.write('1234567890')

>>> f.close()

>>> f=file('test.dat','rb+')

>>> f.read(5)

>>>'12345'

>>> f.tell()

>>>5L

>>> f.truncate()

>>> f.tell()

>>>10L





>>>( PythonWin 2.3 (#46, Jul 29 2003, 18:54:32) [MSC

v.1200 32 bit (Intel)] on win32. )





Seems it's a Windows only bug.  On a 2.4.3 linux,

libc-2.2.5 the final

statement produces 5L (and the file is only 5 bytes

long).  Same on

another 2.4.19 libc-2.2.5, and a 2.4.21 libc-2.3.1

Linux, all with a

recent Python 2.4a0 .  

reproduce on Windows.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-09-06 12:29

Message:
Logged In: YES 
user_id=31435

Oh, fudge.  The Windows code here is trying very hard to 

preserve the file position, but it turns out that C fflush() on 

Windows changes the file position in this specific test case.



However, the C standard says (about fflush):



"""

If stream points to an output stream or an update stream in 

which the most recent operation was not input, the fflush 

function causes any unwritten data for that stream to be 

delivered to the host environment to be written to the file; 

otherwise, the behavior is undefined.

"""



The last operation performed by the test program before 

Python's internals call fflush() was an input operation, so the 

effect of calling fflush() is undefined.  If it varies across 

platforms (as appears to be the case here), that's fine by the 

standard, and Python is relying on undefined behavior.



If you stick, e.g., f.seek(5) after the f.tell() call, then on 

Windows this test program works as intended (prints 5 at the 

end, and the file is truncated to 5 bytes).  Then the last 

operation performed on the stream opened for update is 

*not* an input operation, so the effect of fflush() is defined.

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

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

From noreply at sourceforge.net  Sat Sep  6 11:58:41 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 13:58:47 2003
Subject: [Python-bugs-list] [ python-Bugs-727692 ] Documentation formatting
	bugs
Message-ID: <E19vhKb-0001Qy-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin v. L?wis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Documentation formatting bugs

Initial Comment:
I found that some of my changes get incorrectly 

formatted, but I don't know how to fix them. Assigning to 

Fred in the hope that he knows the proper incantations.



- HTML version of 4.9.2 (standard encodings):

The table is incorrect in the lines that have an empty 

Aliases column (e.g. cp874). The Alias ought to be 

empty, and "Thai" ought to occur in the third column



- HTML version of 4.9.3 (encodings.IDNA)

The first paragraph starts with a bogus "P>"



- HTML of whatsnew, 17, "Support for internationalized 

domain names": The first line of Python prints as a 

guillemet, not as ">>" Notice that I used a non-

preformatted enviroment so that I could output c-cedilla.



- Postscript version of 4.9.2: the table is overfull in its 

width. It would be ok to wrap the aliases lists as much 

as necessary

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-06 13:58

Message:
Logged In: YES 
user_id=3066

The original problem in the "What's New" document is worked

around in the current CVS version of the formatting tools,

so I no longer consider that to be an issue.



The only remaining problem of those described in this report

is the overly-wide tables in the PDF and PostScript formats,

and that's a well known problem in the Python documentation.



Closing this report as "fixed as we can make it for now."

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-04 17:26

Message:
Logged In: YES 
user_id=3066

Fixed table generation in HTML that caused cells to be

dropped in the standard encodings table in

Doc/perl/python.perl revision 1.140.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-30 11:06

Message:
Logged In: YES 
user_id=3066

- Standard encodings table: ouch!  I'll see what I can do

about this, but it'll take more time than I can spend right now.



- encodings.idna documentation:  That's a bug in the

formatting software; hopefully I'll be able to fix it. 

Worked around it for now (Doc/lib/libcodecs.tex 1.20).



- What's New document: I've worked around the problem so the

interactive prompt shows up properly, but an extraneous

space is generated at the beginning of the line; not sure

why (Doc/whatsnew/whatsnew23.tex 1.144).



- Postscript:  I expect the PDF to exhibit the same problem.

 This is a general problem for tables with a lot of

horizontal-mode material in LaTeX; I don't know how to work

around this (yet).

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

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

From noreply at sourceforge.net  Sat Sep  6 15:10:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 17:10:21 2003
Subject: [Python-bugs-list] [ python-Bugs-801306 ] Bad RE in scanf example
Message-ID: <E19vkJr-000492-00@sc8-sf-web2.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jimm Domingo (jimm_domingo)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Bad RE in scanf example

Initial Comment:
In section 4.2.6 "Examples" of the Python Library

Reference, the regular expression for scanf format

tokens %e, %E, %f, %g does not allow an optional sign

in the exponent.  The RE should be:



  [-+]?(\d+(\.\d*)?|\d*\.\d+)([eE][-+]?\d+)?



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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 14:10

Message:
Logged In: YES 
user_id=357491

Double-checking with K&R, Jimm is right and regex looks good to 

me.  Hope that helps in some way, Raymond.

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

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

From noreply at sourceforge.net  Sat Sep  6 15:13:57 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 17:14:03 2003
Subject: [Python-bugs-list] [ python-Bugs-800899 ] Making "|" directive from
	REs a bit clearer
Message-ID: <E19vkNZ-0000eY-00@sc8-sf-web4.sourceforge.net>

Bugs item #800899, was opened at 2003-09-04 23:59
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800899&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Making "|" directive from REs a bit clearer

Initial Comment:
Let's take a look, Library Reference, 4.2.1 Regular 

Expression Syntax says:



   "|"

           A|B, where A and B can be arbitrary REs, creates a 

regular

           expression that will match either A or B.

           [...]

!!here_starts_the_darkness!!

           REs separated by "|" are tried from left to right, and 

the

           first one that allows the complete pattern to match 

is considered

           the accepted branch. This means that if A matches, 

B will never

           be tested, even if it would produce a longer overall 

match.

!!here_ends_the_darkness!!



It's not as clear as it can be. For more information take a 

look at: 

<http://mail.python.org/pipermail/python-dev/2003-September/037924.html>



Here's a proposal from Terry Reedy for changing those 

lines from darkness ;-)



"""As the target string is scanned, REs separated by "|" are 

tried from

left to right.  When one pattern completely matches, that 

branch is

accepted.  This means that once A matches, B will not be 

tested

further, even if it would produce a longer overall match."""





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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 14:13

Message:
Logged In: YES 
user_id=357491

This was also brought to the attention of python-dev directly and 

discussed in the thread "Discordance in Documentation..." which 

can be found at http://mail.python.org/pipermail/python-dev/

2003-September/037924.html .

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

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

From noreply at sourceforge.net  Sat Sep  6 15:23:24 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 17:23:29 2003
Subject: [Python-bugs-list] [ python-Bugs-799369 ] documentation for
	sys.platform is unclear
Message-ID: <E19vkWi-0000y6-00@sc8-sf-web4.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: documentation for sys.platform is unclear

Initial Comment:
The use of sys.platform is very risky, because it is

not at all clear what the possible values are.  For

example, on Mac OS X "darwin" is used, but this can

only be discovered by trying it out and asking Jack

when another value will be used.



Another problem is that the examples given include a

number, which suggests that an OS version number might

be included here.  Is that only a major version number?

 And why doesn't Mac OS X report "macosx10.2"?



Suggestion: Add a list of known values and for what

platforms they are used.

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 14:23

Message:
Logged In: YES 
user_id=357491

How often are new platforms supported?  From my short time on 

python-dev I would say not very often.  So listing all known 

platforms shouldn't suffer *too* much from bit rot, but it is 

something to consider before going forward with this.

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-09-05 06:45

Message:
Logged In: YES 
user_id=45365

A first step would be to document that for Unix the value is based 

on the information returned by "uname" *at the time of building 

Python*, mapped to lowercase and with some cruft removed.



For other platforms for which the value is known (Windows, 

MacOS9) we could document the actual values.

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

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

From noreply at sourceforge.net  Sat Sep  6 15:42:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 17:42:15 2003
Subject: [Python-bugs-list] [ python-Bugs-798652 ] Clarify trailing comma in
	func arg list
Message-ID: <E19vkoo-0000i8-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Terry J. Reedy (tjreedy)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Clarify trailing comma in func arg list

Initial Comment:
Current Ref Man 5.3.4 Calls says after grammar:

"A trailing comma may be present after an argument 

list but does not affect the semantics. "

But this is not true if arg list ends with *expr or **expr:



>>> dict(*l,) # any function will do since not called

  File "<stdin>", line 1

    dict(*l,)

            ^ # points at ')'

SyntaxError: invalid syntax

>>> dict(**d,)

  File "<stdin>", line 1

    dict(**d,)

            ^ # points at ','

SyntaxError: invalid syntax



Suggestion: "If an argument list does *not* end with 

*expr or **expr, a trailing comma may be added 

without affecting the semantics."



The same exception applies to function defs as well as 

calls, but 7.5 Function definitions does not have a 

statement such as above.  However, the production for 

parameter_list does end with 'defparameter [","]'.  I 

suggest that this be the first of the parenthesized 

alternatives, as it logically should be, rather than the 

last, so it flows better and so that no one (ignorant 

that '[]' binds tighter than '|') could possible think that 

the '[,]' applies to the * and ** parts.  IE: change 



parameter_list  ::=  (defparameter ",")* 

    ("*" identifier [, "**" identifier] 

    | "**" identifier | defparameter [","]) 



to



parameter_list  ::=  (defparameter ",")* 

    (defparameter [","]

    |'*' identifier [, "**" identifier] 

    | "**" identifier)



Squeezing out a line is a suboptimazation.

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 14:42

Message:
Logged In: YES 
user_id=357491

Terry is right that the line is wrong.  You can examine the actual 

Grammar/Grammar file to see that:



varargslist: (fpdef ['=' test] ',')* ('*' NAME [',' '**' NAME] | '**' 

NAME) | fpdef ['=' test] (',' fpdef ['=' test])* [',']



As you can see the actual grammar does not even have the 

definition of a 'call' token.  Not only that, but the example in the 

docs is not entirely correct since is says that the * and ** syntax 

take an 'expression' token which in the grammar in the docs is 

basically a tuple-like syntax while the official grammar wants a 

NAME which is defined as a primitive token.



I don't know how extensive of a change is warranted.  That one 

line does need to be changed, but if *only* that line is changed 

then the text won't match the example grammar.  But since the 

example grammar does not mirror the real grammar I don't want 

to go messing with it without Fred weighing in on this.



I am going to assign to Fred to see what he has to say.

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

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

From noreply at sourceforge.net  Sat Sep  6 15:53:49 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 17:53:58 2003
Subject: [Python-bugs-list] [ python-Bugs-801349 ] New slice behaviour. Bug
	or feature?
Message-ID: <E19vl09-0003Jc-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Michael Hudson (mwh)
Summary: New slice behaviour.  Bug or feature?

Initial Comment:
Using a slice of x[:None] returns the whole list.  I would 

thing that if this sort of statement is valid, it should 

return an empty list, like x[:0].  In 2.2, you'll get an 

error with this statement.



This bit me when I was using None as a sentinel.



I'll be able to write a patch when I find out what the 

desired behaviour is (fine as-is, None should behave as 

0, it should throw an error, or other) assuming sf's cvs is 

playing nice.





Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.



C:\Documents and Settings\grant>c:\python23\python

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

[1, 2, 3, 4]

>>> ^Z





C:\Documents and Settings\grant>c:\python22\python

'import site' failed; use -v for traceback

Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit 

(Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

TypeError: sequence index must be integer

>>> ^Z





C:\Documents and Settings\grant>

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

>Comment By: logistix (logistix)
Date: 2003-09-06 16:53

Message:
Logged In: YES 
user_id=699438

Actually I now think this is behaving properly since slice uses 

None as sentinels.  'a[slice(None,None)]' is equivilent to a[:].  

Although 'a[None:None]' isn't a backward-compatible 

statement, it doesn't cause any forward compatibility issues 

with pre-2.3 code.  And changing the definition of 'None' on 

slice attributes would cause some serious breakage on third-

party packages.



However, if this is defined behaviour, I'll need to write some 

documentation patches.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-05 20:31

Message:
Logged In: YES 
user_id=33168

Michael, do you think happened with your extended slice changes?

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

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

From noreply at sourceforge.net  Sat Sep  6 16:22:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 18:22:06 2003
Subject: [Python-bugs-list] [ python-Bugs-798046 ] select module doesn't
	allow any iterable.
Message-ID: <E19vlRR-0001yc-00@sc8-sf-web1.sourceforge.net>

Bugs item #798046, was opened at 2003-08-31 00:31
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798046&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: select module doesn't allow any iterable.

Initial Comment:
The select module only allows lists, not any 
iterable.  While this may slightly increase efficiency 
for the select.select() function itself, for many 
applications passing select.select a sets.Set would 
probably be much more efficient (i.e., when things 
are being added/removed from the readable or 
writable lists quite often, the O(n) removal of lists 
would certainly be worse than the O(1) removal of 
sets.) 

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 15:22

Message:
Logged In: YES 
user_id=357491

There seems to be two things that are preventing the use of an 

object that supports the iterator protocol instead of a list.  One is 

the explicit check that the arguments are lists; PyList_Check is run 

on the passed-in lists for a basic sanity check.  Then there is a call 

to a function called list2set that takes in a Python list and then 

sets the passed-in fd_set properly.  In that function there is 

nothing that screams "we should only use lists" beyond it allows 

assuming a list and thus doesn't have any hoops to jump through.



But the iterator protocol was set up to minimize hoop jumping.  

There seems to be little stopping a move over to using the iterator 

protocol beyond a minimial amount of recoding to rip out the list 

check to replace it with PyIter_Check and instead of using a 'for' 

loop through a list you just use a 'while' calling PyIter_Next .



But since this seems to have gone so long without being changed I 

would feel better about having someone tell me it is okay to 

change.  I will email python-dev and ask.

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

Comment By: Armin Rigo (arigo)
Date: 2003-09-02 11:23

Message:
Logged In: YES 
user_id=4771

Using select.poll() instead of select.select() might be a

good alternative, at least on platforms that support it, if

the sets are getting large enough for you to want to avoid

having to build lists explicitely as in :



    select.select(list(a), list(b), list(c))



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

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

From noreply at sourceforge.net  Sat Sep  6 16:51:03 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 18:51:12 2003
Subject: [Python-bugs-list] [ python-Bugs-793822 ] gc.get_referrers() is
	inherently dangerous
Message-ID: <E19vltX-0003h4-00@sc8-sf-web4.sourceforge.net>

Bugs item #793822, was opened at 2003-08-23 10:17
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793822&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: gc.get_referrers() is inherently dangerous

Initial Comment:
gc.get_referrers() can be used to crash any Python

interpreter because it allows the user to obtain

objects which are still under construction.



Here is an example where an iterator can use it to

obtain a tuple while it is still being populated by the

'tuple' built-in function. The following example

triggers a SystemError, but as the tuple 't' is at the

moment still full of null values it can easily generate

segfaults instead.



from gc import get_referrers



def iter():

    tag = object()

    yield tag   # 'tag' gets stored in the result tuple

    lst = [x for x in get_referrers(tag)

           if isinstance(x, tuple)]

    t = lst[0]  # this *is* the result tuple

    print t     # full of nulls !



tuple(iter())



Unless someone has more ideas than me as to how to

prevent this problem, I'd suggest that

gc.get_referrers() should be deemed 'officially

dangerous' in the docs.



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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 15:51

Message:
Logged In: YES 
user_id=357491

The wording Armin proposes in his patch makes sense to me.

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

Comment By: Armin Rigo (arigo)
Date: 2003-09-02 11:11

Message:
Logged In: YES 
user_id=4771

Here is the doc patch (attached).



A clean solution to this problem would involve delaying GC

registration, which I think would imply changes in the C

API. It is probably not worth it. I don't think it would be

a problem for the GC not to be able to browse through

objects still under constructions because such objects are

never part of a dead cycle anyway, and probably not part of

a cycle at all until later mutated.

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

Comment By: Tim Peters (tim_one)
Date: 2003-08-31 16:36

Message:
Logged In: YES 
user_id=31435

Martin, it's easy to transform the example into one that 

crashes.  For example, adding "print t[3]" as the last line of 

the iter() function causes it to die with a segfault on my box.  

Virtually anything that fetches a NULL from the tuple will try 

to Py_INCREF it (that's all "t[3]" does), and that's an instant 

NULL-pointer dereferencing death.



That said, it would be more helpful <wink> if Armin submitted 

a doc patch.  The introspective features of the gc module are 

intended to be used by consenting adults facing hard 

debugging problems, and I don't care if they can be tricked 

into blowing up.  I agree the docs should point out the 

possibility, though.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-08-31 10:18

Message:
Logged In: YES 
user_id=21627

I see no harm in your example. Even though the tuple has

NULLs in it, is in a stable state. The lesson learned is

that an object should become gc-tracked only if it is in a

stable state, as gc-tracking means to expose references to

the object. This is true independent of get_referrers, as

gc-tracking means that tp_traverse might be called for the

object, so it *has* to be in a stable state.



I fail to see how the example "crashes" the Python

interpreter. I causes a SystemError when the tuple is

resized, that's all. There are many ways to cause a

SystemError, including



raise SystemError



I recommend not to declare a function as "dangerous" in the

docs. Instead, the actual problem should be explained, both

in the GC part of the C API, and in gc module docs (for both

get_referrers, and get_objects).

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

Comment By: Armin Rigo (arigo)
Date: 2003-08-28 06:23

Message:
Logged In: YES 
user_id=4771

But it would be very difficult to fix the code base to avoid

the problem. The 'tuple' constructor was only an example; it

is actually a quite common pattern everywhere in the C code

base of both the core and extension modules. Expecting an

object not to be seen before you first hand it out is

extremely common, and get_referrers() breaks that

assumption. Hence the claim that the problem really lies in

get_referrers().

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

Comment By: Denis S. Otkidach (ods)
Date: 2003-08-28 00:35

Message:
Logged In: YES 
user_id=63454

I guess it's dangerous to make object that is not properly 

initialized reachable from other code. Even if it's reachable 

with get_referrers() only. There is no danger in 

get_referrers() itself.

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

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

From noreply at sourceforge.net  Sat Sep  6 16:57:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 18:57:13 2003
Subject: [Python-bugs-list] [ python-Bugs-793753 ] sgmllib parser problem
Message-ID: <E19vlzQ-0003s9-00@sc8-sf-web4.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Walter Hofmann (walterh)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib parser problem

Initial Comment:
Hi,



I notices that the parser htmllib.HTMLParser has a

problem with parsing the following code:



   <select value"" tabindex="11" name="status">



The problem is the missing = after 'value'. As a

result, it will not report the tabindex and name

attributes to the start_select method (it just stops

parsing).



I'm unsure if you aim at parsing every broken HTML code

out there, so maybe this is not a valid bug report.

Anyway, this code snipplet can be found at

 http://81.180.95.165/debtreduction/

(NB: If you use Mozilla's view source function you

won't see the correct HTML code because Mozilla

automatically changes it to ...value tabindex=...)



I found that changing sgmllib.py line 35 from



attrfind = re.compile(

    r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*'

   

r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*))?')



to



attrfind = re.compile(

    r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=?\s*'

   

r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*))?')



fixes this (I inserted a ? after the =). I cannot say

if it breaks something else instead.



Walter Hofmann, walterh@gmx.de







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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 15:57

Message:
Logged In: YES 
user_id=357491

We are not trying to handle every piece of broken HTML out there; 

there is just too much it.  =)



I am going to go ahead and close this as invalid.

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

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

From noreply at sourceforge.net  Sat Sep  6 17:10:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 19:10:59 2003
Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open()
	only in 2.3?
Message-ID: <E19vmCa-000815-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: David Lambert (jdalambert)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Memory leak on open() only in 2.3?

Initial Comment:




If  for instance /tmp is a directory, then the follwing

code fragment produces a large memory leak on Python

2.3 compiled on Linux 2.4.20. This does not appear to

be a problem with previous versions of the interpreter.





#!/usr/local/bin/python





while 1:

    try:

        open('/tmp')

    except:

        pass



It appears that the exception IOError: [Error 21] Is a

directory leave garbage. If the parameter to open()

does not exist, the problem does not occur.



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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 16:10

Message:
Logged In: YES 
user_id=357491

Maybe?  =)



I just did a quick check and PyErr_SetObject (in Python/errors.c) 

calls PyErr_Restore in the same file that uses the 'value' argument 

to set the current PyThreadState's curexc_value which holds a 

PyObject.



But there are so many places where PyThreadState is used I don't 

feel up to hunting down where it might cause an issue.  Perhaps 

with more knowledge of the exception framework can answer the 

question.

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

Comment By: David Lambert (jdalambert)
Date: 2003-08-19 13:17

Message:
Logged In: YES 
user_id=845425

Good point, but if PyObject_CallFunction fails, is

PyErr_SetObject safe with a NULL second parameter? 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-19 12:12

Message:
Logged In: YES 
user_id=33168

Your fix is the same as what I checked in, except that I

used Py_XDECREF instead of Py_DECREF, since

PyObject_CallFunction could fail and return NULL.  This

still needs a test and backport to 2.3.1.

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

Comment By: David Lambert (jdalambert)
Date: 2003-08-19 06:52

Message:
Logged In: YES 
user_id=845425

Over the weekend and through Monday I ran my system 24/7

with the previously attached code. There do not seem to be

any problems, but I am waiting for your "blessing" before

considering it a fix.



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

Comment By: David Lambert (jdalambert)
Date: 2003-08-16 16:09

Message:
Logged In: YES 
user_id=845425

I think I may have a fix. Check out the attached file. It

seems to work for me.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-15 13:07

Message:
Logged In: YES 
user_id=33168

Wow, it sure does leak!



Checked in as:  Objects/fileobject.c 2.180



Still needs a test.  Leaving open until I get around to it.

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

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

From noreply at sourceforge.net  Sat Sep  6 17:22:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 19:22:21 2003
Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker
	thread..
Message-ID: <E19vmNj-0004Yj-00@sc8-sf-web4.sourceforge.net>

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

Category: Windows
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: mark lee smith (netytan)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib output: Worker thread..

Initial Comment:
Hi all,



I've used urlib many times before and have never got 

anything like this.. therefore i'm assuming this is a new 

thing in 2.3. because i've only been seeing this since I 

upgraded my Python version. Anyway At the end of a 

program that uses urllib.urlopen() this line appears



Worker thread [ 4291533751 ] : recieved quit event



And even if the program doesn't output anything it still 

appears, it's not really a big problem but it is very 

anoying! If somone could explain it I would much 

appreciate it.



I've attach a sample program (i've tested it with a few 

smaller programs and get the same output)



Mark.

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 16:22

Message:
Logged In: YES 
user_id=357491

Since the string "Worker" can only be found in three comments in 

Distutils I am closing this bug as invalid.

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

Comment By: mark lee smith (netytan)
Date: 2003-08-19 08:02

Message:
Logged In: YES 
user_id=797196

I get the same results as you. I have no idea where this error 

is coming form then, and I?m only getting these results from 

this box, I tested it on XP and it worked fine. No sign of the 

elusive worker thread anywhere.



Comfused but since this doesn't appear to be a problem with 

Python and more with ME I can live with it :)



Thanks for all your help guys,



Have fun,

Mark.

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

Comment By: Christos Georgiou (tzot)
Date: 2003-08-18 04:01

Message:
Logged In: YES 
user_id=539787

Perhaps this has to do only with your version of IDLE?  In the 

current CVS, various greps for "orker", "recieved" etc did not 

show up with something relevant.

If you are sure about the "Worker" spelling, try this script in 

your Millenium windows:



### code start

import sys, os, itertools



for dirname, dirnames, filenames in os.walk(sys.prefix):

    joiner = os.path.join.__get__(dirname)

    for filename in itertools.imap(joiner, filenames):

        data = file(filename, "rb").read()

        if "Worker" in data:

            print filename

### code end



this searches your whole python installation directory, 

for /any/ file containing the string "Worker".  A run on a 2.3b2 

install showed these files:

C:\PY.23\Lib\distutils\bcppcompiler.py

C:\PY.23\Lib\distutils\ccompiler.py

C:\PY.23\Lib\distutils\msvccompiler.py

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

Comment By: mark lee smith (netytan)
Date: 2003-08-17 11:35

Message:
Logged In: YES 
user_id=797196

The problem can also been see when running IDLE (idle.py 

intead of the idle.pyw). When you close the program 

the "worker thread" message appears in the Python window 

before it closes. My conclusion is that this error is definatly to 

do with the socket module (The version of IDLE packaged in 

2.3 uses sockets).



What chages were made to the socket module in 2.3? Also 

has anyone else knoticed this error?



Any help would be very appreciated,



Thanks,

Mark.

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

Comment By: mark lee smith (netytan)
Date: 2003-08-12 16:53

Message:
Logged In: YES 
user_id=797196

Ok I've spent allot of my free time working on this now and 

I'm pretty sure it isn't in the urllib module. The same message 

is displayed when using smtplib and sendmail. Both modules 

use the socket module, but I am not sure about searching 

that for the message since it is writen in C (A lang' i've only 

brushed with a  few times) plus i'm not sure if this has been 

changed since 2.2.. I could probably upgrade my version at 

home and see if i get the same message but i'm a little 

reluctant to do that.



Sorry cannon, I don't know much about Macs or Mac OS :)



Hope this helps, let me know what you think. Am not sure 

where to go next.



Mark.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-08-09 13:25

Message:
Logged In: YES 
user_id=357491

If you could attempt to figure out where the message is coming 

from that would be great since I have no clue what would be 

causing it.



As for the file path thing, I was executing from my CVS directory 

with your files on my desktop so I did not have my working 

directory the same as where the script was.

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

Comment By: mark lee smith (netytan)
Date: 2003-08-08 23:50

Message:
Logged In: YES 
user_id=797196

I agree with you.. I have a few box's, the error is on Windows 

me box. I havn't had the oppertunity to upgrade the version 

of Python on my XP box because it is running some fairly 

important stuff i'm working on but I plan on upgrading as soon 

as I can. I have a FreeBSD box aswell but no Python as of 

yet. My friend is running FreeBSD and doesn't see the Worker 

Thread either..



I did the same search after I posted this message yesterday 

and couldnt fine anything either. If take into account my lack 

of copying skills then that could explain the miss spelling, I 

know we do spell some words differently from american 

english.



Thanks for the tip, as far as I'm aware if you open a file with 

just the files names then Python automatically looks in the 

same dir as the script. So i'm a little unsure why I would want 

to use an absolute file name when the file is right there :).



Thanks for your help.

Mark.



 

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

Comment By: Brett Cannon (bcannon)
Date: 2003-08-08 14:21

Message:
Logged In: YES 
user_id=357491

On my OS X machine I don't get that message.  What OS are you 

using, Mark?  If you look at urllib it does not import any threading 

module.  I ran ``egrep -r "Worker thread" *`` and it found 

nothing.  Search also failed for "recieved quit event" (which 

"recieved" is misspelled so you would think a search would turn it 

up easily).  I have a sneaking suspicion this might be platform-

specific.



Also, just a tip on opening files relative to the running code: it's 

best to make it absolute by making the path like so:



path = os.path.join(os.path.split(__file__)[0], "file.txt"))



This makes the path absolute so if people (like me) try to execute 

your script from another directory Python doesn't say it can't find 

the file you are referencing.

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

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

From noreply at sourceforge.net  Sat Sep  6 21:32:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep  6 23:32:50 2003
Subject: [Python-bugs-list] [ python-Bugs-801631 ] file.truncate fault on
	windows
Message-ID: <E19vqIA-0006R9-00@sc8-sf-web2.sourceforge.net>

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

Category: Windows
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: simon place (psi-man)
Assigned to: Tim Peters (tim_one)
Summary: file.truncate fault on windows

Initial Comment:
>manual says file.truncate leave the pointer unmoved, 



>>> f=file('test.dat', 'wb') to make things easier

>>> f.write('1234567890')

>>> f.close()

>>> f=file('test.dat','rb+')

>>> f.read(5)

>>>'12345'

>>> f.tell()

>>>5L

>>> f.truncate()

>>> f.tell()

>>>10L





>>>( PythonWin 2.3 (#46, Jul 29 2003, 18:54:32) [MSC

v.1200 32 bit (Intel)] on win32. )





Seems it's a Windows only bug.  On a 2.4.3 linux,

libc-2.2.5 the final

statement produces 5L (and the file is only 5 bytes

long).  Same on

another 2.4.19 libc-2.2.5, and a 2.4.21 libc-2.3.1

Linux, all with a

recent Python 2.4a0 .  

reproduce on Windows.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-09-06 23:32

Message:
Logged In: YES 
user_id=31435

Repaired, via



Lib/test/test_file.py; new revision: 1.13

Misc/NEWS; new revision: 1.852

Objects/fileobject.c; new revision: 2.182

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

Comment By: Tim Peters (tim_one)
Date: 2003-09-06 12:29

Message:
Logged In: YES 
user_id=31435

Oh, fudge.  The Windows code here is trying very hard to 

preserve the file position, but it turns out that C fflush() on 

Windows changes the file position in this specific test case.



However, the C standard says (about fflush):



"""

If stream points to an output stream or an update stream in 

which the most recent operation was not input, the fflush 

function causes any unwritten data for that stream to be 

delivered to the host environment to be written to the file; 

otherwise, the behavior is undefined.

"""



The last operation performed by the test program before 

Python's internals call fflush() was an input operation, so the 

effect of calling fflush() is undefined.  If it varies across 

platforms (as appears to be the case here), that's fine by the 

standard, and Python is relying on undefined behavior.



If you stick, e.g., f.seek(5) after the f.tell() call, then on 

Windows this test program works as intended (prints 5 at the 

end, and the file is truncated to 5 bytes).  Then the last 

operation performed on the stream opened for update is 

*not* an input operation, so the effect of fflush() is defined.

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

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

From noreply at sourceforge.net  Sun Sep  7 07:02:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 09:02:48 2003
Subject: [Python-bugs-list] [ python-Feature Requests-793802 ] class for
	function calls that are not thread safe
Message-ID: <E19vzBf-0000mk-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #793802, was opened at 2003-08-23 18:02
Message generated for change (Comment added) made by elfring
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793802&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Elfring (elfring)
>Assigned to: Martin v. L?wis (loewis)
Summary: class for function calls that are not thread safe

Initial Comment:
I would like that a class will be added to perform thread unsafe 
function or method calls in an easy way like I describe it in the 
request 
"https://sourceforge.net/mailarchive/forum.php?thread_id=1585197&forum_id=24972" 
for the TCL thread package.

The description 
"http://zthread.sourceforge.net/html/classZThread_1_1SynchronousExecutor.html" 
seems to come near what I want. But I think that there is a little bit 
missing.

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

>Comment By: Markus Elfring (elfring)
Date: 2003-09-07 15:02

Message:
Logged In: YES 
user_id=572001

I am looking for a monitor implementation that has got the scope of a 
library or package and not a single synchronized method or block like it 
is in Java.

A function object will get this monitor as a parameter.

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

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

From noreply at sourceforge.net  Sun Sep  7 07:44:30 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 09:44:35 2003
Subject: [Python-bugs-list] [ python-Bugs-801992 ] cgi.CGIHTTPRequestHandler
	remembers QUERY_STRING
Message-ID: <E19vzqA-0007VF-00@sc8-sf-web3.sourceforge.net>

Bugs item #801992, was opened at 2003-09-07 15: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=801992&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivo Danihelka (fidlej)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.CGIHTTPRequestHandler remembers QUERY_STRING

Initial Comment:
Python 2.3+, Debian SID:

cgi.CGIHTTPRequestHandler remembers QUERY_STRING from

last query.

If query is '', then condition "if query:" fails and

env['QUERY_STRING'] is remembered from last query.



Solution:

--- /usr/lib/python2.3/CGIHTTPServer.py 2003-09-07

15:33:41.000000000 +0200

+++ CGIHTTPServer.py    2003-09-07 15:36:27.000000000 +0200

@@ -147,8 +147,7 @@

         env['PATH_INFO'] = uqrest

         env['PATH_TRANSLATED'] =

self.translate_path(uqrest)

         env['SCRIPT_NAME'] = scriptname

-        if query:

-            env['QUERY_STRING'] = query

+        env['QUERY_STRING'] = query

         host = self.address_string()

         if host != self.client_address[0]:

             env['REMOTE_HOST'] = host







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

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

From noreply at sourceforge.net  Sun Sep  7 09:23:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 11:24:08 2003
Subject: [Python-bugs-list] [ python-Bugs-799428 ] tk_focusNext() fails
Message-ID: <E19w1OI-0000u8-00@sc8-sf-web4.sourceforge.net>

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

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Perry Greenfield (perrygreenfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: tk_focusNext() fails

Initial Comment:
Calls to the widget method tk_focusNext() fail with

"unsubscriptable object" error. Looking at the Tkinter.py 

code for the routine shows this statement:



name = self.tk.call('tk_focusNext', self._w)



(line 433)



which used to return a string in 2.2 but now returns

a "cmdName object". When this is passed to 

self._nametowidget(name), it fails when it tries to

subscript name (line 1006) since the object does

not support indexing. Perhaps str(name) or

name.string is more appropriate now? (when

that change is made, it works--well, I tested

name.string and that worked)



Perry Greenfield (perry@stsci.edu)

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

Comment By: Jeff Epler (jepler)
Date: 2003-09-07 10:23

Message:
Logged In: YES 
user_id=2772

Presumably, _nametowidget() should be modified to work properly with a "cmdName object", rather than modifying each site that gets a widget path from a tk command.  

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

Comment By: Perry Greenfield (perrygreenfield)
Date: 2003-09-03 08:29

Message:
Logged In: YES 
user_id=252130

Presumably the same problem exists with tk_focusPrev.

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

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

From noreply at sourceforge.net  Sun Sep  7 12:59:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 14:59:38 2003
Subject: [Python-bugs-list] [ python-Feature Requests-793802 ] class for
	function calls that are not thread safe
Message-ID: <E19w4l2-00014r-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #793802, was opened at 2003-08-23 18:02
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793802&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Elfring (elfring)
>Assigned to: Nobody/Anonymous (nobody)
Summary: class for function calls that are not thread safe

Initial Comment:
I would like that a class will be added to perform thread unsafe 
function or method calls in an easy way like I describe it in the 
request 
"https://sourceforge.net/mailarchive/forum.php?thread_id=1585197&forum_id=24972" 
for the TCL thread package.

The description 
"http://zthread.sourceforge.net/html/classZThread_1_1SynchronousExecutor.html" 
seems to come near what I want. But I think that there is a little bit 
missing.

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

Comment By: Markus Elfring (elfring)
Date: 2003-09-07 15:02

Message:
Logged In: YES 
user_id=572001

I am looking for a monitor implementation that has got the scope of a 
library or package and not a single synchronized method or block like it 
is in Java.

A function object will get this monitor as a parameter.

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

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

From noreply at sourceforge.net  Sun Sep  7 13:37:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 15:37:42 2003
Subject: [Python-bugs-list] [ python-Feature Requests-780602 ] No sleep or
	busy wait
Message-ID: <E19w5Ls-00043r-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #780602, was opened at 2003-07-31 02:14
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=780602&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean M. Brouwers (jbrouwers)
Assigned to: Nobody/Anonymous (nobody)
Summary: No sleep or busy wait

Initial Comment:
This is a request for three, related changes to file

Modules/_tkinter.c in Python 2.3, specifically to avoid

sleeping or busy waiting.





1) The main loop, function Tkapp_Mainloop(), includes a

now configurable sleep period which may cause

undesirable delays (in the threaded builds).  If no

Tcl/Tk event was handled, the main loop sleeps for 20

millisec (or whatever the value of

Tkinter_busywaitinterval* is).



Another, better way to achieve that would be to create

a timer event for in the main loop BEFORE calling the

Tcl/Tk event handler and call the Tcl/Tk event handler

with a zero argument to wait for an event**.



This produces the same idle period as the current

implementation.  The difference is that the main loop

(actually the Tcl/Tk event handler) stays awake instead

of going to sleep for the idle period.  Any events

occurring during the idle period will be handled

without delay.





2) In addition, only one event is handled per iteration

of the main loop, causing the state to be saved and

restored, locks to be acquired and releases, etc. many

times.



Instead handle not one event, but all pending events. 

After handling one event, all other pending events

should be handled as well by calling the Tcl/Tk event

handler again (with a TCL_DONT_WAIT argument) until

there are no more events.



The net result is that any pending events are handled

more quickly and with less overhead.





3) After the first change abiove, static function

Sleep() can be removed.  It is still needed in function

WaitForMainloop() but that call can be replaced by

Tcl_Sleep().  Tcl_Sleep() is equivalent to Sleep() and

it works on all platforms, not just those which have

select().



--------

*) The name Tkinter_busywaitinterval is a misnomer.  It

is not a busy wait but a non-buzy sleep, at least with

Tcl_Sleep().



**) There are a few more details to make this work

correctly and I have a version for _tkinter.c which

does implement these changes.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-07 21:37

Message:
Logged In: YES 
user_id=21627

1) The main-loop is inherently *busy*-wait, as the loop is

continuously polling for events. The interval between two of

these wait-for-event calls is then indeed a busywaitinterval.



2) Processing all events would mean that other threads

cannot invoke Tcl methods while there are pending requests.

This would be a change in behaviour, and might influence

responsiveness in a undesirable way.



3) Can you name a platform on which the current Sleep does

not work?

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

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

From noreply at sourceforge.net  Sun Sep  7 13:48:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 15:48:26 2003
Subject: [Python-bugs-list] [ python-Bugs-801992 ] cgi.CGIHTTPRequestHandler
	remembers QUERY_STRING
Message-ID: <E19w5WF-0002mk-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivo Danihelka (fidlej)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.CGIHTTPRequestHandler remembers QUERY_STRING

Initial Comment:
Python 2.3+, Debian SID:

cgi.CGIHTTPRequestHandler remembers QUERY_STRING from

last query.

If query is '', then condition "if query:" fails and

env['QUERY_STRING'] is remembered from last query.



Solution:

--- /usr/lib/python2.3/CGIHTTPServer.py 2003-09-07

15:33:41.000000000 +0200

+++ CGIHTTPServer.py    2003-09-07 15:36:27.000000000 +0200

@@ -147,8 +147,7 @@

         env['PATH_INFO'] = uqrest

         env['PATH_TRANSLATED'] =

self.translate_path(uqrest)

         env['SCRIPT_NAME'] = scriptname

-        if query:

-            env['QUERY_STRING'] = query

+        env['QUERY_STRING'] = query

         host = self.address_string()

         if host != self.client_address[0]:

             env['REMOTE_HOST'] = host







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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-07 21:48

Message:
Logged In: YES 
user_id=21627

I believe the bug lies elsewhere: If we have fork, we

shouldn't set the environment variables in the parent

process, but only in the child process.

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

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

From noreply at sourceforge.net  Sun Sep  7 14:44:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 16:44:19 2003
Subject: [Python-bugs-list] [ python-Bugs-800824 ] test_dumbdbm failing
Message-ID: <E19w6OM-0001RT-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Martin v. L?wis (loewis)
Summary: test_dumbdbm failing

Initial Comment:
Getting the following failures:



test_close_twice (__main__.DumbDBMTestCase) ... ok

test_dumbdbm_creation (__main__.DumbDBMTestCase) ... 

ok

test_dumbdbm_keys (__main__.DumbDBMTestCase) ... 

ERROR

test_dumbdbm_modification (__main__.DumbDBMTestCase) 

... ERROR

test_dumbdbm_read (__main__.DumbDBMTestCase) ... 

ERROR

test_random (__main__.DumbDBMTestCase) ... ERROR

test_write_write_read (__main__.DumbDBMTestCase) ... 

ERROR





They all error out with the same problem:



Traceback (most recent call last):

  File "Lib/test/test_dumbdbm.py", line 73, in 

test_write_write_read

    f = dumbdbm.open(_fname)

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

dumbdbm.py", line 232, in open

    return _Database(file, mode)

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

dumbdbm.py", line 73, in __init__

    self._update()

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

dumbdbm.py", line 84, in _update

    key, pos_and_siz_pair = eval(line)

TypeError: expected string without null bytes





test_whichdb is also failing for essentially the same reason 

although it is hidden under some executed code:



test_whichdb_dbm (__main__.WhichDBTestCase) ... ok

test_whichdb_dumbdbm (__main__.WhichDBTestCase) ... 

FAIL



=====================================

=================================

FAIL: test_whichdb_dumbdbm (__main__.WhichDBTestCase)

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

--

Traceback (most recent call last):

  File "Lib/test/test_whichdb.py", line 56, in 

test_whichdb_name

    self.assertEqual(name, whichdb.whichdb(_fname))

  File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/

unittest.py", line 292, in failUnlessEqual

    raise self.failureException, \

AssertionError: 'dumbdbm' != None





If I run the test by hand by copy-n-paste in the interpreter I 

get the same error as above about null bytes.



Now I compile with --enable-unicode=ucs4, if that has 

anything to do with it.



This is all on OS X 10.2.6 .

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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-07 22:44

Message:
Logged In: YES 
user_id=21627

This is now fixed in fileobject.c 2.183 and 2.179.8.2.



The bug was triggered by a bug in dumbdbm: the mode argument

does not actually define the file mode, but the buffer size...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-06 06:52

Message:
Logged In: YES 
user_id=80475

Martin, this appears to be caused by your recent patch to 

fileobject.c and fileobject.h.



FYI, it only fails when run with python_d.

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

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

From noreply at sourceforge.net  Sun Sep  7 14:46:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 16:46:07 2003
Subject: [Python-bugs-list] [ python-Bugs-802128 ] Mode argument of dumbdbm
	does not work
Message-ID: <E19w6Q8-0001Ue-00@sc8-sf-web1.sourceforge.net>

Bugs item #802128, was opened at 2003-09-07 22:46
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=802128&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L?wis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Mode argument of dumbdbm does not work

Initial Comment:
In dumbdbm.py 2.15, support for a mode argument was

added. However, this support does not work: The mode

argument is passed to __builtin__.open, which does not

support specification of a mode. Instead, the third

argument to that function specifies the buffer size.

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

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

From noreply at sourceforge.net  Sun Sep  7 16:48:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 18:48:14 2003
Subject: [Python-bugs-list] [ python-Feature Requests-780602 ] No sleep or
	busy wait
Message-ID: <E19w8K9-0005hx-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #780602, was opened at 2003-07-30 19:14
Message generated for change (Comment added) made by jbrouwers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=780602&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean M. Brouwers (jbrouwers)
Assigned to: Nobody/Anonymous (nobody)
Summary: No sleep or busy wait

Initial Comment:
This is a request for three, related changes to file

Modules/_tkinter.c in Python 2.3, specifically to avoid

sleeping or busy waiting.





1) The main loop, function Tkapp_Mainloop(), includes a

now configurable sleep period which may cause

undesirable delays (in the threaded builds).  If no

Tcl/Tk event was handled, the main loop sleeps for 20

millisec (or whatever the value of

Tkinter_busywaitinterval* is).



Another, better way to achieve that would be to create

a timer event for in the main loop BEFORE calling the

Tcl/Tk event handler and call the Tcl/Tk event handler

with a zero argument to wait for an event**.



This produces the same idle period as the current

implementation.  The difference is that the main loop

(actually the Tcl/Tk event handler) stays awake instead

of going to sleep for the idle period.  Any events

occurring during the idle period will be handled

without delay.





2) In addition, only one event is handled per iteration

of the main loop, causing the state to be saved and

restored, locks to be acquired and releases, etc. many

times.



Instead handle not one event, but all pending events. 

After handling one event, all other pending events

should be handled as well by calling the Tcl/Tk event

handler again (with a TCL_DONT_WAIT argument) until

there are no more events.



The net result is that any pending events are handled

more quickly and with less overhead.





3) After the first change abiove, static function

Sleep() can be removed.  It is still needed in function

WaitForMainloop() but that call can be replaced by

Tcl_Sleep().  Tcl_Sleep() is equivalent to Sleep() and

it works on all platforms, not just those which have

select().



--------

*) The name Tkinter_busywaitinterval is a misnomer.  It

is not a busy wait but a non-buzy sleep, at least with

Tcl_Sleep().



**) There are a few more details to make this work

correctly and I have a version for _tkinter.c which

does implement these changes.

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

>Comment By: Jean M. Brouwers (jbrouwers)
Date: 2003-09-07 17:48

Message:
Logged In: YES 
user_id=832557

No, I do not know of any platforms where the current Sleep()

implementation in Tkinter would not work.  That aside, I

believe that there are still two issues with using Sleep().



>From previous experience with Tcl/Tk (non-Python), I do know

that events tend to pile up in single-threaded, event driven

applications which use Tcl timer events.  In such

applications calls like Sleep() or Tcl_Sleep() should be

avoided entirely.  Using Tcl/Tk timer events is a far better

approach in this case, for reasons mentioned earlier.



I'm not familiar enough with Tkinter, multi-threading and

the impact of Sleep() in Python.  However, instead of using

Sleep(), what about yield() or some similar threading

function?  And compile that call only in the threaded Python

build?



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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-07 14:37

Message:
Logged In: YES 
user_id=21627

1) The main-loop is inherently *busy*-wait, as the loop is

continuously polling for events. The interval between two of

these wait-for-event calls is then indeed a busywaitinterval.



2) Processing all events would mean that other threads

cannot invoke Tcl methods while there are pending requests.

This would be a change in behaviour, and might influence

responsiveness in a undesirable way.



3) Can you name a platform on which the current Sleep does

not work?

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

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

From noreply at sourceforge.net  Sun Sep  7 17:17:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep  7 19:18:01 2003
Subject: [Python-bugs-list] [ python-Bugs-797853 ] Small problems with the
	csv module's documentation
Message-ID: <E19w8n0-00021R-00@sc8-sf-web4.sourceforge.net>

Bugs item #797853, was opened at 2003-08-30 13:07
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=797853&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Florent Rougon (frougon)
>Assigned to: Skip Montanaro (montanaro)
Summary: Small problems with the csv module's documentation

Initial Comment:
The csv module's documentation in python 2.3 has the

following (not

severe) problems:



1. http://www.python.org/doc/current/lib/node545.html

    ("Modules Contents")



    In addition to the problems mentioned in bug #792558

    (csv.DictReader parms inconsistent with docs),

there is a

    repetition and a typo in the doc for csv.DictReader:



      If the row read has fewer fields than the

fieldnames sequence, the

      value of restval will be used as the default

value. [...] If the

      row read has fewer fields than the fieldnames

sequence, the

      remaining keys take the value of the optiona

restval parameter



    (the typo is "optiona")



2.

http://www.python.org/doc/current/lib/csv-fmt-params.html

    ("Dialects and Formatting Parameters")



    The first paragraph contains:



      In addition to, or instead of, the dialect

parameter, the

      programmer can also specify individual formatting

parameters,

      which have the same names as the attributes

defined above for the

      Dialect class.



    but the "attributes defined above" are actually

defined below. Also,

    the documentation of the "quoting" paramteres contains:



      It can take on any of the QUOTE_* constants

defined below and

      defaults to QUOTE_MINIMAL.



    which is probably correct for text, DVI, PS and PDF

output formats

    but a bit confusing in the HTML output (and perhaps

Info, for the

    systems where it is generated--at least in Debian)

since the

    "QUOTE_* constants" are defined in another HTML

page (the "Modules

    Contents" page). I think a real cross-reference

(\ref or whatever it

    is with the python doc. document class) should be

introduced.



3. http://www.python.org/doc/current/lib/node547.html

   ("Reader Objects")



   The first sentence reads:



     Reader objects (DictReader instances and objects

returned by the

     reader()function) have the following public methods:



   where a space is missing between "reader()" and

"function".



4. The docs are not ideally explicit as for what types

of parameters are

   accepted by some functions, for instance the "row"

and "rows"

   parameters of writer objects in

   http://www.python.org/doc/current/lib/node548.html

("Writer

   Objects").



Thank you very much for your work on Python!



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-31 00:46

Message:
Logged In: YES 
user_id=80475

Okay, fixed the first three.

Leaving the last one for Skip or Andrew.

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

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

From noreply at sourceforge.net  Mon Sep  8 01:35:41 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  8 03:35:44 2003
Subject: [Python-bugs-list] [ python-Bugs-802302 ] Invalid documentation for
	dbhash.
Message-ID: <E19wGYn-0000Mv-00@sc8-sf-web4.sourceforge.net>

Bugs item #802302, was opened at 2003-09-08 03: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=802302&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid documentation for dbhash.

Initial Comment:
The documentation for dbhash is incorrect.  Using its *exact* 
example: 
 
functor% python 
Python 2.3+ (#2, Aug 10 2003, 11:33:47) 
[GCC 3.3.1 (Debian)] on linux2 
Type "help", "copyright", "credits" or "license" for more 
information. 
>>> import dbhash 
>>> db = dbhash.open('awaken.dbm', 'r') 
>>> k = db.first() 
>>> while k != None: 
...   print k 
...   k = db.next(k) 
... 
('U465', '(lp0\nS"Ulerin\'s"\np1\na.') 
Traceback (most recent call last): 
  File "<stdin>", line 3, in ? 
TypeError: next() takes exactly 1 argument (2 given) 
 
Whereas the documentation says: 
next(key) 
 Returns the key that follows key in the traversal. The following 
code prints every key in the database db, without having to create 
a list in memory that contains them all:  
 
k = db.first() 
while k != None: 
    print k 
    k = db.next(k) 
 
Also interesting is that this is apparently supposed to iterate 
through the keys, but it appears to be iterating through the items 
in general: notice the one key printed was ('U465', '(lp0\nS"Ulerin
\'s"\np1\na.'). 
 
Incidentally, it works with no argument to .next, but errors at 
some point: 
 
>>> import dbhash 
>>> db = dbhash.open('awaken.dbm', 'r') 
>>> k = db.first() 
>>> fd = file('/dev/null', 'w') 
>>> while k != None: 
...   print >>fd, k 
...   k = db.next() 
... 
Traceback (most recent call last): 
  File "<stdin>", line 3, in ? 
  File "/usr/lib/python2.3/bsddb/__init__.py", line 122, in next 
    rv = self.dbc.next() 
_bsddb.DBNotFoundError: (-30991, 'DB_NOTFOUND: No 
matching key/data pair found') 
 
This is before finishing the iteration through the database.  But 
this is probably a different bug report; I want to make sure I'm not 
misunderstanding something first.  

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

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

From noreply at sourceforge.net  Mon Sep  8 01:52:56 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  8 03:52:59 2003
Subject: [Python-bugs-list] [ python-Bugs-802310 ] tkFont may reuse font
	names
Message-ID: <E19wGpU-0002ql-00@sc8-sf-web1.sourceforge.net>

Bugs item #802310, was opened at 2003-09-08 09: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=802310&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Fredrik Lundh (effbot)
Assigned to: Nobody/Anonymous (nobody)
Summary: tkFont may reuse font names

Initial Comment:
(sent to me instead of to the bug manager; note that 

the tkFont naming approach is also used for widgets and 

callbacks /F)



The class tkFont has a problem name it chooses if no 

name is

given. The choosen method 'name = "font" + str(id

(self))' isn't safe

because the name may exists longer than the Font 

object and so another

Font object may be created with a different font but the 

same

id() and so the same name. id() says



    Return the identity of an object.  This is guaranteed 

to be unique

    among simultaneously existing objects.

          ^^^^^^^^^^^^^^^^^^^^^^^



Note that this bug doesn't strike if you hold a reference 

to the Font

object and so the GC can't reclaim the space.



To reproduce run the attached program. It produces 

something like:



previously: ('Times', 15, 'bold')

now: ('Times', 18, 'bold')

iterations: 8

mapping: {'font136494612': ('Times', 

14, 'bold'), 'font136499772': ('Times', 

15, 'bold'), 'font136545468': ('Times', 

17, 'bold'), 'font136483156': ('Times', 

11, 'bold'), 'font136502700': ('Times', 

12, 'bold'), 'font136510460': ('Times', 

13, 'bold'), 'font136515228': ('Times', 

16, 'bold'), 'font136365348': ('Times', 10, 'bold')}

Traceback (most recent call last):

  File "tkfont_bug.py", line 20, in ?

    assert 0

AssertionError



Raimar



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

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

From noreply at sourceforge.net  Mon Sep  8 06:10:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  8 08:10:48 2003
Subject: [Python-bugs-list] [ python-Bugs-802417 ] Bogus use of
	Tkinter.PhotoImage can give sig11
Message-ID: <E19wKqy-0005Eg-00@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bogus use of Tkinter.PhotoImage can give sig11

Initial Comment:
Running the following script can cause a signal11 (the

script is invalid, but presumably should result only in

a traceback, not a sig11):

from Tkinter import *

t = Tk()

i = PhotoImage(t)

print "here"



The signal 11 happens before the print statement is

reached.



My system is RedHat9, tcl/tk 8.3.5, Python 2.2.2 (also

observed on 2.3b1)



This may be a tk bug (thus unfixable in

Python/Tkinter), because the following sequence kills wish:

% image create photo . 

Illegal instruction



The traceback looks like this:

(gdb) run tkinter-image-bug.py 

Starting program: /usr/local/bin/python

tkinter-image-bug.py

[New Thread 1074993152 (LWP 30584)]



Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 1074993152 (LWP 30584)]

0x082b4518 in ?? ()

(gdb) where

#0  0x082b4518 in ?? ()

#1  0x405cc169 in Tk_DeleteImage () from

/usr/lib/libtk8.3.so

#2  0x405cb77d in Tk_ImageObjCmd () from

/usr/lib/libtk8.3.so

#3  0x4065e517 in TclExpandTokenArray () from

/usr/lib/libtcl8.3.so

#4  0x4065e638 in Tcl_EvalObjv () from

/usr/lib/libtcl8.3.so

#5  0x4047016c in Tkapp_Call (_self=0x81e7528,

args=0x81d634c) at

/usr/src/Python-2.3b1/Modules/_tkinter.c:1292

#6  0x080f4bcc in PyCFunction_Call (func=0x81e674c,

arg=0x81d634c, kw=0x82afb20) at Objects/methodobject.c:108

#7  0x080a5ea5 in call_function (pp_stack=0xbfffeaec,

oparg=137053208) at Python/ceval.c:3416

#8  0x080a4494 in eval_frame (f=0x819b4bc) at

Python/ceval.c:2093

#9  0x080a4f0c in PyEval_EvalCodeEx (co=0x826b120,

globals=0x82b4418, locals=0x0, args=0x81cfd28,

argcount=5, kws=0x82c6780, kwcount=0, defs=0x8272b50,

defcount=3, closure=0x0) at Python/ceval.c:2640

#10 0x080f4821 in function_call (func=0x827f064,

arg=0x81cfd1c, kw=0x827edfc) at Objects/funcobject.c:501

#11 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81cfd1c, kw=0x827edfc) at Objects/abstract.c:1755

#12 0x08062c7c in instancemethod_call (func=0x827f064,

arg=0x81cfd1c, kw=0x827edfc) at Objects/classobject.c:2432

#13 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81cfd1c, kw=0x827edfc) at Objects/abstract.c:1755

#14 0x080a6301 in ext_do_call (func=0x81d643c,

pp_stack=0xbfffeeec, flags=0, na=5, nk=0) at

Python/ceval.c:3690

#15 0x080a4883 in eval_frame (f=0x81a6d3c) at

Python/ceval.c:2128

#16 0x080a4f0c in PyEval_EvalCodeEx (co=0x826b4a0,

globals=0x81cfd1c, locals=0x0, args=0x81a6e88,

argcount=2, kws=0x0, kwcount=0, defs=0x8272b78,

defcount=3, closure=0x0) at Python/ceval.c:2640

#17 0x080f4821 in function_call (func=0x827f25c,

arg=0x81f158c, kw=0x0) at Objects/funcobject.c:501

#18 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81f158c, kw=0x0) at Objects/abstract.c:1755

#19 0x08062c7c in instancemethod_call (func=0x827f25c,

arg=0x81f158c, kw=0x0) at Objects/classobject.c:2432

#20 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81d2e0c, kw=0x0) at Objects/abstract.c:1755

#21 0x080a5c3f in PyEval_CallObjectWithKeywords

(func=0x81d1fcc, arg=0x81d2e0c, kw=0x0) at

Python/ceval.c:3323

#22 0x0805da9d in PyInstance_New (klass=0x82745fc,

arg=0x81d2e0c, kw=0x0) at Objects/classobject.c:575

#23 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81d2e0c, kw=0x0) at Objects/abstract.c:1755

#24 0x080a606b in do_call (func=0x82745fc,

pp_stack=0xbffff37c, na=1, nk=136130060) at

Python/ceval.c:3621

#25 0x080a5d27 in call_function (pp_stack=0xbffff37c,

oparg=136130060) at Python/ceval.c:3437

#26 0x080a4494 in eval_frame (f=0x820c164) at

Python/ceval.c:2093

#27 0x080a4f0c in PyEval_EvalCodeEx (co=0x81c7f20,

globals=0x81d2e0c, locals=0x815079c, args=0x0,

argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,

closure=0x0) at Python/ceval.c:2640

#28 0x080a742e in PyEval_EvalCode (co=0x81c7f20,

globals=0x815079c, locals=0x815079c) at Python/ceval.c:537

#29 0x080cc185 in run_node (n=0x8138410,

filename=0xbffffb7d "tkinter-image-bug.py",

globals=0x815079c, locals=0x815079c, flags=0xbffff4d8)

at Python/pythonrun.c:1173

#30 0x080cba41 in PyRun_SimpleFileExFlags

(fp=0x8136f48, filename=0xbffffb7d

"tkinter-image-bug.py", closeit=1, flags=0xbffff4d8) at

Python/pythonrun.c:770

#31 0x0805599c in Py_Main (argc=0, argv=0xbffff554) at

Modules/main.c:417

#32 0x0805554e in main (argc=2, argv=0xbffff554) at

Modules/python.c:26

#33 0x420156a4 in __libc_start_main () from

/lib/tls/libc.so.6



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

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

From noreply at sourceforge.net  Mon Sep  8 06:11:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  8 08:11:13 2003
Subject: [Python-bugs-list] [ python-Bugs-802417 ] Bogus use of
	Tkinter.PhotoImage can give sig11
Message-ID: <E19wKrM-0005G7-00@sc8-sf-web3.sourceforge.net>

Bugs item #802417, was opened at 2003-09-08 07:10
Message generated for change (Settings changed) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802417&group_id=5470

>Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bogus use of Tkinter.PhotoImage can give sig11

Initial Comment:
Running the following script can cause a signal11 (the

script is invalid, but presumably should result only in

a traceback, not a sig11):

from Tkinter import *

t = Tk()

i = PhotoImage(t)

print "here"



The signal 11 happens before the print statement is

reached.



My system is RedHat9, tcl/tk 8.3.5, Python 2.2.2 (also

observed on 2.3b1)



This may be a tk bug (thus unfixable in

Python/Tkinter), because the following sequence kills wish:

% image create photo . 

Illegal instruction



The traceback looks like this:

(gdb) run tkinter-image-bug.py 

Starting program: /usr/local/bin/python

tkinter-image-bug.py

[New Thread 1074993152 (LWP 30584)]



Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 1074993152 (LWP 30584)]

0x082b4518 in ?? ()

(gdb) where

#0  0x082b4518 in ?? ()

#1  0x405cc169 in Tk_DeleteImage () from

/usr/lib/libtk8.3.so

#2  0x405cb77d in Tk_ImageObjCmd () from

/usr/lib/libtk8.3.so

#3  0x4065e517 in TclExpandTokenArray () from

/usr/lib/libtcl8.3.so

#4  0x4065e638 in Tcl_EvalObjv () from

/usr/lib/libtcl8.3.so

#5  0x4047016c in Tkapp_Call (_self=0x81e7528,

args=0x81d634c) at

/usr/src/Python-2.3b1/Modules/_tkinter.c:1292

#6  0x080f4bcc in PyCFunction_Call (func=0x81e674c,

arg=0x81d634c, kw=0x82afb20) at Objects/methodobject.c:108

#7  0x080a5ea5 in call_function (pp_stack=0xbfffeaec,

oparg=137053208) at Python/ceval.c:3416

#8  0x080a4494 in eval_frame (f=0x819b4bc) at

Python/ceval.c:2093

#9  0x080a4f0c in PyEval_EvalCodeEx (co=0x826b120,

globals=0x82b4418, locals=0x0, args=0x81cfd28,

argcount=5, kws=0x82c6780, kwcount=0, defs=0x8272b50,

defcount=3, closure=0x0) at Python/ceval.c:2640

#10 0x080f4821 in function_call (func=0x827f064,

arg=0x81cfd1c, kw=0x827edfc) at Objects/funcobject.c:501

#11 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81cfd1c, kw=0x827edfc) at Objects/abstract.c:1755

#12 0x08062c7c in instancemethod_call (func=0x827f064,

arg=0x81cfd1c, kw=0x827edfc) at Objects/classobject.c:2432

#13 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81cfd1c, kw=0x827edfc) at Objects/abstract.c:1755

#14 0x080a6301 in ext_do_call (func=0x81d643c,

pp_stack=0xbfffeeec, flags=0, na=5, nk=0) at

Python/ceval.c:3690

#15 0x080a4883 in eval_frame (f=0x81a6d3c) at

Python/ceval.c:2128

#16 0x080a4f0c in PyEval_EvalCodeEx (co=0x826b4a0,

globals=0x81cfd1c, locals=0x0, args=0x81a6e88,

argcount=2, kws=0x0, kwcount=0, defs=0x8272b78,

defcount=3, closure=0x0) at Python/ceval.c:2640

#17 0x080f4821 in function_call (func=0x827f25c,

arg=0x81f158c, kw=0x0) at Objects/funcobject.c:501

#18 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81f158c, kw=0x0) at Objects/abstract.c:1755

#19 0x08062c7c in instancemethod_call (func=0x827f25c,

arg=0x81f158c, kw=0x0) at Objects/classobject.c:2432

#20 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81d2e0c, kw=0x0) at Objects/abstract.c:1755

#21 0x080a5c3f in PyEval_CallObjectWithKeywords

(func=0x81d1fcc, arg=0x81d2e0c, kw=0x0) at

Python/ceval.c:3323

#22 0x0805da9d in PyInstance_New (klass=0x82745fc,

arg=0x81d2e0c, kw=0x0) at Objects/classobject.c:575

#23 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81d2e0c, kw=0x0) at Objects/abstract.c:1755

#24 0x080a606b in do_call (func=0x82745fc,

pp_stack=0xbffff37c, na=1, nk=136130060) at

Python/ceval.c:3621

#25 0x080a5d27 in call_function (pp_stack=0xbffff37c,

oparg=136130060) at Python/ceval.c:3437

#26 0x080a4494 in eval_frame (f=0x820c164) at

Python/ceval.c:2093

#27 0x080a4f0c in PyEval_EvalCodeEx (co=0x81c7f20,

globals=0x81d2e0c, locals=0x815079c, args=0x0,

argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,

closure=0x0) at Python/ceval.c:2640

#28 0x080a742e in PyEval_EvalCode (co=0x81c7f20,

globals=0x815079c, locals=0x815079c) at Python/ceval.c:537

#29 0x080cc185 in run_node (n=0x8138410,

filename=0xbffffb7d "tkinter-image-bug.py",

globals=0x815079c, locals=0x815079c, flags=0xbffff4d8)

at Python/pythonrun.c:1173

#30 0x080cba41 in PyRun_SimpleFileExFlags

(fp=0x8136f48, filename=0xbffffb7d

"tkinter-image-bug.py", closeit=1, flags=0xbffff4d8) at

Python/pythonrun.c:770

#31 0x0805599c in Py_Main (argc=0, argv=0xbffff554) at

Modules/main.c:417

#32 0x0805554e in main (argc=2, argv=0xbffff554) at

Modules/python.c:26

#33 0x420156a4 in __libc_start_main () from

/lib/tls/libc.so.6



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

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

From noreply at sourceforge.net  Mon Sep  8 12:12:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  8 14:12:52 2003
Subject: [Python-bugs-list] [ python-Bugs-802417 ] Bogus use of
	Tkinter.PhotoImage can give sig11
Message-ID: <E19wQVJ-00005H-00@sc8-sf-web3.sourceforge.net>

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

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bogus use of Tkinter.PhotoImage can give sig11

Initial Comment:
Running the following script can cause a signal11 (the

script is invalid, but presumably should result only in

a traceback, not a sig11):

from Tkinter import *

t = Tk()

i = PhotoImage(t)

print "here"



The signal 11 happens before the print statement is

reached.



My system is RedHat9, tcl/tk 8.3.5, Python 2.2.2 (also

observed on 2.3b1)



This may be a tk bug (thus unfixable in

Python/Tkinter), because the following sequence kills wish:

% image create photo . 

Illegal instruction



The traceback looks like this:

(gdb) run tkinter-image-bug.py 

Starting program: /usr/local/bin/python

tkinter-image-bug.py

[New Thread 1074993152 (LWP 30584)]



Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 1074993152 (LWP 30584)]

0x082b4518 in ?? ()

(gdb) where

#0  0x082b4518 in ?? ()

#1  0x405cc169 in Tk_DeleteImage () from

/usr/lib/libtk8.3.so

#2  0x405cb77d in Tk_ImageObjCmd () from

/usr/lib/libtk8.3.so

#3  0x4065e517 in TclExpandTokenArray () from

/usr/lib/libtcl8.3.so

#4  0x4065e638 in Tcl_EvalObjv () from

/usr/lib/libtcl8.3.so

#5  0x4047016c in Tkapp_Call (_self=0x81e7528,

args=0x81d634c) at

/usr/src/Python-2.3b1/Modules/_tkinter.c:1292

#6  0x080f4bcc in PyCFunction_Call (func=0x81e674c,

arg=0x81d634c, kw=0x82afb20) at Objects/methodobject.c:108

#7  0x080a5ea5 in call_function (pp_stack=0xbfffeaec,

oparg=137053208) at Python/ceval.c:3416

#8  0x080a4494 in eval_frame (f=0x819b4bc) at

Python/ceval.c:2093

#9  0x080a4f0c in PyEval_EvalCodeEx (co=0x826b120,

globals=0x82b4418, locals=0x0, args=0x81cfd28,

argcount=5, kws=0x82c6780, kwcount=0, defs=0x8272b50,

defcount=3, closure=0x0) at Python/ceval.c:2640

#10 0x080f4821 in function_call (func=0x827f064,

arg=0x81cfd1c, kw=0x827edfc) at Objects/funcobject.c:501

#11 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81cfd1c, kw=0x827edfc) at Objects/abstract.c:1755

#12 0x08062c7c in instancemethod_call (func=0x827f064,

arg=0x81cfd1c, kw=0x827edfc) at Objects/classobject.c:2432

#13 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81cfd1c, kw=0x827edfc) at Objects/abstract.c:1755

#14 0x080a6301 in ext_do_call (func=0x81d643c,

pp_stack=0xbfffeeec, flags=0, na=5, nk=0) at

Python/ceval.c:3690

#15 0x080a4883 in eval_frame (f=0x81a6d3c) at

Python/ceval.c:2128

#16 0x080a4f0c in PyEval_EvalCodeEx (co=0x826b4a0,

globals=0x81cfd1c, locals=0x0, args=0x81a6e88,

argcount=2, kws=0x0, kwcount=0, defs=0x8272b78,

defcount=3, closure=0x0) at Python/ceval.c:2640

#17 0x080f4821 in function_call (func=0x827f25c,

arg=0x81f158c, kw=0x0) at Objects/funcobject.c:501

#18 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81f158c, kw=0x0) at Objects/abstract.c:1755

#19 0x08062c7c in instancemethod_call (func=0x827f25c,

arg=0x81f158c, kw=0x0) at Objects/classobject.c:2432

#20 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81d2e0c, kw=0x0) at Objects/abstract.c:1755

#21 0x080a5c3f in PyEval_CallObjectWithKeywords

(func=0x81d1fcc, arg=0x81d2e0c, kw=0x0) at

Python/ceval.c:3323

#22 0x0805da9d in PyInstance_New (klass=0x82745fc,

arg=0x81d2e0c, kw=0x0) at Objects/classobject.c:575

#23 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81d2e0c, kw=0x0) at Objects/abstract.c:1755

#24 0x080a606b in do_call (func=0x82745fc,

pp_stack=0xbffff37c, na=1, nk=136130060) at

Python/ceval.c:3621

#25 0x080a5d27 in call_function (pp_stack=0xbffff37c,

oparg=136130060) at Python/ceval.c:3437

#26 0x080a4494 in eval_frame (f=0x820c164) at

Python/ceval.c:2093

#27 0x080a4f0c in PyEval_EvalCodeEx (co=0x81c7f20,

globals=0x81d2e0c, locals=0x815079c, args=0x0,

argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,

closure=0x0) at Python/ceval.c:2640

#28 0x080a742e in PyEval_EvalCode (co=0x81c7f20,

globals=0x815079c, locals=0x815079c) at Python/ceval.c:537

#29 0x080cc185 in run_node (n=0x8138410,

filename=0xbffffb7d "tkinter-image-bug.py",

globals=0x815079c, locals=0x815079c, flags=0xbffff4d8)

at Python/pythonrun.c:1173

#30 0x080cba41 in PyRun_SimpleFileExFlags

(fp=0x8136f48, filename=0xbffffb7d

"tkinter-image-bug.py", closeit=1, flags=0xbffff4d8) at

Python/pythonrun.c:770

#31 0x0805599c in Py_Main (argc=0, argv=0xbffff554) at

Modules/main.c:417

#32 0x0805554e in main (argc=2, argv=0xbffff554) at

Modules/python.c:26

#33 0x420156a4 in __libc_start_main () from

/lib/tls/libc.so.6



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

Comment By: Jeffrey Hobbs (hobbs)
Date: 2003-09-08 11:12

Message:
Logged In: YES 
user_id=72656

This bug is already corrected in Tk 8.4.

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

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

From noreply at sourceforge.net  Mon Sep  8 14:00:33 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep  8 16:00:37 2003
Subject: [Python-bugs-list] [ python-Bugs-791542 ] test_threading
Message-ID: <E19wSBd-0007Ym-00@sc8-sf-web2.sourceforge.net>

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

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Shawn Leard (sleard1)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_threading

Initial Comment:


Due the problems reported with version 2.3 I thought I

would give version 2.2.3 a shot. The problem I am

having here is no matter what switches I pass configure

to disable threading it still tries to test them and as

a result the make test fails.



168 tests OK.

1 test failed:

    test_threading

24 tests skipped:

    test_al test_asynchat test_bsddb test_cd test_cl

test_curses

    test_dl test_email_codecs test_fork1 test_gl

test_imgfile

    test_linuxaudiodev test_minidom test_openpty

test_pyexpat

    test_queue test_sax test_socket_ssl

test_socketserver test_thread

    test_threaded_import test_threadedtempfile test_winreg

    test_winsound



--------



./configure --prefix=/usr/local --with-gnu-ld

--with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld

--enable-nls   --with-included-gettext --with-fpectl

--with-threads=no --without-threads --disable-threads

--with-gnu-as



--------



mars$ /files/local/src/Python-2.2.3/python

test_threading.py

Traceback (most recent call last):

  File "test_threading.py", line 7, in ?

    import threading

  File

"/files/local/src/Python-2.2.3/Lib/threading.py", line

5, in ?

    import thread

ImportError: No module named thread



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

>Comment By: Shawn Leard (sleard1)
Date: 2003-09-08 16:00

Message:
Logged In: YES 
user_id=328879





I will give this a shot and get back to you.





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

Comment By: Brett Cannon (bcannon)
Date: 2003-09-04 21:53

Message:
Logged In: YES 
user_id=357491

In order to better debug this, can you state what the line says 

when test_threading fails; e.g., "test_sunaudiodev skipped -- ..."?



The test will be run regardless of whether you compiled with 

threads or not, but it should be listed as a skip instead of a 

failure.

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

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

From noreply at sourceforge.net  Mon Sep  8 19:14:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 02:35:50 2003
Subject: [Python-bugs-list] [ python-Bugs-560286 ] Add docs for 'basestring'
Message-ID: <E19wX59-0004AC-00@sc8-sf-web2.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add docs for 'basestring'

Initial Comment:
Please document the new built-in abstract type

'string'.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 20:23

Message:
Logged In: YES 
user_id=33168

Updated summary, since string was changed to basestring.

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

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

From noreply at sourceforge.net  Mon Sep  8 19:59:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 02:43:22 2003
Subject: [Python-bugs-list] [ python-Bugs-792649 ] RESET_ERROR is not
	defined(logging module)
Message-ID: <E19wXmt-0005st-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: RESET_ERROR is not defined(logging module)

Initial Comment:
ConfigStreamHandler class(logging/config.py) has the 

following code in its handle method:



    except socket.error, e:

        if type(e.args) != types.TupleType:

            raise

        else:

            errcode = e.args[0]

            if errcode != RESET_ERROR:

                raise



However, RESET_ERROR is not defined.

So if the handle method catches socket.error, this will 

raise NameError.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-08 20:59

Message:
Logged In: YES 
user_id=80475

Guido, do you know what Vinay intended here?



I'm guessing it is errno.ECONNRESET but am not sure which 

of the many reset error numbers he intended to catch and 

ignore.



I emailed him but have not gotten a reply.

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

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

From noreply at sourceforge.net  Mon Sep  8 19:32:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 02:43:33 2003
Subject: [Python-bugs-list] [ python-Bugs-801306 ] Bad RE in scanf example
Message-ID: <E19wXND-0006A0-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jimm Domingo (jimm_domingo)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Bad RE in scanf example

Initial Comment:
In section 4.2.6 "Examples" of the Python Library

Reference, the regular expression for scanf format

tokens %e, %E, %f, %g does not allow an optional sign

in the exponent.  The RE should be:



  [-+]?(\d+(\.\d*)?|\d*\.\d+)([eE][-+]?\d+)?



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-08 20:32

Message:
Logged In: YES 
user_id=80475

Fixed.

Thanks for the report.

And, Brett, thanks for the confirmation.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 16:10

Message:
Logged In: YES 
user_id=357491

Double-checking with K&R, Jimm is right and regex looks good to 

me.  Hope that helps in some way, Raymond.

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

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

From noreply at sourceforge.net  Tue Sep  9 08:12:27 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 10:13:43 2003
Subject: [Python-bugs-list] [ python-Bugs-764447 ] cvs update warnings
Message-ID: <E19wjEJ-0003QJ-00@sc8-sf-web2.sourceforge.net>

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

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Just van Rossum (jvr)
Summary: cvs update warnings

Initial Comment:
On Windows, when you do "cvs update" in the "Mac/IDE

scripts" directory, you get the following warnings

(example uses Cygwin, but it also happens with other

CVS clients):



$ cd "Mac/IDE scripts"; cvs update

? Hold option to open a script

? Insert file name

? Insert folder name

? Search Python Documentation

? Hack/Remove .pyc files

? Hack/Toolbox Assistant

cvs server: Updating .

cvs server: Updating Hack

cvs server: Updating Widget demos

$



This is due to the fact that Windows can't deal with

periods at the end of file names.  All files giving

warnings end in "...".  These periods are removed when

the files get created, and so CVS sees the files

without periods and complains about them.



At one level the solution is simple: rename those

files.  At another level, I don't know what the

consequences are for the Mac, so assigning to Just

(Jack doesn't seem to want to deal with this :-)



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

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-09-09 16:12

Message:
Logged In: YES 
user_id=43607

It's now past 2.3 final, so can you look into this again?

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-07-02 12:36

Message:
Logged In: YES 
user_id=43607

I've lived with this for years.  A few more weeks won't matter.

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

Comment By: Just van Rossum (jvr)
Date: 2003-07-02 11:33

Message:
Logged In: YES 
user_id=92689

Any objections to postponing this to after 2.3 final? The thing is, 

currently these file names map to menu items directly, and to fix 

this I have to build a way to specify the menu item from within 

the file. This will cause way more changes than I'm comfortable 

with, just before 2.3. Removing the spaces from folder names can 

be done at the same time.

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

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

From noreply at sourceforge.net  Tue Sep  9 08:15:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 10:15:52 2003
Subject: [Python-bugs-list] [ python-Bugs-788183 ] build fails on Tru64 Unix
	(osf1V5)
Message-ID: <E19wjHB-0005J3-00@sc8-sf-web1.sourceforge.net>

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

Category: Build
Group: 3rd Party
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: build fails on Tru64 Unix (osf1V5)

Initial Comment:
the build on an alpha (Tru64 Unix) machine fails when

compiling Modules/posixModule.c; it complains about

stat and lstat, which HP has defined as _F64_stat and

_F64_lstat. HP claims that they automatically convert

them to stat and lstat for portability but my guess is

that the Python #define STAT code overrides this and so

it fails. Changing it to expliciltly reference

_F64_stat and _F64_lstat solves the problem. In the

same module, plock() and unsetenv() are referenced but

neither are found in the include files on the box.

Setting the HAVE_PLOCk and HAVE_UNSETENV macros

properly solves this problem (why didn't configure

detect this?)



Finally, once everything is done, distutils does not

include -lpthread in the list of libraries needed for link.



If you have any questions about these issues, let me know.

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

>Comment By: Anthony Tuininga (atuining)
Date: 2003-09-09 08:15

Message:
Logged In: YES 
user_id=619560

Confirmed. I was using gcc 3.0.2 and I upgraded to gcc 3.3.1

and the problems went away.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-06 08:58

Message:
Logged In: YES 
user_id=21627

See http://python.org/sf/524600

You are probably using gcc, and this is a compiler bug.

Closing it as third-party. I believe a newer gcc version

should fix this; if not, you should use the system compiler.

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

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

From noreply at sourceforge.net  Tue Sep  9 14:31:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 16:31:32 2003
Subject: [Python-bugs-list] [ python-Bugs-803413 ] uu.decode prints to stderr
Message-ID: <E19wp94-00086g-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sami Hangaslammi (shang)
Assigned to: Nobody/Anonymous (nobody)
Summary: uu.decode prints to stderr

Initial Comment:


Python 2.3 final



The standard library function uu.decode prints a

warning message to stderr if there is an error when

decoding the file. This feels like an incorrect

behaviour for a library function.



The warning message can be supressed by providing a

quiet=True parameter, but this is not currently documented.



The relevant line in uu.py is 138

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

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

From noreply at sourceforge.net  Tue Sep  9 14:53:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 16:53:17 2003
Subject: [Python-bugs-list] [ python-Bugs-803422 ] sgmllib doesn't support
	hex or Unicode character references
Message-ID: <E19wpUA-000873-00@sc8-sf-web4.sourceforge.net>

Bugs item #803422, was opened at 2003-09-09 15: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=803422&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib doesn't support hex or Unicode character references

Initial Comment:
sgmllib doesn't support the hexadecimal style of character nor 

Unicode characters, both of which are commonly seen on web pages. 

The following replacements fix both problems.



charref = re.compile('&#([0-9a-fA-F]+)[^0-9a-fA-F]')



	def handle_charref(self, ref):

		try:

			if ref[0] == 'x' or ref[0] == 'X': m = 

int(ref[1:], 16)

			else: m = int(ref)

			self.handle_data(unichr(m).encode('utf-8'))

		except ValueError:

			self.unknown_charref(ref)



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

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

From noreply at sourceforge.net  Tue Sep  9 14:56:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 16:56:17 2003
Subject: [Python-bugs-list] [ python-Bugs-655802 ] cPickle not always same
	as pickle
Message-ID: <E19wpX4-0002W0-00@sc8-sf-web1.sourceforge.net>

Bugs item #655802, was opened at 2002-12-18 10:23
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655802&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick K. O'Brien (pobrien)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cPickle not always same as pickle

Initial Comment:
Please see the previous bug report for background 
details: 
 
[ python-Bugs-654866 ] pickle and cPickle not 
equivalent 
 
The basic problem is that in certain rather rare (but not 
*that* rare either, imo) situations cPickle produces a 
pickle file that cannot reconstruct the same class 
instance identities as the pickle file produced by pickle. 
In addition, this appears to be true about pickling 
old-style class instances, but not pickling new-style 
class instances. So changing a class from old-style to 
new-style can change what gets pickled by cPickle. 
 
Here are items from the current docs that are candidates 
for clarification. My commentary appears within brackets: 
 
The data streams the two modules produce are 
guaranteed to be interchangeable. [Depends on the 
definition of interchangeable. I'd like to see something 
about reconstructability as well.] 
 
The pickle module keeps track of the objects it has 
already serialized, so that later references to the same 
object won't be serialized again. [Not true for cPickle, 
which apparently only keeps track if the refcount > 1. 
Note that this statement has never been true about 
instances of simple object types, like int and string.] 
 
If the same object is pickled by multiple dump() calls, the 
load() will all yield references to the same object. 
[Depends on whether you consider an object pickled as 
part of a container, and later pickled independently, as 
pickling the same object. If you expect that load() will 
yield references to the same object (and why wouldn't 
you, right? But that's why I'm disturbed by this.) then you 
need to be aware of the situations in which cPickle 
decides not to keep track.] 
 
The pickle data stream produced by pickle and cPickle 
are identical, so it is possible to use pickle and cPickle 
interchangeably with existing pickles. [This statement is 
part true and part false. The pickle data streams are not 
identical - they are often cosmetically different and 
occassionally substantially different. And this isn't really 
the reason the data streams are interchangeable. That 
has to do with the structure of the data stream, not the 
content of the data stream. We need to make it clear that 
the content isn't guaranteed to be identical, even though 
the structure of existing pickles can be read by either 
pickle or cPickle.] 
 
There are additional minor differences in API between 
cPickle and pickle, however for most applications, they 
are interchangable. More documentation is provided in 
the pickle module documentation, which includes a list of 
the documented differences. [Applications that care 
about object identity will want to be aware of the 
limitation of the cPickle memoization capability and how it 
differs from the pickle version.] 
 
Footnotes 
 
... pickles3.13  
Since the pickle data format is actually a tiny 
stack-oriented programming language, and some freedom 
is taken in the encodings of certain objects, it is possible 
that the two modules produce different data streams for 
the same input objects. However it is guaranteed that 
they will always be able to read each other's data 
streams. [Again, readability is not good enough for 
applications that expect object reconstuction 
equivalence.] 
 

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

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

From noreply at sourceforge.net  Tue Sep  9 15:00:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 17:00:26 2003
Subject: [Python-bugs-list] [ python-Bugs-779976 ] docs missing 'trace'
	module
Message-ID: <E19wpam-0001iy-00@sc8-sf-web3.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
>Assigned to: Jeremy Hylton (jhylton)
Summary: docs missing 'trace' module

Initial Comment:
The 'trace' module is new in Python 2.3.  There is no 

mention of it in the module listing at http://www.python.org/

doc/2.3/modindex.html nor is it documented in the 

"undocumented modules" chapter at http://www.python.org/

doc/2.3/lib/undoc.html .



(You would think as one of the coauthors for that module 

that I could be of help, but it's been about 4 years since I 

looked at it.  :)



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-09 17:00

Message:
Logged In: YES 
user_id=3066

Jeremy made this a module, so he's volunteered to write the

LaTeX docs.

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

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

From noreply at sourceforge.net  Tue Sep  9 15:00:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 17:00:44 2003
Subject: [Python-bugs-list] [ python-Bugs-803422 ] sgmllib doesn't support
	hex or Unicode character references
Message-ID: <E19wpbG-0002lr-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib doesn't support hex or Unicode character references

Initial Comment:
sgmllib doesn't support the hexadecimal style of character nor 

Unicode characters, both of which are commonly seen on web pages. 

The following replacements fix both problems.



charref = re.compile('&#([0-9a-fA-F]+)[^0-9a-fA-F]')



	def handle_charref(self, ref):

		try:

			if ref[0] == 'x' or ref[0] == 'X': m = 

int(ref[1:], 16)

			else: m = int(ref)

			self.handle_data(unichr(m).encode('utf-8'))

		except ValueError:

			self.unknown_charref(ref)



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

>Comment By: Aaron Swartz (aaronsw)
Date: 2003-09-09 16:00

Message:
Logged In: YES 
user_id=122141

Oops, that should be: 



charref = re.compile('&#([0-9a-fA-FxX][0-9a-fA-F]*)[^0-9a-fA-F]')

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

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

From noreply at sourceforge.net  Tue Sep  9 17:34:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 19:34:45 2003
Subject: [Python-bugs-list] [ python-Bugs-803498 ] plat-mac/applesingle.py
	needs cosmetic changes
Message-ID: <E19ws0N-00074d-00@sc8-sf-web4.sourceforge.net>

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

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: plat-mac/applesingle.py needs cosmetic changes

Initial Comment:
1)  it uses a string exception

2)  it has a warning every time you use it:

/Library/Frameworks/Python.framework/Versions/2.3/lib/

python2.3/plat-mac/applesingle.py:40: FutureWarning: %u/

%o/%x/%X of negative int will return a signed string in 

Python 2.4 and up

3) its decode function overloads __builtin__ names (input, 

id) and uses type(input) == type('') when it really means: 

isinstance(input, basestring).. or maybe even better: not 

hasattr(input, 'read')

4) it can be useful on platforms other than MacOS (bub-n-

bob uses it for example)



Attached is a revamped and backwards compatible version.

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

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

From noreply at sourceforge.net  Tue Sep  9 18:13:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 20:13:24 2003
Subject: [Python-bugs-list] [ python-Bugs-792649 ] RESET_ERROR is not
	defined(logging module)
Message-ID: <E19wsbo-0008EM-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: RESET_ERROR is not defined(logging module)

Initial Comment:
ConfigStreamHandler class(logging/config.py) has the 

following code in its handle method:



    except socket.error, e:

        if type(e.args) != types.TupleType:

            raise

        else:

            errcode = e.args[0]

            if errcode != RESET_ERROR:

                raise



However, RESET_ERROR is not defined.

So if the handle method catches socket.error, this will 

raise NameError.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-08 20:59

Message:
Logged In: YES 
user_id=80475

Guido, do you know what Vinay intended here?



I'm guessing it is errno.ECONNRESET but am not sure which 

of the many reset error numbers he intended to catch and 

ignore.



I emailed him but have not gotten a reply.

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

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

From noreply at sourceforge.net  Tue Sep  9 18:47:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 20:47:14 2003
Subject: [Python-bugs-list] [ python-Bugs-775353 ] IDLE: "Save As..."
	keybind (Ctrl+Shift+S) does not work
Message-ID: <E19wt8Z-0003zb-00@sc8-sf-web1.sourceforge.net>

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

Category: IDLE
Group: Python 2.4
Status: Open
Resolution: Accepted
>Priority: 6
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work

Initial Comment:
Info:

-Python Version: Python 2.3c1 (#44, Jul 18 2003, 14:32:

36) [MSC v.1200 32 bit (Intel)] on win32

-IDLE Version:IDLE 1.0rc1  

-OS: Windows 2000 SP4

-Source: Installed from Installer on website (http://www.

python.org/ftp/python/2.3/Python-2.3c1.exe)



Behavior:



In the "File" dropdown menu in IDLE, the listed keybind for 

"Save As" is Ctrl+Shift+S.  This does not work.  When 

you hit Ctrl+Shift+S, nothing happens.



Additionally, the keybind for "Save Copy As...", 

Alt+Shift+S, does not work.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-07-23 00:23

Message:
Logged In: YES 
user_id=149084

Duplicate of IDLEfork Bug 755647



None of the bindings with a Shift modifier

work because it is then necessary to use the upper

case keysym.  IDLE is using the lower case.

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

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-07-21 19:32

Message:
Logged In: YES 
user_id=716326

Checking through the code, it seems that the problem is in the 

file "configHandler.py".  The bindings are assigned with 

_lowercase_ letters:



'<<save-copy-of-window-as-file>>': ['<Alt-Shift-s>'], 

'<<save-window-as-file>>': ['<Alt-s>'],



So the keybindings will work when CAPSLOCK is active.  

Otherwise, it won't.

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

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

From noreply at sourceforge.net  Tue Sep  9 20:46:21 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 22:46:25 2003
Subject: [Python-bugs-list] [ python-Bugs-775061 ] 2 problems with IDLE
Message-ID: <E19wuzt-0005s5-00@sc8-sf-web2.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Kurt B. Kaiser (kbk)
Summary: 2 problems with IDLE

Initial Comment:
Lib/idlelib/idle.py should use #!/usr/bin/env python

not /usr/bin/python so the user can modify their path

to execute the correct version of python.



In Lib/idlelib/rpc.py around line 623, svr.register

(svr is an RPCServer instance)  is called, but there is

no register method AFAICT.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-09 21:46

Message:
Logged In: YES 
user_id=149084

idle.py 1.11

rpc.py 1.27

removed "idle" script



idle.py actually has the functionality to start IDLE

from any location even when python is not installed:

<path to python>/python  <path to python>/Lib/idlelib/idle.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-05 21:10

Message:
Logged In: YES 
user_id=33168

No objection from me.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 21:04

Message:
Logged In: YES 
user_id=149084

My idea on how to resolve this:

remove the "idle" script from idlelib and

remove the shebang from idlelib/idle.py so

it has to be called explicitly.  Any objections?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 18:13

Message:
Logged In: YES 
user_id=149084

I use (from the idlelib dir):

../../python ./PyShell.py

to start an uninstalled IDLE for testing.



There is a more elaborate idle.py in IDLEfork which allows

starting an uninstalled IDLEfork from anywhere in the file

system.  Maybe something like that would be useful to

someone? It's not useful to me, I either use the above,

or call my installed version (which is the latest official

release) from outside that directory.  There is always an

installed IDLE now.



I recommend removing the idle script from 

idlelib, since it is actually installed from Tools/scripts.

The files there uniformly start with #! /usr/bin/env python.

Exceptions: gprof2html.py, parseentities.py



Without objection, I'm going to remove idlelib/idle.



As far as the RPCServer issue goes, this is defunct test

code.  I'll comment it out for now. A proper unit test of

the rpc.py module is needed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-21 21:19

Message:
Logged In: YES 
user_id=33168

Hmmm, I do remember something about distutils rewriting the

line, but I'm not sure.  My problem was that I was running

an uninstalled version in the CVS tree:

  ./Lib/idlelib/idle



Perhaps this isn't a bug.  RPCServer still appears to be a

problem either way.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-21 17:43

Message:
Logged In: YES 
user_id=21627

I fail to see the first problem. Shouldn't distutils replace

the path in #! with sys.exec_prefix? /usr/bin/env should

*not* be used, as this might be a different python than the

one IDLE was installed for.

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

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

From noreply at sourceforge.net  Tue Sep  9 21:11:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 23:11:48 2003
Subject: [Python-bugs-list] [ python-Bugs-768391 ] hardcoded python paths
Message-ID: <E19wvOM-0006yK-00@sc8-sf-web2.sourceforge.net>

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

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 5
Submitted By: Tiago Castro Henriques (tiagoh)
>Assigned to: Jack Jansen (jackjansen)
Summary: hardcoded python paths

Initial Comment:
I tried to use the new version of idle that is now

integrated into 2.3b2, but I got an error when I tried

to run /usr/local/lib/python2.3/idlelib/idle:



% /usr/local/lib/python2.3/idlelib/idle

Traceback (most recent call last):

  File "./idle", line 8, in ?

    import PyShell

  File "./PyShell.py", line 19, in ?

    from Tkinter import *

  File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 35,

in ?

    import _tkinter # If this fails your Python may not

be configured for Tk

ImportError: No module named _tkinter



I'm using python2.3b2 on MacOSX 10.2.6, compiled from

source with standard options.



Apparently the builtin 2.2 version of Python is being

used, even though $PYTHONHOME is not set (according to

the manpages, this should make it default to

/usr/local, and not /usr as seems to be the case).



This is due to the fact that this executable script

contains a shebang declaration with a hardcoded python

path:



% head -1 /usr/local/lib/python2.3/idlelib/idle

#!/usr/bin/python



This should be replaced by the standard shebang

declaration:

#! /usr/bin/env python



I checked to see if there were any other *.py files in

/usr/local/lib/python2.3 suffering from similar

problems, and found the following files to be affected:



/usr/local/lib/python2.3/cgi.py:

#! /usr/local/bin/python

/usr/local/lib/python2.3/test/test_bz2.py:

#!/usr/bin/python

/usr/local/lib/python2.3/test/test_largefile.py:

#!python

/usr/local/lib/python2.3/test/test_optparse.py:

#!/usr/bin/python



The files /usr/local/bin/idle, /usr/local/bin/pydoc and

/usr/local/bin/pycolor also have a hardcoded python path:

% head -1 idle pycolor pydoc

==> idle <==

#!/usr/local/bin/python



==> pycolor <==

#!/usr/local/bin/python



==> pydoc <==

#!/usr/local/bin/python



These should similarly be changed to #! /usr/bin/env python



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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-09 22:11

Message:
Logged In: YES 
user_id=149084

Refer to Python Bug 775061 (closed)



idlelib/idle  script has been removed since the

idle script is now in Tools/scripts and at least

the Linux installation is setting the shebang correctly.



Also, the shebang has been removed from idlelib/idle.py.



I don't know how OSX handles the script installation

so I'm referring this to Jack Jansen in case there is

a further problem.  How does IDLE start on OSX 

these days?  Is there any problem backporting the

deletions to 2.3 maint?

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

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

From noreply at sourceforge.net  Tue Sep  9 21:35:27 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 23:35:32 2003
Subject: [Python-bugs-list] [ python-Bugs-792649 ] RESET_ERROR is not
	defined(logging module)
Message-ID: <E19wvlP-00081c-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Raymond Hettinger (rhettinger)
Summary: RESET_ERROR is not defined(logging module)

Initial Comment:
ConfigStreamHandler class(logging/config.py) has the 

following code in its handle method:



    except socket.error, e:

        if type(e.args) != types.TupleType:

            raise

        else:

            errcode = e.args[0]

            if errcode != RESET_ERROR:

                raise



However, RESET_ERROR is not defined.

So if the handle method catches socket.error, this will 

raise NameError.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-09 22:35

Message:
Logged In: YES 
user_id=80475

Fixed.

See:

    Lib/logging/config.py 1.17.10.1

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-08 20:59

Message:
Logged In: YES 
user_id=80475

Guido, do you know what Vinay intended here?



I'm guessing it is errno.ECONNRESET but am not sure which 

of the many reset error numbers he intended to catch and 

ignore.



I emailed him but have not gotten a reply.

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

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

From noreply at sourceforge.net  Tue Sep  9 21:40:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 23:40:25 2003
Subject: [Python-bugs-list] [ python-Bugs-801992 ] cgi.CGIHTTPRequestHandler
	remembers QUERY_STRING
Message-ID: <E19wvq8-0008BJ-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivo Danihelka (fidlej)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.CGIHTTPRequestHandler remembers QUERY_STRING

Initial Comment:
Python 2.3+, Debian SID:

cgi.CGIHTTPRequestHandler remembers QUERY_STRING from

last query.

If query is '', then condition "if query:" fails and

env['QUERY_STRING'] is remembered from last query.



Solution:

--- /usr/lib/python2.3/CGIHTTPServer.py 2003-09-07

15:33:41.000000000 +0200

+++ CGIHTTPServer.py    2003-09-07 15:36:27.000000000 +0200

@@ -147,8 +147,7 @@

         env['PATH_INFO'] = uqrest

         env['PATH_TRANSLATED'] =

self.translate_path(uqrest)

         env['SCRIPT_NAME'] = scriptname

-        if query:

-            env['QUERY_STRING'] = query

+        env['QUERY_STRING'] = query

         host = self.address_string()

         if host != self.client_address[0]:

             env['REMOTE_HOST'] = host







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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-09 22:40

Message:
Logged In: YES 
user_id=80475

See the patch at www.python.org/sf/796772

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-07 14:48

Message:
Logged In: YES 
user_id=21627

I believe the bug lies elsewhere: If we have fork, we

shouldn't set the environment variables in the parent

process, but only in the child process.

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

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

From noreply at sourceforge.net  Tue Sep  9 21:54:02 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 23:54:08 2003
Subject: [Python-bugs-list] [ python-Feature Requests-715263 ] Access to DOM
	Element attributes using __getitem__
Message-ID: <E19ww3O-00026g-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #715263, was opened at 2003-04-04 07:26
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=715263&group_id=5470

Category: XML
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: chris burdess (bluezoo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Access to DOM Element attributes using __getitem__

Initial Comment:
Element objects in XML DOM implementations in Python

should provide access to their attributes in a standard

Python way, using __getitem__. Thus, the following code

to print the version of an XMI document should work:



  import xml.dom.minidom

  print

xml.dom.minidom.parse(filename).documentElement['xmi.version']



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-09 23:53

Message:
Logged In: YES 
user_id=3066

It's not clear that this is reasonable.



DOM Level 2 elements may provide access to attributes using

either name (qualified name if namespaces are in play), or

(uri, localname) pairs.  What constitutes the "right thing"

isn't clear, but implementing a __getitem__() that takes

either a name or a pair seems too magical.



The DOM API is already huge; extending it, even when the

"right thing" is clear, is pretty risky, and introduces true

difficulty and compatibility issues for implementors.



For these reasons, I'm rejecting this request.  To appeal,

this matter should be taken up on the XML-SIG mailing list;

I'll make sure minidom conforms to decisions of group.  I

can't speak for the other implementors.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-12 13:52

Message:
Logged In: YES 
user_id=80475

At first blush, this seems reasonble.  Fred, what do you 

think?

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

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

From noreply at sourceforge.net  Tue Sep  9 21:56:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep  9 23:56:13 2003
Subject: [Python-bugs-list] [ python-Bugs-800899 ] Making "|" directive from
	REs a bit clearer
Message-ID: <E19ww5P-0002C8-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Making "|" directive from REs a bit clearer

Initial Comment:
Let's take a look, Library Reference, 4.2.1 Regular 

Expression Syntax says:



   "|"

           A|B, where A and B can be arbitrary REs, creates a 

regular

           expression that will match either A or B.

           [...]

!!here_starts_the_darkness!!

           REs separated by "|" are tried from left to right, and 

the

           first one that allows the complete pattern to match 

is considered

           the accepted branch. This means that if A matches, 

B will never

           be tested, even if it would produce a longer overall 

match.

!!here_ends_the_darkness!!



It's not as clear as it can be. For more information take a 

look at: 

<http://mail.python.org/pipermail/python-dev/2003-September/037924.html>



Here's a proposal from Terry Reedy for changing those 

lines from darkness ;-)



"""As the target string is scanned, REs separated by "|" are 

tried from

left to right.  When one pattern completely matches, that 

branch is

accepted.  This means that once A matches, B will not be 

tested

further, even if it would produce a longer overall match."""





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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-09 22:56

Message:
Logged In: YES 
user_id=80475

Accepted and applied.

Thanks for the contribution.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 16:13

Message:
Logged In: YES 
user_id=357491

This was also brought to the attention of python-dev directly and 

discussed in the thread "Discordance in Documentation..." which 

can be found at http://mail.python.org/pipermail/python-dev/

2003-September/037924.html .

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

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

From noreply at sourceforge.net  Tue Sep  9 22:46:17 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 00:46:22 2003
Subject: [Python-bugs-list] [ python-Bugs-802302 ] Invalid documentation for
	dbhash.
Message-ID: <E19wwrx-0003m6-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid documentation for dbhash.

Initial Comment:
The documentation for dbhash is incorrect.  Using its *exact* 
example: 
 
functor% python 
Python 2.3+ (#2, Aug 10 2003, 11:33:47) 
[GCC 3.3.1 (Debian)] on linux2 
Type "help", "copyright", "credits" or "license" for more 
information. 
>>> import dbhash 
>>> db = dbhash.open('awaken.dbm', 'r') 
>>> k = db.first() 
>>> while k != None: 
...   print k 
...   k = db.next(k) 
... 
('U465', '(lp0\nS"Ulerin\'s"\np1\na.') 
Traceback (most recent call last): 
  File "<stdin>", line 3, in ? 
TypeError: next() takes exactly 1 argument (2 given) 
 
Whereas the documentation says: 
next(key) 
 Returns the key that follows key in the traversal. The following 
code prints every key in the database db, without having to create 
a list in memory that contains them all:  
 
k = db.first() 
while k != None: 
    print k 
    k = db.next(k) 
 
Also interesting is that this is apparently supposed to iterate 
through the keys, but it appears to be iterating through the items 
in general: notice the one key printed was ('U465', '(lp0\nS"Ulerin
\'s"\np1\na.'). 
 
Incidentally, it works with no argument to .next, but errors at 
some point: 
 
>>> import dbhash 
>>> db = dbhash.open('awaken.dbm', 'r') 
>>> k = db.first() 
>>> fd = file('/dev/null', 'w') 
>>> while k != None: 
...   print >>fd, k 
...   k = db.next() 
... 
Traceback (most recent call last): 
  File "<stdin>", line 3, in ? 
  File "/usr/lib/python2.3/bsddb/__init__.py", line 122, in next 
    rv = self.dbc.next() 
_bsddb.DBNotFoundError: (-30991, 'DB_NOTFOUND: No 
matching key/data pair found') 
 
This is before finishing the iteration through the database.  But 
this is probably a different bug report; I want to make sure I'm not 
misunderstanding something first.  

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-09 23:46

Message:
Logged In: YES 
user_id=80475

Thanks for the report.

The docs were way off on this one.

I'm amazed that you were the first to notice it.

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

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

From noreply at sourceforge.net  Wed Sep 10 00:18:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 02:18:31 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19wyJA-0003S6-00@sc8-sf-web4.sourceforge.net>

Bugs item #803610, was opened at 2003-09-10 06: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=803610&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

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

From noreply at sourceforge.net  Wed Sep 10 00:30:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 02:30:59 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19wyVD-0007MT-00@sc8-sf-web1.sourceforge.net>

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

>Category: Python Library
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

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

From noreply at sourceforge.net  Wed Sep 10 01:43:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 03:43:03 2003
Subject: [Python-bugs-list] [ python-Bugs-803634 ] urllib/urllib2(?) timeouts
Message-ID: <E19wzcz-0008SZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #803634, was opened at 2003-09-10 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=803634&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib/urllib2(?) timeouts

Initial Comment:
Could Skip's example from 

http://groups.google.com/groups?hl=en&lr=&ie=UTF-

8&selm=mailman.1051711375.3445.python-list%

40python.org be added to the documentation? 



(slightly re-worded)

You can set the default timeout for sockets before 

opening the URL (use 0.0 for non-blocking sockets):



    dto = socket.getdefaulttimeout()

    socket.setdefaulttimeout(mytimeout)

    try:

        try:

            f = urllib2.urlopen("http://www.python.org/")

            x = f.read()

        except socket.error, msg:  ### Note2

            print "timeout"

    finally:

        # restore default

        socket.setdefaulttimeout(dto)



Note1: urllib, urllib2, or both? (and should there be 

a "see also: urllib2" in the urllib docs?)



Note2: Experimenting (and digressing -- it's late :-)



  urllib.urlopen, timeout=0.0: IOError(?) [1]

  urllib.urlopen, timeout=0.1: IOError(?) [2]

  urllib2.urlopen, timeout=0.0: urllib2.URLError [3]

  urllib2.urlopen, timeout=0.1: socket.timeout



I can understand the last one... sort of. The 

exception "reporting" is part of a module's interface, so 

I'd expect to be able to "Except urllib.exception" (modulo 

consistent naming) to catch all reasonable[0] 

exceptions resulting from calling into the module, and 

urllib.timeout to catch timeouts.



I can see the argument that the user set the timeout in 

the socket module, so should expect them, but then 

handling timeouts are routine for web programming...



IOError is not related to socket.timeout, so I'm not sure 

why it's left free to escape, especially with that errno :-)



-- bjorn



[0] of course not urllib.MemoryError or other 

catastrophic events



[1]

  File "E:\Python23\lib\httplib.py", line 564, in send

    self.connect()

  File "E:\Python23\lib\httplib.py", line 548, in connect

    raise socket.error, msg <--### see below

IOError: [Errno socket error] (10035, 'The socket 

operation could not complete without blocking')

>>> x = 0

>>> try:

...   urllib.urlopen

('http://www.comcast.net/memberservices/index.jsp')

... except Exception, e:

...   x = e

...

>>> x   

<exceptions.IOError instance at 0x00A63288> ###

 

[2]

  File "E:\Python23\lib\httplib.py", line 564, in send

    self.connect()

  File "E:\Python23\lib\httplib.py", line 548, in connect

    raise socket.error, msg

IOError: [Errno socket error] timed out



...and also...



  File "E:\Python23\lib\socket.py", line 323, in readline

    data = recv(1)

IOError: [Errno socket error] timed out



[3]

  File "e:\python23\lib\urllib2.py", line 849, in http_open

    return self.do_open(httplib.HTTP, req)

  File "e:\python23\lib\urllib2.py", line 834, in do_open

    raise URLError(err)

urllib2.URLError: <urlopen error (10035, 'The socket 

operation could not complete without blocking')>



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

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

From noreply at sourceforge.net  Wed Sep 10 05:34:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 07:34:13 2003
Subject: [Python-bugs-list] [ python-Bugs-803679 ] Missing section number in
	csv module documentation
Message-ID: <E19x3Ed-00062r-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing section number in csv module documentation

Initial Comment:
In the two following places of the Postscript A4 version 

of the documentation:



- section 12.20.1, end of first paragraph of the 

description of the 'reader' function



- section 12.20.1, around the middle of the first 

paragraph of the description of the 'write' function



there is a reference to section 'Dialects and Formatting 

Parameters' with '??' instead of the correct section 

number (12.20.2)

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

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

From noreply at sourceforge.net  Wed Sep 10 09:45:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 11:45:33 2003
Subject: [Python-bugs-list] [ python-Bugs-658254 ] Accept None for
	time.ctime() and friends
Message-ID: <E19x79e-0002wz-00@sc8-sf-web4.sourceforge.net>

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

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Accept None for time.ctime() and friends

Initial Comment:
Several functions in the time module can have the time

value they operate on omitted to indicate the current

time, but they do not accept None as equivalent to

omitting the value.  It should be equivalent.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-10 11:45

Message:
Logged In: YES 
user_id=3066

I generally expect that None should be accepted for an

omitted arg, but Guido has certainly never cared about that.

 Given that no existing code passes None, it's ok to reject.

 If the truth be told, though, the current situation

certainly complicates some existing code!

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

Comment By: Christopher Blunck (blunck2)
Date: 2003-01-06 22:43

Message:
Logged In: YES 
user_id=531881

see patch 663482

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

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

From noreply at sourceforge.net  Wed Sep 10 10:37:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 12:37:35 2003
Subject: [Python-bugs-list] [ python-Bugs-803842 ] Wrong description of
	regexp concatenation
Message-ID: <E19x7yD-0007ZA-00@sc8-sf-web2.sourceforge.net>

Bugs item #803842, was opened at 2003-09-10 18: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=803842&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hallvard B Furuseth (hfuru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong description of regexp concatenation

Initial Comment:
http://www.python.org/doc/current/lib/re-syntax.html

says:



If a string p matches A and another string q matches B,

the string pq will match AB if A and B do no specify

boundary conditions that are no longer satisfied by pq.



This is not true if A or B contains an unparenthesized

"|": A = "x|y", B = "z", p = "x", q = "z".



Nor if A contains parentheses and B contains \number.

A = "(x)", B = r'(.)\1', p = "x", q = "yy".



Nor if A or B contains a (?...) which modifies the

behaviour of the entire regular expression.



Nor if B contains (?<!...) matching AB, including

a portion of A.



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

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

From noreply at sourceforge.net  Wed Sep 10 10:57:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 12:57:56 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19x8Hw-0000E9-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 18:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Wed Sep 10 10:58:49 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 12:58:57 2003
Subject: [Python-bugs-list] [ python-Bugs-803422 ] sgmllib doesn't support
	hex or Unicode character references
Message-ID: <E19x8Ir-000258-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib doesn't support hex or Unicode character references

Initial Comment:
sgmllib doesn't support the hexadecimal style of character nor 

Unicode characters, both of which are commonly seen on web pages. 

The following replacements fix both problems.



charref = re.compile('&#([0-9a-fA-F]+)[^0-9a-fA-F]')



	def handle_charref(self, ref):

		try:

			if ref[0] == 'x' or ref[0] == 'X': m = 

int(ref[1:], 16)

			else: m = int(ref)

			self.handle_data(unichr(m).encode('utf-8'))

		except ValueError:

			self.unknown_charref(ref)



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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 18:58

Message:
Logged In: YES 
user_id=21627

Are you sure hexadecimal character references are part of

the SGML standard?

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

Comment By: Aaron Swartz (aaronsw)
Date: 2003-09-09 23:00

Message:
Logged In: YES 
user_id=122141

Oops, that should be: 



charref = re.compile('&#([0-9a-fA-FxX][0-9a-fA-F]*)[^0-9a-fA-F]')

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

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

From noreply at sourceforge.net  Wed Sep 10 11:33:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 13:34:04 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19x8qt-00027R-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Syrah (syrah)
Date: 2003-09-10 17:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 16:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Wed Sep 10 12:48:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 14:48:55 2003
Subject: [Python-bugs-list] [ python-Bugs-803842 ] Wrong description of
	regexp concatenation
Message-ID: <E19xA1L-000099-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Hallvard B Furuseth (hfuru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong description of regexp concatenation

Initial Comment:
http://www.python.org/doc/current/lib/re-syntax.html

says:



If a string p matches A and another string q matches B,

the string pq will match AB if A and B do no specify

boundary conditions that are no longer satisfied by pq.



This is not true if A or B contains an unparenthesized

"|": A = "x|y", B = "z", p = "x", q = "z".



Nor if A contains parentheses and B contains \number.

A = "(x)", B = r'(.)\1', p = "x", q = "yy".



Nor if A or B contains a (?...) which modifies the

behaviour of the entire regular expression.



Nor if B contains (?<!...) matching AB, including

a portion of A.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-10 13:48

Message:
Logged In: YES 
user_id=80475

These two exceptions (low precedence operations and group 

numbering) seem obvious to me; however, precedence errors 

with | is are common.  Accordingly, I've updated the docs to 

the two exceptions to the general rule.



Thanks for the report.

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

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

From noreply at sourceforge.net  Wed Sep 10 12:57:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 14:57:58 2003
Subject: [Python-bugs-list] [ python-Bugs-803679 ] Missing section number in
	csv module documentation
Message-ID: <E19xAA4-00071y-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing section number in csv module documentation

Initial Comment:
In the two following places of the Postscript A4 version 

of the documentation:



- section 12.20.1, end of first paragraph of the 

description of the 'reader' function



- section 12.20.1, around the middle of the first 

paragraph of the description of the 'write' function



there is a reference to section 'Dialects and Formatting 

Parameters' with '??' instead of the correct section 

number (12.20.2)

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-10 13:57

Message:
Logged In: YES 
user_id=80475

Okay, it's fixed now.

Thanks for the report.

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

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

From noreply at sourceforge.net  Wed Sep 10 13:24:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 15:24:43 2003
Subject: [Python-bugs-list] [ python-Feature Requests-798046 ] select module
	doesn't allow any iterable.
Message-ID: <E19xAZy-00078Z-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #798046, was opened at 2003-08-31 00:31
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=798046&group_id=5470

>Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: select module doesn't allow any iterable.

Initial Comment:
The select module only allows lists, not any 
iterable.  While this may slightly increase efficiency 
for the select.select() function itself, for many 
applications passing select.select a sets.Set would 
probably be much more efficient (i.e., when things 
are being added/removed from the readable or 
writable lists quite often, the O(n) removal of lists 
would certainly be worse than the O(1) removal of 
sets.) 

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

Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 15:22

Message:
Logged In: YES 
user_id=357491

There seems to be two things that are preventing the use of an 

object that supports the iterator protocol instead of a list.  One is 

the explicit check that the arguments are lists; PyList_Check is run 

on the passed-in lists for a basic sanity check.  Then there is a call 

to a function called list2set that takes in a Python list and then 

sets the passed-in fd_set properly.  In that function there is 

nothing that screams "we should only use lists" beyond it allows 

assuming a list and thus doesn't have any hoops to jump through.



But the iterator protocol was set up to minimize hoop jumping.  

There seems to be little stopping a move over to using the iterator 

protocol beyond a minimial amount of recoding to rip out the list 

check to replace it with PyIter_Check and instead of using a 'for' 

loop through a list you just use a 'while' calling PyIter_Next .



But since this seems to have gone so long without being changed I 

would feel better about having someone tell me it is okay to 

change.  I will email python-dev and ask.

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

Comment By: Armin Rigo (arigo)
Date: 2003-09-02 11:23

Message:
Logged In: YES 
user_id=4771

Using select.poll() instead of select.select() might be a

good alternative, at least on platforms that support it, if

the sets are getting large enough for you to want to avoid

having to build lists explicitely as in :



    select.select(list(a), list(b), list(c))



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

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

From noreply at sourceforge.net  Wed Sep 10 13:39:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 15:39:55 2003
Subject: [Python-bugs-list] [ python-Feature Requests-798046 ] select module
	doesn't allow any iterable.
Message-ID: <E19xAoi-0000O8-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #798046, was opened at 2003-08-31 00:31
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=798046&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: select module doesn't allow any iterable.

Initial Comment:
The select module only allows lists, not any 
iterable.  While this may slightly increase efficiency 
for the select.select() function itself, for many 
applications passing select.select a sets.Set would 
probably be much more efficient (i.e., when things 
are being added/removed from the readable or 
writable lists quite often, the O(n) removal of lists 
would certainly be worse than the O(1) removal of 
sets.) 

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

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-10 12:39

Message:
Logged In: YES 
user_id=357491

Rev. 2.74 of Modules/selectmodule.c has select.select() accept a 

sequence (as defined by PySequence_Fast()) for its first three 

arguments; this includes sets.



Changed to an RFE since it wasn't really a bug and closed.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 15:22

Message:
Logged In: YES 
user_id=357491

There seems to be two things that are preventing the use of an 

object that supports the iterator protocol instead of a list.  One is 

the explicit check that the arguments are lists; PyList_Check is run 

on the passed-in lists for a basic sanity check.  Then there is a call 

to a function called list2set that takes in a Python list and then 

sets the passed-in fd_set properly.  In that function there is 

nothing that screams "we should only use lists" beyond it allows 

assuming a list and thus doesn't have any hoops to jump through.



But the iterator protocol was set up to minimize hoop jumping.  

There seems to be little stopping a move over to using the iterator 

protocol beyond a minimial amount of recoding to rip out the list 

check to replace it with PyIter_Check and instead of using a 'for' 

loop through a list you just use a 'while' calling PyIter_Next .



But since this seems to have gone so long without being changed I 

would feel better about having someone tell me it is okay to 

change.  I will email python-dev and ask.

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

Comment By: Armin Rigo (arigo)
Date: 2003-09-02 11:23

Message:
Logged In: YES 
user_id=4771

Using select.poll() instead of select.select() might be a

good alternative, at least on platforms that support it, if

the sets are getting large enough for you to want to avoid

having to build lists explicitely as in :



    select.select(list(a), list(b), list(c))



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

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

From noreply at sourceforge.net  Wed Sep 10 14:19:58 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 16:20:07 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19xBRW-00053R-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 22:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),

and reports an error if and only if the operating system

reports an error. So there is absolutely zero possibility

that the operatin system lets close(2) succeeed, yet python

returns OSError(9). As a consequence, if python raises

OSError(9), it was the operating system that has returned an

error before.



If you doubt this statement, please use ktrace/strace to

diagnose this further.



Also, if you *know* that a parent process has set up fd 3,

your test case is irrelevant. Your test case is only

meaningful in a context where a parent process has set up fd

3, however, you have not reported the code of that parent

process. Providing a minimal test case would be appreciated.

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

Comment By: Syrah (syrah)
Date: 2003-09-10 19:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 18:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Wed Sep 10 16:42:42 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 18:42:48 2003
Subject: [Python-bugs-list] [ python-Bugs-803422 ] sgmllib doesn't support
	hex or Unicode character references
Message-ID: <E19xDfe-00010M-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib doesn't support hex or Unicode character references

Initial Comment:
sgmllib doesn't support the hexadecimal style of character nor 

Unicode characters, both of which are commonly seen on web pages. 

The following replacements fix both problems.



charref = re.compile('&#([0-9a-fA-F]+)[^0-9a-fA-F]')



	def handle_charref(self, ref):

		try:

			if ref[0] == 'x' or ref[0] == 'X': m = 

int(ref[1:], 16)

			else: m = int(ref)

			self.handle_data(unichr(m).encode('utf-8'))

		except ValueError:

			self.unknown_charref(ref)



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

>Comment By: Aaron Swartz (aaronsw)
Date: 2003-09-10 17:42

Message:
Logged In: YES 
user_id=122141

I don't have the money to shell out for the XML spec, but according to http://

developers.omnimark.com/documentation/concept/764.htm they were 

added in SGML TC 2.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 11:58

Message:
Logged In: YES 
user_id=21627

Are you sure hexadecimal character references are part of

the SGML standard?

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

Comment By: Aaron Swartz (aaronsw)
Date: 2003-09-09 16:00

Message:
Logged In: YES 
user_id=122141

Oops, that should be: 



charref = re.compile('&#([0-9a-fA-FxX][0-9a-fA-F]*)[^0-9a-fA-F]')

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

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

From noreply at sourceforge.net  Wed Sep 10 16:45:42 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 18:45:51 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19xDiY-000175-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Syrah (syrah)
Date: 2003-09-10 22:45

Message:
Logged In: YES 
user_id=827529

I agree that this is a very strange error.  Python should be

directly calling the operating systems close function.  It

is very puzzling that there is an error.



I did include in my initial post a parent that sets up fd 3.

 I used bash.  I was able to test successfully with bash.  I

wrote a C program:



-------- test.c --------

#include <stdio.h>



int main () {

  int i = close (3);

  printf ("close: %i\n", i); }

--------



Using bash, I tested test.py, test2.py, and test.c (gcc

test.c -o test).  test.c behaved properly.  When I set up fd

3 with bash, test.c printed "close: 0".  When I did not set

up fd 3, test.c printed "close: -1".



I therefore have bash working properly, C working properly

and test2.py working properly.  The only thing that is not

working properly is test.py.  To me, it seems that I have

isolated the problem.



However, this problem only manifests on FreeBSD.  test.py

runs fine on Gentoo Linux.  At present, those are the only

two OSes I have easy access to.



So... if you really want a test program that sets up fd3,

I'll write one - let me know.  Would you prefer me to write

it in Python, C, PHP, Ruby, Perl?  I'd prefer C as it is

most direct.  But bash seems sufficient: "[bash]$ python

test.py 3> file" sets up file descriptor 3 so it writes into

a file named "file".



To look at it from another angle... is it possible that

Python, during its startup and initialization stuff messes

with file descriptor 3?  Is it possible it does this in some

really non-standard way?  Perhaps it does it indirectly by

calling some OS function that, as a side effect on FreeBSD

touches fd 3?  Something is going on with file descriptions

0-4 _every_ time python runs.  [Based on the ktrace's below,

it looks like



[syrah@ripple]$ python

Python 2.3 (#1, Sep  9 2003, 22:47:18) 

[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5

Type "help", "copyright", "credits" or "license" for more

information.

>>> import os 

>>> os.fstat (0)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206044,

1063206044, 1063206044)

>>> os.fstat (1)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206046,

1063206046, 1063206046)

>>> os.fstat (2)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206048,

1063206048, 1063206048)

>>> os.fstat (3)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (4)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (5)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

OSError: [Errno 9] Bad file descriptor

>>> 



Also, it is very strange that after calling os.fstat(3),

os.close(3) works.  This says to me that fd 3 is fine, but

Python thinks fd 3 is bogus, but

calling os.fstat (3) forces Python to check fd 3's real status.



I considered the possibility that os.fstat(x) will the next

os.close(x) to succeed, but that is not the case:



[bash]$ cat test3.py

import os

os.fstat (3)

os.close (3)

os.fstat (3)

os.close (3)



[bash]$ python test3.py 3> file

(an the error is raised on the second os.fstat(3) call, just

as you would expect)



Okay, here is your ktrace:



26520 python   GIO   fd 6 read 23 bytes

       "import os

        os.close (3)

       "

 26520 python   RET   read 23/0x17

 26520 python   CALL  write(0x2,0x80e6708,0x4)

 26520 python   GIO   fd 2 wrote 4 bytes

       "    "

 26520 python   RET   write 4

 26520 python   CALL  write(0x2,0xbfbfeb70,0xd)

 26520 python   GIO   fd 2 wrote 13 bytes

       "os.close (3)

       "

 26520 python   RET   write 13/0xd

 26520 python   CALL  fstat(0x6,0xbfbfe670)

 26520 python   RET   fstat 0

 26520 python   CALL  fcntl(0x6,0x3,0)

 26520 python   RET   fcntl 4

 26520 python   CALL  fcntl(0x6,0x4,0)

 26520 python   RET   fcntl 0

 26520 python   CALL  close(0x6)

 26520 python   RET   close 0

 26520 python   CALL  write(0x2,0x813a3b4,0x7)

 26520 python   GIO   fd 2 wrote 7 bytes

       "OSError"

 26520 python   RET   write 7

 26520 python   CALL  write(0x2,0x80dbe5f,0x2)

 26520 python   GIO   fd 2 wrote 2 bytes

       ": "

 26520 python   RET   write 2

 26520 python   CALL  write(0x2,0x81c5dfc,0x1d)

 26520 python   GIO   fd 2 wrote 29 bytes

       "[Errno 9] Bad file descriptor"

 26520 python   RET   write 29/0x1d

 26520 python   CALL  write(0x2,0x80e4d42,0x1)

 26520 python   GIO   fd 2 wrote 1 byte

       "

       "



Note that when I call os.close (3), python calls close(0x6),

so it looks like python is "mapping" the file description

numbers.  There are many other close calls the ktrace, but

_none_ of them close (0x3).  This says to me that (possibly)

python is doing lots of fd manipulation, but fd 3 is already

open, so python never uses it.



Here is a ktrace of test2.py.  It's very interesting.  6 is

fstated, closed, then 3 is fstated, fnctled, and closed

successfully.



 26498 python   GIO   fd 6 read 36 bytes

       "import os

        os.fstat (3)

        os.close (3)

       "

 26498 python   RET   read 36/0x24

 26498 python   CALL  lseek(0x6,0,0,0,0x1)

 26498 python   RET   lseek 36/0x24

 26498 python   CALL  read(0x6,0x8203000,0x4000)

 26498 python   GIO   fd 6 read 0 bytes

       ""

 26498 python   RET   read 0

 26498 python   CALL  fstat(0x6,0xbfbff450)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x6,0x3,0)

 26498 python   RET   fcntl 4

 26498 python   CALL  fcntl(0x6,0x4,0)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x6)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 1

 26498 python   CALL  fcntl(0x3,0x4,0x5)

 26498 python   RET   fcntl 0

 26498 python   CALL  fstat(0x3,0xbfbff290)

 26498 python   RET   fstat 0

 26498 python   CALL  fstat(0x3,0xbfbff260)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 5

 26498 python   CALL  fcntl(0x3,0x4,0x1)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x3)

 26498 python   RET   close 0

 26498 python   CALL  sigaction(0x2,0xbfbff4b0,0)

 26498 python   RET   sigaction 0

 26498 python   CALL  setitimer(0x2,0xbfbff5f0,0)

 26498 python   RET   setitimer 0

 26498 python   CALL  close(0x4)

 26498 python   RET   close 0

 26498 python   CALL  close(0x5)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0,0x3,0)

 26498 python   RET   fcntl 6

 26498 python   CALL  fcntl(0,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x1,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x1,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x2,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x2,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  exit(0)



Does fd 3 have some special significance on FreeBSD?  Or on

other OSes?  I'm aware of 0, 1 and 2 being stdin, out, err.

 But I didn't know that 3 was anything special.  And 3 is

what courier uses to communicate with its filters.



Okay... I just searched through the whole ktrace of test.py.

 As far as I can tell, nothing touches fd 3 in the whole

ktrace.  fcntl takes 0x3 as the second argument many times,

but that is a command, not a file descriptor.



So... this means that with test.py, Python decides (based on

an fstat (0x6)?) that os.close(3) will fail without ever

calling close(3) to see what will happen.



This could be a bug in FreeBSD.  But then why did my C

program work as expected?  Or perhaps there is a library

inbetween Python and the OS, a library that my c program

does not use.



Any suggestions for further diagnosis?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 20:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),

and reports an error if and only if the operating system

reports an error. So there is absolutely zero possibility

that the operatin system lets close(2) succeeed, yet python

returns OSError(9). As a consequence, if python raises

OSError(9), it was the operating system that has returned an

error before.



If you doubt this statement, please use ktrace/strace to

diagnose this further.



Also, if you *know* that a parent process has set up fd 3,

your test case is irrelevant. Your test case is only

meaningful in a context where a parent process has set up fd

3, however, you have not reported the code of that parent

process. Providing a minimal test case would be appreciated.

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

Comment By: Syrah (syrah)
Date: 2003-09-10 17:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 16:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Wed Sep 10 19:07:54 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 21:08:06 2003
Subject: [Python-bugs-list] [ python-Bugs-804113 ] Crypto terminology for
	crypto hash function
Message-ID: <E19xFwA-00072o-00@sc8-sf-web2.sourceforge.net>

Bugs item #804113, was opened at 2003-09-10 20: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=804113&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crypto terminology for crypto hash function

Initial Comment:
On web page:



http://www.python.org/dev/doc/devel////lib/module-

sha.html



the documentation should be improved to make it clear 

that the hash function implemented here is really what 

is known as "SHA-1" and not just "SHA".  NIST originally 

proposed a "SHA" hash function.  NSA found a problem 

with SHA, and proposed a small fix to it; the revised 

hash function is typically called "SHA-1".   The version 

implemented is indeed "SHA-1" and not "SHA" (I tested 

it).   The documentation should make this clear, and 

might also include "SHA1" somewhere as a synonym so 

searches will find this common spelling variant too.  

Renaming the module as "sha1" would also be nice...



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

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

From noreply at sourceforge.net  Wed Sep 10 19:19:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 10 21:19:49 2003
Subject: [Python-bugs-list] [ python-Bugs-804115 ] bad argument
	handling(unittest.py)
Message-ID: <E19xG7d-0004ki-00@sc8-sf-web3.sourceforge.net>

Bugs item #804115, was opened at 2003-09-11 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=804115&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: bad argument handling(unittest.py)

Initial Comment:
_WritelnDecorator.writeln method handles arbitrary 

number of argumetns badly.



In the following part,



    def writeln(self, *args):

        if args: self.write(*args)



since _WritelnDecorator's stream is by default 

sys.stderr,

sys.stderr.write() takes exactly one argument.



If you give more than one argument to writeln 

method,

TypeError is raised.

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

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

From noreply at sourceforge.net  Wed Sep 10 23:27:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 11 01:28:07 2003
Subject: [Python-bugs-list] [ python-Bugs-804115 ] bad argument
	handling(unittest.py)
Message-ID: <E19xJzr-0006ls-00@sc8-sf-web2.sourceforge.net>

Bugs item #804115, was opened at 2003-09-10 20:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Steve Purcell (purcell)
Summary: bad argument handling(unittest.py)

Initial Comment:
_WritelnDecorator.writeln method handles arbitrary 

number of argumetns badly.



In the following part,



    def writeln(self, *args):

        if args: self.write(*args)



since _WritelnDecorator's stream is by default 

sys.stderr,

sys.stderr.write() takes exactly one argument.



If you give more than one argument to writeln 

method,

TypeError is raised.

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

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

From noreply at sourceforge.net  Thu Sep 11 00:01:05 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 11 02:01:17 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19xKVt-0006kA-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 08:01

Message:
Logged In: YES 
user_id=21627

Was that the complete ktrace? I'm missing the point where it

outputs "Traceback (most recent call last):". If you have

stripped it down, can you please attach the entire thing

(please don't paste it)?

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

Comment By: Syrah (syrah)
Date: 2003-09-11 00:45

Message:
Logged In: YES 
user_id=827529

I agree that this is a very strange error.  Python should be

directly calling the operating systems close function.  It

is very puzzling that there is an error.



I did include in my initial post a parent that sets up fd 3.

 I used bash.  I was able to test successfully with bash.  I

wrote a C program:



-------- test.c --------

#include <stdio.h>



int main () {

  int i = close (3);

  printf ("close: %i\n", i); }

--------



Using bash, I tested test.py, test2.py, and test.c (gcc

test.c -o test).  test.c behaved properly.  When I set up fd

3 with bash, test.c printed "close: 0".  When I did not set

up fd 3, test.c printed "close: -1".



I therefore have bash working properly, C working properly

and test2.py working properly.  The only thing that is not

working properly is test.py.  To me, it seems that I have

isolated the problem.



However, this problem only manifests on FreeBSD.  test.py

runs fine on Gentoo Linux.  At present, those are the only

two OSes I have easy access to.



So... if you really want a test program that sets up fd3,

I'll write one - let me know.  Would you prefer me to write

it in Python, C, PHP, Ruby, Perl?  I'd prefer C as it is

most direct.  But bash seems sufficient: "[bash]$ python

test.py 3> file" sets up file descriptor 3 so it writes into

a file named "file".



To look at it from another angle... is it possible that

Python, during its startup and initialization stuff messes

with file descriptor 3?  Is it possible it does this in some

really non-standard way?  Perhaps it does it indirectly by

calling some OS function that, as a side effect on FreeBSD

touches fd 3?  Something is going on with file descriptions

0-4 _every_ time python runs.  [Based on the ktrace's below,

it looks like



[syrah@ripple]$ python

Python 2.3 (#1, Sep  9 2003, 22:47:18) 

[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5

Type "help", "copyright", "credits" or "license" for more

information.

>>> import os 

>>> os.fstat (0)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206044,

1063206044, 1063206044)

>>> os.fstat (1)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206046,

1063206046, 1063206046)

>>> os.fstat (2)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206048,

1063206048, 1063206048)

>>> os.fstat (3)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (4)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (5)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

OSError: [Errno 9] Bad file descriptor

>>> 



Also, it is very strange that after calling os.fstat(3),

os.close(3) works.  This says to me that fd 3 is fine, but

Python thinks fd 3 is bogus, but

calling os.fstat (3) forces Python to check fd 3's real status.



I considered the possibility that os.fstat(x) will the next

os.close(x) to succeed, but that is not the case:



[bash]$ cat test3.py

import os

os.fstat (3)

os.close (3)

os.fstat (3)

os.close (3)



[bash]$ python test3.py 3> file

(an the error is raised on the second os.fstat(3) call, just

as you would expect)



Okay, here is your ktrace:



26520 python   GIO   fd 6 read 23 bytes

       "import os

        os.close (3)

       "

 26520 python   RET   read 23/0x17

 26520 python   CALL  write(0x2,0x80e6708,0x4)

 26520 python   GIO   fd 2 wrote 4 bytes

       "    "

 26520 python   RET   write 4

 26520 python   CALL  write(0x2,0xbfbfeb70,0xd)

 26520 python   GIO   fd 2 wrote 13 bytes

       "os.close (3)

       "

 26520 python   RET   write 13/0xd

 26520 python   CALL  fstat(0x6,0xbfbfe670)

 26520 python   RET   fstat 0

 26520 python   CALL  fcntl(0x6,0x3,0)

 26520 python   RET   fcntl 4

 26520 python   CALL  fcntl(0x6,0x4,0)

 26520 python   RET   fcntl 0

 26520 python   CALL  close(0x6)

 26520 python   RET   close 0

 26520 python   CALL  write(0x2,0x813a3b4,0x7)

 26520 python   GIO   fd 2 wrote 7 bytes

       "OSError"

 26520 python   RET   write 7

 26520 python   CALL  write(0x2,0x80dbe5f,0x2)

 26520 python   GIO   fd 2 wrote 2 bytes

       ": "

 26520 python   RET   write 2

 26520 python   CALL  write(0x2,0x81c5dfc,0x1d)

 26520 python   GIO   fd 2 wrote 29 bytes

       "[Errno 9] Bad file descriptor"

 26520 python   RET   write 29/0x1d

 26520 python   CALL  write(0x2,0x80e4d42,0x1)

 26520 python   GIO   fd 2 wrote 1 byte

       "

       "



Note that when I call os.close (3), python calls close(0x6),

so it looks like python is "mapping" the file description

numbers.  There are many other close calls the ktrace, but

_none_ of them close (0x3).  This says to me that (possibly)

python is doing lots of fd manipulation, but fd 3 is already

open, so python never uses it.



Here is a ktrace of test2.py.  It's very interesting.  6 is

fstated, closed, then 3 is fstated, fnctled, and closed

successfully.



 26498 python   GIO   fd 6 read 36 bytes

       "import os

        os.fstat (3)

        os.close (3)

       "

 26498 python   RET   read 36/0x24

 26498 python   CALL  lseek(0x6,0,0,0,0x1)

 26498 python   RET   lseek 36/0x24

 26498 python   CALL  read(0x6,0x8203000,0x4000)

 26498 python   GIO   fd 6 read 0 bytes

       ""

 26498 python   RET   read 0

 26498 python   CALL  fstat(0x6,0xbfbff450)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x6,0x3,0)

 26498 python   RET   fcntl 4

 26498 python   CALL  fcntl(0x6,0x4,0)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x6)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 1

 26498 python   CALL  fcntl(0x3,0x4,0x5)

 26498 python   RET   fcntl 0

 26498 python   CALL  fstat(0x3,0xbfbff290)

 26498 python   RET   fstat 0

 26498 python   CALL  fstat(0x3,0xbfbff260)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 5

 26498 python   CALL  fcntl(0x3,0x4,0x1)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x3)

 26498 python   RET   close 0

 26498 python   CALL  sigaction(0x2,0xbfbff4b0,0)

 26498 python   RET   sigaction 0

 26498 python   CALL  setitimer(0x2,0xbfbff5f0,0)

 26498 python   RET   setitimer 0

 26498 python   CALL  close(0x4)

 26498 python   RET   close 0

 26498 python   CALL  close(0x5)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0,0x3,0)

 26498 python   RET   fcntl 6

 26498 python   CALL  fcntl(0,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x1,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x1,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x2,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x2,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  exit(0)



Does fd 3 have some special significance on FreeBSD?  Or on

other OSes?  I'm aware of 0, 1 and 2 being stdin, out, err.

 But I didn't know that 3 was anything special.  And 3 is

what courier uses to communicate with its filters.



Okay... I just searched through the whole ktrace of test.py.

 As far as I can tell, nothing touches fd 3 in the whole

ktrace.  fcntl takes 0x3 as the second argument many times,

but that is a command, not a file descriptor.



So... this means that with test.py, Python decides (based on

an fstat (0x6)?) that os.close(3) will fail without ever

calling close(3) to see what will happen.



This could be a bug in FreeBSD.  But then why did my C

program work as expected?  Or perhaps there is a library

inbetween Python and the OS, a library that my c program

does not use.



Any suggestions for further diagnosis?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 22:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),

and reports an error if and only if the operating system

reports an error. So there is absolutely zero possibility

that the operatin system lets close(2) succeeed, yet python

returns OSError(9). As a consequence, if python raises

OSError(9), it was the operating system that has returned an

error before.



If you doubt this statement, please use ktrace/strace to

diagnose this further.



Also, if you *know* that a parent process has set up fd 3,

your test case is irrelevant. Your test case is only

meaningful in a context where a parent process has set up fd

3, however, you have not reported the code of that parent

process. Providing a minimal test case would be appreciated.

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

Comment By: Syrah (syrah)
Date: 2003-09-10 19:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 18:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Thu Sep 11 05:55:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 11 07:55:36 2003
Subject: [Python-bugs-list] [ python-Bugs-652749 ] extra __builtin__ stuff
	not documented
Message-ID: <E19xQ2u-0002BD-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: extra __builtin__ stuff not documented

Initial Comment:
The names that site.py adds to __builtin__ are not

document.  E.g. exit, quit, help, copyright, license,

credits.



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-11 07:55

Message:
Logged In: YES 
user_id=3066

I've started writing this.

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

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

From noreply at sourceforge.net  Thu Sep 11 09:46:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 11 11:46:35 2003
Subject: [Python-bugs-list] [ python-Bugs-804543 ] invalid use of setlocale
Message-ID: <E19xTeJ-0003M9-00@sc8-sf-web2.sourceforge.net>

Bugs item #804543, was opened at 2003-09-11 17:46
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=804543&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stanislav Brabec (sbrabec)
Assigned to: Nobody/Anonymous (nobody)
Summary: invalid use of setlocale

Initial Comment:
char *oldloc=setlocale(LC_CTYPE,NULL);

setlocale(LC_CTYPE, "C");

setlocale(LC_CTYPE, oldloc);



can cause strange problems.



The glibc documentation clearly states, that you must

make your own copy of the string.



>From glibc docs:

setlocale()



RETURN VALUE

       ... This  string  may  be allocated  in static

storage. ...



It means, that subsequent call of setlocale can

overwrite this string. And since glibc-2.3 it does.



There is a fix.



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

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

From noreply at sourceforge.net  Thu Sep 11 10:50:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 11 12:50:58 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19xUec-0001yc-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Syrah (syrah)
Date: 2003-09-11 16:50

Message:
Logged In: YES 
user_id=827529

Okay.  I think I have attached a tgz file with 3 programs, 3

binary ktraces, and the ktraces converted to text files.



In all cases, the programs were run as follows:



[bash]$ program 3> file



Many thanks for your continued interest.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 06:01

Message:
Logged In: YES 
user_id=21627

Was that the complete ktrace? I'm missing the point where it

outputs "Traceback (most recent call last):". If you have

stripped it down, can you please attach the entire thing

(please don't paste it)?

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

Comment By: Syrah (syrah)
Date: 2003-09-10 22:45

Message:
Logged In: YES 
user_id=827529

I agree that this is a very strange error.  Python should be

directly calling the operating systems close function.  It

is very puzzling that there is an error.



I did include in my initial post a parent that sets up fd 3.

 I used bash.  I was able to test successfully with bash.  I

wrote a C program:



-------- test.c --------

#include <stdio.h>



int main () {

  int i = close (3);

  printf ("close: %i\n", i); }

--------



Using bash, I tested test.py, test2.py, and test.c (gcc

test.c -o test).  test.c behaved properly.  When I set up fd

3 with bash, test.c printed "close: 0".  When I did not set

up fd 3, test.c printed "close: -1".



I therefore have bash working properly, C working properly

and test2.py working properly.  The only thing that is not

working properly is test.py.  To me, it seems that I have

isolated the problem.



However, this problem only manifests on FreeBSD.  test.py

runs fine on Gentoo Linux.  At present, those are the only

two OSes I have easy access to.



So... if you really want a test program that sets up fd3,

I'll write one - let me know.  Would you prefer me to write

it in Python, C, PHP, Ruby, Perl?  I'd prefer C as it is

most direct.  But bash seems sufficient: "[bash]$ python

test.py 3> file" sets up file descriptor 3 so it writes into

a file named "file".



To look at it from another angle... is it possible that

Python, during its startup and initialization stuff messes

with file descriptor 3?  Is it possible it does this in some

really non-standard way?  Perhaps it does it indirectly by

calling some OS function that, as a side effect on FreeBSD

touches fd 3?  Something is going on with file descriptions

0-4 _every_ time python runs.  [Based on the ktrace's below,

it looks like



[syrah@ripple]$ python

Python 2.3 (#1, Sep  9 2003, 22:47:18) 

[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5

Type "help", "copyright", "credits" or "license" for more

information.

>>> import os 

>>> os.fstat (0)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206044,

1063206044, 1063206044)

>>> os.fstat (1)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206046,

1063206046, 1063206046)

>>> os.fstat (2)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206048,

1063206048, 1063206048)

>>> os.fstat (3)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (4)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (5)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

OSError: [Errno 9] Bad file descriptor

>>> 



Also, it is very strange that after calling os.fstat(3),

os.close(3) works.  This says to me that fd 3 is fine, but

Python thinks fd 3 is bogus, but

calling os.fstat (3) forces Python to check fd 3's real status.



I considered the possibility that os.fstat(x) will the next

os.close(x) to succeed, but that is not the case:



[bash]$ cat test3.py

import os

os.fstat (3)

os.close (3)

os.fstat (3)

os.close (3)



[bash]$ python test3.py 3> file

(an the error is raised on the second os.fstat(3) call, just

as you would expect)



Okay, here is your ktrace:



26520 python   GIO   fd 6 read 23 bytes

       "import os

        os.close (3)

       "

 26520 python   RET   read 23/0x17

 26520 python   CALL  write(0x2,0x80e6708,0x4)

 26520 python   GIO   fd 2 wrote 4 bytes

       "    "

 26520 python   RET   write 4

 26520 python   CALL  write(0x2,0xbfbfeb70,0xd)

 26520 python   GIO   fd 2 wrote 13 bytes

       "os.close (3)

       "

 26520 python   RET   write 13/0xd

 26520 python   CALL  fstat(0x6,0xbfbfe670)

 26520 python   RET   fstat 0

 26520 python   CALL  fcntl(0x6,0x3,0)

 26520 python   RET   fcntl 4

 26520 python   CALL  fcntl(0x6,0x4,0)

 26520 python   RET   fcntl 0

 26520 python   CALL  close(0x6)

 26520 python   RET   close 0

 26520 python   CALL  write(0x2,0x813a3b4,0x7)

 26520 python   GIO   fd 2 wrote 7 bytes

       "OSError"

 26520 python   RET   write 7

 26520 python   CALL  write(0x2,0x80dbe5f,0x2)

 26520 python   GIO   fd 2 wrote 2 bytes

       ": "

 26520 python   RET   write 2

 26520 python   CALL  write(0x2,0x81c5dfc,0x1d)

 26520 python   GIO   fd 2 wrote 29 bytes

       "[Errno 9] Bad file descriptor"

 26520 python   RET   write 29/0x1d

 26520 python   CALL  write(0x2,0x80e4d42,0x1)

 26520 python   GIO   fd 2 wrote 1 byte

       "

       "



Note that when I call os.close (3), python calls close(0x6),

so it looks like python is "mapping" the file description

numbers.  There are many other close calls the ktrace, but

_none_ of them close (0x3).  This says to me that (possibly)

python is doing lots of fd manipulation, but fd 3 is already

open, so python never uses it.



Here is a ktrace of test2.py.  It's very interesting.  6 is

fstated, closed, then 3 is fstated, fnctled, and closed

successfully.



 26498 python   GIO   fd 6 read 36 bytes

       "import os

        os.fstat (3)

        os.close (3)

       "

 26498 python   RET   read 36/0x24

 26498 python   CALL  lseek(0x6,0,0,0,0x1)

 26498 python   RET   lseek 36/0x24

 26498 python   CALL  read(0x6,0x8203000,0x4000)

 26498 python   GIO   fd 6 read 0 bytes

       ""

 26498 python   RET   read 0

 26498 python   CALL  fstat(0x6,0xbfbff450)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x6,0x3,0)

 26498 python   RET   fcntl 4

 26498 python   CALL  fcntl(0x6,0x4,0)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x6)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 1

 26498 python   CALL  fcntl(0x3,0x4,0x5)

 26498 python   RET   fcntl 0

 26498 python   CALL  fstat(0x3,0xbfbff290)

 26498 python   RET   fstat 0

 26498 python   CALL  fstat(0x3,0xbfbff260)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 5

 26498 python   CALL  fcntl(0x3,0x4,0x1)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x3)

 26498 python   RET   close 0

 26498 python   CALL  sigaction(0x2,0xbfbff4b0,0)

 26498 python   RET   sigaction 0

 26498 python   CALL  setitimer(0x2,0xbfbff5f0,0)

 26498 python   RET   setitimer 0

 26498 python   CALL  close(0x4)

 26498 python   RET   close 0

 26498 python   CALL  close(0x5)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0,0x3,0)

 26498 python   RET   fcntl 6

 26498 python   CALL  fcntl(0,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x1,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x1,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x2,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x2,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  exit(0)



Does fd 3 have some special significance on FreeBSD?  Or on

other OSes?  I'm aware of 0, 1 and 2 being stdin, out, err.

 But I didn't know that 3 was anything special.  And 3 is

what courier uses to communicate with its filters.



Okay... I just searched through the whole ktrace of test.py.

 As far as I can tell, nothing touches fd 3 in the whole

ktrace.  fcntl takes 0x3 as the second argument many times,

but that is a command, not a file descriptor.



So... this means that with test.py, Python decides (based on

an fstat (0x6)?) that os.close(3) will fail without ever

calling close(3) to see what will happen.



This could be a bug in FreeBSD.  But then why did my C

program work as expected?  Or perhaps there is a library

inbetween Python and the OS, a library that my c program

does not use.



Any suggestions for further diagnosis?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 20:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),

and reports an error if and only if the operating system

reports an error. So there is absolutely zero possibility

that the operatin system lets close(2) succeeed, yet python

returns OSError(9). As a consequence, if python raises

OSError(9), it was the operating system that has returned an

error before.



If you doubt this statement, please use ktrace/strace to

diagnose this further.



Also, if you *know* that a parent process has set up fd 3,

your test case is irrelevant. Your test case is only

meaningful in a context where a parent process has set up fd

3, however, you have not reported the code of that parent

process. Providing a minimal test case would be appreciated.

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

Comment By: Syrah (syrah)
Date: 2003-09-10 17:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 16:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Thu Sep 11 16:06:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 11 18:06:51 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19xZaN-0004yT-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-12 00:06

Message:
Logged In: YES 
user_id=21627

I think you are misinterpreting the ktrace output. fd 6 is

the source code file, test.py, which can be seen by looking

at the read result for fd 6. Unfortunately, there is no

corresponding open call opening the file... (there is a

second open call for test.py, when Python opens the file to

print the backtrace, but there should be an earlier call).



If this ktrace output can be trusted, it appears that Python

does not call os.open(3) at all, but immediately decides on

an error - which could happen if errno was somehow

overwritten. However, I doubt that ktrace output, since it

fails to report the first open of test.py, which I know must

be there.



I recommend to run this under a debugger, and break at

posix_open.

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

Comment By: Syrah (syrah)
Date: 2003-09-11 18:50

Message:
Logged In: YES 
user_id=827529

Okay.  I think I have attached a tgz file with 3 programs, 3

binary ktraces, and the ktraces converted to text files.



In all cases, the programs were run as follows:



[bash]$ program 3> file



Many thanks for your continued interest.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 08:01

Message:
Logged In: YES 
user_id=21627

Was that the complete ktrace? I'm missing the point where it

outputs "Traceback (most recent call last):". If you have

stripped it down, can you please attach the entire thing

(please don't paste it)?

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

Comment By: Syrah (syrah)
Date: 2003-09-11 00:45

Message:
Logged In: YES 
user_id=827529

I agree that this is a very strange error.  Python should be

directly calling the operating systems close function.  It

is very puzzling that there is an error.



I did include in my initial post a parent that sets up fd 3.

 I used bash.  I was able to test successfully with bash.  I

wrote a C program:



-------- test.c --------

#include <stdio.h>



int main () {

  int i = close (3);

  printf ("close: %i\n", i); }

--------



Using bash, I tested test.py, test2.py, and test.c (gcc

test.c -o test).  test.c behaved properly.  When I set up fd

3 with bash, test.c printed "close: 0".  When I did not set

up fd 3, test.c printed "close: -1".



I therefore have bash working properly, C working properly

and test2.py working properly.  The only thing that is not

working properly is test.py.  To me, it seems that I have

isolated the problem.



However, this problem only manifests on FreeBSD.  test.py

runs fine on Gentoo Linux.  At present, those are the only

two OSes I have easy access to.



So... if you really want a test program that sets up fd3,

I'll write one - let me know.  Would you prefer me to write

it in Python, C, PHP, Ruby, Perl?  I'd prefer C as it is

most direct.  But bash seems sufficient: "[bash]$ python

test.py 3> file" sets up file descriptor 3 so it writes into

a file named "file".



To look at it from another angle... is it possible that

Python, during its startup and initialization stuff messes

with file descriptor 3?  Is it possible it does this in some

really non-standard way?  Perhaps it does it indirectly by

calling some OS function that, as a side effect on FreeBSD

touches fd 3?  Something is going on with file descriptions

0-4 _every_ time python runs.  [Based on the ktrace's below,

it looks like



[syrah@ripple]$ python

Python 2.3 (#1, Sep  9 2003, 22:47:18) 

[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5

Type "help", "copyright", "credits" or "license" for more

information.

>>> import os 

>>> os.fstat (0)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206044,

1063206044, 1063206044)

>>> os.fstat (1)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206046,

1063206046, 1063206046)

>>> os.fstat (2)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206048,

1063206048, 1063206048)

>>> os.fstat (3)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (4)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (5)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

OSError: [Errno 9] Bad file descriptor

>>> 



Also, it is very strange that after calling os.fstat(3),

os.close(3) works.  This says to me that fd 3 is fine, but

Python thinks fd 3 is bogus, but

calling os.fstat (3) forces Python to check fd 3's real status.



I considered the possibility that os.fstat(x) will the next

os.close(x) to succeed, but that is not the case:



[bash]$ cat test3.py

import os

os.fstat (3)

os.close (3)

os.fstat (3)

os.close (3)



[bash]$ python test3.py 3> file

(an the error is raised on the second os.fstat(3) call, just

as you would expect)



Okay, here is your ktrace:



26520 python   GIO   fd 6 read 23 bytes

       "import os

        os.close (3)

       "

 26520 python   RET   read 23/0x17

 26520 python   CALL  write(0x2,0x80e6708,0x4)

 26520 python   GIO   fd 2 wrote 4 bytes

       "    "

 26520 python   RET   write 4

 26520 python   CALL  write(0x2,0xbfbfeb70,0xd)

 26520 python   GIO   fd 2 wrote 13 bytes

       "os.close (3)

       "

 26520 python   RET   write 13/0xd

 26520 python   CALL  fstat(0x6,0xbfbfe670)

 26520 python   RET   fstat 0

 26520 python   CALL  fcntl(0x6,0x3,0)

 26520 python   RET   fcntl 4

 26520 python   CALL  fcntl(0x6,0x4,0)

 26520 python   RET   fcntl 0

 26520 python   CALL  close(0x6)

 26520 python   RET   close 0

 26520 python   CALL  write(0x2,0x813a3b4,0x7)

 26520 python   GIO   fd 2 wrote 7 bytes

       "OSError"

 26520 python   RET   write 7

 26520 python   CALL  write(0x2,0x80dbe5f,0x2)

 26520 python   GIO   fd 2 wrote 2 bytes

       ": "

 26520 python   RET   write 2

 26520 python   CALL  write(0x2,0x81c5dfc,0x1d)

 26520 python   GIO   fd 2 wrote 29 bytes

       "[Errno 9] Bad file descriptor"

 26520 python   RET   write 29/0x1d

 26520 python   CALL  write(0x2,0x80e4d42,0x1)

 26520 python   GIO   fd 2 wrote 1 byte

       "

       "



Note that when I call os.close (3), python calls close(0x6),

so it looks like python is "mapping" the file description

numbers.  There are many other close calls the ktrace, but

_none_ of them close (0x3).  This says to me that (possibly)

python is doing lots of fd manipulation, but fd 3 is already

open, so python never uses it.



Here is a ktrace of test2.py.  It's very interesting.  6 is

fstated, closed, then 3 is fstated, fnctled, and closed

successfully.



 26498 python   GIO   fd 6 read 36 bytes

       "import os

        os.fstat (3)

        os.close (3)

       "

 26498 python   RET   read 36/0x24

 26498 python   CALL  lseek(0x6,0,0,0,0x1)

 26498 python   RET   lseek 36/0x24

 26498 python   CALL  read(0x6,0x8203000,0x4000)

 26498 python   GIO   fd 6 read 0 bytes

       ""

 26498 python   RET   read 0

 26498 python   CALL  fstat(0x6,0xbfbff450)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x6,0x3,0)

 26498 python   RET   fcntl 4

 26498 python   CALL  fcntl(0x6,0x4,0)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x6)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 1

 26498 python   CALL  fcntl(0x3,0x4,0x5)

 26498 python   RET   fcntl 0

 26498 python   CALL  fstat(0x3,0xbfbff290)

 26498 python   RET   fstat 0

 26498 python   CALL  fstat(0x3,0xbfbff260)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 5

 26498 python   CALL  fcntl(0x3,0x4,0x1)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x3)

 26498 python   RET   close 0

 26498 python   CALL  sigaction(0x2,0xbfbff4b0,0)

 26498 python   RET   sigaction 0

 26498 python   CALL  setitimer(0x2,0xbfbff5f0,0)

 26498 python   RET   setitimer 0

 26498 python   CALL  close(0x4)

 26498 python   RET   close 0

 26498 python   CALL  close(0x5)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0,0x3,0)

 26498 python   RET   fcntl 6

 26498 python   CALL  fcntl(0,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x1,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x1,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x2,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x2,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  exit(0)



Does fd 3 have some special significance on FreeBSD?  Or on

other OSes?  I'm aware of 0, 1 and 2 being stdin, out, err.

 But I didn't know that 3 was anything special.  And 3 is

what courier uses to communicate with its filters.



Okay... I just searched through the whole ktrace of test.py.

 As far as I can tell, nothing touches fd 3 in the whole

ktrace.  fcntl takes 0x3 as the second argument many times,

but that is a command, not a file descriptor.



So... this means that with test.py, Python decides (based on

an fstat (0x6)?) that os.close(3) will fail without ever

calling close(3) to see what will happen.



This could be a bug in FreeBSD.  But then why did my C

program work as expected?  Or perhaps there is a library

inbetween Python and the OS, a library that my c program

does not use.



Any suggestions for further diagnosis?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 22:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),

and reports an error if and only if the operating system

reports an error. So there is absolutely zero possibility

that the operatin system lets close(2) succeeed, yet python

returns OSError(9). As a consequence, if python raises

OSError(9), it was the operating system that has returned an

error before.



If you doubt this statement, please use ktrace/strace to

diagnose this further.



Also, if you *know* that a parent process has set up fd 3,

your test case is irrelevant. Your test case is only

meaningful in a context where a parent process has set up fd

3, however, you have not reported the code of that parent

process. Providing a minimal test case would be appreciated.

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

Comment By: Syrah (syrah)
Date: 2003-09-10 19:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 18:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Thu Sep 11 18:11:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 11 20:11:45 2003
Subject: [Python-bugs-list] [ python-Bugs-804115 ] bad argument
	handling(unittest.py)
Message-ID: <E19xbXI-000626-00@sc8-sf-web1.sourceforge.net>

Bugs item #804115, was opened at 2003-09-10 20:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: bad argument handling(unittest.py)

Initial Comment:
_WritelnDecorator.writeln method handles arbitrary 

number of argumetns badly.



In the following part,



    def writeln(self, *args):

        if args: self.write(*args)



since _WritelnDecorator's stream is by default 

sys.stderr,

sys.stderr.write() takes exactly one argument.



If you give more than one argument to writeln 

method,

TypeError is raised.

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

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

From noreply at sourceforge.net  Thu Sep 11 18:55:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 11 20:56:05 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19xcDx-0002rl-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Syrah (syrah)
Date: 2003-09-12 00:55

Message:
Logged In: YES 
user_id=827529

I think fd6 is created in the pipe call.  But why is pipe

returning 4?  It should return 0 or -1, shouldn't it?



Do I need to recomiple python (so that debug info is added

to the executable) to attach the debugger to it?



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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 22:06

Message:
Logged In: YES 
user_id=21627

I think you are misinterpreting the ktrace output. fd 6 is

the source code file, test.py, which can be seen by looking

at the read result for fd 6. Unfortunately, there is no

corresponding open call opening the file... (there is a

second open call for test.py, when Python opens the file to

print the backtrace, but there should be an earlier call).



If this ktrace output can be trusted, it appears that Python

does not call os.open(3) at all, but immediately decides on

an error - which could happen if errno was somehow

overwritten. However, I doubt that ktrace output, since it

fails to report the first open of test.py, which I know must

be there.



I recommend to run this under a debugger, and break at

posix_open.

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

Comment By: Syrah (syrah)
Date: 2003-09-11 16:50

Message:
Logged In: YES 
user_id=827529

Okay.  I think I have attached a tgz file with 3 programs, 3

binary ktraces, and the ktraces converted to text files.



In all cases, the programs were run as follows:



[bash]$ program 3> file



Many thanks for your continued interest.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 06:01

Message:
Logged In: YES 
user_id=21627

Was that the complete ktrace? I'm missing the point where it

outputs "Traceback (most recent call last):". If you have

stripped it down, can you please attach the entire thing

(please don't paste it)?

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

Comment By: Syrah (syrah)
Date: 2003-09-10 22:45

Message:
Logged In: YES 
user_id=827529

I agree that this is a very strange error.  Python should be

directly calling the operating systems close function.  It

is very puzzling that there is an error.



I did include in my initial post a parent that sets up fd 3.

 I used bash.  I was able to test successfully with bash.  I

wrote a C program:



-------- test.c --------

#include <stdio.h>



int main () {

  int i = close (3);

  printf ("close: %i\n", i); }

--------



Using bash, I tested test.py, test2.py, and test.c (gcc

test.c -o test).  test.c behaved properly.  When I set up fd

3 with bash, test.c printed "close: 0".  When I did not set

up fd 3, test.c printed "close: -1".



I therefore have bash working properly, C working properly

and test2.py working properly.  The only thing that is not

working properly is test.py.  To me, it seems that I have

isolated the problem.



However, this problem only manifests on FreeBSD.  test.py

runs fine on Gentoo Linux.  At present, those are the only

two OSes I have easy access to.



So... if you really want a test program that sets up fd3,

I'll write one - let me know.  Would you prefer me to write

it in Python, C, PHP, Ruby, Perl?  I'd prefer C as it is

most direct.  But bash seems sufficient: "[bash]$ python

test.py 3> file" sets up file descriptor 3 so it writes into

a file named "file".



To look at it from another angle... is it possible that

Python, during its startup and initialization stuff messes

with file descriptor 3?  Is it possible it does this in some

really non-standard way?  Perhaps it does it indirectly by

calling some OS function that, as a side effect on FreeBSD

touches fd 3?  Something is going on with file descriptions

0-4 _every_ time python runs.  [Based on the ktrace's below,

it looks like



[syrah@ripple]$ python

Python 2.3 (#1, Sep  9 2003, 22:47:18) 

[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5

Type "help", "copyright", "credits" or "license" for more

information.

>>> import os 

>>> os.fstat (0)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206044,

1063206044, 1063206044)

>>> os.fstat (1)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206046,

1063206046, 1063206046)

>>> os.fstat (2)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206048,

1063206048, 1063206048)

>>> os.fstat (3)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (4)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (5)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

OSError: [Errno 9] Bad file descriptor

>>> 



Also, it is very strange that after calling os.fstat(3),

os.close(3) works.  This says to me that fd 3 is fine, but

Python thinks fd 3 is bogus, but

calling os.fstat (3) forces Python to check fd 3's real status.



I considered the possibility that os.fstat(x) will the next

os.close(x) to succeed, but that is not the case:



[bash]$ cat test3.py

import os

os.fstat (3)

os.close (3)

os.fstat (3)

os.close (3)



[bash]$ python test3.py 3> file

(an the error is raised on the second os.fstat(3) call, just

as you would expect)



Okay, here is your ktrace:



26520 python   GIO   fd 6 read 23 bytes

       "import os

        os.close (3)

       "

 26520 python   RET   read 23/0x17

 26520 python   CALL  write(0x2,0x80e6708,0x4)

 26520 python   GIO   fd 2 wrote 4 bytes

       "    "

 26520 python   RET   write 4

 26520 python   CALL  write(0x2,0xbfbfeb70,0xd)

 26520 python   GIO   fd 2 wrote 13 bytes

       "os.close (3)

       "

 26520 python   RET   write 13/0xd

 26520 python   CALL  fstat(0x6,0xbfbfe670)

 26520 python   RET   fstat 0

 26520 python   CALL  fcntl(0x6,0x3,0)

 26520 python   RET   fcntl 4

 26520 python   CALL  fcntl(0x6,0x4,0)

 26520 python   RET   fcntl 0

 26520 python   CALL  close(0x6)

 26520 python   RET   close 0

 26520 python   CALL  write(0x2,0x813a3b4,0x7)

 26520 python   GIO   fd 2 wrote 7 bytes

       "OSError"

 26520 python   RET   write 7

 26520 python   CALL  write(0x2,0x80dbe5f,0x2)

 26520 python   GIO   fd 2 wrote 2 bytes

       ": "

 26520 python   RET   write 2

 26520 python   CALL  write(0x2,0x81c5dfc,0x1d)

 26520 python   GIO   fd 2 wrote 29 bytes

       "[Errno 9] Bad file descriptor"

 26520 python   RET   write 29/0x1d

 26520 python   CALL  write(0x2,0x80e4d42,0x1)

 26520 python   GIO   fd 2 wrote 1 byte

       "

       "



Note that when I call os.close (3), python calls close(0x6),

so it looks like python is "mapping" the file description

numbers.  There are many other close calls the ktrace, but

_none_ of them close (0x3).  This says to me that (possibly)

python is doing lots of fd manipulation, but fd 3 is already

open, so python never uses it.



Here is a ktrace of test2.py.  It's very interesting.  6 is

fstated, closed, then 3 is fstated, fnctled, and closed

successfully.



 26498 python   GIO   fd 6 read 36 bytes

       "import os

        os.fstat (3)

        os.close (3)

       "

 26498 python   RET   read 36/0x24

 26498 python   CALL  lseek(0x6,0,0,0,0x1)

 26498 python   RET   lseek 36/0x24

 26498 python   CALL  read(0x6,0x8203000,0x4000)

 26498 python   GIO   fd 6 read 0 bytes

       ""

 26498 python   RET   read 0

 26498 python   CALL  fstat(0x6,0xbfbff450)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x6,0x3,0)

 26498 python   RET   fcntl 4

 26498 python   CALL  fcntl(0x6,0x4,0)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x6)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 1

 26498 python   CALL  fcntl(0x3,0x4,0x5)

 26498 python   RET   fcntl 0

 26498 python   CALL  fstat(0x3,0xbfbff290)

 26498 python   RET   fstat 0

 26498 python   CALL  fstat(0x3,0xbfbff260)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 5

 26498 python   CALL  fcntl(0x3,0x4,0x1)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x3)

 26498 python   RET   close 0

 26498 python   CALL  sigaction(0x2,0xbfbff4b0,0)

 26498 python   RET   sigaction 0

 26498 python   CALL  setitimer(0x2,0xbfbff5f0,0)

 26498 python   RET   setitimer 0

 26498 python   CALL  close(0x4)

 26498 python   RET   close 0

 26498 python   CALL  close(0x5)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0,0x3,0)

 26498 python   RET   fcntl 6

 26498 python   CALL  fcntl(0,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x1,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x1,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x2,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x2,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  exit(0)



Does fd 3 have some special significance on FreeBSD?  Or on

other OSes?  I'm aware of 0, 1 and 2 being stdin, out, err.

 But I didn't know that 3 was anything special.  And 3 is

what courier uses to communicate with its filters.



Okay... I just searched through the whole ktrace of test.py.

 As far as I can tell, nothing touches fd 3 in the whole

ktrace.  fcntl takes 0x3 as the second argument many times,

but that is a command, not a file descriptor.



So... this means that with test.py, Python decides (based on

an fstat (0x6)?) that os.close(3) will fail without ever

calling close(3) to see what will happen.



This could be a bug in FreeBSD.  But then why did my C

program work as expected?  Or perhaps there is a library

inbetween Python and the OS, a library that my c program

does not use.



Any suggestions for further diagnosis?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 20:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),

and reports an error if and only if the operating system

reports an error. So there is absolutely zero possibility

that the operatin system lets close(2) succeeed, yet python

returns OSError(9). As a consequence, if python raises

OSError(9), it was the operating system that has returned an

error before.



If you doubt this statement, please use ktrace/strace to

diagnose this further.



Also, if you *know* that a parent process has set up fd 3,

your test case is irrelevant. Your test case is only

meaningful in a context where a parent process has set up fd

3, however, you have not reported the code of that parent

process. Providing a minimal test case would be appreciated.

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

Comment By: Syrah (syrah)
Date: 2003-09-10 17:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 16:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Thu Sep 11 19:13:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 11 21:13:17 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19xcUp-0007mU-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Syrah (syrah)
Date: 2003-09-12 01:13

Message:
Logged In: YES 
user_id=827529

Well... I just got a FreeBSD 4.8 machine running.  (FreeBSD

5.1 is billed as experimental.)



The problem does NOT manifest on FreeBSD 4.8.  They are both

running Python 2.3.  (Although the 5.1 machine has

portrevision 1, whereas the 4.8 machine has portrevision 0.

 But they use the same sourcecode tarball.)



So... I'm willing to close out the bug report and assume

that the bug is in FreeBSD 5.1 somewhere.  If in the future

I determine otherwise, I'll reopen the bug then.



Let me know what you think.  Many thanks for all your help.

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

Comment By: Syrah (syrah)
Date: 2003-09-12 00:55

Message:
Logged In: YES 
user_id=827529

I think fd6 is created in the pipe call.  But why is pipe

returning 4?  It should return 0 or -1, shouldn't it?



Do I need to recomiple python (so that debug info is added

to the executable) to attach the debugger to it?



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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 22:06

Message:
Logged In: YES 
user_id=21627

I think you are misinterpreting the ktrace output. fd 6 is

the source code file, test.py, which can be seen by looking

at the read result for fd 6. Unfortunately, there is no

corresponding open call opening the file... (there is a

second open call for test.py, when Python opens the file to

print the backtrace, but there should be an earlier call).



If this ktrace output can be trusted, it appears that Python

does not call os.open(3) at all, but immediately decides on

an error - which could happen if errno was somehow

overwritten. However, I doubt that ktrace output, since it

fails to report the first open of test.py, which I know must

be there.



I recommend to run this under a debugger, and break at

posix_open.

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

Comment By: Syrah (syrah)
Date: 2003-09-11 16:50

Message:
Logged In: YES 
user_id=827529

Okay.  I think I have attached a tgz file with 3 programs, 3

binary ktraces, and the ktraces converted to text files.



In all cases, the programs were run as follows:



[bash]$ program 3> file



Many thanks for your continued interest.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 06:01

Message:
Logged In: YES 
user_id=21627

Was that the complete ktrace? I'm missing the point where it

outputs "Traceback (most recent call last):". If you have

stripped it down, can you please attach the entire thing

(please don't paste it)?

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

Comment By: Syrah (syrah)
Date: 2003-09-10 22:45

Message:
Logged In: YES 
user_id=827529

I agree that this is a very strange error.  Python should be

directly calling the operating systems close function.  It

is very puzzling that there is an error.



I did include in my initial post a parent that sets up fd 3.

 I used bash.  I was able to test successfully with bash.  I

wrote a C program:



-------- test.c --------

#include <stdio.h>



int main () {

  int i = close (3);

  printf ("close: %i\n", i); }

--------



Using bash, I tested test.py, test2.py, and test.c (gcc

test.c -o test).  test.c behaved properly.  When I set up fd

3 with bash, test.c printed "close: 0".  When I did not set

up fd 3, test.c printed "close: -1".



I therefore have bash working properly, C working properly

and test2.py working properly.  The only thing that is not

working properly is test.py.  To me, it seems that I have

isolated the problem.



However, this problem only manifests on FreeBSD.  test.py

runs fine on Gentoo Linux.  At present, those are the only

two OSes I have easy access to.



So... if you really want a test program that sets up fd3,

I'll write one - let me know.  Would you prefer me to write

it in Python, C, PHP, Ruby, Perl?  I'd prefer C as it is

most direct.  But bash seems sufficient: "[bash]$ python

test.py 3> file" sets up file descriptor 3 so it writes into

a file named "file".



To look at it from another angle... is it possible that

Python, during its startup and initialization stuff messes

with file descriptor 3?  Is it possible it does this in some

really non-standard way?  Perhaps it does it indirectly by

calling some OS function that, as a side effect on FreeBSD

touches fd 3?  Something is going on with file descriptions

0-4 _every_ time python runs.  [Based on the ktrace's below,

it looks like



[syrah@ripple]$ python

Python 2.3 (#1, Sep  9 2003, 22:47:18) 

[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5

Type "help", "copyright", "credits" or "license" for more

information.

>>> import os 

>>> os.fstat (0)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206044,

1063206044, 1063206044)

>>> os.fstat (1)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206046,

1063206046, 1063206046)

>>> os.fstat (2)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206048,

1063206048, 1063206048)

>>> os.fstat (3)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (4)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (5)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

OSError: [Errno 9] Bad file descriptor

>>> 



Also, it is very strange that after calling os.fstat(3),

os.close(3) works.  This says to me that fd 3 is fine, but

Python thinks fd 3 is bogus, but

calling os.fstat (3) forces Python to check fd 3's real status.



I considered the possibility that os.fstat(x) will the next

os.close(x) to succeed, but that is not the case:



[bash]$ cat test3.py

import os

os.fstat (3)

os.close (3)

os.fstat (3)

os.close (3)



[bash]$ python test3.py 3> file

(an the error is raised on the second os.fstat(3) call, just

as you would expect)



Okay, here is your ktrace:



26520 python   GIO   fd 6 read 23 bytes

       "import os

        os.close (3)

       "

 26520 python   RET   read 23/0x17

 26520 python   CALL  write(0x2,0x80e6708,0x4)

 26520 python   GIO   fd 2 wrote 4 bytes

       "    "

 26520 python   RET   write 4

 26520 python   CALL  write(0x2,0xbfbfeb70,0xd)

 26520 python   GIO   fd 2 wrote 13 bytes

       "os.close (3)

       "

 26520 python   RET   write 13/0xd

 26520 python   CALL  fstat(0x6,0xbfbfe670)

 26520 python   RET   fstat 0

 26520 python   CALL  fcntl(0x6,0x3,0)

 26520 python   RET   fcntl 4

 26520 python   CALL  fcntl(0x6,0x4,0)

 26520 python   RET   fcntl 0

 26520 python   CALL  close(0x6)

 26520 python   RET   close 0

 26520 python   CALL  write(0x2,0x813a3b4,0x7)

 26520 python   GIO   fd 2 wrote 7 bytes

       "OSError"

 26520 python   RET   write 7

 26520 python   CALL  write(0x2,0x80dbe5f,0x2)

 26520 python   GIO   fd 2 wrote 2 bytes

       ": "

 26520 python   RET   write 2

 26520 python   CALL  write(0x2,0x81c5dfc,0x1d)

 26520 python   GIO   fd 2 wrote 29 bytes

       "[Errno 9] Bad file descriptor"

 26520 python   RET   write 29/0x1d

 26520 python   CALL  write(0x2,0x80e4d42,0x1)

 26520 python   GIO   fd 2 wrote 1 byte

       "

       "



Note that when I call os.close (3), python calls close(0x6),

so it looks like python is "mapping" the file description

numbers.  There are many other close calls the ktrace, but

_none_ of them close (0x3).  This says to me that (possibly)

python is doing lots of fd manipulation, but fd 3 is already

open, so python never uses it.



Here is a ktrace of test2.py.  It's very interesting.  6 is

fstated, closed, then 3 is fstated, fnctled, and closed

successfully.



 26498 python   GIO   fd 6 read 36 bytes

       "import os

        os.fstat (3)

        os.close (3)

       "

 26498 python   RET   read 36/0x24

 26498 python   CALL  lseek(0x6,0,0,0,0x1)

 26498 python   RET   lseek 36/0x24

 26498 python   CALL  read(0x6,0x8203000,0x4000)

 26498 python   GIO   fd 6 read 0 bytes

       ""

 26498 python   RET   read 0

 26498 python   CALL  fstat(0x6,0xbfbff450)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x6,0x3,0)

 26498 python   RET   fcntl 4

 26498 python   CALL  fcntl(0x6,0x4,0)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x6)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 1

 26498 python   CALL  fcntl(0x3,0x4,0x5)

 26498 python   RET   fcntl 0

 26498 python   CALL  fstat(0x3,0xbfbff290)

 26498 python   RET   fstat 0

 26498 python   CALL  fstat(0x3,0xbfbff260)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 5

 26498 python   CALL  fcntl(0x3,0x4,0x1)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x3)

 26498 python   RET   close 0

 26498 python   CALL  sigaction(0x2,0xbfbff4b0,0)

 26498 python   RET   sigaction 0

 26498 python   CALL  setitimer(0x2,0xbfbff5f0,0)

 26498 python   RET   setitimer 0

 26498 python   CALL  close(0x4)

 26498 python   RET   close 0

 26498 python   CALL  close(0x5)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0,0x3,0)

 26498 python   RET   fcntl 6

 26498 python   CALL  fcntl(0,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x1,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x1,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x2,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x2,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  exit(0)



Does fd 3 have some special significance on FreeBSD?  Or on

other OSes?  I'm aware of 0, 1 and 2 being stdin, out, err.

 But I didn't know that 3 was anything special.  And 3 is

what courier uses to communicate with its filters.



Okay... I just searched through the whole ktrace of test.py.

 As far as I can tell, nothing touches fd 3 in the whole

ktrace.  fcntl takes 0x3 as the second argument many times,

but that is a command, not a file descriptor.



So... this means that with test.py, Python decides (based on

an fstat (0x6)?) that os.close(3) will fail without ever

calling close(3) to see what will happen.



This could be a bug in FreeBSD.  But then why did my C

program work as expected?  Or perhaps there is a library

inbetween Python and the OS, a library that my c program

does not use.



Any suggestions for further diagnosis?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 20:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),

and reports an error if and only if the operating system

reports an error. So there is absolutely zero possibility

that the operatin system lets close(2) succeeed, yet python

returns OSError(9). As a consequence, if python raises

OSError(9), it was the operating system that has returned an

error before.



If you doubt this statement, please use ktrace/strace to

diagnose this further.



Also, if you *know* that a parent process has set up fd 3,

your test case is irrelevant. Your test case is only

meaningful in a context where a parent process has set up fd

3, however, you have not reported the code of that parent

process. Providing a minimal test case would be appreciated.

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

Comment By: Syrah (syrah)
Date: 2003-09-10 17:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 16:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Thu Sep 11 23:44:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 01:44:07 2003
Subject: [Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises
	OSError: [Errno 9] Bad file descriptor
Message-ID: <E19xgiv-00058L-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah@ripple filter]$ cat test.py

import os

os.close (3)



[syrah@ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah@ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah@ripple filter]$ python test2.py 3> file



[syrah@ripple filter]$   (success!)



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

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-12 07:44

Message:
Logged In: YES 
user_id=21627

Ok, closing it.

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

Comment By: Syrah (syrah)
Date: 2003-09-12 03:13

Message:
Logged In: YES 
user_id=827529

Well... I just got a FreeBSD 4.8 machine running.  (FreeBSD

5.1 is billed as experimental.)



The problem does NOT manifest on FreeBSD 4.8.  They are both

running Python 2.3.  (Although the 5.1 machine has

portrevision 1, whereas the 4.8 machine has portrevision 0.

 But they use the same sourcecode tarball.)



So... I'm willing to close out the bug report and assume

that the bug is in FreeBSD 5.1 somewhere.  If in the future

I determine otherwise, I'll reopen the bug then.



Let me know what you think.  Many thanks for all your help.

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

Comment By: Syrah (syrah)
Date: 2003-09-12 02:55

Message:
Logged In: YES 
user_id=827529

I think fd6 is created in the pipe call.  But why is pipe

returning 4?  It should return 0 or -1, shouldn't it?



Do I need to recomiple python (so that debug info is added

to the executable) to attach the debugger to it?



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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-12 00:06

Message:
Logged In: YES 
user_id=21627

I think you are misinterpreting the ktrace output. fd 6 is

the source code file, test.py, which can be seen by looking

at the read result for fd 6. Unfortunately, there is no

corresponding open call opening the file... (there is a

second open call for test.py, when Python opens the file to

print the backtrace, but there should be an earlier call).



If this ktrace output can be trusted, it appears that Python

does not call os.open(3) at all, but immediately decides on

an error - which could happen if errno was somehow

overwritten. However, I doubt that ktrace output, since it

fails to report the first open of test.py, which I know must

be there.



I recommend to run this under a debugger, and break at

posix_open.

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

Comment By: Syrah (syrah)
Date: 2003-09-11 18:50

Message:
Logged In: YES 
user_id=827529

Okay.  I think I have attached a tgz file with 3 programs, 3

binary ktraces, and the ktraces converted to text files.



In all cases, the programs were run as follows:



[bash]$ program 3> file



Many thanks for your continued interest.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 08:01

Message:
Logged In: YES 
user_id=21627

Was that the complete ktrace? I'm missing the point where it

outputs "Traceback (most recent call last):". If you have

stripped it down, can you please attach the entire thing

(please don't paste it)?

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

Comment By: Syrah (syrah)
Date: 2003-09-11 00:45

Message:
Logged In: YES 
user_id=827529

I agree that this is a very strange error.  Python should be

directly calling the operating systems close function.  It

is very puzzling that there is an error.



I did include in my initial post a parent that sets up fd 3.

 I used bash.  I was able to test successfully with bash.  I

wrote a C program:



-------- test.c --------

#include <stdio.h>



int main () {

  int i = close (3);

  printf ("close: %i\n", i); }

--------



Using bash, I tested test.py, test2.py, and test.c (gcc

test.c -o test).  test.c behaved properly.  When I set up fd

3 with bash, test.c printed "close: 0".  When I did not set

up fd 3, test.c printed "close: -1".



I therefore have bash working properly, C working properly

and test2.py working properly.  The only thing that is not

working properly is test.py.  To me, it seems that I have

isolated the problem.



However, this problem only manifests on FreeBSD.  test.py

runs fine on Gentoo Linux.  At present, those are the only

two OSes I have easy access to.



So... if you really want a test program that sets up fd3,

I'll write one - let me know.  Would you prefer me to write

it in Python, C, PHP, Ruby, Perl?  I'd prefer C as it is

most direct.  But bash seems sufficient: "[bash]$ python

test.py 3> file" sets up file descriptor 3 so it writes into

a file named "file".



To look at it from another angle... is it possible that

Python, during its startup and initialization stuff messes

with file descriptor 3?  Is it possible it does this in some

really non-standard way?  Perhaps it does it indirectly by

calling some OS function that, as a side effect on FreeBSD

touches fd 3?  Something is going on with file descriptions

0-4 _every_ time python runs.  [Based on the ktrace's below,

it looks like



[syrah@ripple]$ python

Python 2.3 (#1, Sep  9 2003, 22:47:18) 

[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5

Type "help", "copyright", "credits" or "license" for more

information.

>>> import os 

>>> os.fstat (0)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206044,

1063206044, 1063206044)

>>> os.fstat (1)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206046,

1063206046, 1063206046)

>>> os.fstat (2)

(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206048,

1063206048, 1063206048)

>>> os.fstat (3)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (4)

(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,

1063206027)

>>> os.fstat (5)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

OSError: [Errno 9] Bad file descriptor

>>> 



Also, it is very strange that after calling os.fstat(3),

os.close(3) works.  This says to me that fd 3 is fine, but

Python thinks fd 3 is bogus, but

calling os.fstat (3) forces Python to check fd 3's real status.



I considered the possibility that os.fstat(x) will the next

os.close(x) to succeed, but that is not the case:



[bash]$ cat test3.py

import os

os.fstat (3)

os.close (3)

os.fstat (3)

os.close (3)



[bash]$ python test3.py 3> file

(an the error is raised on the second os.fstat(3) call, just

as you would expect)



Okay, here is your ktrace:



26520 python   GIO   fd 6 read 23 bytes

       "import os

        os.close (3)

       "

 26520 python   RET   read 23/0x17

 26520 python   CALL  write(0x2,0x80e6708,0x4)

 26520 python   GIO   fd 2 wrote 4 bytes

       "    "

 26520 python   RET   write 4

 26520 python   CALL  write(0x2,0xbfbfeb70,0xd)

 26520 python   GIO   fd 2 wrote 13 bytes

       "os.close (3)

       "

 26520 python   RET   write 13/0xd

 26520 python   CALL  fstat(0x6,0xbfbfe670)

 26520 python   RET   fstat 0

 26520 python   CALL  fcntl(0x6,0x3,0)

 26520 python   RET   fcntl 4

 26520 python   CALL  fcntl(0x6,0x4,0)

 26520 python   RET   fcntl 0

 26520 python   CALL  close(0x6)

 26520 python   RET   close 0

 26520 python   CALL  write(0x2,0x813a3b4,0x7)

 26520 python   GIO   fd 2 wrote 7 bytes

       "OSError"

 26520 python   RET   write 7

 26520 python   CALL  write(0x2,0x80dbe5f,0x2)

 26520 python   GIO   fd 2 wrote 2 bytes

       ": "

 26520 python   RET   write 2

 26520 python   CALL  write(0x2,0x81c5dfc,0x1d)

 26520 python   GIO   fd 2 wrote 29 bytes

       "[Errno 9] Bad file descriptor"

 26520 python   RET   write 29/0x1d

 26520 python   CALL  write(0x2,0x80e4d42,0x1)

 26520 python   GIO   fd 2 wrote 1 byte

       "

       "



Note that when I call os.close (3), python calls close(0x6),

so it looks like python is "mapping" the file description

numbers.  There are many other close calls the ktrace, but

_none_ of them close (0x3).  This says to me that (possibly)

python is doing lots of fd manipulation, but fd 3 is already

open, so python never uses it.



Here is a ktrace of test2.py.  It's very interesting.  6 is

fstated, closed, then 3 is fstated, fnctled, and closed

successfully.



 26498 python   GIO   fd 6 read 36 bytes

       "import os

        os.fstat (3)

        os.close (3)

       "

 26498 python   RET   read 36/0x24

 26498 python   CALL  lseek(0x6,0,0,0,0x1)

 26498 python   RET   lseek 36/0x24

 26498 python   CALL  read(0x6,0x8203000,0x4000)

 26498 python   GIO   fd 6 read 0 bytes

       ""

 26498 python   RET   read 0

 26498 python   CALL  fstat(0x6,0xbfbff450)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x6,0x3,0)

 26498 python   RET   fcntl 4

 26498 python   CALL  fcntl(0x6,0x4,0)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x6)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 1

 26498 python   CALL  fcntl(0x3,0x4,0x5)

 26498 python   RET   fcntl 0

 26498 python   CALL  fstat(0x3,0xbfbff290)

 26498 python   RET   fstat 0

 26498 python   CALL  fstat(0x3,0xbfbff260)

 26498 python   RET   fstat 0

 26498 python   CALL  fcntl(0x3,0x3,0)

 26498 python   RET   fcntl 5

 26498 python   CALL  fcntl(0x3,0x4,0x1)

 26498 python   RET   fcntl 0

 26498 python   CALL  close(0x3)

 26498 python   RET   close 0

 26498 python   CALL  sigaction(0x2,0xbfbff4b0,0)

 26498 python   RET   sigaction 0

 26498 python   CALL  setitimer(0x2,0xbfbff5f0,0)

 26498 python   RET   setitimer 0

 26498 python   CALL  close(0x4)

 26498 python   RET   close 0

 26498 python   CALL  close(0x5)

 26498 python   RET   close 0

 26498 python   CALL  fcntl(0,0x3,0)

 26498 python   RET   fcntl 6

 26498 python   CALL  fcntl(0,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x1,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x1,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  fcntl(0x2,0x3,0)

 26498 python   RET   fcntl 2

 26498 python   CALL  fcntl(0x2,0x4,0x2)

 26498 python   RET   fcntl 0

 26498 python   CALL  exit(0)



Does fd 3 have some special significance on FreeBSD?  Or on

other OSes?  I'm aware of 0, 1 and 2 being stdin, out, err.

 But I didn't know that 3 was anything special.  And 3 is

what courier uses to communicate with its filters.



Okay... I just searched through the whole ktrace of test.py.

 As far as I can tell, nothing touches fd 3 in the whole

ktrace.  fcntl takes 0x3 as the second argument many times,

but that is a command, not a file descriptor.



So... this means that with test.py, Python decides (based on

an fstat (0x6)?) that os.close(3) will fail without ever

calling close(3) to see what will happen.



This could be a bug in FreeBSD.  But then why did my C

program work as expected?  Or perhaps there is a library

inbetween Python and the OS, a library that my c program

does not use.



Any suggestions for further diagnosis?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 22:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),

and reports an error if and only if the operating system

reports an error. So there is absolutely zero possibility

that the operatin system lets close(2) succeeed, yet python

returns OSError(9). As a consequence, if python raises

OSError(9), it was the operating system that has returned an

error before.



If you doubt this statement, please use ktrace/strace to

diagnose this further.



Also, if you *know* that a parent process has set up fd 3,

your test case is irrelevant. Your test case is only

meaningful in a context where a parent process has set up fd

3, however, you have not reported the code of that parent

process. Providing a minimal test case would be appreciated.

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

Comment By: Syrah (syrah)
Date: 2003-09-10 19:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 18:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

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

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

From noreply at sourceforge.net  Fri Sep 12 00:18:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 02:18:55 2003
Subject: [Python-bugs-list] [ python-Bugs-802128 ] Mode argument of dumbdbm
	does not work
Message-ID: <E19xhGd-0004Oq-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L?wis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Mode argument of dumbdbm does not work

Initial Comment:
In dumbdbm.py 2.15, support for a mode argument was

added. However, this support does not work: The mode

argument is passed to __builtin__.open, which does not

support specification of a mode. Instead, the third

argument to that function specifies the buffer size.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-12 02:18

Message:
Logged In: YES 
user_id=3066

I have what I think is a correct patch, but I should be able

to simplify it (related to handling the umask).  Untested on

Windows.

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

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

From noreply at sourceforge.net  Fri Sep 12 00:36:03 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 02:36:16 2003
Subject: [Python-bugs-list] [ python-Feature Requests-662923 ] iterator for
	dbm keys
Message-ID: <E19xhXH-00013U-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #662923, was opened at 2003-01-05 21:34
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662923&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: iterator for dbm keys

Initial Comment:
if d is a dbm (gdbm, bsddb, shelve, etc.) object, then

"for k in d"

should iterate through the keys of d, like you can do

with dicts.  Alternatively, add a new operation,

d.xkeys(), which returns an iterator that steps through

all the keys in d.  d.keys() is often inappropriate

since dbm databases can be extremely large and d.keys()

tries to read all the keys into memory at once.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-12 01:36

Message:
Logged In: YES 
user_id=80475

bsddb and dbhash were missed for Py2.3.

Adding the to Py2.4.

See:

   Lib/bsddb/__init__.py 1.6

   Lib/test/test_bsddb.py 1.13

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-12 13:08

Message:
Logged In: YES 
user_id=80475

I think this was taken case of for Python 2.3.  Please 

check to see if all of your needs have been met.  If so, 

please close the request.  If not, paste a patch (applying 

UserDict.DictMixin) for anything that was missed.

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

Comment By: paul rubin (phr)
Date: 2003-02-08 05:27

Message:
Logged In: YES 
user_id=72053

That's nice about shelve, but really, all the dbm classes

need this operation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-10 04:47

Message:
Logged In: YES 
user_id=80475

* for Py2.3, all shelve now inherits from UserDict.DictMixin 

which adds in the missing methods for a dictionary style 

interface.



* the appropriate name for d.xkeys() is d.iterkeys().

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

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

From noreply at sourceforge.net  Fri Sep 12 00:36:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 02:36:47 2003
Subject: [Python-bugs-list] [ python-Feature Requests-662923 ] iterator for
	dbm keys
Message-ID: <E19xhXv-000149-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #662923, was opened at 2003-01-05 21:34
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662923&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: iterator for dbm keys

Initial Comment:
if d is a dbm (gdbm, bsddb, shelve, etc.) object, then

"for k in d"

should iterate through the keys of d, like you can do

with dicts.  Alternatively, add a new operation,

d.xkeys(), which returns an iterator that steps through

all the keys in d.  d.keys() is often inappropriate

since dbm databases can be extremely large and d.keys()

tries to read all the keys into memory at once.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-12 01:36

Message:
Logged In: YES 
user_id=80475

bsddb and dbhash were missed for Py2.3.

Adding the to Py2.4.

See:

   Lib/bsddb/__init__.py 1.6

   Lib/test/test_bsddb.py 1.13

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-12 13:08

Message:
Logged In: YES 
user_id=80475

I think this was taken case of for Python 2.3.  Please 

check to see if all of your needs have been met.  If so, 

please close the request.  If not, paste a patch (applying 

UserDict.DictMixin) for anything that was missed.

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

Comment By: paul rubin (phr)
Date: 2003-02-08 05:27

Message:
Logged In: YES 
user_id=72053

That's nice about shelve, but really, all the dbm classes

need this operation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-10 04:47

Message:
Logged In: YES 
user_id=80475

* for Py2.3, all shelve now inherits from UserDict.DictMixin 

which adds in the missing methods for a dictionary style 

interface.



* the appropriate name for d.xkeys() is d.iterkeys().

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

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

From noreply at sourceforge.net  Fri Sep 12 05:39:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 07:39:36 2003
Subject: [Python-bugs-list] [ python-Bugs-805015 ]
	PyUnicode_FromEncodedObject
Message-ID: <E19xmGy-0003le-00@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyUnicode_FromEncodedObject

Initial Comment:
There's a bug, either in the code or docs for

PyUnicode_FromEncodedObject.  The docs read:



  "Unicode objects are passed back as-is with 

incremented

  refcount. Note: These cannot be decoded; passing a 

non-NULL value

  for encoding will result in a TypeError."





'tain't so; the following shows that the error is 

unconditional.







    if (obj == NULL) {

	PyErr_BadInternalCall();

	return NULL;

    }



#if 0

    /* For b/w compatibility we also accept Unicode 

objects provided

       that no encodings is given and then redirect to

       PyObject_Unicode() which then applies the 

additional logic for

       Unicode subclasses.



       NOTE: This API should really only be used for 

object which

             represent *encoded* Unicode !



    */

	if (PyUnicode_Check(obj)) {

	    if (encoding) {

		PyErr_SetString(PyExc_TypeError,

				"decoding Unicode 

is not supported");

	    return NULL;

	    }

	return PyObject_Unicode(obj);

	    }

#else

    if (PyUnicode_Check(obj)) {

	PyErr_SetString(PyExc_TypeError,

			"decoding Unicode is not 

supported");

	return NULL;

	}

#endif



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

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

From noreply at sourceforge.net  Fri Sep 12 12:08:53 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 12:09:09 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xqTd-0001up-00@sc8-sf-web1.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 22: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=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

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

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 19:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 04:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 12:46:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 12:47:07 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xr4V-0004Ml-00@sc8-sf-web3.sourceforge.net>

Bugs item #775414, was opened at 2003-07-22 02:29
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 16:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 16:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 23:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 08:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 12:56:21 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 12:56:31 2003
Subject: [Python-bugs-list] [ python-Bugs-805194 ] Inappropriate error
	received using socket timeout
Message-ID: <E19xrDZ-0007NZ-00@sc8-sf-web2.sourceforge.net>

Bugs item #805194, was opened at 2003-09-12 16: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=805194&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Popov (evgeni_popov)
Assigned to: Tim Peters (tim_one)
Summary: Inappropriate error received using socket timeout

Initial Comment:
When using the timeout option with a socket object 

(python 2.3), I don't have the same behaviour under 

Windows than under Linux / Mac.



Specifically, if trying to connect to an unopened port of 

the localhost, I get a timeout exception on Windows 

(tested under W2K Server), whereas I get a "111 - 

Connection Refused" exception on Linux and "22 - Invalid 

Argument" on Mac (OS X).



Even if the error message under Mac is not really 

appropriate (someone said to me he got the 

right 'Connection Refused' on his MAC), I think that the 

behaviour under Linux and Mac is the right one, in that it

sends (quickly) an error message and not timeouting.



Note that when using blocking socket the behaviour is 

ok under all platforms: they each return back quickly 

a "Connection refused" error message (err codes are 

different depending on the platform (61=Mac,

111=Linux, 10061=Windows)). FYI, I don't use firewall or 

similar prog on my windows box (but that should not 

matter, because it does work in blocking mode, so that 

can't be a firewall problem).



I heard that the timeout option was implemented based 

on Timothy O'Malley timeoutsocket.py. Then, maybe the 

pb can come from the usage of select in the connection 

function: select is not asked to get back exceptions in 

the returned triple, whereas I think some errors can be

returned back through this mean under Windows 

(according to Tip 25 of Jon C. Snader book's "Effective 

TCP/IP Programming"). So, by not checking the returned 

exceptions, we would miss the "connection refused" 

error and get instead the timeout error...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 13:04:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 13:05:01 2003
Subject: [Python-bugs-list] [ python-Bugs-805194 ] Inappropriate error
	received using socket timeout
Message-ID: <E19xrLr-0007qC-00@sc8-sf-web2.sourceforge.net>

Bugs item #805194, was opened at 2003-09-12 12:56
Message generated for change (Settings changed) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Popov (evgeni_popov)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Inappropriate error received using socket timeout

Initial Comment:
When using the timeout option with a socket object 

(python 2.3), I don't have the same behaviour under 

Windows than under Linux / Mac.



Specifically, if trying to connect to an unopened port of 

the localhost, I get a timeout exception on Windows 

(tested under W2K Server), whereas I get a "111 - 

Connection Refused" exception on Linux and "22 - Invalid 

Argument" on Mac (OS X).



Even if the error message under Mac is not really 

appropriate (someone said to me he got the 

right 'Connection Refused' on his MAC), I think that the 

behaviour under Linux and Mac is the right one, in that it

sends (quickly) an error message and not timeouting.



Note that when using blocking socket the behaviour is 

ok under all platforms: they each return back quickly 

a "Connection refused" error message (err codes are 

different depending on the platform (61=Mac,

111=Linux, 10061=Windows)). FYI, I don't use firewall or 

similar prog on my windows box (but that should not 

matter, because it does work in blocking mode, so that 

can't be a firewall problem).



I heard that the timeout option was implemented based 

on Timothy O'Malley timeoutsocket.py. Then, maybe the 

pb can come from the usage of select in the connection 

function: select is not asked to get back exceptions in 

the returned triple, whereas I think some errors can be

returned back through this mean under Windows 

(according to Tip 25 of Jon C. Snader book's "Effective 

TCP/IP Programming"). So, by not checking the returned 

exceptions, we would miss the "connection refused" 

error and get instead the timeout error...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 13:13:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 13:13:38 2003
Subject: [Python-bugs-list] [ python-Bugs-805200 ] _tkinter compilation fails
Message-ID: <E19xrUB-0005hG-00@sc8-sf-web3.sourceforge.net>

Bugs item #805200, was opened at 2003-09-12 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=805200&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Samson Abramsky (bobrowski)
Assigned to: Nobody/Anonymous (nobody)
Summary: _tkinter compilation fails

Initial Comment:
Building Python 2.3 on Linux.

At make stage:

_tkinter compilation fails: libtk8.4.so  no such file

of directory

with  gcc arguments 

    -L/usr/local/lib -ltk8.4



However, /usr/local/lib/libtk8.4.so does exist.!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805200&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 13:14:47 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 13:14:51 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xrVP-00022m-00@sc8-sf-web4.sourceforge.net>

Bugs item #775414, was opened at 2003-07-22 02:29
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 17:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 16:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 16:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 23:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 08:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 12:38:58 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 14:08:58 2003
Subject: [Python-bugs-list] [ python-Bugs-711632 ]
	htmllib.HTMLParser.anchorlist problem
Message-ID: <E19xqwk-0003yM-00@sc8-sf-web3.sourceforge.net>

Bugs item #711632, was opened at 2003-03-29 01:26
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711632&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Chris Gray (cpgray)
Assigned to: Nobody/Anonymous (nobody)
Summary: htmllib.HTMLParser.anchorlist problem

Initial Comment:
htmllib.HTMLParser.anchorlist is cleared when

__init__() is called but not when reset() is called. 

Processing more than one document with the same

instance accumulates anchors from all documents

processed in the list.



Arguably a feature not a bug, but it makes sense for

reset to clear whatever is initialized by __init__.



Here is an illustrative IDLE session:



Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit

(Intel)] on win32

Type "copyright", "credits" or "license" for more

information.

IDLE 0.8 -- press F1 for help

>>> import htmllib

>>> import formatter

>>> p = htmllib.HTMLParser(formatter.NullFormatter())

>>> p.feed('<a href="http://www.python.org">Python</a>')

>>> p.anchorlist

['http://www.python.org']

>>> p.reset()

>>> p.feed('<a

href="http://sourceforge.net/">Sourceforge</a>')

>>> p.anchorlist

['http://www.python.org', 'http://sourceforge.net/']

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-12 18:38

Message:
Logged In: YES 
user_id=21627

Fixed with #793021.

----------------------------------------------------------------------

Comment By: Andrew Gaul (gaul)
Date: 2003-08-22 10:44

Message:
Logged In: YES 
user_id=139865

See patch 793021 for a fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711632&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 14:23:42 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 14:23:50 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xsa6-0005XQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 21:29
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 11:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 18:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 03:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 14:30:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 14:30:21 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xsgQ-0005sd-00@sc8-sf-web4.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 19:29
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 10:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 09:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 09:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 16:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 01:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 14:35:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 14:35:08 2003
Subject: [Python-bugs-list] [ python-Bugs-805200 ] _tkinter compilation fails
Message-ID: <E19xsl2-0003yN-00@sc8-sf-web2.sourceforge.net>

Bugs item #805200, was opened at 2003-09-12 13:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805200&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Samson Abramsky (bobrowski)
Assigned to: Nobody/Anonymous (nobody)
Summary: _tkinter compilation fails

Initial Comment:
Building Python 2.3 on Linux.

At make stage:

_tkinter compilation fails: libtk8.4.so  no such file

of directory

with  gcc arguments 

    -L/usr/local/lib -ltk8.4



However, /usr/local/lib/libtk8.4.so does exist.!

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-12 14:35

Message:
Logged In: YES 
user_id=33168

Are you sure libtk8.4.so isn't a sym link to a non-existent

file?  Is /usr/local/lib configured in ld.so?  Is

LD_LIBRARY_PATH set properly?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805200&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 14:37:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 14:37:46 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xsna-0001Nh-00@sc8-sf-web3.sourceforge.net>

Bugs item #775414, was opened at 2003-07-22 02:29
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 18:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 18:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 17:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 16:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 16:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 23:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 08:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 15:00:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:03:02 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xt9I-0007O3-00@sc8-sf-web4.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 21:29
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 11:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 18:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 03:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 14:57:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:03:06 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xt6y-0007JH-00@sc8-sf-web4.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 21:29
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 11:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 18:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 03:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 14:45:47 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:03:09 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xsvT-0006jB-00@sc8-sf-web4.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 19:29
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 10:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 09:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 09:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 16:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 01:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 15:03:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:03:42 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xtCj-0002Rx-00@sc8-sf-web1.sourceforge.net>

Bugs item #775414, was opened at 2003-07-22 02:29
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 19:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 19:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 18:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 18:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 18:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 17:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 16:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 16:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 23:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 08:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 15:07:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:07:33 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xtGQ-0007i9-00@sc8-sf-web4.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 22: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=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-12 15:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 15:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 15:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 19:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 04:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 15:08:02 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:08:05 2003
Subject: [Python-bugs-list] [ python-Feature Requests-805255 ]
	remove/discard method for dict objects.
Message-ID: <E19xtH0-0002f1-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #805255, was opened at 2003-09-12 15:08
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=805255&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: remove/discard method for dict objects.

Initial Comment:
dict objects already provide a method for getting from

the dictionary (possibly returning a default value) so

as to avoid raising KeyError.  But there's no way to

remove an item that may or may not be in a dictionary

from a dictionary without risking raising KeyError.



I think there should be a method to remove a key if it

is in the dictionary, but to do nothing if it isn't. 

I'd suggest calling it .remove, but the sets.Set type

offers this functionality as .discard, so perhaps

that's a better name.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=805255&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 15:10:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:10:39 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xtJH-0007sP-00@sc8-sf-web4.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 19:29
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 12:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 12:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 10:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 09:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 09:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 16:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 01:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 15:18:02 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:18:08 2003
Subject: [Python-bugs-list] [ python-Feature Requests-793069 ] Add
	--remove-source option
Message-ID: <E19xtQg-0008Ck-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #793069, was opened at 2003-08-22 06:08
Message generated for change (Comment added) made by jemfinch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793069&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add --remove-source option

Initial Comment:
For distributing non-opensource software, it is helpful

to just distribute the .pyc/.pyo files and not the

original .py files.

The reverse (just distributing .py files) is possible

through the --no-target-compile and

--no-target-optimize switches to the distutils bdist

command.

We have added a --remove-source option which goes

through and deletes all the source files from the build

directory. This has been tested and works smoothly with

Python 2.2.3 and seems to apply cleanly to Python 2.3

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-09-12 15:18

Message:
Logged In: YES 
user_id=99508

It's someone trivial to retrieve the source code from a

compiled bytecode module; distributing only the bytecode

files does practically nothing to protect your source code.



Check out http://www.crazy-compilers.com/decompyle/

----------------------------------------------------------------------

Comment By: David Fraser (davidfraser)
Date: 2003-08-22 06:34

Message:
Logged In: YES 
user_id=221678

Added a patch for this (sorry, probably should have just

done that) as 793070:

https://sourceforge.net/tracker/?func=detail&aid=793070&group_id=5470&atid=305470

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793069&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 15:22:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:23:05 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xtVT-0003Ra-00@sc8-sf-web1.sourceforge.net>

Bugs item #775414, was opened at 2003-07-22 02:29
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 19:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 19:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 19:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 19:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 19:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 18:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 18:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 18:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 17:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 16:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 16:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 23:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 08:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 15:25:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:25:11 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xtXQ-0008VE-00@sc8-sf-web4.sourceforge.net>

Bugs item #775414, was opened at 2003-07-22 02:29
Message generated for change (Comment added) made by richiehindle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 19:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 19:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 19:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 19:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 19:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 19:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 18:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 18:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 18:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 17:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 16:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 16:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 23:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 08:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 15:52:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 15:52:30 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xtxo-0004p2-00@sc8-sf-web1.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 21:29
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 14:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 14:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 11:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 18:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 03:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 16:10:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 16:10:52 2003
Subject: [Python-bugs-list] [ python-Bugs-805304 ] super instances don't
	support item assignment
Message-ID: <E19xuFf-0005cw-00@sc8-sf-web1.sourceforge.net>

Bugs item #805304, was opened at 2003-09-12 16:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: super instances don't support item assignment

Initial Comment:
This snippet produces a TypeError in Python 2.2.3, 2.3,

and CVS:



class C(object):

    def __setitem__(self, name, value):

        print (name, value)



class D(C):

    def __setitem__(self, name, value):

        super(D, self)[name] = value



d = D()

d['foo'] = 'bar'



Here's the traceback:



Traceback (most recent call last):

  File "/home/fdrake/tmp/setitem.py", line 10, in ?

    d['foo'] = 'bar'

  File "/home/fdrake/tmp/setitem.py", line 7, in

__setitem__

    super(D, self)[name] = value

TypeError: object does not support item assignment



The problem appears to be that the item assignment

isn't getting mapped to the __setitem__ of the base

class, so this is probably somewhere deep in

Objects/typeobject.c.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 16:40:49 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 16:40:55 2003
Subject: [Python-bugs-list] [ python-Feature Requests-793069 ] Add
	--remove-source option
Message-ID: <E19xuin-0003Hk-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #793069, was opened at 2003-08-22 12:08
Message generated for change (Comment added) made by davidfraser
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793069&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add --remove-source option

Initial Comment:
For distributing non-opensource software, it is helpful

to just distribute the .pyc/.pyo files and not the

original .py files.

The reverse (just distributing .py files) is possible

through the --no-target-compile and

--no-target-optimize switches to the distutils bdist

command.

We have added a --remove-source option which goes

through and deletes all the source files from the build

directory. This has been tested and works smoothly with

Python 2.2.3 and seems to apply cleanly to Python 2.3

----------------------------------------------------------------------

>Comment By: David Fraser (davidfraser)
Date: 2003-09-12 22:40

Message:
Logged In: YES 
user_id=221678

Sure, I'm aware of decompyling. However removing the source

might have a slight psychological effect on honest people.

Also it ties in to license things about decompiling etc.

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-09-12 21:18

Message:
Logged In: YES 
user_id=99508

It's someone trivial to retrieve the source code from a

compiled bytecode module; distributing only the bytecode

files does practically nothing to protect your source code.



Check out http://www.crazy-compilers.com/decompyle/

----------------------------------------------------------------------

Comment By: David Fraser (davidfraser)
Date: 2003-08-22 12:34

Message:
Logged In: YES 
user_id=221678

Added a patch for this (sorry, probably should have just

done that) as 793070:

https://sourceforge.net/tracker/?func=detail&aid=793070&group_id=5470&atid=305470

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793069&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 18:28:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 18:28:14 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E19xwOd-0005WI-00@sc8-sf-web2.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 19:29
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 15:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 12:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 12:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 12:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 12:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 10:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 09:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 09:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 16:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 01:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Fri Sep 12 22:59:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 12 22:59:45 2003
Subject: [Python-bugs-list] [ python-Bugs-804115 ] bad argument
	handling(unittest.py)
Message-ID: <E19y0dK-000399-00@sc8-sf-web1.sourceforge.net>

Bugs item #804115, was opened at 2003-09-10 20:19
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Raymond Hettinger (rhettinger)
Summary: bad argument handling(unittest.py)

Initial Comment:
_WritelnDecorator.writeln method handles arbitrary 

number of argumetns badly.



In the following part,



    def writeln(self, *args):

        if args: self.write(*args)



since _WritelnDecorator's stream is by default 

sys.stderr,

sys.stderr.write() takes exactly one argument.



If you give more than one argument to writeln 

method,

TypeError is raised.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-12 21:59

Message:
Logged In: YES 
user_id=80475

Fixed.

See Lib/unittest.py 1.25 and 1.24.6.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

From noreply at sourceforge.net  Sat Sep 13 02:50:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 02:50:26 2003
Subject: [Python-bugs-list] [ python-Bugs-805304 ] super instances don't
	support item assignment
Message-ID: <E19y4Eh-0000yx-00@sc8-sf-web1.sourceforge.net>

Bugs item #805304, was opened at 2003-09-12 15:10
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: super instances don't support item assignment

Initial Comment:
This snippet produces a TypeError in Python 2.2.3, 2.3,

and CVS:



class C(object):

    def __setitem__(self, name, value):

        print (name, value)



class D(C):

    def __setitem__(self, name, value):

        super(D, self)[name] = value



d = D()

d['foo'] = 'bar'



Here's the traceback:



Traceback (most recent call last):

  File "/home/fdrake/tmp/setitem.py", line 10, in ?

    d['foo'] = 'bar'

  File "/home/fdrake/tmp/setitem.py", line 7, in

__setitem__

    super(D, self)[name] = value

TypeError: object does not support item assignment



The problem appears to be that the item assignment

isn't getting mapped to the __setitem__ of the base

class, so this is probably somewhere deep in

Objects/typeobject.c.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 01:50

Message:
Logged In: YES 
user_id=80475

This one is tough.  



All of super's magic happens with descriptors upon attribute 

lookup.  The example above will work fine if the call were 

written as:  "super(D, self).__setitem__(name)".



However, when written as "super(D, self)[name]", ceval.c 

triggers a STORE_SUBSCR opcode which calls 

PyObject_SetItem which in turns looks directly at the super 

object's type table (and finding nothing).  Nowhere in this 

process is an attribute lookup called or a descriptor invoked.



The current implementation waits until attribute binding time 

to search the bases.  Hence, at the time the super object is 

created, it doesn't know enough information to fill out its 

table about which methods will be available.  Consequently, 

direct table probes will fail.



To make a general purpose fix would be a mess and involves 

changing the semantics of super to do its base search at the 

time the super object is created and to fillout its table with 

the appropriate methods.  Unfortunately, any dynamic 

changes to the methods in the base object would *not* get 

reflected at lookup.



There may be a reasonable special purpose fix.  Fill-out the 

entire superobject table with custom methods that trigger an 

attribute lookup.  For instance, fillout the sq_ass_item slot 

with a function that calls self.__setitem__ which will trigger 

the attribute search.  Even this approach has problems 

because the super object has no way of knowing in advance 

whether sq_ass_item or mp_ass_subscript is the appropriate 

method for the object being referred to (is it a mapping or a 

sequence?).



I recommend punting on this one and documenting that 

direct syntax manipulation of super objects is not defined 

and the super().__special_method__ format be used instead.

Perhaps, all of super's unfilled slots can be filled with a 

placeholder method that emits an explanatory error message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470

From noreply at sourceforge.net  Thu Sep  4 17:27:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 09:14:37 2003
Subject: [Python-bugs-list] [ python-Bugs-800710 ] build fails
Message-ID: <E19v1dH-0002ot-00@sc8-sf-web2.sourceforge.net>

Bugs item #800710, was opened at 2003-09-04 21: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=800710&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Schran (aschran)
Assigned to: Nobody/Anonymous (nobody)
Summary: build fails

Initial Comment:
dear python code samurais,



I ran ./configure and make on python 2.3, and got this 

failure on the make.  researched extensively before 

posting to you guys. =)



This problem only happens when installing Python 2.3.  

Python 2.2 installs flawlessly.



This is on a 2-year-old Linux box running slackware, with 

gcc version 2.7.2. 



I was able to get Python 2.3 to install on a newer 

machine with a different linux distrib with no problem. 



here are the results of the .configure and the make. 

Thanks for any help getting Python going on this 

machine! I'll try any suggestions. Adam



azure:~/Python-2.3$ ./configure

checking MACHDEP... linux2

checking EXTRAPLATDIR... 

checking for --without-gcc... no

checking for --with-cxx=<compiler>... no

checking for c++... c++

checking for C++ compiler default output... a.out

checking whether the C++ compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for gcc... gcc

checking for C compiler default output... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking how to run the C preprocessor... gcc -E

checking for AIX... no

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... no

checking for stdint.h... no

checking for unistd.h... yes

checking minix/config.h usability... no

checking minix/config.h presence... no

checking for minix/config.h... no

checking for --with-suffix... 

checking for case-insensitive build directory... no

checking LIBRARY... libpython$(VERSION).a

checking LINKCC... $(PURIFY) $(CC)

checking for --enable-shared... no

checking LDLIBRARY... libpython$(VERSION).a

checking for ranlib... ranlib

checking for ar... ar

checking for a BSD-compatible install... /usr/bin/ginstall -

c

checking for --with-pydebug... no

checking whether gcc accepts -fno-strict-aliasing... no

checking whether gcc accepts -OPT:Olimit=0... no

checking whether gcc accepts -Olimit 1500... no

checking whether pthreads are available without 

options... no

checking whether gcc accepts -Kpthread... no

checking whether gcc accepts -Kthread... no

checking whether gcc accepts -pthread... no

checking whether c++ also accepts flags for thread 

support... no

checking for ANSI C header files... (cached) yes

checking dlfcn.h usability... yes

checking dlfcn.h presence... yes

checking for dlfcn.h... yes

checking fcntl.h usability... yes

checking fcntl.h presence... yes

checking for fcntl.h... yes

checking grp.h usability... yes

checking grp.h presence... yes

checking for grp.h... yes

checking limits.h usability... yes

checking limits.h presence... yes

checking for limits.h... yes

checking langinfo.h usability... yes

checking langinfo.h presence... yes

checking for langinfo.h... yes

checking libintl.h usability... no

checking libintl.h presence... no

checking for libintl.h... no

checking locale.h usability... yes

checking locale.h presence... yes

checking for locale.h... yes

checking ncurses.h usability... no

checking ncurses.h presence... no

checking for ncurses.h... no

checking poll.h usability... no

checking poll.h presence... no

checking for poll.h... no

checking pthread.h usability... yes

checking pthread.h presence... yes

checking for pthread.h... yes

checking signal.h usability... yes

checking signal.h presence... yes

checking for signal.h... yes

checking stdarg.h usability... yes

checking stdarg.h presence... yes

checking for stdarg.h... yes

checking stddef.h usability... yes

checking stddef.h presence... yes

checking for stddef.h... yes

checking for stdlib.h... (cached) yes

checking stropts.h usability... no

checking stropts.h presence... no

checking for stropts.h... no

checking termios.h usability... yes

checking termios.h presence... yes

checking for termios.h... yes

checking thread.h usability... no

checking thread.h presence... no

checking for thread.h... no

checking for unistd.h... (cached) yes

checking utime.h usability... yes

checking utime.h presence... yes

checking for utime.h... yes

checking sys/audioio.h usability... no

checking sys/audioio.h presence... no

checking for sys/audioio.h... no

checking sys/bsdtty.h usability... no

checking sys/bsdtty.h presence... no

checking for sys/bsdtty.h... no

checking sys/file.h usability... yes

checking sys/file.h presence... yes

checking for sys/file.h... yes

checking sys/lock.h usability... no

checking sys/lock.h presence... no

checking for sys/lock.h... no

checking sys/mkdev.h usability... no

checking sys/mkdev.h presence... no

checking for sys/mkdev.h... no

checking sys/modem.h usability... no

checking sys/modem.h presence... no

checking for sys/modem.h... no

checking sys/param.h usability... yes

checking sys/param.h presence... yes

checking for sys/param.h... yes

checking sys/poll.h usability... no

checking sys/poll.h presence... no

checking for sys/poll.h... no

checking sys/select.h usability... no

checking sys/select.h presence... no

checking for sys/select.h... no

checking sys/socket.h usability... yes

checking sys/socket.h presence... yes

checking for sys/socket.h... yes

checking sys/time.h usability... yes

checking sys/time.h presence... yes

checking for sys/time.h... yes

checking sys/times.h usability... yes

checking sys/times.h presence... yes

checking for sys/times.h... yes

checking sys/un.h usability... no

checking sys/un.h presence... yes

configure: WARNING: sys/un.h: present but cannot be 

compiled

configure: WARNING: sys/un.h: check for missing 

prerequisite headers?

configure: WARNING: sys/un.h: proceeding with the 

preprocessor's result

checking for sys/un.h... yes

checking sys/utsname.h usability... yes

checking sys/utsname.h presence... yes

checking for sys/utsname.h... yes

checking sys/wait.h usability... yes

checking sys/wait.h presence... yes

checking for sys/wait.h... yes

checking pty.h usability... no

checking pty.h presence... no

checking for pty.h... no

checking term.h usability... yes

checking term.h presence... yes

checking for term.h... yes

checking libutil.h usability... no

checking libutil.h presence... no

checking for libutil.h... no

checking sys/resource.h usability... yes

checking sys/resource.h presence... yes

checking for sys/resource.h... yes

checking netpacket/packet.h usability... no

checking netpacket/packet.h presence... no

checking for netpacket/packet.h... no

checking sysexits.h usability... yes

checking sysexits.h presence... yes

checking for sysexits.h... yes

checking for dirent.h that defines DIR... yes

checking for library containing opendir... none required

checking whether sys/types.h defines makedev... no

checking for sys/mkdev.h... (cached) no

checking sys/sysmacros.h usability... yes

checking sys/sysmacros.h presence... yes

checking for sys/sysmacros.h... yes

checking for clock_t in time.h... yes

checking for makedev... no

checking Solaris LFS bug... no

checking for mode_t... yes

checking for off_t... yes

checking for pid_t... yes

checking return type of signal handlers... void

checking for size_t... yes

checking for uid_t in sys/types.h... yes

checking for int... yes

checking size of int... 4

checking for long... yes

checking size of long... 4

checking for void *... yes

checking size of void *... 4

checking for char... yes

checking size of char... 1

checking for short... yes

checking size of short... 2

checking for float... yes

checking size of float... 4

checking for double... yes

checking size of double... 8

checking for fpos_t... yes

checking size of fpos_t... 4

checking for long long support... yes

checking for long long... yes

checking size of long long... 8

checking for uintptr_t support... no

checking size of off_t... 4

checking whether to enable large file support... no

checking size of time_t... 4

checking for pthread_t... yes

checking size of pthread_t... 4

checking for --enable-toolbox-glue... no

checking for --enable-framework... no

checking for dyld... no

checking SO... .so

checking LDSHARED... $(CC) -shared

checking CCSHARED... -fPIC

checking LINKFORSHARED... -Xlinker -export-dynamic

checking CFLAGSFORSHARED... 

checking SHLIBS... $(LIBS)

checking for dlopen in -ldl... yes

checking for shl_load in -ldld... no

checking for library containing sem_init... -lpthread

checking for textdomain in -lintl... no

checking for t_open in -lnsl... no

checking for socket in -lsocket... no

checking for --with-libs... no

checking for --with-signal-module... yes

checking for --with-dec-threads... no

checking for --with-threads... yes

checking for _POSIX_THREADS in unistd.h... no

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 for usconfig in -lmpc... no

checking if PTHREAD_SCOPE_SYSTEM is supported... yes

checking for pthread_sigmask... yes

checking if --enable-ipv6 is specified... no

checking for --with-universal-newlines... yes

checking for --with-doc-strings... yes

checking for --with-pymalloc... yes

checking for --with-wctype-functions... no

checking for --with-sgi-dl... no

checking for --with-dl-dld... no

checking for dlopen... yes

checking DYNLOADFILE... dynload_shlib.o

checking MACHDEP_OBJS... MACHDEP_OBJS

checking for alarm... yes

checking for chown... yes

checking for clock... yes

checking for confstr... yes

checking for ctermid... yes

checking for execv... yes

checking for fchdir... yes

checking for fork... yes

checking for fsync... yes

checking for fdatasync... yes

checking for fpathconf... yes

checking for ftime... yes

checking for ftruncate... yes

checking for gai_strerror... no

checking for getgroups... yes

checking for getlogin... yes

checking for getloadavg... no

checking for getpeername... yes

checking for getpgid... yes

checking for getpid... yes

checking for getpriority... yes

checking for getpwent... yes

checking for getwd... yes

checking for kill... yes

checking for killpg... yes

checking for lchown... no

checking for lstat... yes

checking for mkfifo... yes

checking for mknod... yes

checking for mktime... yes

checking for mremap... yes

checking for nice... yes

checking for pathconf... yes

checking for pause... yes

checking for plock... no

checking for poll... no

checking for pthread_init... no

checking for putenv... yes

checking for readlink... yes

checking for realpath... yes

checking for select... yes

checking for setegid... yes

checking for seteuid... yes

checking for setgid... yes

checking for setlocale... yes

checking for setregid... yes

checking for setreuid... yes

checking for setsid... yes

checking for setpgid... yes

checking for setpgrp... yes

checking for setuid... yes

checking for setvbuf... yes

checking for snprintf... yes

checking for sigaction... yes

checking for siginterrupt... yes

checking for sigrelse... no

checking for strftime... yes

checking for strptime... yes

checking for sysconf... yes

checking for tcgetpgrp... yes

checking for tcsetpgrp... yes

checking for tempnam... yes

checking for timegm... yes

checking for times... yes

checking for tmpfile... yes

checking for tmpnam... yes

checking for tmpnam_r... no

checking for truncate... yes

checking for uname... yes

checking for unsetenv... yes

checking for utimes... yes

checking for waitpid... yes

checking for wcscoll... no

checking for _getpty... no

checking for chroot... no

checking for link... yes

checking for symlink... no

checking for ctermid_r... no

checking for flock... yes

checking for getpagesize... no

checking for true... true

checking for inet_aton in -lc... yes

checking for hstrerror... no

checking for inet_aton... yes

checking for inet_pton... no

checking for setgroups... no

checking for openpty... no

checking for openpty in -lutil... no

checking for forkpty... no

checking for forkpty in -lutil... no

checking for fseek64... no

checking for fseeko... no

checking for fstatvfs... no

checking for ftell64... no

checking for ftello... no

checking for statvfs... no

checking for dup2... yes

checking for getcwd... yes

checking for strdup... yes

checking for strerror... yes

checking for memmove... yes

checking for getpgrp... yes

checking for setpgrp... (cached) yes

checking for gettimeofday... yes

checking for major... yes

checking for getaddrinfo... no

checking for getnameinfo... no

checking whether time.h and sys/time.h may both be 

included... yes

checking whether struct tm is in sys/time.h or time.h... 

time.h

checking for struct tm.tm_zone... no

checking for tzname... yes

checking for struct stat.st_rdev... yes

checking for struct stat.st_blksize... yes

checking for struct stat.st_blocks... yes

checking for time.h that defines altzone... no

checking whether sys/select.h and sys/time.h may both 

be included... no

checking for addrinfo... no

checking for sockaddr_storage... no

checking whether char is unsigned... no

checking for gcc option to accept ANSI C... none needed

checking for an ANSI C-conforming const... yes

checking for working volatile... yes

checking for working signed char... yes

checking for prototypes... yes

checking for variable length prototypes and stdarg.h... 

yes

checking for bad exec* prototypes... no

checking if sockaddr has sa_len member... no

checking whether va_list is an array... no

checking for gethostbyname_r... yes

checking gethostbyname_r with 6 args... no

checking gethostbyname_r with 5 args... yes

checking for __fpu_control... yes

checking for --with-fpectl... no

checking for --with-libm=STRING... default LIBM="-lm"

checking for --with-libc=STRING... default LIBC=""

checking for hypot... yes

checking wchar.h usability... no

checking wchar.h presence... no

checking for wchar.h... no

checking what type to use for unicode... unsigned short

checking whether byte ordering is bigendian... no

checking whether right shift extends the sign bit... yes

checking for getc_unlocked() and friends... yes

checking for rl_pre_input_hook in -lreadline... no

checking for rl_completion_matches in -lreadline... no

checking for broken nice()... yes

checking for working tzset()... yes

checking for tv_nsec in struct stat... no

checking whether mvwdelch is an expression... yes

checking whether WINDOW has _flags... yes

checking for /dev/ptmx... no

checking for /dev/ptc... no

checking for socklen_t... no

checking for build directories... done

configure: creating ./config.status

config.status: creating Makefile.pre

config.status: creating Modules/Setup.config

config.status: creating pyconfig.h

creating Setup

creating Setup.local

creating Makefile

azure:~/Python-2.3$ 





azure:~/Python-2.3$ make

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/python.o 

Modules/python.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/python.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/acceler.o 

Parser/acceler.c

In file included from Include/grammar.h:10,

                 from Parser/acceler.c:14:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/acceler.c:13:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar1.o 

Parser/grammar1.c

In file included from Include/grammar.h:10,

                 from Parser/grammar1.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar1.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/listnode.o 

Parser/listnode.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/listnode.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/node.o 

Parser/node.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/node.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parser.o 

Parser/parser.c

In file included from Include/grammar.h:10,

                 from Parser/parser.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/parser.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parsetok.o 

Parser/parsetok.c

In file included from Include/grammar.h:10,

                 from Parser/parsetok.c:7:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/parsetok.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/bitset.o 

Parser/bitset.c

In file included from Parser/bitset.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/bitset.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/metagrammar.o 

Parser/metagrammar.c

In file included from Include/grammar.h:10,

                 from Parser/metagrammar.c:4:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/metagrammar.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/firstsets.o 

Parser/firstsets.c

In file included from Include/grammar.h:10,

                 from Parser/firstsets.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/firstsets.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar.o 

Parser/grammar.c

In file included from Include/grammar.h:10,

                 from Parser/grammar.c:10:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Parser/grammar.c: In function `_Py_adddfa':

Parser/grammar.c:45: warning: implicit declaration of 

function `strdup'

Parser/grammar.c:45: warning: assignment makes 

pointer from integer without a cast

Parser/grammar.c: In function `_Py_addlabel':

Parser/grammar.c:105: warning: assignment makes 

pointer from integer without a cast

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgen.o 

Parser/pgen.c

In file included from Include/grammar.h:10,

                 from Parser/pgen.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgen.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/myreadline.o 

Parser/myreadline.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/myreadline.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer.o 

Parser/tokenizer.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/abstract.o 

Objects/abstract.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/abstract.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/boolobject.o 

Objects/boolobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/boolobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/bufferobject.o 

Objects/bufferobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/bufferobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cellobject.o 

Objects/cellobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cellobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/classobject.o 

Objects/classobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/classobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cobject.o 

Objects/cobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/complexobject.o Objects/complexobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/complexobject.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/descrobject.o 

Objects/descrobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/descrobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/enumobject.o 

Objects/enumobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/enumobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/fileobject.o 

Objects/fileobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/fileobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Objects/fileobject.c: In function `file_truncate':

Objects/fileobject.c:618: warning: implicit declaration of 

function `ftruncate'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/floatobject.o 

Objects/floatobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/floatobject.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/frameobject.o 

Objects/frameobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/frameobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/funcobject.o 

Objects/funcobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/funcobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/intobject.o 

Objects/intobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/intobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/iterobject.o 

Objects/iterobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/iterobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/listobject.o 

Objects/listobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/listobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/longobject.o 

Objects/longobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/longobject.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/dictobject.o 

Objects/dictobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/dictobject.c:10:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/methodobject.o Objects/methodobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/methodobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/moduleobject.o 

Objects/moduleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/moduleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/object.o 

Objects/object.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/object.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/obmalloc.o 

Objects/obmalloc.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/obmalloc.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/rangeobject.o 

Objects/rangeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/rangeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/sliceobject.o 

Objects/sliceobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/sliceobject.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/stringobject.o 

Objects/stringobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/stringobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/structseq.o 

Objects/structseq.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/structseq.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/tupleobject.o 

Objects/tupleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/tupleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/typeobject.o 

Objects/typeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/typeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/weakrefobject.o Objects/weakrefobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/weakrefobject.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/unicodeobject.o Objects/unicodeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodeobject.c:39:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/unicodectype.o 

Objects/unicodectype.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodectype.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/bltinmodule.o 

Python/bltinmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/bltinmodule.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/exceptions.o 

Python/exceptions.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/exceptions.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/ceval.o 

Python/ceval.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/ceval.c:9:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mysnprintf.o 

Python/mysnprintf.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mysnprintf.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o 

Parser/tokenizer_pgen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4,

                 from Parser/tokenizer_pgen.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/printgrammar.o 

Parser/printgrammar.c

In file included from Include/grammar.h:10,

                 from Parser/printgrammar.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/printgrammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgenmain.o 

Parser/pgenmain.c

In file included from Include/grammar.h:10,

                 from Parser/pgenmain.c:18:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgenmain.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   

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 Objects/obmalloc.o 

Python/mysnprintf.o Parser/tokenizer_pgen.o 

Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl  -

lpthread -o Parser/pgen

Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Py

thon/graminit.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/compile.o 

Python/compile.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/compile.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/codecs.o 

Python/codecs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/codecs.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/errors.o 

Python/errors.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/errors.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/errors.c: At top level:

Python/errors.c:602: warning: function declaration isn't 

a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozen.o 

Python/frozen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozen.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozenmain.o 

Python/frozenmain.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozenmain.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/future.o 

Python/future.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/future.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getargs.o 

Python/getargs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getargs.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcompiler.o 

Python/getcompiler.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcompiler.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcopyright.o 

Python/getcopyright.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcopyright.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getmtime.o 

Python/getmtime.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getmtime.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPLATFORM='"linux2"' -o 

Python/getplatform.o ./Python/getplatform.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/getplatform.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getversion.o 

Python/getversion.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getversion.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/graminit.o 

Python/graminit.c

In file included from Include/grammar.h:10,

                 from Python/graminit.c:2:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Python/graminit.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/import.o 

Python/import.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/import.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -I. -o 

Python/importdl.o ./Python/importdl.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/importdl.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/marshal.o 

Python/marshal.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/marshal.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/modsupport.o 

Python/modsupport.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/modsupport.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mystrtoul.o 

Python/mystrtoul.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mystrtoul.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pyfpe.o 

Python/pyfpe.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pystate.o 

Python/pystate.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pystate.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pythonrun.o 

Python/pythonrun.c

In file included from Include/grammar.h:10,

                 from Python/pythonrun.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pythonrun.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/pythonrun.c: At top level:

Python/pythonrun.c:81: warning: function declaration 

isn't a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/structmember.o 

Python/structmember.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/structmember.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/symtable.o 

Python/symtable.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/symtable.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/sysmodule.o 

Python/sysmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/sysmodule.c:17:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/sysmodule.c: In function `PySys_SetArgv':

Python/sysmodule.c:1163: warning: implicit declaration 

of function `readlink'

Python/sysmodule.c:1212: warning: implicit declaration 

of function `realpath'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/traceback.o 

Python/traceback.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/traceback.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getopt.o 

Python/getopt.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/dynload_shlib.o 

Python/dynload_shlib.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/dynload_shlib.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/thread.o 

Python/thread.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/thread.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/config.o 

Modules/config.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/config.c:19:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPYTHONPATH='":plat-

linux2:lib-tk"' \

        -DPREFIX='"/usr/local"' \

        -DEXEC_PREFIX='"/usr/local"' \

        -DVERSION='"2.3"' \

        -DVPATH='""' \

        -o Modules/getpath.o ./Modules/getpath.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/getpath.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/getpath.c: In function `calculate_path':

./Modules/getpath.c:454: warning: implicit declaration of 

function `readlink'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/main.o 

Modules/main.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/main.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o 

Modules/gcmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/gcmodule.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/threadmodule.c -o Modules/threadmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/threadmodule.c:5:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/signalmodule.c -o Modules/signalmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/signalmodule.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/signalmodule.c: In function `signal_handler':

./Modules/signalmodule.c:141: warning: implicit 

declaration of function `siginterrupt'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/posixmodule.c -o Modules/posixmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/posixmodule.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/posixmodule.c: In function `posix_fchdir':

./Modules/posixmodule.c:1132: `fchdir' undeclared (first 

use this function)

./Modules/posixmodule.c:1132: (Each undeclared 

identifier is reported only once

./Modules/posixmodule.c:1132: for each function it 

appears in.)

./Modules/posixmodule.c: In function `posix_fsync':

./Modules/posixmodule.c:1181: `fsync' undeclared (first 

use this function)

./Modules/posixmodule.c: In function `posix_fdatasync':

./Modules/posixmodule.c:1199: `fdatasync' undeclared 

(first use this function)

./Modules/posixmodule.c: In function `posix_nice':

./Modules/posixmodule.c:1722: warning: implicit 

declaration of function `nice'

./Modules/posixmodule.c: In function `posix_seteuid':

./Modules/posixmodule.c:4380: warning: implicit 

declaration of function `seteuid'

./Modules/posixmodule.c: In function `posix_setegid':

./Modules/posixmodule.c:4400: warning: implicit 

declaration of function `setegid'

./Modules/posixmodule.c: In function `posix_setreuid':

./Modules/posixmodule.c:4420: warning: implicit 

declaration of function `setreuid'

./Modules/posixmodule.c: In function `posix_setregid':

./Modules/posixmodule.c:4440: warning: implicit 

declaration of function `setregid'

./Modules/posixmodule.c: In function `posix_readlink':

./Modules/posixmodule.c:4632: warning: implicit 

declaration of function `readlink'

./Modules/posixmodule.c: In function `posix_ftruncate':

./Modules/posixmodule.c:5255: warning: implicit 

declaration of function `ftruncate'

./Modules/posixmodule.c: In function `posix_putenv':

./Modules/posixmodule.c:5312: warning: implicit 

declaration of function `putenv'

./Modules/posixmodule.c: In function `posix_unsetenv':

./Modules/posixmodule.c:5351: warning: implicit 

declaration of function `unsetenv'

make: *** [Modules/posixmodule.o] Error 1

azure:~/Python-2.3$ 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

From noreply at sourceforge.net  Fri Sep  5 01:12:57 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 09:14:48 2003
Subject: [Python-bugs-list] [ python-Bugs-800710 ] build fails
Message-ID: <E19v8u1-0005nU-00@sc8-sf-web3.sourceforge.net>

Bugs item #800710, was opened at 2003-09-04 23:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Schran (aschran)
Assigned to: Nobody/Anonymous (nobody)
Summary: build fails

Initial Comment:
dear python code samurais,



I ran ./configure and make on python 2.3, and got this 

failure on the make.  researched extensively before 

posting to you guys. =)



This problem only happens when installing Python 2.3.  

Python 2.2 installs flawlessly.



This is on a 2-year-old Linux box running slackware, with 

gcc version 2.7.2. 



I was able to get Python 2.3 to install on a newer 

machine with a different linux distrib with no problem. 



here are the results of the .configure and the make. 

Thanks for any help getting Python going on this 

machine! I'll try any suggestions. Adam



azure:~/Python-2.3$ ./configure

checking MACHDEP... linux2

checking EXTRAPLATDIR... 

checking for --without-gcc... no

checking for --with-cxx=<compiler>... no

checking for c++... c++

checking for C++ compiler default output... a.out

checking whether the C++ compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for gcc... gcc

checking for C compiler default output... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking how to run the C preprocessor... gcc -E

checking for AIX... no

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... no

checking for stdint.h... no

checking for unistd.h... yes

checking minix/config.h usability... no

checking minix/config.h presence... no

checking for minix/config.h... no

checking for --with-suffix... 

checking for case-insensitive build directory... no

checking LIBRARY... libpython$(VERSION).a

checking LINKCC... $(PURIFY) $(CC)

checking for --enable-shared... no

checking LDLIBRARY... libpython$(VERSION).a

checking for ranlib... ranlib

checking for ar... ar

checking for a BSD-compatible install... /usr/bin/ginstall -

c

checking for --with-pydebug... no

checking whether gcc accepts -fno-strict-aliasing... no

checking whether gcc accepts -OPT:Olimit=0... no

checking whether gcc accepts -Olimit 1500... no

checking whether pthreads are available without 

options... no

checking whether gcc accepts -Kpthread... no

checking whether gcc accepts -Kthread... no

checking whether gcc accepts -pthread... no

checking whether c++ also accepts flags for thread 

support... no

checking for ANSI C header files... (cached) yes

checking dlfcn.h usability... yes

checking dlfcn.h presence... yes

checking for dlfcn.h... yes

checking fcntl.h usability... yes

checking fcntl.h presence... yes

checking for fcntl.h... yes

checking grp.h usability... yes

checking grp.h presence... yes

checking for grp.h... yes

checking limits.h usability... yes

checking limits.h presence... yes

checking for limits.h... yes

checking langinfo.h usability... yes

checking langinfo.h presence... yes

checking for langinfo.h... yes

checking libintl.h usability... no

checking libintl.h presence... no

checking for libintl.h... no

checking locale.h usability... yes

checking locale.h presence... yes

checking for locale.h... yes

checking ncurses.h usability... no

checking ncurses.h presence... no

checking for ncurses.h... no

checking poll.h usability... no

checking poll.h presence... no

checking for poll.h... no

checking pthread.h usability... yes

checking pthread.h presence... yes

checking for pthread.h... yes

checking signal.h usability... yes

checking signal.h presence... yes

checking for signal.h... yes

checking stdarg.h usability... yes

checking stdarg.h presence... yes

checking for stdarg.h... yes

checking stddef.h usability... yes

checking stddef.h presence... yes

checking for stddef.h... yes

checking for stdlib.h... (cached) yes

checking stropts.h usability... no

checking stropts.h presence... no

checking for stropts.h... no

checking termios.h usability... yes

checking termios.h presence... yes

checking for termios.h... yes

checking thread.h usability... no

checking thread.h presence... no

checking for thread.h... no

checking for unistd.h... (cached) yes

checking utime.h usability... yes

checking utime.h presence... yes

checking for utime.h... yes

checking sys/audioio.h usability... no

checking sys/audioio.h presence... no

checking for sys/audioio.h... no

checking sys/bsdtty.h usability... no

checking sys/bsdtty.h presence... no

checking for sys/bsdtty.h... no

checking sys/file.h usability... yes

checking sys/file.h presence... yes

checking for sys/file.h... yes

checking sys/lock.h usability... no

checking sys/lock.h presence... no

checking for sys/lock.h... no

checking sys/mkdev.h usability... no

checking sys/mkdev.h presence... no

checking for sys/mkdev.h... no

checking sys/modem.h usability... no

checking sys/modem.h presence... no

checking for sys/modem.h... no

checking sys/param.h usability... yes

checking sys/param.h presence... yes

checking for sys/param.h... yes

checking sys/poll.h usability... no

checking sys/poll.h presence... no

checking for sys/poll.h... no

checking sys/select.h usability... no

checking sys/select.h presence... no

checking for sys/select.h... no

checking sys/socket.h usability... yes

checking sys/socket.h presence... yes

checking for sys/socket.h... yes

checking sys/time.h usability... yes

checking sys/time.h presence... yes

checking for sys/time.h... yes

checking sys/times.h usability... yes

checking sys/times.h presence... yes

checking for sys/times.h... yes

checking sys/un.h usability... no

checking sys/un.h presence... yes

configure: WARNING: sys/un.h: present but cannot be 

compiled

configure: WARNING: sys/un.h: check for missing 

prerequisite headers?

configure: WARNING: sys/un.h: proceeding with the 

preprocessor's result

checking for sys/un.h... yes

checking sys/utsname.h usability... yes

checking sys/utsname.h presence... yes

checking for sys/utsname.h... yes

checking sys/wait.h usability... yes

checking sys/wait.h presence... yes

checking for sys/wait.h... yes

checking pty.h usability... no

checking pty.h presence... no

checking for pty.h... no

checking term.h usability... yes

checking term.h presence... yes

checking for term.h... yes

checking libutil.h usability... no

checking libutil.h presence... no

checking for libutil.h... no

checking sys/resource.h usability... yes

checking sys/resource.h presence... yes

checking for sys/resource.h... yes

checking netpacket/packet.h usability... no

checking netpacket/packet.h presence... no

checking for netpacket/packet.h... no

checking sysexits.h usability... yes

checking sysexits.h presence... yes

checking for sysexits.h... yes

checking for dirent.h that defines DIR... yes

checking for library containing opendir... none required

checking whether sys/types.h defines makedev... no

checking for sys/mkdev.h... (cached) no

checking sys/sysmacros.h usability... yes

checking sys/sysmacros.h presence... yes

checking for sys/sysmacros.h... yes

checking for clock_t in time.h... yes

checking for makedev... no

checking Solaris LFS bug... no

checking for mode_t... yes

checking for off_t... yes

checking for pid_t... yes

checking return type of signal handlers... void

checking for size_t... yes

checking for uid_t in sys/types.h... yes

checking for int... yes

checking size of int... 4

checking for long... yes

checking size of long... 4

checking for void *... yes

checking size of void *... 4

checking for char... yes

checking size of char... 1

checking for short... yes

checking size of short... 2

checking for float... yes

checking size of float... 4

checking for double... yes

checking size of double... 8

checking for fpos_t... yes

checking size of fpos_t... 4

checking for long long support... yes

checking for long long... yes

checking size of long long... 8

checking for uintptr_t support... no

checking size of off_t... 4

checking whether to enable large file support... no

checking size of time_t... 4

checking for pthread_t... yes

checking size of pthread_t... 4

checking for --enable-toolbox-glue... no

checking for --enable-framework... no

checking for dyld... no

checking SO... .so

checking LDSHARED... $(CC) -shared

checking CCSHARED... -fPIC

checking LINKFORSHARED... -Xlinker -export-dynamic

checking CFLAGSFORSHARED... 

checking SHLIBS... $(LIBS)

checking for dlopen in -ldl... yes

checking for shl_load in -ldld... no

checking for library containing sem_init... -lpthread

checking for textdomain in -lintl... no

checking for t_open in -lnsl... no

checking for socket in -lsocket... no

checking for --with-libs... no

checking for --with-signal-module... yes

checking for --with-dec-threads... no

checking for --with-threads... yes

checking for _POSIX_THREADS in unistd.h... no

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 for usconfig in -lmpc... no

checking if PTHREAD_SCOPE_SYSTEM is supported... yes

checking for pthread_sigmask... yes

checking if --enable-ipv6 is specified... no

checking for --with-universal-newlines... yes

checking for --with-doc-strings... yes

checking for --with-pymalloc... yes

checking for --with-wctype-functions... no

checking for --with-sgi-dl... no

checking for --with-dl-dld... no

checking for dlopen... yes

checking DYNLOADFILE... dynload_shlib.o

checking MACHDEP_OBJS... MACHDEP_OBJS

checking for alarm... yes

checking for chown... yes

checking for clock... yes

checking for confstr... yes

checking for ctermid... yes

checking for execv... yes

checking for fchdir... yes

checking for fork... yes

checking for fsync... yes

checking for fdatasync... yes

checking for fpathconf... yes

checking for ftime... yes

checking for ftruncate... yes

checking for gai_strerror... no

checking for getgroups... yes

checking for getlogin... yes

checking for getloadavg... no

checking for getpeername... yes

checking for getpgid... yes

checking for getpid... yes

checking for getpriority... yes

checking for getpwent... yes

checking for getwd... yes

checking for kill... yes

checking for killpg... yes

checking for lchown... no

checking for lstat... yes

checking for mkfifo... yes

checking for mknod... yes

checking for mktime... yes

checking for mremap... yes

checking for nice... yes

checking for pathconf... yes

checking for pause... yes

checking for plock... no

checking for poll... no

checking for pthread_init... no

checking for putenv... yes

checking for readlink... yes

checking for realpath... yes

checking for select... yes

checking for setegid... yes

checking for seteuid... yes

checking for setgid... yes

checking for setlocale... yes

checking for setregid... yes

checking for setreuid... yes

checking for setsid... yes

checking for setpgid... yes

checking for setpgrp... yes

checking for setuid... yes

checking for setvbuf... yes

checking for snprintf... yes

checking for sigaction... yes

checking for siginterrupt... yes

checking for sigrelse... no

checking for strftime... yes

checking for strptime... yes

checking for sysconf... yes

checking for tcgetpgrp... yes

checking for tcsetpgrp... yes

checking for tempnam... yes

checking for timegm... yes

checking for times... yes

checking for tmpfile... yes

checking for tmpnam... yes

checking for tmpnam_r... no

checking for truncate... yes

checking for uname... yes

checking for unsetenv... yes

checking for utimes... yes

checking for waitpid... yes

checking for wcscoll... no

checking for _getpty... no

checking for chroot... no

checking for link... yes

checking for symlink... no

checking for ctermid_r... no

checking for flock... yes

checking for getpagesize... no

checking for true... true

checking for inet_aton in -lc... yes

checking for hstrerror... no

checking for inet_aton... yes

checking for inet_pton... no

checking for setgroups... no

checking for openpty... no

checking for openpty in -lutil... no

checking for forkpty... no

checking for forkpty in -lutil... no

checking for fseek64... no

checking for fseeko... no

checking for fstatvfs... no

checking for ftell64... no

checking for ftello... no

checking for statvfs... no

checking for dup2... yes

checking for getcwd... yes

checking for strdup... yes

checking for strerror... yes

checking for memmove... yes

checking for getpgrp... yes

checking for setpgrp... (cached) yes

checking for gettimeofday... yes

checking for major... yes

checking for getaddrinfo... no

checking for getnameinfo... no

checking whether time.h and sys/time.h may both be 

included... yes

checking whether struct tm is in sys/time.h or time.h... 

time.h

checking for struct tm.tm_zone... no

checking for tzname... yes

checking for struct stat.st_rdev... yes

checking for struct stat.st_blksize... yes

checking for struct stat.st_blocks... yes

checking for time.h that defines altzone... no

checking whether sys/select.h and sys/time.h may both 

be included... no

checking for addrinfo... no

checking for sockaddr_storage... no

checking whether char is unsigned... no

checking for gcc option to accept ANSI C... none needed

checking for an ANSI C-conforming const... yes

checking for working volatile... yes

checking for working signed char... yes

checking for prototypes... yes

checking for variable length prototypes and stdarg.h... 

yes

checking for bad exec* prototypes... no

checking if sockaddr has sa_len member... no

checking whether va_list is an array... no

checking for gethostbyname_r... yes

checking gethostbyname_r with 6 args... no

checking gethostbyname_r with 5 args... yes

checking for __fpu_control... yes

checking for --with-fpectl... no

checking for --with-libm=STRING... default LIBM="-lm"

checking for --with-libc=STRING... default LIBC=""

checking for hypot... yes

checking wchar.h usability... no

checking wchar.h presence... no

checking for wchar.h... no

checking what type to use for unicode... unsigned short

checking whether byte ordering is bigendian... no

checking whether right shift extends the sign bit... yes

checking for getc_unlocked() and friends... yes

checking for rl_pre_input_hook in -lreadline... no

checking for rl_completion_matches in -lreadline... no

checking for broken nice()... yes

checking for working tzset()... yes

checking for tv_nsec in struct stat... no

checking whether mvwdelch is an expression... yes

checking whether WINDOW has _flags... yes

checking for /dev/ptmx... no

checking for /dev/ptc... no

checking for socklen_t... no

checking for build directories... done

configure: creating ./config.status

config.status: creating Makefile.pre

config.status: creating Modules/Setup.config

config.status: creating pyconfig.h

creating Setup

creating Setup.local

creating Makefile

azure:~/Python-2.3$ 





azure:~/Python-2.3$ make

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/python.o 

Modules/python.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/python.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/acceler.o 

Parser/acceler.c

In file included from Include/grammar.h:10,

                 from Parser/acceler.c:14:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/acceler.c:13:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar1.o 

Parser/grammar1.c

In file included from Include/grammar.h:10,

                 from Parser/grammar1.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar1.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/listnode.o 

Parser/listnode.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/listnode.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/node.o 

Parser/node.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/node.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parser.o 

Parser/parser.c

In file included from Include/grammar.h:10,

                 from Parser/parser.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/parser.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parsetok.o 

Parser/parsetok.c

In file included from Include/grammar.h:10,

                 from Parser/parsetok.c:7:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/parsetok.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/bitset.o 

Parser/bitset.c

In file included from Parser/bitset.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/bitset.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/metagrammar.o 

Parser/metagrammar.c

In file included from Include/grammar.h:10,

                 from Parser/metagrammar.c:4:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/metagrammar.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/firstsets.o 

Parser/firstsets.c

In file included from Include/grammar.h:10,

                 from Parser/firstsets.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/firstsets.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar.o 

Parser/grammar.c

In file included from Include/grammar.h:10,

                 from Parser/grammar.c:10:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Parser/grammar.c: In function `_Py_adddfa':

Parser/grammar.c:45: warning: implicit declaration of 

function `strdup'

Parser/grammar.c:45: warning: assignment makes 

pointer from integer without a cast

Parser/grammar.c: In function `_Py_addlabel':

Parser/grammar.c:105: warning: assignment makes 

pointer from integer without a cast

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgen.o 

Parser/pgen.c

In file included from Include/grammar.h:10,

                 from Parser/pgen.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgen.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/myreadline.o 

Parser/myreadline.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/myreadline.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer.o 

Parser/tokenizer.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/abstract.o 

Objects/abstract.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/abstract.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/boolobject.o 

Objects/boolobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/boolobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/bufferobject.o 

Objects/bufferobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/bufferobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cellobject.o 

Objects/cellobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cellobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/classobject.o 

Objects/classobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/classobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cobject.o 

Objects/cobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/complexobject.o Objects/complexobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/complexobject.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/descrobject.o 

Objects/descrobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/descrobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/enumobject.o 

Objects/enumobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/enumobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/fileobject.o 

Objects/fileobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/fileobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Objects/fileobject.c: In function `file_truncate':

Objects/fileobject.c:618: warning: implicit declaration of 

function `ftruncate'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/floatobject.o 

Objects/floatobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/floatobject.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/frameobject.o 

Objects/frameobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/frameobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/funcobject.o 

Objects/funcobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/funcobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/intobject.o 

Objects/intobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/intobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/iterobject.o 

Objects/iterobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/iterobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/listobject.o 

Objects/listobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/listobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/longobject.o 

Objects/longobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/longobject.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/dictobject.o 

Objects/dictobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/dictobject.c:10:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/methodobject.o Objects/methodobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/methodobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/moduleobject.o 

Objects/moduleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/moduleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/object.o 

Objects/object.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/object.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/obmalloc.o 

Objects/obmalloc.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/obmalloc.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/rangeobject.o 

Objects/rangeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/rangeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/sliceobject.o 

Objects/sliceobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/sliceobject.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/stringobject.o 

Objects/stringobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/stringobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/structseq.o 

Objects/structseq.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/structseq.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/tupleobject.o 

Objects/tupleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/tupleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/typeobject.o 

Objects/typeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/typeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/weakrefobject.o Objects/weakrefobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/weakrefobject.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/unicodeobject.o Objects/unicodeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodeobject.c:39:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/unicodectype.o 

Objects/unicodectype.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodectype.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/bltinmodule.o 

Python/bltinmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/bltinmodule.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/exceptions.o 

Python/exceptions.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/exceptions.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/ceval.o 

Python/ceval.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/ceval.c:9:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mysnprintf.o 

Python/mysnprintf.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mysnprintf.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o 

Parser/tokenizer_pgen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4,

                 from Parser/tokenizer_pgen.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/printgrammar.o 

Parser/printgrammar.c

In file included from Include/grammar.h:10,

                 from Parser/printgrammar.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/printgrammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgenmain.o 

Parser/pgenmain.c

In file included from Include/grammar.h:10,

                 from Parser/pgenmain.c:18:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgenmain.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   

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 Objects/obmalloc.o 

Python/mysnprintf.o Parser/tokenizer_pgen.o 

Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl  -

lpthread -o Parser/pgen

Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Py

thon/graminit.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/compile.o 

Python/compile.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/compile.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/codecs.o 

Python/codecs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/codecs.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/errors.o 

Python/errors.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/errors.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/errors.c: At top level:

Python/errors.c:602: warning: function declaration isn't 

a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozen.o 

Python/frozen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozen.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozenmain.o 

Python/frozenmain.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozenmain.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/future.o 

Python/future.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/future.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getargs.o 

Python/getargs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getargs.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcompiler.o 

Python/getcompiler.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcompiler.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcopyright.o 

Python/getcopyright.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcopyright.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getmtime.o 

Python/getmtime.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getmtime.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPLATFORM='"linux2"' -o 

Python/getplatform.o ./Python/getplatform.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/getplatform.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getversion.o 

Python/getversion.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getversion.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/graminit.o 

Python/graminit.c

In file included from Include/grammar.h:10,

                 from Python/graminit.c:2:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Python/graminit.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/import.o 

Python/import.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/import.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -I. -o 

Python/importdl.o ./Python/importdl.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/importdl.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/marshal.o 

Python/marshal.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/marshal.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/modsupport.o 

Python/modsupport.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/modsupport.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mystrtoul.o 

Python/mystrtoul.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mystrtoul.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pyfpe.o 

Python/pyfpe.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pystate.o 

Python/pystate.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pystate.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pythonrun.o 

Python/pythonrun.c

In file included from Include/grammar.h:10,

                 from Python/pythonrun.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pythonrun.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/pythonrun.c: At top level:

Python/pythonrun.c:81: warning: function declaration 

isn't a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/structmember.o 

Python/structmember.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/structmember.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/symtable.o 

Python/symtable.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/symtable.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/sysmodule.o 

Python/sysmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/sysmodule.c:17:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/sysmodule.c: In function `PySys_SetArgv':

Python/sysmodule.c:1163: warning: implicit declaration 

of function `readlink'

Python/sysmodule.c:1212: warning: implicit declaration 

of function `realpath'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/traceback.o 

Python/traceback.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/traceback.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getopt.o 

Python/getopt.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/dynload_shlib.o 

Python/dynload_shlib.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/dynload_shlib.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/thread.o 

Python/thread.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/thread.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/config.o 

Modules/config.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/config.c:19:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPYTHONPATH='":plat-

linux2:lib-tk"' \

        -DPREFIX='"/usr/local"' \

        -DEXEC_PREFIX='"/usr/local"' \

        -DVERSION='"2.3"' \

        -DVPATH='""' \

        -o Modules/getpath.o ./Modules/getpath.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/getpath.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/getpath.c: In function `calculate_path':

./Modules/getpath.c:454: warning: implicit declaration of 

function `readlink'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/main.o 

Modules/main.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/main.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o 

Modules/gcmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/gcmodule.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/threadmodule.c -o Modules/threadmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/threadmodule.c:5:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/signalmodule.c -o Modules/signalmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/signalmodule.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/signalmodule.c: In function `signal_handler':

./Modules/signalmodule.c:141: warning: implicit 

declaration of function `siginterrupt'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/posixmodule.c -o Modules/posixmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/posixmodule.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/posixmodule.c: In function `posix_fchdir':

./Modules/posixmodule.c:1132: `fchdir' undeclared (first 

use this function)

./Modules/posixmodule.c:1132: (Each undeclared 

identifier is reported only once

./Modules/posixmodule.c:1132: for each function it 

appears in.)

./Modules/posixmodule.c: In function `posix_fsync':

./Modules/posixmodule.c:1181: `fsync' undeclared (first 

use this function)

./Modules/posixmodule.c: In function `posix_fdatasync':

./Modules/posixmodule.c:1199: `fdatasync' undeclared 

(first use this function)

./Modules/posixmodule.c: In function `posix_nice':

./Modules/posixmodule.c:1722: warning: implicit 

declaration of function `nice'

./Modules/posixmodule.c: In function `posix_seteuid':

./Modules/posixmodule.c:4380: warning: implicit 

declaration of function `seteuid'

./Modules/posixmodule.c: In function `posix_setegid':

./Modules/posixmodule.c:4400: warning: implicit 

declaration of function `setegid'

./Modules/posixmodule.c: In function `posix_setreuid':

./Modules/posixmodule.c:4420: warning: implicit 

declaration of function `setreuid'

./Modules/posixmodule.c: In function `posix_setregid':

./Modules/posixmodule.c:4440: warning: implicit 

declaration of function `setregid'

./Modules/posixmodule.c: In function `posix_readlink':

./Modules/posixmodule.c:4632: warning: implicit 

declaration of function `readlink'

./Modules/posixmodule.c: In function `posix_ftruncate':

./Modules/posixmodule.c:5255: warning: implicit 

declaration of function `ftruncate'

./Modules/posixmodule.c: In function `posix_putenv':

./Modules/posixmodule.c:5312: warning: implicit 

declaration of function `putenv'

./Modules/posixmodule.c: In function `posix_unsetenv':

./Modules/posixmodule.c:5351: warning: implicit 

declaration of function `unsetenv'

make: *** [Modules/posixmodule.o] Error 1

azure:~/Python-2.3$ 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-05 07:12

Message:
Logged In: YES 
user_id=21627

We should focus on understanding a single problem at a time.

I propose that we focus on the failure



./Modules/posixmodule.c:1132: `fchdir' undeclared (first

use this function)



Now, this function ought to be declared in

/usr/include/unistd.h. Can you find out whether it is

declared there? If it is, can you find out why the

definition is not visible? If it is not, can you find out

whether it is declared elsewhere?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

From noreply at sourceforge.net  Fri Sep  5 13:13:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 09:14:53 2003
Subject: [Python-bugs-list] [ python-Bugs-800710 ] build fails
Message-ID: <E19vK9X-0003Ov-00@sc8-sf-web4.sourceforge.net>

Bugs item #800710, was opened at 2003-09-04 21:27
Message generated for change (Comment added) made by aschran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Schran (aschran)
Assigned to: Nobody/Anonymous (nobody)
Summary: build fails

Initial Comment:
dear python code samurais,



I ran ./configure and make on python 2.3, and got this 

failure on the make.  researched extensively before 

posting to you guys. =)



This problem only happens when installing Python 2.3.  

Python 2.2 installs flawlessly.



This is on a 2-year-old Linux box running slackware, with 

gcc version 2.7.2. 



I was able to get Python 2.3 to install on a newer 

machine with a different linux distrib with no problem. 



here are the results of the .configure and the make. 

Thanks for any help getting Python going on this 

machine! I'll try any suggestions. Adam



azure:~/Python-2.3$ ./configure

checking MACHDEP... linux2

checking EXTRAPLATDIR... 

checking for --without-gcc... no

checking for --with-cxx=<compiler>... no

checking for c++... c++

checking for C++ compiler default output... a.out

checking whether the C++ compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for gcc... gcc

checking for C compiler default output... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking how to run the C preprocessor... gcc -E

checking for AIX... no

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... no

checking for stdint.h... no

checking for unistd.h... yes

checking minix/config.h usability... no

checking minix/config.h presence... no

checking for minix/config.h... no

checking for --with-suffix... 

checking for case-insensitive build directory... no

checking LIBRARY... libpython$(VERSION).a

checking LINKCC... $(PURIFY) $(CC)

checking for --enable-shared... no

checking LDLIBRARY... libpython$(VERSION).a

checking for ranlib... ranlib

checking for ar... ar

checking for a BSD-compatible install... /usr/bin/ginstall -

c

checking for --with-pydebug... no

checking whether gcc accepts -fno-strict-aliasing... no

checking whether gcc accepts -OPT:Olimit=0... no

checking whether gcc accepts -Olimit 1500... no

checking whether pthreads are available without 

options... no

checking whether gcc accepts -Kpthread... no

checking whether gcc accepts -Kthread... no

checking whether gcc accepts -pthread... no

checking whether c++ also accepts flags for thread 

support... no

checking for ANSI C header files... (cached) yes

checking dlfcn.h usability... yes

checking dlfcn.h presence... yes

checking for dlfcn.h... yes

checking fcntl.h usability... yes

checking fcntl.h presence... yes

checking for fcntl.h... yes

checking grp.h usability... yes

checking grp.h presence... yes

checking for grp.h... yes

checking limits.h usability... yes

checking limits.h presence... yes

checking for limits.h... yes

checking langinfo.h usability... yes

checking langinfo.h presence... yes

checking for langinfo.h... yes

checking libintl.h usability... no

checking libintl.h presence... no

checking for libintl.h... no

checking locale.h usability... yes

checking locale.h presence... yes

checking for locale.h... yes

checking ncurses.h usability... no

checking ncurses.h presence... no

checking for ncurses.h... no

checking poll.h usability... no

checking poll.h presence... no

checking for poll.h... no

checking pthread.h usability... yes

checking pthread.h presence... yes

checking for pthread.h... yes

checking signal.h usability... yes

checking signal.h presence... yes

checking for signal.h... yes

checking stdarg.h usability... yes

checking stdarg.h presence... yes

checking for stdarg.h... yes

checking stddef.h usability... yes

checking stddef.h presence... yes

checking for stddef.h... yes

checking for stdlib.h... (cached) yes

checking stropts.h usability... no

checking stropts.h presence... no

checking for stropts.h... no

checking termios.h usability... yes

checking termios.h presence... yes

checking for termios.h... yes

checking thread.h usability... no

checking thread.h presence... no

checking for thread.h... no

checking for unistd.h... (cached) yes

checking utime.h usability... yes

checking utime.h presence... yes

checking for utime.h... yes

checking sys/audioio.h usability... no

checking sys/audioio.h presence... no

checking for sys/audioio.h... no

checking sys/bsdtty.h usability... no

checking sys/bsdtty.h presence... no

checking for sys/bsdtty.h... no

checking sys/file.h usability... yes

checking sys/file.h presence... yes

checking for sys/file.h... yes

checking sys/lock.h usability... no

checking sys/lock.h presence... no

checking for sys/lock.h... no

checking sys/mkdev.h usability... no

checking sys/mkdev.h presence... no

checking for sys/mkdev.h... no

checking sys/modem.h usability... no

checking sys/modem.h presence... no

checking for sys/modem.h... no

checking sys/param.h usability... yes

checking sys/param.h presence... yes

checking for sys/param.h... yes

checking sys/poll.h usability... no

checking sys/poll.h presence... no

checking for sys/poll.h... no

checking sys/select.h usability... no

checking sys/select.h presence... no

checking for sys/select.h... no

checking sys/socket.h usability... yes

checking sys/socket.h presence... yes

checking for sys/socket.h... yes

checking sys/time.h usability... yes

checking sys/time.h presence... yes

checking for sys/time.h... yes

checking sys/times.h usability... yes

checking sys/times.h presence... yes

checking for sys/times.h... yes

checking sys/un.h usability... no

checking sys/un.h presence... yes

configure: WARNING: sys/un.h: present but cannot be 

compiled

configure: WARNING: sys/un.h: check for missing 

prerequisite headers?

configure: WARNING: sys/un.h: proceeding with the 

preprocessor's result

checking for sys/un.h... yes

checking sys/utsname.h usability... yes

checking sys/utsname.h presence... yes

checking for sys/utsname.h... yes

checking sys/wait.h usability... yes

checking sys/wait.h presence... yes

checking for sys/wait.h... yes

checking pty.h usability... no

checking pty.h presence... no

checking for pty.h... no

checking term.h usability... yes

checking term.h presence... yes

checking for term.h... yes

checking libutil.h usability... no

checking libutil.h presence... no

checking for libutil.h... no

checking sys/resource.h usability... yes

checking sys/resource.h presence... yes

checking for sys/resource.h... yes

checking netpacket/packet.h usability... no

checking netpacket/packet.h presence... no

checking for netpacket/packet.h... no

checking sysexits.h usability... yes

checking sysexits.h presence... yes

checking for sysexits.h... yes

checking for dirent.h that defines DIR... yes

checking for library containing opendir... none required

checking whether sys/types.h defines makedev... no

checking for sys/mkdev.h... (cached) no

checking sys/sysmacros.h usability... yes

checking sys/sysmacros.h presence... yes

checking for sys/sysmacros.h... yes

checking for clock_t in time.h... yes

checking for makedev... no

checking Solaris LFS bug... no

checking for mode_t... yes

checking for off_t... yes

checking for pid_t... yes

checking return type of signal handlers... void

checking for size_t... yes

checking for uid_t in sys/types.h... yes

checking for int... yes

checking size of int... 4

checking for long... yes

checking size of long... 4

checking for void *... yes

checking size of void *... 4

checking for char... yes

checking size of char... 1

checking for short... yes

checking size of short... 2

checking for float... yes

checking size of float... 4

checking for double... yes

checking size of double... 8

checking for fpos_t... yes

checking size of fpos_t... 4

checking for long long support... yes

checking for long long... yes

checking size of long long... 8

checking for uintptr_t support... no

checking size of off_t... 4

checking whether to enable large file support... no

checking size of time_t... 4

checking for pthread_t... yes

checking size of pthread_t... 4

checking for --enable-toolbox-glue... no

checking for --enable-framework... no

checking for dyld... no

checking SO... .so

checking LDSHARED... $(CC) -shared

checking CCSHARED... -fPIC

checking LINKFORSHARED... -Xlinker -export-dynamic

checking CFLAGSFORSHARED... 

checking SHLIBS... $(LIBS)

checking for dlopen in -ldl... yes

checking for shl_load in -ldld... no

checking for library containing sem_init... -lpthread

checking for textdomain in -lintl... no

checking for t_open in -lnsl... no

checking for socket in -lsocket... no

checking for --with-libs... no

checking for --with-signal-module... yes

checking for --with-dec-threads... no

checking for --with-threads... yes

checking for _POSIX_THREADS in unistd.h... no

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 for usconfig in -lmpc... no

checking if PTHREAD_SCOPE_SYSTEM is supported... yes

checking for pthread_sigmask... yes

checking if --enable-ipv6 is specified... no

checking for --with-universal-newlines... yes

checking for --with-doc-strings... yes

checking for --with-pymalloc... yes

checking for --with-wctype-functions... no

checking for --with-sgi-dl... no

checking for --with-dl-dld... no

checking for dlopen... yes

checking DYNLOADFILE... dynload_shlib.o

checking MACHDEP_OBJS... MACHDEP_OBJS

checking for alarm... yes

checking for chown... yes

checking for clock... yes

checking for confstr... yes

checking for ctermid... yes

checking for execv... yes

checking for fchdir... yes

checking for fork... yes

checking for fsync... yes

checking for fdatasync... yes

checking for fpathconf... yes

checking for ftime... yes

checking for ftruncate... yes

checking for gai_strerror... no

checking for getgroups... yes

checking for getlogin... yes

checking for getloadavg... no

checking for getpeername... yes

checking for getpgid... yes

checking for getpid... yes

checking for getpriority... yes

checking for getpwent... yes

checking for getwd... yes

checking for kill... yes

checking for killpg... yes

checking for lchown... no

checking for lstat... yes

checking for mkfifo... yes

checking for mknod... yes

checking for mktime... yes

checking for mremap... yes

checking for nice... yes

checking for pathconf... yes

checking for pause... yes

checking for plock... no

checking for poll... no

checking for pthread_init... no

checking for putenv... yes

checking for readlink... yes

checking for realpath... yes

checking for select... yes

checking for setegid... yes

checking for seteuid... yes

checking for setgid... yes

checking for setlocale... yes

checking for setregid... yes

checking for setreuid... yes

checking for setsid... yes

checking for setpgid... yes

checking for setpgrp... yes

checking for setuid... yes

checking for setvbuf... yes

checking for snprintf... yes

checking for sigaction... yes

checking for siginterrupt... yes

checking for sigrelse... no

checking for strftime... yes

checking for strptime... yes

checking for sysconf... yes

checking for tcgetpgrp... yes

checking for tcsetpgrp... yes

checking for tempnam... yes

checking for timegm... yes

checking for times... yes

checking for tmpfile... yes

checking for tmpnam... yes

checking for tmpnam_r... no

checking for truncate... yes

checking for uname... yes

checking for unsetenv... yes

checking for utimes... yes

checking for waitpid... yes

checking for wcscoll... no

checking for _getpty... no

checking for chroot... no

checking for link... yes

checking for symlink... no

checking for ctermid_r... no

checking for flock... yes

checking for getpagesize... no

checking for true... true

checking for inet_aton in -lc... yes

checking for hstrerror... no

checking for inet_aton... yes

checking for inet_pton... no

checking for setgroups... no

checking for openpty... no

checking for openpty in -lutil... no

checking for forkpty... no

checking for forkpty in -lutil... no

checking for fseek64... no

checking for fseeko... no

checking for fstatvfs... no

checking for ftell64... no

checking for ftello... no

checking for statvfs... no

checking for dup2... yes

checking for getcwd... yes

checking for strdup... yes

checking for strerror... yes

checking for memmove... yes

checking for getpgrp... yes

checking for setpgrp... (cached) yes

checking for gettimeofday... yes

checking for major... yes

checking for getaddrinfo... no

checking for getnameinfo... no

checking whether time.h and sys/time.h may both be 

included... yes

checking whether struct tm is in sys/time.h or time.h... 

time.h

checking for struct tm.tm_zone... no

checking for tzname... yes

checking for struct stat.st_rdev... yes

checking for struct stat.st_blksize... yes

checking for struct stat.st_blocks... yes

checking for time.h that defines altzone... no

checking whether sys/select.h and sys/time.h may both 

be included... no

checking for addrinfo... no

checking for sockaddr_storage... no

checking whether char is unsigned... no

checking for gcc option to accept ANSI C... none needed

checking for an ANSI C-conforming const... yes

checking for working volatile... yes

checking for working signed char... yes

checking for prototypes... yes

checking for variable length prototypes and stdarg.h... 

yes

checking for bad exec* prototypes... no

checking if sockaddr has sa_len member... no

checking whether va_list is an array... no

checking for gethostbyname_r... yes

checking gethostbyname_r with 6 args... no

checking gethostbyname_r with 5 args... yes

checking for __fpu_control... yes

checking for --with-fpectl... no

checking for --with-libm=STRING... default LIBM="-lm"

checking for --with-libc=STRING... default LIBC=""

checking for hypot... yes

checking wchar.h usability... no

checking wchar.h presence... no

checking for wchar.h... no

checking what type to use for unicode... unsigned short

checking whether byte ordering is bigendian... no

checking whether right shift extends the sign bit... yes

checking for getc_unlocked() and friends... yes

checking for rl_pre_input_hook in -lreadline... no

checking for rl_completion_matches in -lreadline... no

checking for broken nice()... yes

checking for working tzset()... yes

checking for tv_nsec in struct stat... no

checking whether mvwdelch is an expression... yes

checking whether WINDOW has _flags... yes

checking for /dev/ptmx... no

checking for /dev/ptc... no

checking for socklen_t... no

checking for build directories... done

configure: creating ./config.status

config.status: creating Makefile.pre

config.status: creating Modules/Setup.config

config.status: creating pyconfig.h

creating Setup

creating Setup.local

creating Makefile

azure:~/Python-2.3$ 





azure:~/Python-2.3$ make

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/python.o 

Modules/python.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/python.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/acceler.o 

Parser/acceler.c

In file included from Include/grammar.h:10,

                 from Parser/acceler.c:14:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/acceler.c:13:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar1.o 

Parser/grammar1.c

In file included from Include/grammar.h:10,

                 from Parser/grammar1.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar1.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/listnode.o 

Parser/listnode.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/listnode.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/node.o 

Parser/node.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/node.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parser.o 

Parser/parser.c

In file included from Include/grammar.h:10,

                 from Parser/parser.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/parser.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parsetok.o 

Parser/parsetok.c

In file included from Include/grammar.h:10,

                 from Parser/parsetok.c:7:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/parsetok.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/bitset.o 

Parser/bitset.c

In file included from Parser/bitset.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/bitset.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/metagrammar.o 

Parser/metagrammar.c

In file included from Include/grammar.h:10,

                 from Parser/metagrammar.c:4:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/metagrammar.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/firstsets.o 

Parser/firstsets.c

In file included from Include/grammar.h:10,

                 from Parser/firstsets.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/firstsets.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar.o 

Parser/grammar.c

In file included from Include/grammar.h:10,

                 from Parser/grammar.c:10:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Parser/grammar.c: In function `_Py_adddfa':

Parser/grammar.c:45: warning: implicit declaration of 

function `strdup'

Parser/grammar.c:45: warning: assignment makes 

pointer from integer without a cast

Parser/grammar.c: In function `_Py_addlabel':

Parser/grammar.c:105: warning: assignment makes 

pointer from integer without a cast

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgen.o 

Parser/pgen.c

In file included from Include/grammar.h:10,

                 from Parser/pgen.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgen.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/myreadline.o 

Parser/myreadline.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/myreadline.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer.o 

Parser/tokenizer.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/abstract.o 

Objects/abstract.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/abstract.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/boolobject.o 

Objects/boolobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/boolobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/bufferobject.o 

Objects/bufferobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/bufferobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cellobject.o 

Objects/cellobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cellobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/classobject.o 

Objects/classobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/classobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cobject.o 

Objects/cobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/complexobject.o Objects/complexobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/complexobject.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/descrobject.o 

Objects/descrobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/descrobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/enumobject.o 

Objects/enumobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/enumobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/fileobject.o 

Objects/fileobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/fileobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Objects/fileobject.c: In function `file_truncate':

Objects/fileobject.c:618: warning: implicit declaration of 

function `ftruncate'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/floatobject.o 

Objects/floatobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/floatobject.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/frameobject.o 

Objects/frameobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/frameobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/funcobject.o 

Objects/funcobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/funcobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/intobject.o 

Objects/intobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/intobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/iterobject.o 

Objects/iterobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/iterobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/listobject.o 

Objects/listobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/listobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/longobject.o 

Objects/longobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/longobject.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/dictobject.o 

Objects/dictobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/dictobject.c:10:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/methodobject.o Objects/methodobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/methodobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/moduleobject.o 

Objects/moduleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/moduleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/object.o 

Objects/object.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/object.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/obmalloc.o 

Objects/obmalloc.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/obmalloc.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/rangeobject.o 

Objects/rangeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/rangeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/sliceobject.o 

Objects/sliceobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/sliceobject.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/stringobject.o 

Objects/stringobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/stringobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/structseq.o 

Objects/structseq.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/structseq.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/tupleobject.o 

Objects/tupleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/tupleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/typeobject.o 

Objects/typeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/typeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/weakrefobject.o Objects/weakrefobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/weakrefobject.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/unicodeobject.o Objects/unicodeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodeobject.c:39:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/unicodectype.o 

Objects/unicodectype.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodectype.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/bltinmodule.o 

Python/bltinmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/bltinmodule.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/exceptions.o 

Python/exceptions.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/exceptions.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/ceval.o 

Python/ceval.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/ceval.c:9:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mysnprintf.o 

Python/mysnprintf.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mysnprintf.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o 

Parser/tokenizer_pgen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4,

                 from Parser/tokenizer_pgen.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/printgrammar.o 

Parser/printgrammar.c

In file included from Include/grammar.h:10,

                 from Parser/printgrammar.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/printgrammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgenmain.o 

Parser/pgenmain.c

In file included from Include/grammar.h:10,

                 from Parser/pgenmain.c:18:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgenmain.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   

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 Objects/obmalloc.o 

Python/mysnprintf.o Parser/tokenizer_pgen.o 

Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl  -

lpthread -o Parser/pgen

Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Py

thon/graminit.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/compile.o 

Python/compile.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/compile.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/codecs.o 

Python/codecs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/codecs.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/errors.o 

Python/errors.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/errors.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/errors.c: At top level:

Python/errors.c:602: warning: function declaration isn't 

a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozen.o 

Python/frozen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozen.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozenmain.o 

Python/frozenmain.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozenmain.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/future.o 

Python/future.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/future.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getargs.o 

Python/getargs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getargs.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcompiler.o 

Python/getcompiler.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcompiler.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcopyright.o 

Python/getcopyright.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcopyright.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getmtime.o 

Python/getmtime.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getmtime.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPLATFORM='"linux2"' -o 

Python/getplatform.o ./Python/getplatform.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/getplatform.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getversion.o 

Python/getversion.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getversion.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/graminit.o 

Python/graminit.c

In file included from Include/grammar.h:10,

                 from Python/graminit.c:2:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Python/graminit.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/import.o 

Python/import.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/import.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -I. -o 

Python/importdl.o ./Python/importdl.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/importdl.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/marshal.o 

Python/marshal.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/marshal.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/modsupport.o 

Python/modsupport.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/modsupport.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mystrtoul.o 

Python/mystrtoul.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mystrtoul.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pyfpe.o 

Python/pyfpe.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pystate.o 

Python/pystate.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pystate.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pythonrun.o 

Python/pythonrun.c

In file included from Include/grammar.h:10,

                 from Python/pythonrun.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pythonrun.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/pythonrun.c: At top level:

Python/pythonrun.c:81: warning: function declaration 

isn't a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/structmember.o 

Python/structmember.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/structmember.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/symtable.o 

Python/symtable.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/symtable.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/sysmodule.o 

Python/sysmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/sysmodule.c:17:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/sysmodule.c: In function `PySys_SetArgv':

Python/sysmodule.c:1163: warning: implicit declaration 

of function `readlink'

Python/sysmodule.c:1212: warning: implicit declaration 

of function `realpath'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/traceback.o 

Python/traceback.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/traceback.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getopt.o 

Python/getopt.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/dynload_shlib.o 

Python/dynload_shlib.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/dynload_shlib.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/thread.o 

Python/thread.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/thread.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/config.o 

Modules/config.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/config.c:19:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPYTHONPATH='":plat-

linux2:lib-tk"' \

        -DPREFIX='"/usr/local"' \

        -DEXEC_PREFIX='"/usr/local"' \

        -DVERSION='"2.3"' \

        -DVPATH='""' \

        -o Modules/getpath.o ./Modules/getpath.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/getpath.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/getpath.c: In function `calculate_path':

./Modules/getpath.c:454: warning: implicit declaration of 

function `readlink'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/main.o 

Modules/main.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/main.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o 

Modules/gcmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/gcmodule.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/threadmodule.c -o Modules/threadmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/threadmodule.c:5:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/signalmodule.c -o Modules/signalmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/signalmodule.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/signalmodule.c: In function `signal_handler':

./Modules/signalmodule.c:141: warning: implicit 

declaration of function `siginterrupt'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/posixmodule.c -o Modules/posixmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/posixmodule.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/posixmodule.c: In function `posix_fchdir':

./Modules/posixmodule.c:1132: `fchdir' undeclared (first 

use this function)

./Modules/posixmodule.c:1132: (Each undeclared 

identifier is reported only once

./Modules/posixmodule.c:1132: for each function it 

appears in.)

./Modules/posixmodule.c: In function `posix_fsync':

./Modules/posixmodule.c:1181: `fsync' undeclared (first 

use this function)

./Modules/posixmodule.c: In function `posix_fdatasync':

./Modules/posixmodule.c:1199: `fdatasync' undeclared 

(first use this function)

./Modules/posixmodule.c: In function `posix_nice':

./Modules/posixmodule.c:1722: warning: implicit 

declaration of function `nice'

./Modules/posixmodule.c: In function `posix_seteuid':

./Modules/posixmodule.c:4380: warning: implicit 

declaration of function `seteuid'

./Modules/posixmodule.c: In function `posix_setegid':

./Modules/posixmodule.c:4400: warning: implicit 

declaration of function `setegid'

./Modules/posixmodule.c: In function `posix_setreuid':

./Modules/posixmodule.c:4420: warning: implicit 

declaration of function `setreuid'

./Modules/posixmodule.c: In function `posix_setregid':

./Modules/posixmodule.c:4440: warning: implicit 

declaration of function `setregid'

./Modules/posixmodule.c: In function `posix_readlink':

./Modules/posixmodule.c:4632: warning: implicit 

declaration of function `readlink'

./Modules/posixmodule.c: In function `posix_ftruncate':

./Modules/posixmodule.c:5255: warning: implicit 

declaration of function `ftruncate'

./Modules/posixmodule.c: In function `posix_putenv':

./Modules/posixmodule.c:5312: warning: implicit 

declaration of function `putenv'

./Modules/posixmodule.c: In function `posix_unsetenv':

./Modules/posixmodule.c:5351: warning: implicit 

declaration of function `unsetenv'

make: *** [Modules/posixmodule.o] Error 1

azure:~/Python-2.3$ 

----------------------------------------------------------------------

>Comment By: Adam Schran (aschran)
Date: 2003-09-05 17:13

Message:
Logged In: YES 
user_id=859405

Loewis - This is what I found in unistd.h, note the __USE_BSD 

definition:



#ifdef  __USE_BSD

/* Change the owner and group of the file that FD is open 

on.  */

extern int __fchown __P ((int __fd,

                          __uid_t __owner, __gid_t __group));

extern int fchown __P ((int __fd,

                        __uid_t __owner, __gid_t __group));

/* Change the process's working directory to the directory

   that FD is open on.  */

extern int __fchdir __P ((int __fd));

extern int fchdir __P ((int __fd));

#endif /* Use BSD.  */





---



The fchdir function appears to be defined, but only if the 

__USE_BSD value is defined.



I grepped through all of thje *.h and *.c files in the Python's 

Modules directory, as well as the top-level Makefile, and 

I could not find any place where that value was set.



I also grepped through /usr/include for other instances of the 

fchdir() function and did not find any.



This is a Linux system, not BSD.  Also, these configure and 

make errors were reproduced on another Linux machine we 

have when we tried installing Python 2.3.



Does this help at all?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-05 05:12

Message:
Logged In: YES 
user_id=21627

We should focus on understanding a single problem at a time.

I propose that we focus on the failure



./Modules/posixmodule.c:1132: `fchdir' undeclared (first

use this function)



Now, this function ought to be declared in

/usr/include/unistd.h. Can you find out whether it is

declared there? If it is, can you find out why the

definition is not visible? If it is not, can you find out

whether it is declared elsewhere?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

From noreply at sourceforge.net  Sat Sep  6 10:49:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 09:14:58 2003
Subject: [Python-bugs-list] [ python-Bugs-800710 ] build fails
Message-ID: <E19veNe-0005EP-00@sc8-sf-web3.sourceforge.net>

Bugs item #800710, was opened at 2003-09-04 23:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Schran (aschran)
Assigned to: Nobody/Anonymous (nobody)
Summary: build fails

Initial Comment:
dear python code samurais,



I ran ./configure and make on python 2.3, and got this 

failure on the make.  researched extensively before 

posting to you guys. =)



This problem only happens when installing Python 2.3.  

Python 2.2 installs flawlessly.



This is on a 2-year-old Linux box running slackware, with 

gcc version 2.7.2. 



I was able to get Python 2.3 to install on a newer 

machine with a different linux distrib with no problem. 



here are the results of the .configure and the make. 

Thanks for any help getting Python going on this 

machine! I'll try any suggestions. Adam



azure:~/Python-2.3$ ./configure

checking MACHDEP... linux2

checking EXTRAPLATDIR... 

checking for --without-gcc... no

checking for --with-cxx=<compiler>... no

checking for c++... c++

checking for C++ compiler default output... a.out

checking whether the C++ compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for gcc... gcc

checking for C compiler default output... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking how to run the C preprocessor... gcc -E

checking for AIX... no

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... no

checking for stdint.h... no

checking for unistd.h... yes

checking minix/config.h usability... no

checking minix/config.h presence... no

checking for minix/config.h... no

checking for --with-suffix... 

checking for case-insensitive build directory... no

checking LIBRARY... libpython$(VERSION).a

checking LINKCC... $(PURIFY) $(CC)

checking for --enable-shared... no

checking LDLIBRARY... libpython$(VERSION).a

checking for ranlib... ranlib

checking for ar... ar

checking for a BSD-compatible install... /usr/bin/ginstall -

c

checking for --with-pydebug... no

checking whether gcc accepts -fno-strict-aliasing... no

checking whether gcc accepts -OPT:Olimit=0... no

checking whether gcc accepts -Olimit 1500... no

checking whether pthreads are available without 

options... no

checking whether gcc accepts -Kpthread... no

checking whether gcc accepts -Kthread... no

checking whether gcc accepts -pthread... no

checking whether c++ also accepts flags for thread 

support... no

checking for ANSI C header files... (cached) yes

checking dlfcn.h usability... yes

checking dlfcn.h presence... yes

checking for dlfcn.h... yes

checking fcntl.h usability... yes

checking fcntl.h presence... yes

checking for fcntl.h... yes

checking grp.h usability... yes

checking grp.h presence... yes

checking for grp.h... yes

checking limits.h usability... yes

checking limits.h presence... yes

checking for limits.h... yes

checking langinfo.h usability... yes

checking langinfo.h presence... yes

checking for langinfo.h... yes

checking libintl.h usability... no

checking libintl.h presence... no

checking for libintl.h... no

checking locale.h usability... yes

checking locale.h presence... yes

checking for locale.h... yes

checking ncurses.h usability... no

checking ncurses.h presence... no

checking for ncurses.h... no

checking poll.h usability... no

checking poll.h presence... no

checking for poll.h... no

checking pthread.h usability... yes

checking pthread.h presence... yes

checking for pthread.h... yes

checking signal.h usability... yes

checking signal.h presence... yes

checking for signal.h... yes

checking stdarg.h usability... yes

checking stdarg.h presence... yes

checking for stdarg.h... yes

checking stddef.h usability... yes

checking stddef.h presence... yes

checking for stddef.h... yes

checking for stdlib.h... (cached) yes

checking stropts.h usability... no

checking stropts.h presence... no

checking for stropts.h... no

checking termios.h usability... yes

checking termios.h presence... yes

checking for termios.h... yes

checking thread.h usability... no

checking thread.h presence... no

checking for thread.h... no

checking for unistd.h... (cached) yes

checking utime.h usability... yes

checking utime.h presence... yes

checking for utime.h... yes

checking sys/audioio.h usability... no

checking sys/audioio.h presence... no

checking for sys/audioio.h... no

checking sys/bsdtty.h usability... no

checking sys/bsdtty.h presence... no

checking for sys/bsdtty.h... no

checking sys/file.h usability... yes

checking sys/file.h presence... yes

checking for sys/file.h... yes

checking sys/lock.h usability... no

checking sys/lock.h presence... no

checking for sys/lock.h... no

checking sys/mkdev.h usability... no

checking sys/mkdev.h presence... no

checking for sys/mkdev.h... no

checking sys/modem.h usability... no

checking sys/modem.h presence... no

checking for sys/modem.h... no

checking sys/param.h usability... yes

checking sys/param.h presence... yes

checking for sys/param.h... yes

checking sys/poll.h usability... no

checking sys/poll.h presence... no

checking for sys/poll.h... no

checking sys/select.h usability... no

checking sys/select.h presence... no

checking for sys/select.h... no

checking sys/socket.h usability... yes

checking sys/socket.h presence... yes

checking for sys/socket.h... yes

checking sys/time.h usability... yes

checking sys/time.h presence... yes

checking for sys/time.h... yes

checking sys/times.h usability... yes

checking sys/times.h presence... yes

checking for sys/times.h... yes

checking sys/un.h usability... no

checking sys/un.h presence... yes

configure: WARNING: sys/un.h: present but cannot be 

compiled

configure: WARNING: sys/un.h: check for missing 

prerequisite headers?

configure: WARNING: sys/un.h: proceeding with the 

preprocessor's result

checking for sys/un.h... yes

checking sys/utsname.h usability... yes

checking sys/utsname.h presence... yes

checking for sys/utsname.h... yes

checking sys/wait.h usability... yes

checking sys/wait.h presence... yes

checking for sys/wait.h... yes

checking pty.h usability... no

checking pty.h presence... no

checking for pty.h... no

checking term.h usability... yes

checking term.h presence... yes

checking for term.h... yes

checking libutil.h usability... no

checking libutil.h presence... no

checking for libutil.h... no

checking sys/resource.h usability... yes

checking sys/resource.h presence... yes

checking for sys/resource.h... yes

checking netpacket/packet.h usability... no

checking netpacket/packet.h presence... no

checking for netpacket/packet.h... no

checking sysexits.h usability... yes

checking sysexits.h presence... yes

checking for sysexits.h... yes

checking for dirent.h that defines DIR... yes

checking for library containing opendir... none required

checking whether sys/types.h defines makedev... no

checking for sys/mkdev.h... (cached) no

checking sys/sysmacros.h usability... yes

checking sys/sysmacros.h presence... yes

checking for sys/sysmacros.h... yes

checking for clock_t in time.h... yes

checking for makedev... no

checking Solaris LFS bug... no

checking for mode_t... yes

checking for off_t... yes

checking for pid_t... yes

checking return type of signal handlers... void

checking for size_t... yes

checking for uid_t in sys/types.h... yes

checking for int... yes

checking size of int... 4

checking for long... yes

checking size of long... 4

checking for void *... yes

checking size of void *... 4

checking for char... yes

checking size of char... 1

checking for short... yes

checking size of short... 2

checking for float... yes

checking size of float... 4

checking for double... yes

checking size of double... 8

checking for fpos_t... yes

checking size of fpos_t... 4

checking for long long support... yes

checking for long long... yes

checking size of long long... 8

checking for uintptr_t support... no

checking size of off_t... 4

checking whether to enable large file support... no

checking size of time_t... 4

checking for pthread_t... yes

checking size of pthread_t... 4

checking for --enable-toolbox-glue... no

checking for --enable-framework... no

checking for dyld... no

checking SO... .so

checking LDSHARED... $(CC) -shared

checking CCSHARED... -fPIC

checking LINKFORSHARED... -Xlinker -export-dynamic

checking CFLAGSFORSHARED... 

checking SHLIBS... $(LIBS)

checking for dlopen in -ldl... yes

checking for shl_load in -ldld... no

checking for library containing sem_init... -lpthread

checking for textdomain in -lintl... no

checking for t_open in -lnsl... no

checking for socket in -lsocket... no

checking for --with-libs... no

checking for --with-signal-module... yes

checking for --with-dec-threads... no

checking for --with-threads... yes

checking for _POSIX_THREADS in unistd.h... no

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 for usconfig in -lmpc... no

checking if PTHREAD_SCOPE_SYSTEM is supported... yes

checking for pthread_sigmask... yes

checking if --enable-ipv6 is specified... no

checking for --with-universal-newlines... yes

checking for --with-doc-strings... yes

checking for --with-pymalloc... yes

checking for --with-wctype-functions... no

checking for --with-sgi-dl... no

checking for --with-dl-dld... no

checking for dlopen... yes

checking DYNLOADFILE... dynload_shlib.o

checking MACHDEP_OBJS... MACHDEP_OBJS

checking for alarm... yes

checking for chown... yes

checking for clock... yes

checking for confstr... yes

checking for ctermid... yes

checking for execv... yes

checking for fchdir... yes

checking for fork... yes

checking for fsync... yes

checking for fdatasync... yes

checking for fpathconf... yes

checking for ftime... yes

checking for ftruncate... yes

checking for gai_strerror... no

checking for getgroups... yes

checking for getlogin... yes

checking for getloadavg... no

checking for getpeername... yes

checking for getpgid... yes

checking for getpid... yes

checking for getpriority... yes

checking for getpwent... yes

checking for getwd... yes

checking for kill... yes

checking for killpg... yes

checking for lchown... no

checking for lstat... yes

checking for mkfifo... yes

checking for mknod... yes

checking for mktime... yes

checking for mremap... yes

checking for nice... yes

checking for pathconf... yes

checking for pause... yes

checking for plock... no

checking for poll... no

checking for pthread_init... no

checking for putenv... yes

checking for readlink... yes

checking for realpath... yes

checking for select... yes

checking for setegid... yes

checking for seteuid... yes

checking for setgid... yes

checking for setlocale... yes

checking for setregid... yes

checking for setreuid... yes

checking for setsid... yes

checking for setpgid... yes

checking for setpgrp... yes

checking for setuid... yes

checking for setvbuf... yes

checking for snprintf... yes

checking for sigaction... yes

checking for siginterrupt... yes

checking for sigrelse... no

checking for strftime... yes

checking for strptime... yes

checking for sysconf... yes

checking for tcgetpgrp... yes

checking for tcsetpgrp... yes

checking for tempnam... yes

checking for timegm... yes

checking for times... yes

checking for tmpfile... yes

checking for tmpnam... yes

checking for tmpnam_r... no

checking for truncate... yes

checking for uname... yes

checking for unsetenv... yes

checking for utimes... yes

checking for waitpid... yes

checking for wcscoll... no

checking for _getpty... no

checking for chroot... no

checking for link... yes

checking for symlink... no

checking for ctermid_r... no

checking for flock... yes

checking for getpagesize... no

checking for true... true

checking for inet_aton in -lc... yes

checking for hstrerror... no

checking for inet_aton... yes

checking for inet_pton... no

checking for setgroups... no

checking for openpty... no

checking for openpty in -lutil... no

checking for forkpty... no

checking for forkpty in -lutil... no

checking for fseek64... no

checking for fseeko... no

checking for fstatvfs... no

checking for ftell64... no

checking for ftello... no

checking for statvfs... no

checking for dup2... yes

checking for getcwd... yes

checking for strdup... yes

checking for strerror... yes

checking for memmove... yes

checking for getpgrp... yes

checking for setpgrp... (cached) yes

checking for gettimeofday... yes

checking for major... yes

checking for getaddrinfo... no

checking for getnameinfo... no

checking whether time.h and sys/time.h may both be 

included... yes

checking whether struct tm is in sys/time.h or time.h... 

time.h

checking for struct tm.tm_zone... no

checking for tzname... yes

checking for struct stat.st_rdev... yes

checking for struct stat.st_blksize... yes

checking for struct stat.st_blocks... yes

checking for time.h that defines altzone... no

checking whether sys/select.h and sys/time.h may both 

be included... no

checking for addrinfo... no

checking for sockaddr_storage... no

checking whether char is unsigned... no

checking for gcc option to accept ANSI C... none needed

checking for an ANSI C-conforming const... yes

checking for working volatile... yes

checking for working signed char... yes

checking for prototypes... yes

checking for variable length prototypes and stdarg.h... 

yes

checking for bad exec* prototypes... no

checking if sockaddr has sa_len member... no

checking whether va_list is an array... no

checking for gethostbyname_r... yes

checking gethostbyname_r with 6 args... no

checking gethostbyname_r with 5 args... yes

checking for __fpu_control... yes

checking for --with-fpectl... no

checking for --with-libm=STRING... default LIBM="-lm"

checking for --with-libc=STRING... default LIBC=""

checking for hypot... yes

checking wchar.h usability... no

checking wchar.h presence... no

checking for wchar.h... no

checking what type to use for unicode... unsigned short

checking whether byte ordering is bigendian... no

checking whether right shift extends the sign bit... yes

checking for getc_unlocked() and friends... yes

checking for rl_pre_input_hook in -lreadline... no

checking for rl_completion_matches in -lreadline... no

checking for broken nice()... yes

checking for working tzset()... yes

checking for tv_nsec in struct stat... no

checking whether mvwdelch is an expression... yes

checking whether WINDOW has _flags... yes

checking for /dev/ptmx... no

checking for /dev/ptc... no

checking for socklen_t... no

checking for build directories... done

configure: creating ./config.status

config.status: creating Makefile.pre

config.status: creating Modules/Setup.config

config.status: creating pyconfig.h

creating Setup

creating Setup.local

creating Makefile

azure:~/Python-2.3$ 





azure:~/Python-2.3$ make

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/python.o 

Modules/python.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/python.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/acceler.o 

Parser/acceler.c

In file included from Include/grammar.h:10,

                 from Parser/acceler.c:14:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/acceler.c:13:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar1.o 

Parser/grammar1.c

In file included from Include/grammar.h:10,

                 from Parser/grammar1.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar1.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/listnode.o 

Parser/listnode.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/listnode.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/node.o 

Parser/node.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/node.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parser.o 

Parser/parser.c

In file included from Include/grammar.h:10,

                 from Parser/parser.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/parser.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parsetok.o 

Parser/parsetok.c

In file included from Include/grammar.h:10,

                 from Parser/parsetok.c:7:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/parsetok.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/bitset.o 

Parser/bitset.c

In file included from Parser/bitset.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/bitset.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/metagrammar.o 

Parser/metagrammar.c

In file included from Include/grammar.h:10,

                 from Parser/metagrammar.c:4:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/metagrammar.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/firstsets.o 

Parser/firstsets.c

In file included from Include/grammar.h:10,

                 from Parser/firstsets.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/firstsets.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar.o 

Parser/grammar.c

In file included from Include/grammar.h:10,

                 from Parser/grammar.c:10:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Parser/grammar.c: In function `_Py_adddfa':

Parser/grammar.c:45: warning: implicit declaration of 

function `strdup'

Parser/grammar.c:45: warning: assignment makes 

pointer from integer without a cast

Parser/grammar.c: In function `_Py_addlabel':

Parser/grammar.c:105: warning: assignment makes 

pointer from integer without a cast

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgen.o 

Parser/pgen.c

In file included from Include/grammar.h:10,

                 from Parser/pgen.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgen.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/myreadline.o 

Parser/myreadline.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/myreadline.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer.o 

Parser/tokenizer.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/abstract.o 

Objects/abstract.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/abstract.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/boolobject.o 

Objects/boolobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/boolobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/bufferobject.o 

Objects/bufferobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/bufferobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cellobject.o 

Objects/cellobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cellobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/classobject.o 

Objects/classobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/classobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cobject.o 

Objects/cobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/complexobject.o Objects/complexobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/complexobject.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/descrobject.o 

Objects/descrobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/descrobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/enumobject.o 

Objects/enumobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/enumobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/fileobject.o 

Objects/fileobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/fileobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Objects/fileobject.c: In function `file_truncate':

Objects/fileobject.c:618: warning: implicit declaration of 

function `ftruncate'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/floatobject.o 

Objects/floatobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/floatobject.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/frameobject.o 

Objects/frameobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/frameobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/funcobject.o 

Objects/funcobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/funcobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/intobject.o 

Objects/intobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/intobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/iterobject.o 

Objects/iterobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/iterobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/listobject.o 

Objects/listobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/listobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/longobject.o 

Objects/longobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/longobject.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/dictobject.o 

Objects/dictobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/dictobject.c:10:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/methodobject.o Objects/methodobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/methodobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/moduleobject.o 

Objects/moduleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/moduleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/object.o 

Objects/object.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/object.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/obmalloc.o 

Objects/obmalloc.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/obmalloc.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/rangeobject.o 

Objects/rangeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/rangeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/sliceobject.o 

Objects/sliceobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/sliceobject.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/stringobject.o 

Objects/stringobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/stringobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/structseq.o 

Objects/structseq.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/structseq.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/tupleobject.o 

Objects/tupleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/tupleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/typeobject.o 

Objects/typeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/typeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/weakrefobject.o Objects/weakrefobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/weakrefobject.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/unicodeobject.o Objects/unicodeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodeobject.c:39:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/unicodectype.o 

Objects/unicodectype.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodectype.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/bltinmodule.o 

Python/bltinmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/bltinmodule.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/exceptions.o 

Python/exceptions.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/exceptions.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/ceval.o 

Python/ceval.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/ceval.c:9:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mysnprintf.o 

Python/mysnprintf.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mysnprintf.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o 

Parser/tokenizer_pgen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4,

                 from Parser/tokenizer_pgen.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/printgrammar.o 

Parser/printgrammar.c

In file included from Include/grammar.h:10,

                 from Parser/printgrammar.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/printgrammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgenmain.o 

Parser/pgenmain.c

In file included from Include/grammar.h:10,

                 from Parser/pgenmain.c:18:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgenmain.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   

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 Objects/obmalloc.o 

Python/mysnprintf.o Parser/tokenizer_pgen.o 

Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl  -

lpthread -o Parser/pgen

Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Py

thon/graminit.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/compile.o 

Python/compile.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/compile.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/codecs.o 

Python/codecs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/codecs.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/errors.o 

Python/errors.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/errors.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/errors.c: At top level:

Python/errors.c:602: warning: function declaration isn't 

a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozen.o 

Python/frozen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozen.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozenmain.o 

Python/frozenmain.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozenmain.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/future.o 

Python/future.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/future.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getargs.o 

Python/getargs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getargs.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcompiler.o 

Python/getcompiler.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcompiler.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcopyright.o 

Python/getcopyright.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcopyright.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getmtime.o 

Python/getmtime.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getmtime.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPLATFORM='"linux2"' -o 

Python/getplatform.o ./Python/getplatform.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/getplatform.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getversion.o 

Python/getversion.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getversion.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/graminit.o 

Python/graminit.c

In file included from Include/grammar.h:10,

                 from Python/graminit.c:2:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Python/graminit.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/import.o 

Python/import.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/import.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -I. -o 

Python/importdl.o ./Python/importdl.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/importdl.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/marshal.o 

Python/marshal.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/marshal.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/modsupport.o 

Python/modsupport.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/modsupport.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mystrtoul.o 

Python/mystrtoul.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mystrtoul.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pyfpe.o 

Python/pyfpe.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pystate.o 

Python/pystate.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pystate.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pythonrun.o 

Python/pythonrun.c

In file included from Include/grammar.h:10,

                 from Python/pythonrun.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pythonrun.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/pythonrun.c: At top level:

Python/pythonrun.c:81: warning: function declaration 

isn't a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/structmember.o 

Python/structmember.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/structmember.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/symtable.o 

Python/symtable.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/symtable.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/sysmodule.o 

Python/sysmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/sysmodule.c:17:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/sysmodule.c: In function `PySys_SetArgv':

Python/sysmodule.c:1163: warning: implicit declaration 

of function `readlink'

Python/sysmodule.c:1212: warning: implicit declaration 

of function `realpath'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/traceback.o 

Python/traceback.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/traceback.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getopt.o 

Python/getopt.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/dynload_shlib.o 

Python/dynload_shlib.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/dynload_shlib.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/thread.o 

Python/thread.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/thread.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/config.o 

Modules/config.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/config.c:19:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPYTHONPATH='":plat-

linux2:lib-tk"' \

        -DPREFIX='"/usr/local"' \

        -DEXEC_PREFIX='"/usr/local"' \

        -DVERSION='"2.3"' \

        -DVPATH='""' \

        -o Modules/getpath.o ./Modules/getpath.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/getpath.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/getpath.c: In function `calculate_path':

./Modules/getpath.c:454: warning: implicit declaration of 

function `readlink'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/main.o 

Modules/main.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/main.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o 

Modules/gcmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/gcmodule.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/threadmodule.c -o Modules/threadmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/threadmodule.c:5:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/signalmodule.c -o Modules/signalmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/signalmodule.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/signalmodule.c: In function `signal_handler':

./Modules/signalmodule.c:141: warning: implicit 

declaration of function `siginterrupt'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/posixmodule.c -o Modules/posixmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/posixmodule.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/posixmodule.c: In function `posix_fchdir':

./Modules/posixmodule.c:1132: `fchdir' undeclared (first 

use this function)

./Modules/posixmodule.c:1132: (Each undeclared 

identifier is reported only once

./Modules/posixmodule.c:1132: for each function it 

appears in.)

./Modules/posixmodule.c: In function `posix_fsync':

./Modules/posixmodule.c:1181: `fsync' undeclared (first 

use this function)

./Modules/posixmodule.c: In function `posix_fdatasync':

./Modules/posixmodule.c:1199: `fdatasync' undeclared 

(first use this function)

./Modules/posixmodule.c: In function `posix_nice':

./Modules/posixmodule.c:1722: warning: implicit 

declaration of function `nice'

./Modules/posixmodule.c: In function `posix_seteuid':

./Modules/posixmodule.c:4380: warning: implicit 

declaration of function `seteuid'

./Modules/posixmodule.c: In function `posix_setegid':

./Modules/posixmodule.c:4400: warning: implicit 

declaration of function `setegid'

./Modules/posixmodule.c: In function `posix_setreuid':

./Modules/posixmodule.c:4420: warning: implicit 

declaration of function `setreuid'

./Modules/posixmodule.c: In function `posix_setregid':

./Modules/posixmodule.c:4440: warning: implicit 

declaration of function `setregid'

./Modules/posixmodule.c: In function `posix_readlink':

./Modules/posixmodule.c:4632: warning: implicit 

declaration of function `readlink'

./Modules/posixmodule.c: In function `posix_ftruncate':

./Modules/posixmodule.c:5255: warning: implicit 

declaration of function `ftruncate'

./Modules/posixmodule.c: In function `posix_putenv':

./Modules/posixmodule.c:5312: warning: implicit 

declaration of function `putenv'

./Modules/posixmodule.c: In function `posix_unsetenv':

./Modules/posixmodule.c:5351: warning: implicit 

declaration of function `unsetenv'

make: *** [Modules/posixmodule.o] Error 1

azure:~/Python-2.3$ 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-06 16:49

Message:
Logged In: YES 
user_id=21627

Please try the attached patch, and report an update on the

build log. Don't paste the build log into the edit window;

instead, attach it using "Check to Upload and Attach a File:"



Please also investigate



/usr/include/sys/stat.h:172: warning: implicit declaration

of function `__machdep_sys__fxstat'



Can you find __machdep_sys__fxstat anywhere?

----------------------------------------------------------------------

Comment By: Adam Schran (aschran)
Date: 2003-09-05 19:13

Message:
Logged In: YES 
user_id=859405

Loewis - This is what I found in unistd.h, note the __USE_BSD 

definition:



#ifdef  __USE_BSD

/* Change the owner and group of the file that FD is open 

on.  */

extern int __fchown __P ((int __fd,

                          __uid_t __owner, __gid_t __group));

extern int fchown __P ((int __fd,

                        __uid_t __owner, __gid_t __group));

/* Change the process's working directory to the directory

   that FD is open on.  */

extern int __fchdir __P ((int __fd));

extern int fchdir __P ((int __fd));

#endif /* Use BSD.  */





---



The fchdir function appears to be defined, but only if the 

__USE_BSD value is defined.



I grepped through all of thje *.h and *.c files in the Python's 

Modules directory, as well as the top-level Makefile, and 

I could not find any place where that value was set.



I also grepped through /usr/include for other instances of the 

fchdir() function and did not find any.



This is a Linux system, not BSD.  Also, these configure and 

make errors were reproduced on another Linux machine we 

have when we tried installing Python 2.3.



Does this help at all?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-05 07:12

Message:
Logged In: YES 
user_id=21627

We should focus on understanding a single problem at a time.

I propose that we focus on the failure



./Modules/posixmodule.c:1132: `fchdir' undeclared (first

use this function)



Now, this function ought to be declared in

/usr/include/unistd.h. Can you find out whether it is

declared there? If it is, can you find out why the

definition is not visible? If it is not, can you find out

whether it is declared elsewhere?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

From python-bugs at shopip.com  Mon Sep  8 16:14:44 2003
From: python-bugs at shopip.com (Python Bugs)
Date: Sat Sep 13 09:15:02 2003
Subject: [Python-bugs-list] DeprecationWarning line number off-by-one
Message-ID: <200309082014.h88KEiH2010033@shopip.com>

Python bug summary: DeprecationWarning line number is off-by-one when the offending character is within multi-line (triple quoted) string.

To reproduce: Create a source file with:

"""
spam
text with non-ASCII character (\x80 to \xFF)
spam
"""

Then execute to produce:
DeprecationWarning: Non-ASCII character '\xxx' in file x on line 4, but no encoding declared;...

(The character is actually on line 3.)

NOTE: I do not think this warning should even be given for text within quotes.

From noreply at sourceforge.net  Sat Sep  6 10:50:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 09:15:07 2003
Subject: [Python-bugs-list] [ python-Bugs-800710 ] build fails
Message-ID: <E19veO7-00087T-00@sc8-sf-web2.sourceforge.net>

Bugs item #800710, was opened at 2003-09-04 23:27
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Schran (aschran)
>Assigned to: Martin v. L?wis (loewis)
Summary: build fails

Initial Comment:
dear python code samurais,



I ran ./configure and make on python 2.3, and got this 

failure on the make.  researched extensively before 

posting to you guys. =)



This problem only happens when installing Python 2.3.  

Python 2.2 installs flawlessly.



This is on a 2-year-old Linux box running slackware, with 

gcc version 2.7.2. 



I was able to get Python 2.3 to install on a newer 

machine with a different linux distrib with no problem. 



here are the results of the .configure and the make. 

Thanks for any help getting Python going on this 

machine! I'll try any suggestions. Adam



azure:~/Python-2.3$ ./configure

checking MACHDEP... linux2

checking EXTRAPLATDIR... 

checking for --without-gcc... no

checking for --with-cxx=<compiler>... no

checking for c++... c++

checking for C++ compiler default output... a.out

checking whether the C++ compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for gcc... gcc

checking for C compiler default output... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking how to run the C preprocessor... gcc -E

checking for AIX... no

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... no

checking for stdint.h... no

checking for unistd.h... yes

checking minix/config.h usability... no

checking minix/config.h presence... no

checking for minix/config.h... no

checking for --with-suffix... 

checking for case-insensitive build directory... no

checking LIBRARY... libpython$(VERSION).a

checking LINKCC... $(PURIFY) $(CC)

checking for --enable-shared... no

checking LDLIBRARY... libpython$(VERSION).a

checking for ranlib... ranlib

checking for ar... ar

checking for a BSD-compatible install... /usr/bin/ginstall -

c

checking for --with-pydebug... no

checking whether gcc accepts -fno-strict-aliasing... no

checking whether gcc accepts -OPT:Olimit=0... no

checking whether gcc accepts -Olimit 1500... no

checking whether pthreads are available without 

options... no

checking whether gcc accepts -Kpthread... no

checking whether gcc accepts -Kthread... no

checking whether gcc accepts -pthread... no

checking whether c++ also accepts flags for thread 

support... no

checking for ANSI C header files... (cached) yes

checking dlfcn.h usability... yes

checking dlfcn.h presence... yes

checking for dlfcn.h... yes

checking fcntl.h usability... yes

checking fcntl.h presence... yes

checking for fcntl.h... yes

checking grp.h usability... yes

checking grp.h presence... yes

checking for grp.h... yes

checking limits.h usability... yes

checking limits.h presence... yes

checking for limits.h... yes

checking langinfo.h usability... yes

checking langinfo.h presence... yes

checking for langinfo.h... yes

checking libintl.h usability... no

checking libintl.h presence... no

checking for libintl.h... no

checking locale.h usability... yes

checking locale.h presence... yes

checking for locale.h... yes

checking ncurses.h usability... no

checking ncurses.h presence... no

checking for ncurses.h... no

checking poll.h usability... no

checking poll.h presence... no

checking for poll.h... no

checking pthread.h usability... yes

checking pthread.h presence... yes

checking for pthread.h... yes

checking signal.h usability... yes

checking signal.h presence... yes

checking for signal.h... yes

checking stdarg.h usability... yes

checking stdarg.h presence... yes

checking for stdarg.h... yes

checking stddef.h usability... yes

checking stddef.h presence... yes

checking for stddef.h... yes

checking for stdlib.h... (cached) yes

checking stropts.h usability... no

checking stropts.h presence... no

checking for stropts.h... no

checking termios.h usability... yes

checking termios.h presence... yes

checking for termios.h... yes

checking thread.h usability... no

checking thread.h presence... no

checking for thread.h... no

checking for unistd.h... (cached) yes

checking utime.h usability... yes

checking utime.h presence... yes

checking for utime.h... yes

checking sys/audioio.h usability... no

checking sys/audioio.h presence... no

checking for sys/audioio.h... no

checking sys/bsdtty.h usability... no

checking sys/bsdtty.h presence... no

checking for sys/bsdtty.h... no

checking sys/file.h usability... yes

checking sys/file.h presence... yes

checking for sys/file.h... yes

checking sys/lock.h usability... no

checking sys/lock.h presence... no

checking for sys/lock.h... no

checking sys/mkdev.h usability... no

checking sys/mkdev.h presence... no

checking for sys/mkdev.h... no

checking sys/modem.h usability... no

checking sys/modem.h presence... no

checking for sys/modem.h... no

checking sys/param.h usability... yes

checking sys/param.h presence... yes

checking for sys/param.h... yes

checking sys/poll.h usability... no

checking sys/poll.h presence... no

checking for sys/poll.h... no

checking sys/select.h usability... no

checking sys/select.h presence... no

checking for sys/select.h... no

checking sys/socket.h usability... yes

checking sys/socket.h presence... yes

checking for sys/socket.h... yes

checking sys/time.h usability... yes

checking sys/time.h presence... yes

checking for sys/time.h... yes

checking sys/times.h usability... yes

checking sys/times.h presence... yes

checking for sys/times.h... yes

checking sys/un.h usability... no

checking sys/un.h presence... yes

configure: WARNING: sys/un.h: present but cannot be 

compiled

configure: WARNING: sys/un.h: check for missing 

prerequisite headers?

configure: WARNING: sys/un.h: proceeding with the 

preprocessor's result

checking for sys/un.h... yes

checking sys/utsname.h usability... yes

checking sys/utsname.h presence... yes

checking for sys/utsname.h... yes

checking sys/wait.h usability... yes

checking sys/wait.h presence... yes

checking for sys/wait.h... yes

checking pty.h usability... no

checking pty.h presence... no

checking for pty.h... no

checking term.h usability... yes

checking term.h presence... yes

checking for term.h... yes

checking libutil.h usability... no

checking libutil.h presence... no

checking for libutil.h... no

checking sys/resource.h usability... yes

checking sys/resource.h presence... yes

checking for sys/resource.h... yes

checking netpacket/packet.h usability... no

checking netpacket/packet.h presence... no

checking for netpacket/packet.h... no

checking sysexits.h usability... yes

checking sysexits.h presence... yes

checking for sysexits.h... yes

checking for dirent.h that defines DIR... yes

checking for library containing opendir... none required

checking whether sys/types.h defines makedev... no

checking for sys/mkdev.h... (cached) no

checking sys/sysmacros.h usability... yes

checking sys/sysmacros.h presence... yes

checking for sys/sysmacros.h... yes

checking for clock_t in time.h... yes

checking for makedev... no

checking Solaris LFS bug... no

checking for mode_t... yes

checking for off_t... yes

checking for pid_t... yes

checking return type of signal handlers... void

checking for size_t... yes

checking for uid_t in sys/types.h... yes

checking for int... yes

checking size of int... 4

checking for long... yes

checking size of long... 4

checking for void *... yes

checking size of void *... 4

checking for char... yes

checking size of char... 1

checking for short... yes

checking size of short... 2

checking for float... yes

checking size of float... 4

checking for double... yes

checking size of double... 8

checking for fpos_t... yes

checking size of fpos_t... 4

checking for long long support... yes

checking for long long... yes

checking size of long long... 8

checking for uintptr_t support... no

checking size of off_t... 4

checking whether to enable large file support... no

checking size of time_t... 4

checking for pthread_t... yes

checking size of pthread_t... 4

checking for --enable-toolbox-glue... no

checking for --enable-framework... no

checking for dyld... no

checking SO... .so

checking LDSHARED... $(CC) -shared

checking CCSHARED... -fPIC

checking LINKFORSHARED... -Xlinker -export-dynamic

checking CFLAGSFORSHARED... 

checking SHLIBS... $(LIBS)

checking for dlopen in -ldl... yes

checking for shl_load in -ldld... no

checking for library containing sem_init... -lpthread

checking for textdomain in -lintl... no

checking for t_open in -lnsl... no

checking for socket in -lsocket... no

checking for --with-libs... no

checking for --with-signal-module... yes

checking for --with-dec-threads... no

checking for --with-threads... yes

checking for _POSIX_THREADS in unistd.h... no

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 for usconfig in -lmpc... no

checking if PTHREAD_SCOPE_SYSTEM is supported... yes

checking for pthread_sigmask... yes

checking if --enable-ipv6 is specified... no

checking for --with-universal-newlines... yes

checking for --with-doc-strings... yes

checking for --with-pymalloc... yes

checking for --with-wctype-functions... no

checking for --with-sgi-dl... no

checking for --with-dl-dld... no

checking for dlopen... yes

checking DYNLOADFILE... dynload_shlib.o

checking MACHDEP_OBJS... MACHDEP_OBJS

checking for alarm... yes

checking for chown... yes

checking for clock... yes

checking for confstr... yes

checking for ctermid... yes

checking for execv... yes

checking for fchdir... yes

checking for fork... yes

checking for fsync... yes

checking for fdatasync... yes

checking for fpathconf... yes

checking for ftime... yes

checking for ftruncate... yes

checking for gai_strerror... no

checking for getgroups... yes

checking for getlogin... yes

checking for getloadavg... no

checking for getpeername... yes

checking for getpgid... yes

checking for getpid... yes

checking for getpriority... yes

checking for getpwent... yes

checking for getwd... yes

checking for kill... yes

checking for killpg... yes

checking for lchown... no

checking for lstat... yes

checking for mkfifo... yes

checking for mknod... yes

checking for mktime... yes

checking for mremap... yes

checking for nice... yes

checking for pathconf... yes

checking for pause... yes

checking for plock... no

checking for poll... no

checking for pthread_init... no

checking for putenv... yes

checking for readlink... yes

checking for realpath... yes

checking for select... yes

checking for setegid... yes

checking for seteuid... yes

checking for setgid... yes

checking for setlocale... yes

checking for setregid... yes

checking for setreuid... yes

checking for setsid... yes

checking for setpgid... yes

checking for setpgrp... yes

checking for setuid... yes

checking for setvbuf... yes

checking for snprintf... yes

checking for sigaction... yes

checking for siginterrupt... yes

checking for sigrelse... no

checking for strftime... yes

checking for strptime... yes

checking for sysconf... yes

checking for tcgetpgrp... yes

checking for tcsetpgrp... yes

checking for tempnam... yes

checking for timegm... yes

checking for times... yes

checking for tmpfile... yes

checking for tmpnam... yes

checking for tmpnam_r... no

checking for truncate... yes

checking for uname... yes

checking for unsetenv... yes

checking for utimes... yes

checking for waitpid... yes

checking for wcscoll... no

checking for _getpty... no

checking for chroot... no

checking for link... yes

checking for symlink... no

checking for ctermid_r... no

checking for flock... yes

checking for getpagesize... no

checking for true... true

checking for inet_aton in -lc... yes

checking for hstrerror... no

checking for inet_aton... yes

checking for inet_pton... no

checking for setgroups... no

checking for openpty... no

checking for openpty in -lutil... no

checking for forkpty... no

checking for forkpty in -lutil... no

checking for fseek64... no

checking for fseeko... no

checking for fstatvfs... no

checking for ftell64... no

checking for ftello... no

checking for statvfs... no

checking for dup2... yes

checking for getcwd... yes

checking for strdup... yes

checking for strerror... yes

checking for memmove... yes

checking for getpgrp... yes

checking for setpgrp... (cached) yes

checking for gettimeofday... yes

checking for major... yes

checking for getaddrinfo... no

checking for getnameinfo... no

checking whether time.h and sys/time.h may both be 

included... yes

checking whether struct tm is in sys/time.h or time.h... 

time.h

checking for struct tm.tm_zone... no

checking for tzname... yes

checking for struct stat.st_rdev... yes

checking for struct stat.st_blksize... yes

checking for struct stat.st_blocks... yes

checking for time.h that defines altzone... no

checking whether sys/select.h and sys/time.h may both 

be included... no

checking for addrinfo... no

checking for sockaddr_storage... no

checking whether char is unsigned... no

checking for gcc option to accept ANSI C... none needed

checking for an ANSI C-conforming const... yes

checking for working volatile... yes

checking for working signed char... yes

checking for prototypes... yes

checking for variable length prototypes and stdarg.h... 

yes

checking for bad exec* prototypes... no

checking if sockaddr has sa_len member... no

checking whether va_list is an array... no

checking for gethostbyname_r... yes

checking gethostbyname_r with 6 args... no

checking gethostbyname_r with 5 args... yes

checking for __fpu_control... yes

checking for --with-fpectl... no

checking for --with-libm=STRING... default LIBM="-lm"

checking for --with-libc=STRING... default LIBC=""

checking for hypot... yes

checking wchar.h usability... no

checking wchar.h presence... no

checking for wchar.h... no

checking what type to use for unicode... unsigned short

checking whether byte ordering is bigendian... no

checking whether right shift extends the sign bit... yes

checking for getc_unlocked() and friends... yes

checking for rl_pre_input_hook in -lreadline... no

checking for rl_completion_matches in -lreadline... no

checking for broken nice()... yes

checking for working tzset()... yes

checking for tv_nsec in struct stat... no

checking whether mvwdelch is an expression... yes

checking whether WINDOW has _flags... yes

checking for /dev/ptmx... no

checking for /dev/ptc... no

checking for socklen_t... no

checking for build directories... done

configure: creating ./config.status

config.status: creating Makefile.pre

config.status: creating Modules/Setup.config

config.status: creating pyconfig.h

creating Setup

creating Setup.local

creating Makefile

azure:~/Python-2.3$ 





azure:~/Python-2.3$ make

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/python.o 

Modules/python.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/python.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/acceler.o 

Parser/acceler.c

In file included from Include/grammar.h:10,

                 from Parser/acceler.c:14:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/acceler.c:13:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar1.o 

Parser/grammar1.c

In file included from Include/grammar.h:10,

                 from Parser/grammar1.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar1.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/listnode.o 

Parser/listnode.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/listnode.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/node.o 

Parser/node.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/node.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parser.o 

Parser/parser.c

In file included from Include/grammar.h:10,

                 from Parser/parser.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/parser.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parsetok.o 

Parser/parsetok.c

In file included from Include/grammar.h:10,

                 from Parser/parsetok.c:7:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/parsetok.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/bitset.o 

Parser/bitset.c

In file included from Parser/bitset.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/bitset.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/metagrammar.o 

Parser/metagrammar.c

In file included from Include/grammar.h:10,

                 from Parser/metagrammar.c:4:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/metagrammar.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/firstsets.o 

Parser/firstsets.c

In file included from Include/grammar.h:10,

                 from Parser/firstsets.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/firstsets.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar.o 

Parser/grammar.c

In file included from Include/grammar.h:10,

                 from Parser/grammar.c:10:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Parser/grammar.c: In function `_Py_adddfa':

Parser/grammar.c:45: warning: implicit declaration of 

function `strdup'

Parser/grammar.c:45: warning: assignment makes 

pointer from integer without a cast

Parser/grammar.c: In function `_Py_addlabel':

Parser/grammar.c:105: warning: assignment makes 

pointer from integer without a cast

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgen.o 

Parser/pgen.c

In file included from Include/grammar.h:10,

                 from Parser/pgen.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgen.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/myreadline.o 

Parser/myreadline.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/myreadline.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer.o 

Parser/tokenizer.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/abstract.o 

Objects/abstract.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/abstract.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/boolobject.o 

Objects/boolobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/boolobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/bufferobject.o 

Objects/bufferobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/bufferobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cellobject.o 

Objects/cellobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cellobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/classobject.o 

Objects/classobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/classobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cobject.o 

Objects/cobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/complexobject.o Objects/complexobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/complexobject.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/descrobject.o 

Objects/descrobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/descrobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/enumobject.o 

Objects/enumobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/enumobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/fileobject.o 

Objects/fileobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/fileobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Objects/fileobject.c: In function `file_truncate':

Objects/fileobject.c:618: warning: implicit declaration of 

function `ftruncate'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/floatobject.o 

Objects/floatobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/floatobject.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/frameobject.o 

Objects/frameobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/frameobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/funcobject.o 

Objects/funcobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/funcobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/intobject.o 

Objects/intobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/intobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/iterobject.o 

Objects/iterobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/iterobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/listobject.o 

Objects/listobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/listobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/longobject.o 

Objects/longobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/longobject.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/dictobject.o 

Objects/dictobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/dictobject.c:10:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/methodobject.o Objects/methodobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/methodobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/moduleobject.o 

Objects/moduleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/moduleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/object.o 

Objects/object.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/object.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/obmalloc.o 

Objects/obmalloc.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/obmalloc.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/rangeobject.o 

Objects/rangeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/rangeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/sliceobject.o 

Objects/sliceobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/sliceobject.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/stringobject.o 

Objects/stringobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/stringobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/structseq.o 

Objects/structseq.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/structseq.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/tupleobject.o 

Objects/tupleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/tupleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/typeobject.o 

Objects/typeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/typeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/weakrefobject.o Objects/weakrefobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/weakrefobject.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/unicodeobject.o Objects/unicodeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodeobject.c:39:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/unicodectype.o 

Objects/unicodectype.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodectype.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/bltinmodule.o 

Python/bltinmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/bltinmodule.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/exceptions.o 

Python/exceptions.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/exceptions.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/ceval.o 

Python/ceval.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/ceval.c:9:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mysnprintf.o 

Python/mysnprintf.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mysnprintf.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o 

Parser/tokenizer_pgen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4,

                 from Parser/tokenizer_pgen.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/printgrammar.o 

Parser/printgrammar.c

In file included from Include/grammar.h:10,

                 from Parser/printgrammar.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/printgrammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgenmain.o 

Parser/pgenmain.c

In file included from Include/grammar.h:10,

                 from Parser/pgenmain.c:18:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgenmain.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   

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 Objects/obmalloc.o 

Python/mysnprintf.o Parser/tokenizer_pgen.o 

Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl  -

lpthread -o Parser/pgen

Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Py

thon/graminit.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/compile.o 

Python/compile.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/compile.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/codecs.o 

Python/codecs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/codecs.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/errors.o 

Python/errors.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/errors.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/errors.c: At top level:

Python/errors.c:602: warning: function declaration isn't 

a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozen.o 

Python/frozen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozen.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozenmain.o 

Python/frozenmain.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozenmain.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/future.o 

Python/future.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/future.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getargs.o 

Python/getargs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getargs.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcompiler.o 

Python/getcompiler.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcompiler.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcopyright.o 

Python/getcopyright.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcopyright.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getmtime.o 

Python/getmtime.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getmtime.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPLATFORM='"linux2"' -o 

Python/getplatform.o ./Python/getplatform.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/getplatform.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getversion.o 

Python/getversion.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getversion.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/graminit.o 

Python/graminit.c

In file included from Include/grammar.h:10,

                 from Python/graminit.c:2:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Python/graminit.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/import.o 

Python/import.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/import.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -I. -o 

Python/importdl.o ./Python/importdl.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/importdl.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/marshal.o 

Python/marshal.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/marshal.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/modsupport.o 

Python/modsupport.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/modsupport.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mystrtoul.o 

Python/mystrtoul.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mystrtoul.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pyfpe.o 

Python/pyfpe.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pystate.o 

Python/pystate.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pystate.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pythonrun.o 

Python/pythonrun.c

In file included from Include/grammar.h:10,

                 from Python/pythonrun.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pythonrun.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/pythonrun.c: At top level:

Python/pythonrun.c:81: warning: function declaration 

isn't a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/structmember.o 

Python/structmember.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/structmember.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/symtable.o 

Python/symtable.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/symtable.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/sysmodule.o 

Python/sysmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/sysmodule.c:17:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/sysmodule.c: In function `PySys_SetArgv':

Python/sysmodule.c:1163: warning: implicit declaration 

of function `readlink'

Python/sysmodule.c:1212: warning: implicit declaration 

of function `realpath'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/traceback.o 

Python/traceback.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/traceback.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getopt.o 

Python/getopt.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/dynload_shlib.o 

Python/dynload_shlib.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/dynload_shlib.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/thread.o 

Python/thread.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/thread.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/config.o 

Modules/config.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/config.c:19:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPYTHONPATH='":plat-

linux2:lib-tk"' \

        -DPREFIX='"/usr/local"' \

        -DEXEC_PREFIX='"/usr/local"' \

        -DVERSION='"2.3"' \

        -DVPATH='""' \

        -o Modules/getpath.o ./Modules/getpath.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/getpath.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/getpath.c: In function `calculate_path':

./Modules/getpath.c:454: warning: implicit declaration of 

function `readlink'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/main.o 

Modules/main.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/main.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o 

Modules/gcmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/gcmodule.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/threadmodule.c -o Modules/threadmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/threadmodule.c:5:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/signalmodule.c -o Modules/signalmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/signalmodule.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/signalmodule.c: In function `signal_handler':

./Modules/signalmodule.c:141: warning: implicit 

declaration of function `siginterrupt'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/posixmodule.c -o Modules/posixmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/posixmodule.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/posixmodule.c: In function `posix_fchdir':

./Modules/posixmodule.c:1132: `fchdir' undeclared (first 

use this function)

./Modules/posixmodule.c:1132: (Each undeclared 

identifier is reported only once

./Modules/posixmodule.c:1132: for each function it 

appears in.)

./Modules/posixmodule.c: In function `posix_fsync':

./Modules/posixmodule.c:1181: `fsync' undeclared (first 

use this function)

./Modules/posixmodule.c: In function `posix_fdatasync':

./Modules/posixmodule.c:1199: `fdatasync' undeclared 

(first use this function)

./Modules/posixmodule.c: In function `posix_nice':

./Modules/posixmodule.c:1722: warning: implicit 

declaration of function `nice'

./Modules/posixmodule.c: In function `posix_seteuid':

./Modules/posixmodule.c:4380: warning: implicit 

declaration of function `seteuid'

./Modules/posixmodule.c: In function `posix_setegid':

./Modules/posixmodule.c:4400: warning: implicit 

declaration of function `setegid'

./Modules/posixmodule.c: In function `posix_setreuid':

./Modules/posixmodule.c:4420: warning: implicit 

declaration of function `setreuid'

./Modules/posixmodule.c: In function `posix_setregid':

./Modules/posixmodule.c:4440: warning: implicit 

declaration of function `setregid'

./Modules/posixmodule.c: In function `posix_readlink':

./Modules/posixmodule.c:4632: warning: implicit 

declaration of function `readlink'

./Modules/posixmodule.c: In function `posix_ftruncate':

./Modules/posixmodule.c:5255: warning: implicit 

declaration of function `ftruncate'

./Modules/posixmodule.c: In function `posix_putenv':

./Modules/posixmodule.c:5312: warning: implicit 

declaration of function `putenv'

./Modules/posixmodule.c: In function `posix_unsetenv':

./Modules/posixmodule.c:5351: warning: implicit 

declaration of function `unsetenv'

make: *** [Modules/posixmodule.o] Error 1

azure:~/Python-2.3$ 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-06 16:49

Message:
Logged In: YES 
user_id=21627

Please try the attached patch, and report an update on the

build log. Don't paste the build log into the edit window;

instead, attach it using "Check to Upload and Attach a File:"



Please also investigate



/usr/include/sys/stat.h:172: warning: implicit declaration

of function `__machdep_sys__fxstat'



Can you find __machdep_sys__fxstat anywhere?

----------------------------------------------------------------------

Comment By: Adam Schran (aschran)
Date: 2003-09-05 19:13

Message:
Logged In: YES 
user_id=859405

Loewis - This is what I found in unistd.h, note the __USE_BSD 

definition:



#ifdef  __USE_BSD

/* Change the owner and group of the file that FD is open 

on.  */

extern int __fchown __P ((int __fd,

                          __uid_t __owner, __gid_t __group));

extern int fchown __P ((int __fd,

                        __uid_t __owner, __gid_t __group));

/* Change the process's working directory to the directory

   that FD is open on.  */

extern int __fchdir __P ((int __fd));

extern int fchdir __P ((int __fd));

#endif /* Use BSD.  */





---



The fchdir function appears to be defined, but only if the 

__USE_BSD value is defined.



I grepped through all of thje *.h and *.c files in the Python's 

Modules directory, as well as the top-level Makefile, and 

I could not find any place where that value was set.



I also grepped through /usr/include for other instances of the 

fchdir() function and did not find any.



This is a Linux system, not BSD.  Also, these configure and 

make errors were reproduced on another Linux machine we 

have when we tried installing Python 2.3.



Does this help at all?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-05 07:12

Message:
Logged In: YES 
user_id=21627

We should focus on understanding a single problem at a time.

I propose that we focus on the failure



./Modules/posixmodule.c:1132: `fchdir' undeclared (first

use this function)



Now, this function ought to be declared in

/usr/include/unistd.h. Can you find out whether it is

declared there? If it is, can you find out why the

definition is not visible? If it is not, can you find out

whether it is declared elsewhere?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

From noreply at sourceforge.net  Mon Sep  8 17:54:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 09:15:11 2003
Subject: [Python-bugs-list] [ python-Bugs-800710 ] build fails
Message-ID: <E19wTyE-0002ep-00@sc8-sf-web4.sourceforge.net>

Bugs item #800710, was opened at 2003-09-04 21:27
Message generated for change (Comment added) made by aschran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Schran (aschran)
Assigned to: Martin v. L?wis (loewis)
Summary: build fails

Initial Comment:
dear python code samurais,



I ran ./configure and make on python 2.3, and got this 

failure on the make.  researched extensively before 

posting to you guys. =)



This problem only happens when installing Python 2.3.  

Python 2.2 installs flawlessly.



This is on a 2-year-old Linux box running slackware, with 

gcc version 2.7.2. 



I was able to get Python 2.3 to install on a newer 

machine with a different linux distrib with no problem. 



here are the results of the .configure and the make. 

Thanks for any help getting Python going on this 

machine! I'll try any suggestions. Adam



azure:~/Python-2.3$ ./configure

checking MACHDEP... linux2

checking EXTRAPLATDIR... 

checking for --without-gcc... no

checking for --with-cxx=<compiler>... no

checking for c++... c++

checking for C++ compiler default output... a.out

checking whether the C++ compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for gcc... gcc

checking for C compiler default output... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking how to run the C preprocessor... gcc -E

checking for AIX... no

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... no

checking for stdint.h... no

checking for unistd.h... yes

checking minix/config.h usability... no

checking minix/config.h presence... no

checking for minix/config.h... no

checking for --with-suffix... 

checking for case-insensitive build directory... no

checking LIBRARY... libpython$(VERSION).a

checking LINKCC... $(PURIFY) $(CC)

checking for --enable-shared... no

checking LDLIBRARY... libpython$(VERSION).a

checking for ranlib... ranlib

checking for ar... ar

checking for a BSD-compatible install... /usr/bin/ginstall -

c

checking for --with-pydebug... no

checking whether gcc accepts -fno-strict-aliasing... no

checking whether gcc accepts -OPT:Olimit=0... no

checking whether gcc accepts -Olimit 1500... no

checking whether pthreads are available without 

options... no

checking whether gcc accepts -Kpthread... no

checking whether gcc accepts -Kthread... no

checking whether gcc accepts -pthread... no

checking whether c++ also accepts flags for thread 

support... no

checking for ANSI C header files... (cached) yes

checking dlfcn.h usability... yes

checking dlfcn.h presence... yes

checking for dlfcn.h... yes

checking fcntl.h usability... yes

checking fcntl.h presence... yes

checking for fcntl.h... yes

checking grp.h usability... yes

checking grp.h presence... yes

checking for grp.h... yes

checking limits.h usability... yes

checking limits.h presence... yes

checking for limits.h... yes

checking langinfo.h usability... yes

checking langinfo.h presence... yes

checking for langinfo.h... yes

checking libintl.h usability... no

checking libintl.h presence... no

checking for libintl.h... no

checking locale.h usability... yes

checking locale.h presence... yes

checking for locale.h... yes

checking ncurses.h usability... no

checking ncurses.h presence... no

checking for ncurses.h... no

checking poll.h usability... no

checking poll.h presence... no

checking for poll.h... no

checking pthread.h usability... yes

checking pthread.h presence... yes

checking for pthread.h... yes

checking signal.h usability... yes

checking signal.h presence... yes

checking for signal.h... yes

checking stdarg.h usability... yes

checking stdarg.h presence... yes

checking for stdarg.h... yes

checking stddef.h usability... yes

checking stddef.h presence... yes

checking for stddef.h... yes

checking for stdlib.h... (cached) yes

checking stropts.h usability... no

checking stropts.h presence... no

checking for stropts.h... no

checking termios.h usability... yes

checking termios.h presence... yes

checking for termios.h... yes

checking thread.h usability... no

checking thread.h presence... no

checking for thread.h... no

checking for unistd.h... (cached) yes

checking utime.h usability... yes

checking utime.h presence... yes

checking for utime.h... yes

checking sys/audioio.h usability... no

checking sys/audioio.h presence... no

checking for sys/audioio.h... no

checking sys/bsdtty.h usability... no

checking sys/bsdtty.h presence... no

checking for sys/bsdtty.h... no

checking sys/file.h usability... yes

checking sys/file.h presence... yes

checking for sys/file.h... yes

checking sys/lock.h usability... no

checking sys/lock.h presence... no

checking for sys/lock.h... no

checking sys/mkdev.h usability... no

checking sys/mkdev.h presence... no

checking for sys/mkdev.h... no

checking sys/modem.h usability... no

checking sys/modem.h presence... no

checking for sys/modem.h... no

checking sys/param.h usability... yes

checking sys/param.h presence... yes

checking for sys/param.h... yes

checking sys/poll.h usability... no

checking sys/poll.h presence... no

checking for sys/poll.h... no

checking sys/select.h usability... no

checking sys/select.h presence... no

checking for sys/select.h... no

checking sys/socket.h usability... yes

checking sys/socket.h presence... yes

checking for sys/socket.h... yes

checking sys/time.h usability... yes

checking sys/time.h presence... yes

checking for sys/time.h... yes

checking sys/times.h usability... yes

checking sys/times.h presence... yes

checking for sys/times.h... yes

checking sys/un.h usability... no

checking sys/un.h presence... yes

configure: WARNING: sys/un.h: present but cannot be 

compiled

configure: WARNING: sys/un.h: check for missing 

prerequisite headers?

configure: WARNING: sys/un.h: proceeding with the 

preprocessor's result

checking for sys/un.h... yes

checking sys/utsname.h usability... yes

checking sys/utsname.h presence... yes

checking for sys/utsname.h... yes

checking sys/wait.h usability... yes

checking sys/wait.h presence... yes

checking for sys/wait.h... yes

checking pty.h usability... no

checking pty.h presence... no

checking for pty.h... no

checking term.h usability... yes

checking term.h presence... yes

checking for term.h... yes

checking libutil.h usability... no

checking libutil.h presence... no

checking for libutil.h... no

checking sys/resource.h usability... yes

checking sys/resource.h presence... yes

checking for sys/resource.h... yes

checking netpacket/packet.h usability... no

checking netpacket/packet.h presence... no

checking for netpacket/packet.h... no

checking sysexits.h usability... yes

checking sysexits.h presence... yes

checking for sysexits.h... yes

checking for dirent.h that defines DIR... yes

checking for library containing opendir... none required

checking whether sys/types.h defines makedev... no

checking for sys/mkdev.h... (cached) no

checking sys/sysmacros.h usability... yes

checking sys/sysmacros.h presence... yes

checking for sys/sysmacros.h... yes

checking for clock_t in time.h... yes

checking for makedev... no

checking Solaris LFS bug... no

checking for mode_t... yes

checking for off_t... yes

checking for pid_t... yes

checking return type of signal handlers... void

checking for size_t... yes

checking for uid_t in sys/types.h... yes

checking for int... yes

checking size of int... 4

checking for long... yes

checking size of long... 4

checking for void *... yes

checking size of void *... 4

checking for char... yes

checking size of char... 1

checking for short... yes

checking size of short... 2

checking for float... yes

checking size of float... 4

checking for double... yes

checking size of double... 8

checking for fpos_t... yes

checking size of fpos_t... 4

checking for long long support... yes

checking for long long... yes

checking size of long long... 8

checking for uintptr_t support... no

checking size of off_t... 4

checking whether to enable large file support... no

checking size of time_t... 4

checking for pthread_t... yes

checking size of pthread_t... 4

checking for --enable-toolbox-glue... no

checking for --enable-framework... no

checking for dyld... no

checking SO... .so

checking LDSHARED... $(CC) -shared

checking CCSHARED... -fPIC

checking LINKFORSHARED... -Xlinker -export-dynamic

checking CFLAGSFORSHARED... 

checking SHLIBS... $(LIBS)

checking for dlopen in -ldl... yes

checking for shl_load in -ldld... no

checking for library containing sem_init... -lpthread

checking for textdomain in -lintl... no

checking for t_open in -lnsl... no

checking for socket in -lsocket... no

checking for --with-libs... no

checking for --with-signal-module... yes

checking for --with-dec-threads... no

checking for --with-threads... yes

checking for _POSIX_THREADS in unistd.h... no

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 for usconfig in -lmpc... no

checking if PTHREAD_SCOPE_SYSTEM is supported... yes

checking for pthread_sigmask... yes

checking if --enable-ipv6 is specified... no

checking for --with-universal-newlines... yes

checking for --with-doc-strings... yes

checking for --with-pymalloc... yes

checking for --with-wctype-functions... no

checking for --with-sgi-dl... no

checking for --with-dl-dld... no

checking for dlopen... yes

checking DYNLOADFILE... dynload_shlib.o

checking MACHDEP_OBJS... MACHDEP_OBJS

checking for alarm... yes

checking for chown... yes

checking for clock... yes

checking for confstr... yes

checking for ctermid... yes

checking for execv... yes

checking for fchdir... yes

checking for fork... yes

checking for fsync... yes

checking for fdatasync... yes

checking for fpathconf... yes

checking for ftime... yes

checking for ftruncate... yes

checking for gai_strerror... no

checking for getgroups... yes

checking for getlogin... yes

checking for getloadavg... no

checking for getpeername... yes

checking for getpgid... yes

checking for getpid... yes

checking for getpriority... yes

checking for getpwent... yes

checking for getwd... yes

checking for kill... yes

checking for killpg... yes

checking for lchown... no

checking for lstat... yes

checking for mkfifo... yes

checking for mknod... yes

checking for mktime... yes

checking for mremap... yes

checking for nice... yes

checking for pathconf... yes

checking for pause... yes

checking for plock... no

checking for poll... no

checking for pthread_init... no

checking for putenv... yes

checking for readlink... yes

checking for realpath... yes

checking for select... yes

checking for setegid... yes

checking for seteuid... yes

checking for setgid... yes

checking for setlocale... yes

checking for setregid... yes

checking for setreuid... yes

checking for setsid... yes

checking for setpgid... yes

checking for setpgrp... yes

checking for setuid... yes

checking for setvbuf... yes

checking for snprintf... yes

checking for sigaction... yes

checking for siginterrupt... yes

checking for sigrelse... no

checking for strftime... yes

checking for strptime... yes

checking for sysconf... yes

checking for tcgetpgrp... yes

checking for tcsetpgrp... yes

checking for tempnam... yes

checking for timegm... yes

checking for times... yes

checking for tmpfile... yes

checking for tmpnam... yes

checking for tmpnam_r... no

checking for truncate... yes

checking for uname... yes

checking for unsetenv... yes

checking for utimes... yes

checking for waitpid... yes

checking for wcscoll... no

checking for _getpty... no

checking for chroot... no

checking for link... yes

checking for symlink... no

checking for ctermid_r... no

checking for flock... yes

checking for getpagesize... no

checking for true... true

checking for inet_aton in -lc... yes

checking for hstrerror... no

checking for inet_aton... yes

checking for inet_pton... no

checking for setgroups... no

checking for openpty... no

checking for openpty in -lutil... no

checking for forkpty... no

checking for forkpty in -lutil... no

checking for fseek64... no

checking for fseeko... no

checking for fstatvfs... no

checking for ftell64... no

checking for ftello... no

checking for statvfs... no

checking for dup2... yes

checking for getcwd... yes

checking for strdup... yes

checking for strerror... yes

checking for memmove... yes

checking for getpgrp... yes

checking for setpgrp... (cached) yes

checking for gettimeofday... yes

checking for major... yes

checking for getaddrinfo... no

checking for getnameinfo... no

checking whether time.h and sys/time.h may both be 

included... yes

checking whether struct tm is in sys/time.h or time.h... 

time.h

checking for struct tm.tm_zone... no

checking for tzname... yes

checking for struct stat.st_rdev... yes

checking for struct stat.st_blksize... yes

checking for struct stat.st_blocks... yes

checking for time.h that defines altzone... no

checking whether sys/select.h and sys/time.h may both 

be included... no

checking for addrinfo... no

checking for sockaddr_storage... no

checking whether char is unsigned... no

checking for gcc option to accept ANSI C... none needed

checking for an ANSI C-conforming const... yes

checking for working volatile... yes

checking for working signed char... yes

checking for prototypes... yes

checking for variable length prototypes and stdarg.h... 

yes

checking for bad exec* prototypes... no

checking if sockaddr has sa_len member... no

checking whether va_list is an array... no

checking for gethostbyname_r... yes

checking gethostbyname_r with 6 args... no

checking gethostbyname_r with 5 args... yes

checking for __fpu_control... yes

checking for --with-fpectl... no

checking for --with-libm=STRING... default LIBM="-lm"

checking for --with-libc=STRING... default LIBC=""

checking for hypot... yes

checking wchar.h usability... no

checking wchar.h presence... no

checking for wchar.h... no

checking what type to use for unicode... unsigned short

checking whether byte ordering is bigendian... no

checking whether right shift extends the sign bit... yes

checking for getc_unlocked() and friends... yes

checking for rl_pre_input_hook in -lreadline... no

checking for rl_completion_matches in -lreadline... no

checking for broken nice()... yes

checking for working tzset()... yes

checking for tv_nsec in struct stat... no

checking whether mvwdelch is an expression... yes

checking whether WINDOW has _flags... yes

checking for /dev/ptmx... no

checking for /dev/ptc... no

checking for socklen_t... no

checking for build directories... done

configure: creating ./config.status

config.status: creating Makefile.pre

config.status: creating Modules/Setup.config

config.status: creating pyconfig.h

creating Setup

creating Setup.local

creating Makefile

azure:~/Python-2.3$ 





azure:~/Python-2.3$ make

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/python.o 

Modules/python.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/python.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/acceler.o 

Parser/acceler.c

In file included from Include/grammar.h:10,

                 from Parser/acceler.c:14:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/acceler.c:13:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar1.o 

Parser/grammar1.c

In file included from Include/grammar.h:10,

                 from Parser/grammar1.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar1.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/listnode.o 

Parser/listnode.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/listnode.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/node.o 

Parser/node.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/node.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parser.o 

Parser/parser.c

In file included from Include/grammar.h:10,

                 from Parser/parser.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/parser.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parsetok.o 

Parser/parsetok.c

In file included from Include/grammar.h:10,

                 from Parser/parsetok.c:7:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/parsetok.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/bitset.o 

Parser/bitset.c

In file included from Parser/bitset.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/bitset.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/metagrammar.o 

Parser/metagrammar.c

In file included from Include/grammar.h:10,

                 from Parser/metagrammar.c:4:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/metagrammar.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/firstsets.o 

Parser/firstsets.c

In file included from Include/grammar.h:10,

                 from Parser/firstsets.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/firstsets.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar.o 

Parser/grammar.c

In file included from Include/grammar.h:10,

                 from Parser/grammar.c:10:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Parser/grammar.c: In function `_Py_adddfa':

Parser/grammar.c:45: warning: implicit declaration of 

function `strdup'

Parser/grammar.c:45: warning: assignment makes 

pointer from integer without a cast

Parser/grammar.c: In function `_Py_addlabel':

Parser/grammar.c:105: warning: assignment makes 

pointer from integer without a cast

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgen.o 

Parser/pgen.c

In file included from Include/grammar.h:10,

                 from Parser/pgen.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgen.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/myreadline.o 

Parser/myreadline.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/myreadline.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer.o 

Parser/tokenizer.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/abstract.o 

Objects/abstract.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/abstract.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/boolobject.o 

Objects/boolobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/boolobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/bufferobject.o 

Objects/bufferobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/bufferobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cellobject.o 

Objects/cellobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cellobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/classobject.o 

Objects/classobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/classobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cobject.o 

Objects/cobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/complexobject.o Objects/complexobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/complexobject.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/descrobject.o 

Objects/descrobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/descrobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/enumobject.o 

Objects/enumobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/enumobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/fileobject.o 

Objects/fileobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/fileobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Objects/fileobject.c: In function `file_truncate':

Objects/fileobject.c:618: warning: implicit declaration of 

function `ftruncate'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/floatobject.o 

Objects/floatobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/floatobject.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/frameobject.o 

Objects/frameobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/frameobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/funcobject.o 

Objects/funcobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/funcobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/intobject.o 

Objects/intobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/intobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/iterobject.o 

Objects/iterobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/iterobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/listobject.o 

Objects/listobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/listobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/longobject.o 

Objects/longobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/longobject.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/dictobject.o 

Objects/dictobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/dictobject.c:10:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/methodobject.o Objects/methodobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/methodobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/moduleobject.o 

Objects/moduleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/moduleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/object.o 

Objects/object.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/object.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/obmalloc.o 

Objects/obmalloc.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/obmalloc.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/rangeobject.o 

Objects/rangeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/rangeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/sliceobject.o 

Objects/sliceobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/sliceobject.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/stringobject.o 

Objects/stringobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/stringobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/structseq.o 

Objects/structseq.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/structseq.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/tupleobject.o 

Objects/tupleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/tupleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/typeobject.o 

Objects/typeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/typeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/weakrefobject.o Objects/weakrefobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/weakrefobject.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/unicodeobject.o Objects/unicodeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodeobject.c:39:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/unicodectype.o 

Objects/unicodectype.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodectype.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/bltinmodule.o 

Python/bltinmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/bltinmodule.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/exceptions.o 

Python/exceptions.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/exceptions.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/ceval.o 

Python/ceval.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/ceval.c:9:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mysnprintf.o 

Python/mysnprintf.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mysnprintf.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o 

Parser/tokenizer_pgen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4,

                 from Parser/tokenizer_pgen.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/printgrammar.o 

Parser/printgrammar.c

In file included from Include/grammar.h:10,

                 from Parser/printgrammar.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/printgrammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgenmain.o 

Parser/pgenmain.c

In file included from Include/grammar.h:10,

                 from Parser/pgenmain.c:18:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgenmain.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   

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 Objects/obmalloc.o 

Python/mysnprintf.o Parser/tokenizer_pgen.o 

Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl  -

lpthread -o Parser/pgen

Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Py

thon/graminit.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/compile.o 

Python/compile.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/compile.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/codecs.o 

Python/codecs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/codecs.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/errors.o 

Python/errors.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/errors.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/errors.c: At top level:

Python/errors.c:602: warning: function declaration isn't 

a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozen.o 

Python/frozen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozen.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozenmain.o 

Python/frozenmain.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozenmain.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/future.o 

Python/future.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/future.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getargs.o 

Python/getargs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getargs.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcompiler.o 

Python/getcompiler.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcompiler.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcopyright.o 

Python/getcopyright.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcopyright.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getmtime.o 

Python/getmtime.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getmtime.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPLATFORM='"linux2"' -o 

Python/getplatform.o ./Python/getplatform.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/getplatform.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getversion.o 

Python/getversion.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getversion.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/graminit.o 

Python/graminit.c

In file included from Include/grammar.h:10,

                 from Python/graminit.c:2:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Python/graminit.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/import.o 

Python/import.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/import.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -I. -o 

Python/importdl.o ./Python/importdl.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/importdl.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/marshal.o 

Python/marshal.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/marshal.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/modsupport.o 

Python/modsupport.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/modsupport.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mystrtoul.o 

Python/mystrtoul.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mystrtoul.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pyfpe.o 

Python/pyfpe.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pystate.o 

Python/pystate.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pystate.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pythonrun.o 

Python/pythonrun.c

In file included from Include/grammar.h:10,

                 from Python/pythonrun.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pythonrun.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/pythonrun.c: At top level:

Python/pythonrun.c:81: warning: function declaration 

isn't a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/structmember.o 

Python/structmember.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/structmember.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/symtable.o 

Python/symtable.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/symtable.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/sysmodule.o 

Python/sysmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/sysmodule.c:17:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/sysmodule.c: In function `PySys_SetArgv':

Python/sysmodule.c:1163: warning: implicit declaration 

of function `readlink'

Python/sysmodule.c:1212: warning: implicit declaration 

of function `realpath'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/traceback.o 

Python/traceback.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/traceback.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getopt.o 

Python/getopt.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/dynload_shlib.o 

Python/dynload_shlib.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/dynload_shlib.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/thread.o 

Python/thread.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/thread.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/config.o 

Modules/config.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/config.c:19:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPYTHONPATH='":plat-

linux2:lib-tk"' \

        -DPREFIX='"/usr/local"' \

        -DEXEC_PREFIX='"/usr/local"' \

        -DVERSION='"2.3"' \

        -DVPATH='""' \

        -o Modules/getpath.o ./Modules/getpath.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/getpath.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/getpath.c: In function `calculate_path':

./Modules/getpath.c:454: warning: implicit declaration of 

function `readlink'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/main.o 

Modules/main.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/main.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o 

Modules/gcmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/gcmodule.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/threadmodule.c -o Modules/threadmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/threadmodule.c:5:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/signalmodule.c -o Modules/signalmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/signalmodule.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/signalmodule.c: In function `signal_handler':

./Modules/signalmodule.c:141: warning: implicit 

declaration of function `siginterrupt'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/posixmodule.c -o Modules/posixmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/posixmodule.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/posixmodule.c: In function `posix_fchdir':

./Modules/posixmodule.c:1132: `fchdir' undeclared (first 

use this function)

./Modules/posixmodule.c:1132: (Each undeclared 

identifier is reported only once

./Modules/posixmodule.c:1132: for each function it 

appears in.)

./Modules/posixmodule.c: In function `posix_fsync':

./Modules/posixmodule.c:1181: `fsync' undeclared (first 

use this function)

./Modules/posixmodule.c: In function `posix_fdatasync':

./Modules/posixmodule.c:1199: `fdatasync' undeclared 

(first use this function)

./Modules/posixmodule.c: In function `posix_nice':

./Modules/posixmodule.c:1722: warning: implicit 

declaration of function `nice'

./Modules/posixmodule.c: In function `posix_seteuid':

./Modules/posixmodule.c:4380: warning: implicit 

declaration of function `seteuid'

./Modules/posixmodule.c: In function `posix_setegid':

./Modules/posixmodule.c:4400: warning: implicit 

declaration of function `setegid'

./Modules/posixmodule.c: In function `posix_setreuid':

./Modules/posixmodule.c:4420: warning: implicit 

declaration of function `setreuid'

./Modules/posixmodule.c: In function `posix_setregid':

./Modules/posixmodule.c:4440: warning: implicit 

declaration of function `setregid'

./Modules/posixmodule.c: In function `posix_readlink':

./Modules/posixmodule.c:4632: warning: implicit 

declaration of function `readlink'

./Modules/posixmodule.c: In function `posix_ftruncate':

./Modules/posixmodule.c:5255: warning: implicit 

declaration of function `ftruncate'

./Modules/posixmodule.c: In function `posix_putenv':

./Modules/posixmodule.c:5312: warning: implicit 

declaration of function `putenv'

./Modules/posixmodule.c: In function `posix_unsetenv':

./Modules/posixmodule.c:5351: warning: implicit 

declaration of function `unsetenv'

make: *** [Modules/posixmodule.o] Error 1

azure:~/Python-2.3$ 

----------------------------------------------------------------------

>Comment By: Adam Schran (aschran)
Date: 2003-09-08 21:54

Message:
Logged In: YES 
user_id=859405

Thank you for the patch, we applied it, and the compile was 

successful.  We then ran "make test", and we noticed some 

failed tests which may or may not be relevant to the current 

issue.  We've attached the output of both "make" and "make 

test".



Regarding the mysterious __machdep_sys_fxstat fuction, I 

recursively grepped through /usr/include/ and only found two 

instances of the function.  Both were calls to the function in 

stat.h, which I have pasted before:



---cut---

#ifdef _POSIX_THREADS



static __inline__ int __machdep_sys_fstat(int __fd, struct 

stat * __statbuf)

{

  return __machdep_sys__fxstat(LINUX_STAT_VERSION, __fd, 

__statbuf);

}



#ifdef _MIT_POSIX_THREADS



static __inline__ int machdep_sys_fstat(int __fd, struct stat 

* __statbuf)

{

  return __machdep_sys__fxstat(LINUX_STAT_VERSION, __fd, 

__statbuf);

}



#endif



#endif

---cut---



Also, if it is important, we did not get any of these warnings 

when we compiled Python 2.2.1 some time ago.





----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-06 14:49

Message:
Logged In: YES 
user_id=21627

Please try the attached patch, and report an update on the

build log. Don't paste the build log into the edit window;

instead, attach it using "Check to Upload and Attach a File:"



Please also investigate



/usr/include/sys/stat.h:172: warning: implicit declaration

of function `__machdep_sys__fxstat'



Can you find __machdep_sys__fxstat anywhere?

----------------------------------------------------------------------

Comment By: Adam Schran (aschran)
Date: 2003-09-05 17:13

Message:
Logged In: YES 
user_id=859405

Loewis - This is what I found in unistd.h, note the __USE_BSD 

definition:



#ifdef  __USE_BSD

/* Change the owner and group of the file that FD is open 

on.  */

extern int __fchown __P ((int __fd,

                          __uid_t __owner, __gid_t __group));

extern int fchown __P ((int __fd,

                        __uid_t __owner, __gid_t __group));

/* Change the process's working directory to the directory

   that FD is open on.  */

extern int __fchdir __P ((int __fd));

extern int fchdir __P ((int __fd));

#endif /* Use BSD.  */





---



The fchdir function appears to be defined, but only if the 

__USE_BSD value is defined.



I grepped through all of thje *.h and *.c files in the Python's 

Modules directory, as well as the top-level Makefile, and 

I could not find any place where that value was set.



I also grepped through /usr/include for other instances of the 

fchdir() function and did not find any.



This is a Linux system, not BSD.  Also, these configure and 

make errors were reproduced on another Linux machine we 

have when we tried installing Python 2.3.



Does this help at all?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-05 05:12

Message:
Logged In: YES 
user_id=21627

We should focus on understanding a single problem at a time.

I propose that we focus on the failure



./Modules/posixmodule.c:1132: `fchdir' undeclared (first

use this function)



Now, this function ought to be declared in

/usr/include/unistd.h. Can you find out whether it is

declared there? If it is, can you find out why the

definition is not visible? If it is not, can you find out

whether it is declared elsewhere?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

From noreply at sourceforge.net  Sat Sep 13 16:00:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 16:00:21 2003
Subject: [Python-bugs-list] [ python-Bugs-805728 ] IDLE can't save UTF-8
	files on Windows
Message-ID: <E19yGZ8-0003nH-00@sc8-sf-web1.sourceforge.net>

Bugs item #805728, was opened at 2003-09-13 22: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=805728&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastian Wangnick (wangnick)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE can't save UTF-8 files on Windows

Initial Comment:
When trying to save a UTF-8-encoded Python source 

code file containing non-ASCII characters, the new IDLE 

of Python 2.3 (final) fails on Windows:



>>> Exception in Tkinter callback

Traceback (most recent call last):

  File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 1345, in 

__call__

    return self.func(*args)

  File "C:\PYTHON23\lib\idlelib\IOBinding.py", line 347, in 

save_as

    if self.writefile(filename):

  File "C:\PYTHON23\lib\idlelib\IOBinding.py", line 370, in 

writefile

    chars = chars.replace("\n", self.eol_convention)

UnicodeDecodeError: 'ascii' codec can't decode byte 

0xc3 in position 241: ordinal not in range(128)





The following patch fixes the problem:



*** iobinding.py	Sun Jun 15 17:12:54 2003

--- iobinding.py.new	Thu Sep 11 05:59:54 2003

***************

*** 365,373 ****

  

      def writefile(self, filename):

          self.fixlastline()

!         chars = self.encode(self.text.get("1.0", "end-1c"))

          if self.eol_convention != "\n":

              chars = chars.replace("\n", 

self.eol_convention)

          try:

              f = open(filename, "wb")

              f.write(chars)

--- 365,374 ----

  

      def writefile(self, filename):

          self.fixlastline()

!         chars = self.text.get("1.0", "end-1c")

          if self.eol_convention != "\n":

              chars = chars.replace("\n", 

self.eol_convention)

+         chars = self.encode(chars)

          try:

              f = open(filename, "wb")

              f.write(chars)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805728&group_id=5470

From noreply at sourceforge.net  Sat Sep 13 18:40:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 18:40:17 2003
Subject: [Python-bugs-list] [ python-Bugs-805788 ] Minor Python Intro update
Message-ID: <E19yJ3v-0007fd-00@sc8-sf-web3.sourceforge.net>

Bugs item #805788, was opened at 2003-09-13 18: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=805788&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor Python Intro update

Initial Comment:
The little source code on the following web page 

demonstrates outdated patterns:



http://python.org/doc/Introduction.html



def invert(table):

    index = {}                # empty dictionary

    for key in table.keys():

        value = table[key]

        if not index.has_key(value):

            index[value] = [] # empty list

        index[value].append(key)

    return index



Perhaps the following would be cleaner:



def invert(table):

    index = {}                # empty dictionary

    for key in table: #"for key, value in table.iteritems():"?

        value = table[key]

        if value not in index:

            index[value] = [] # empty list

        index[value].append(key)

    return index





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805788&group_id=5470

From noreply at sourceforge.net  Sat Sep 13 19:19:54 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 19:19:57 2003
Subject: [Python-bugs-list] [ python-Bugs-805304 ] super instances don't
	support item assignment
Message-ID: <E19yJgI-0000Px-00@sc8-sf-web3.sourceforge.net>

Bugs item #805304, was opened at 2003-09-12 15:10
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: super instances don't support item assignment

Initial Comment:
This snippet produces a TypeError in Python 2.2.3, 2.3,

and CVS:



class C(object):

    def __setitem__(self, name, value):

        print (name, value)



class D(C):

    def __setitem__(self, name, value):

        super(D, self)[name] = value



d = D()

d['foo'] = 'bar'



Here's the traceback:



Traceback (most recent call last):

  File "/home/fdrake/tmp/setitem.py", line 10, in ?

    d['foo'] = 'bar'

  File "/home/fdrake/tmp/setitem.py", line 7, in

__setitem__

    super(D, self)[name] = value

TypeError: object does not support item assignment



The problem appears to be that the item assignment

isn't getting mapped to the __setitem__ of the base

class, so this is probably somewhere deep in

Objects/typeobject.c.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 18:19

Message:
Logged In: YES 
user_id=80475

Okay, let's apply the two-step problem solving approach.  

First, declare the problem impossible to solve.  Then, propose 

a solution ;-)



The attached patch is a proof-of-concept.  It teaches 

PyObject_SetItem to use an attribute lookup for super 

objects whenever a direct table lookup fails.



If the approach is approved, the final version of the patch 

should also address PyObject_GetItem and other ways that 

the attribute lookup mechanism can be bypassed. Also, the 

test for super can be improved by adding PySuper_Check() 

to the typeobject.c API.



Of course, there is also the question as to whether fixing this 

is a bug or a feature.  It does enable a whole set of programs 

to run under Py2.3.1 and Py2.2.4 that would not run under 

Py2.3.0 and Py2.2.3.



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 01:50

Message:
Logged In: YES 
user_id=80475

This one is tough.  



All of super's magic happens with descriptors upon attribute 

lookup.  The example above will work fine if the call were 

written as:  "super(D, self).__setitem__(name)".



However, when written as "super(D, self)[name]", ceval.c 

triggers a STORE_SUBSCR opcode which calls 

PyObject_SetItem which in turns looks directly at the super 

object's type table (and finding nothing).  Nowhere in this 

process is an attribute lookup called or a descriptor invoked.



The current implementation waits until attribute binding time 

to search the bases.  Hence, at the time the super object is 

created, it doesn't know enough information to fill out its 

table about which methods will be available.  Consequently, 

direct table probes will fail.



To make a general purpose fix would be a mess and involves 

changing the semantics of super to do its base search at the 

time the super object is created and to fillout its table with 

the appropriate methods.  Unfortunately, any dynamic 

changes to the methods in the base object would *not* get 

reflected at lookup.



There may be a reasonable special purpose fix.  Fill-out the 

entire superobject table with custom methods that trigger an 

attribute lookup.  For instance, fillout the sq_ass_item slot 

with a function that calls self.__setitem__ which will trigger 

the attribute search.  Even this approach has problems 

because the super object has no way of knowing in advance 

whether sq_ass_item or mp_ass_subscript is the appropriate 

method for the object being referred to (is it a mapping or a 

sequence?).



I recommend punting on this one and documenting that 

direct syntax manipulation of super objects is not defined 

and the super().__special_method__ format be used instead.

Perhaps, all of super's unfilled slots can be filled with a 

placeholder method that emits an explanatory error message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470

From noreply at sourceforge.net  Sat Sep 13 22:42:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 13 22:42:50 2003
Subject: [Python-bugs-list] [ python-Feature Requests-805255 ]
	remove/discard method for dict objects.
Message-ID: <E19yMqb-0007ap-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #805255, was opened at 2003-09-12 14:08
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=805255&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: remove/discard method for dict objects.

Initial Comment:
dict objects already provide a method for getting from

the dictionary (possibly returning a default value) so

as to avoid raising KeyError.  But there's no way to

remove an item that may or may not be in a dictionary

from a dictionary without risking raising KeyError.



I think there should be a method to remove a key if it

is in the dictionary, but to do nothing if it isn't. 

I'd suggest calling it .remove, but the sets.Set type

offers this functionality as .discard, so perhaps

that's a better name.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 21:42

Message:
Logged In: YES 
user_id=80475

That functionality is already provided by dict.pop() in Py2.3:



>>> d = {}

>>> d.pop('a', 1)

1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=805255&group_id=5470

From noreply at sourceforge.net  Sun Sep 14 08:03:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 14 08:03:23 2003
Subject: [Python-bugs-list] [ python-Bugs-804115 ] bad argument
	handling(unittest.py)
Message-ID: <E19yVb2-0005rx-00@sc8-sf-web3.sourceforge.net>

Bugs item #804115, was opened at 2003-09-11 03:19
Message generated for change (Comment added) made by purcell
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Raymond Hettinger (rhettinger)
Summary: bad argument handling(unittest.py)

Initial Comment:
_WritelnDecorator.writeln method handles arbitrary 

number of argumetns badly.



In the following part,



    def writeln(self, *args):

        if args: self.write(*args)



since _WritelnDecorator's stream is by default 

sys.stderr,

sys.stderr.write() takes exactly one argument.



If you give more than one argument to writeln 

method,

TypeError is raised.

----------------------------------------------------------------------

>Comment By: Steve Purcell (purcell)
Date: 2003-09-14 14:03

Message:
Logged In: YES 
user_id=21477

I don't exactly understand why this was considered to be an issue, since 
writeln() is in the _WritelnDecorator class, which is only ever used by 
TextTestRunner. Anyway, the fix is just fine. Thanks for taking care of it. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 04:59

Message:
Logged In: YES 
user_id=80475

Fixed.

See Lib/unittest.py 1.25 and 1.24.6.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

From noreply at sourceforge.net  Sun Sep 14 10:17:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 14 10:17:32 2003
Subject: [Python-bugs-list] [ python-Bugs-802417 ] Bogus use of
	Tkinter.PhotoImage can give sig11
Message-ID: <E19yXgs-0004UA-00@sc8-sf-web1.sourceforge.net>

Bugs item #802417, was opened at 2003-09-08 07:10
Message generated for change (Settings changed) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802417&group_id=5470

Category: Tkinter
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bogus use of Tkinter.PhotoImage can give sig11

Initial Comment:
Running the following script can cause a signal11 (the

script is invalid, but presumably should result only in

a traceback, not a sig11):

from Tkinter import *

t = Tk()

i = PhotoImage(t)

print "here"



The signal 11 happens before the print statement is

reached.



My system is RedHat9, tcl/tk 8.3.5, Python 2.2.2 (also

observed on 2.3b1)



This may be a tk bug (thus unfixable in

Python/Tkinter), because the following sequence kills wish:

% image create photo . 

Illegal instruction



The traceback looks like this:

(gdb) run tkinter-image-bug.py 

Starting program: /usr/local/bin/python

tkinter-image-bug.py

[New Thread 1074993152 (LWP 30584)]



Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 1074993152 (LWP 30584)]

0x082b4518 in ?? ()

(gdb) where

#0  0x082b4518 in ?? ()

#1  0x405cc169 in Tk_DeleteImage () from

/usr/lib/libtk8.3.so

#2  0x405cb77d in Tk_ImageObjCmd () from

/usr/lib/libtk8.3.so

#3  0x4065e517 in TclExpandTokenArray () from

/usr/lib/libtcl8.3.so

#4  0x4065e638 in Tcl_EvalObjv () from

/usr/lib/libtcl8.3.so

#5  0x4047016c in Tkapp_Call (_self=0x81e7528,

args=0x81d634c) at

/usr/src/Python-2.3b1/Modules/_tkinter.c:1292

#6  0x080f4bcc in PyCFunction_Call (func=0x81e674c,

arg=0x81d634c, kw=0x82afb20) at Objects/methodobject.c:108

#7  0x080a5ea5 in call_function (pp_stack=0xbfffeaec,

oparg=137053208) at Python/ceval.c:3416

#8  0x080a4494 in eval_frame (f=0x819b4bc) at

Python/ceval.c:2093

#9  0x080a4f0c in PyEval_EvalCodeEx (co=0x826b120,

globals=0x82b4418, locals=0x0, args=0x81cfd28,

argcount=5, kws=0x82c6780, kwcount=0, defs=0x8272b50,

defcount=3, closure=0x0) at Python/ceval.c:2640

#10 0x080f4821 in function_call (func=0x827f064,

arg=0x81cfd1c, kw=0x827edfc) at Objects/funcobject.c:501

#11 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81cfd1c, kw=0x827edfc) at Objects/abstract.c:1755

#12 0x08062c7c in instancemethod_call (func=0x827f064,

arg=0x81cfd1c, kw=0x827edfc) at Objects/classobject.c:2432

#13 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81cfd1c, kw=0x827edfc) at Objects/abstract.c:1755

#14 0x080a6301 in ext_do_call (func=0x81d643c,

pp_stack=0xbfffeeec, flags=0, na=5, nk=0) at

Python/ceval.c:3690

#15 0x080a4883 in eval_frame (f=0x81a6d3c) at

Python/ceval.c:2128

#16 0x080a4f0c in PyEval_EvalCodeEx (co=0x826b4a0,

globals=0x81cfd1c, locals=0x0, args=0x81a6e88,

argcount=2, kws=0x0, kwcount=0, defs=0x8272b78,

defcount=3, closure=0x0) at Python/ceval.c:2640

#17 0x080f4821 in function_call (func=0x827f25c,

arg=0x81f158c, kw=0x0) at Objects/funcobject.c:501

#18 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81f158c, kw=0x0) at Objects/abstract.c:1755

#19 0x08062c7c in instancemethod_call (func=0x827f25c,

arg=0x81f158c, kw=0x0) at Objects/classobject.c:2432

#20 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81d2e0c, kw=0x0) at Objects/abstract.c:1755

#21 0x080a5c3f in PyEval_CallObjectWithKeywords

(func=0x81d1fcc, arg=0x81d2e0c, kw=0x0) at

Python/ceval.c:3323

#22 0x0805da9d in PyInstance_New (klass=0x82745fc,

arg=0x81d2e0c, kw=0x0) at Objects/classobject.c:575

#23 0x0805cca8 in PyObject_Call (func=0xa30a5208,

arg=0x81d2e0c, kw=0x0) at Objects/abstract.c:1755

#24 0x080a606b in do_call (func=0x82745fc,

pp_stack=0xbffff37c, na=1, nk=136130060) at

Python/ceval.c:3621

#25 0x080a5d27 in call_function (pp_stack=0xbffff37c,

oparg=136130060) at Python/ceval.c:3437

#26 0x080a4494 in eval_frame (f=0x820c164) at

Python/ceval.c:2093

#27 0x080a4f0c in PyEval_EvalCodeEx (co=0x81c7f20,

globals=0x81d2e0c, locals=0x815079c, args=0x0,

argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,

closure=0x0) at Python/ceval.c:2640

#28 0x080a742e in PyEval_EvalCode (co=0x81c7f20,

globals=0x815079c, locals=0x815079c) at Python/ceval.c:537

#29 0x080cc185 in run_node (n=0x8138410,

filename=0xbffffb7d "tkinter-image-bug.py",

globals=0x815079c, locals=0x815079c, flags=0xbffff4d8)

at Python/pythonrun.c:1173

#30 0x080cba41 in PyRun_SimpleFileExFlags

(fp=0x8136f48, filename=0xbffffb7d

"tkinter-image-bug.py", closeit=1, flags=0xbffff4d8) at

Python/pythonrun.c:770

#31 0x0805599c in Py_Main (argc=0, argv=0xbffff554) at

Modules/main.c:417

#32 0x0805554e in main (argc=2, argv=0xbffff554) at

Modules/python.c:26

#33 0x420156a4 in __libc_start_main () from

/lib/tls/libc.so.6



----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2003-09-08 13:12

Message:
Logged In: YES 
user_id=72656

This bug is already corrected in Tk 8.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802417&group_id=5470

From noreply at sourceforge.net  Sun Sep 14 14:33:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 14 14:33:16 2003
Subject: [Python-bugs-list] [ python-Bugs-804115 ] bad argument
	handling(unittest.py)
Message-ID: <E19ybgN-0003wN-00@sc8-sf-web3.sourceforge.net>

Bugs item #804115, was opened at 2003-09-10 20:19
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Raymond Hettinger (rhettinger)
Summary: bad argument handling(unittest.py)

Initial Comment:
_WritelnDecorator.writeln method handles arbitrary 

number of argumetns badly.



In the following part,



    def writeln(self, *args):

        if args: self.write(*args)



since _WritelnDecorator's stream is by default 

sys.stderr,

sys.stderr.write() takes exactly one argument.



If you give more than one argument to writeln 

method,

TypeError is raised.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-14 13:33

Message:
Logged In: YES 
user_id=80475

Steve, if it is okay with you, I would like to add an __all__ 

declaration and amend the docs to include a reference to how 

to include doctests as unittests (Jim Fulton's doctest 

extensions).



__all__ = 

['TestResult', 'TestCase', 'TestSuite', 'TextTestRunner',

           'TestLoader', 'FunctionTestCase',

           'main', 'defaultTestLoader']



# Expose obsolete functions for backwards compatability

__all__.extend

(['getTestCaseNames', 'makeSuite', 'findTestCases'])

----------------------------------------------------------------------

Comment By: Steve Purcell (purcell)
Date: 2003-09-14 07:03

Message:
Logged In: YES 
user_id=21477

I don't exactly understand why this was considered to be an issue, since 
writeln() is in the _WritelnDecorator class, which is only ever used by 
TextTestRunner. Anyway, the fix is just fine. Thanks for taking care of it. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-12 21:59

Message:
Logged In: YES 
user_id=80475

Fixed.

See Lib/unittest.py 1.25 and 1.24.6.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

From noreply at sourceforge.net  Sun Sep 14 15:41:12 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 14 15:41:15 2003
Subject: [Python-bugs-list] [ python-Bugs-806149 ] aetools.TalkTo methods
	can be obscured
Message-ID: <E19yckC-0000gR-00@sc8-sf-web1.sourceforge.net>

Bugs item #806149, was opened at 2003-09-14 21: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=806149&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: aetools.TalkTo methods can be obscured

Initial Comment:
There are still a number of methods in aetools.TalkTo that 

are essential, but can be shadowed by verbs in the OSA 

terminologies. One example is the "send" method, which 

gets overriden if you try to create a suite for Mail.app.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=806149&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 07:03:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 07:03:32 2003
Subject: [Python-bugs-list] [ python-Bugs-804115 ] bad argument
	handling(unittest.py)
Message-ID: <E19yr8g-0002W8-00@sc8-sf-web1.sourceforge.net>

Bugs item #804115, was opened at 2003-09-11 03:19
Message generated for change (Comment added) made by purcell
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Raymond Hettinger (rhettinger)
Summary: bad argument handling(unittest.py)

Initial Comment:
_WritelnDecorator.writeln method handles arbitrary 

number of argumetns badly.



In the following part,



    def writeln(self, *args):

        if args: self.write(*args)



since _WritelnDecorator's stream is by default 

sys.stderr,

sys.stderr.write() takes exactly one argument.



If you give more than one argument to writeln 

method,

TypeError is raised.

----------------------------------------------------------------------

>Comment By: Steve Purcell (purcell)
Date: 2003-09-15 13:03

Message:
Logged In: YES 
user_id=21477

Raymond: I've checked in the __all__ changes as you suggested. 
 
I'd be delighted if you would amend the docs to cover the doctest 
extensions. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-14 20:33

Message:
Logged In: YES 
user_id=80475

Steve, if it is okay with you, I would like to add an __all__ 

declaration and amend the docs to include a reference to how 

to include doctests as unittests (Jim Fulton's doctest 

extensions).



__all__ = 

['TestResult', 'TestCase', 'TestSuite', 'TextTestRunner',

           'TestLoader', 'FunctionTestCase',

           'main', 'defaultTestLoader']



# Expose obsolete functions for backwards compatability

__all__.extend

(['getTestCaseNames', 'makeSuite', 'findTestCases'])

----------------------------------------------------------------------

Comment By: Steve Purcell (purcell)
Date: 2003-09-14 14:03

Message:
Logged In: YES 
user_id=21477

I don't exactly understand why this was considered to be an issue, since 
writeln() is in the _WritelnDecorator class, which is only ever used by 
TextTestRunner. Anyway, the fix is just fine. Thanks for taking care of it. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 04:59

Message:
Logged In: YES 
user_id=80475

Fixed.

See Lib/unittest.py 1.25 and 1.24.6.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804115&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 13:42:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 13:42:21 2003
Subject: [Python-bugs-list] [ python-Bugs-801349 ] New slice behaviour. Bug
	or feature?
Message-ID: <E19yxMV-00075j-00@sc8-sf-web4.sourceforge.net>

Bugs item #801349, was opened at 2003-09-05 21:28
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=801349&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Michael Hudson (mwh)
Summary: New slice behaviour.  Bug or feature?

Initial Comment:
Using a slice of x[:None] returns the whole list.  I would 

thing that if this sort of statement is valid, it should 

return an empty list, like x[:0].  In 2.2, you'll get an 

error with this statement.



This bit me when I was using None as a sentinel.



I'll be able to write a patch when I find out what the 

desired behaviour is (fine as-is, None should behave as 

0, it should throw an error, or other) assuming sf's cvs is 

playing nice.





Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.



C:\Documents and Settings\grant>c:\python23\python

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

[1, 2, 3, 4]

>>> ^Z





C:\Documents and Settings\grant>c:\python22\python

'import site' failed; use -v for traceback

Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit 

(Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

TypeError: sequence index must be integer

>>> ^Z





C:\Documents and Settings\grant>

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-09-15 18:42

Message:
Logged In: YES 
user_id=6656

I think passing a slice index of None should be equivalent to not 

passing any value at all.  Can you come up with a doc patch?

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-09-06 22:53

Message:
Logged In: YES 
user_id=699438

Actually I now think this is behaving properly since slice uses 

None as sentinels.  'a[slice(None,None)]' is equivilent to a[:].  

Although 'a[None:None]' isn't a backward-compatible 

statement, it doesn't cause any forward compatibility issues 

with pre-2.3 code.  And changing the definition of 'None' on 

slice attributes would cause some serious breakage on third-

party packages.



However, if this is defined behaviour, I'll need to write some 

documentation patches.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-06 02:31

Message:
Logged In: YES 
user_id=33168

Michael, do you think happened with your extended slice changes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=801349&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 14:01:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 14:01:20 2003
Subject: [Python-bugs-list] [ python-Bugs-805728 ] IDLE can't save UTF-8
	files on Windows
Message-ID: <E19yxez-00085a-00@sc8-sf-web4.sourceforge.net>

Bugs item #805728, was opened at 2003-09-13 15:00
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805728&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastian Wangnick (wangnick)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE can't save UTF-8 files on Windows

Initial Comment:
When trying to save a UTF-8-encoded Python source 

code file containing non-ASCII characters, the new IDLE 

of Python 2.3 (final) fails on Windows:



>>> Exception in Tkinter callback

Traceback (most recent call last):

  File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 1345, in 

__call__

    return self.func(*args)

  File "C:\PYTHON23\lib\idlelib\IOBinding.py", line 347, in 

save_as

    if self.writefile(filename):

  File "C:\PYTHON23\lib\idlelib\IOBinding.py", line 370, in 

writefile

    chars = chars.replace("\n", self.eol_convention)

UnicodeDecodeError: 'ascii' codec can't decode byte 

0xc3 in position 241: ordinal not in range(128)





The following patch fixes the problem:



*** iobinding.py	Sun Jun 15 17:12:54 2003

--- iobinding.py.new	Thu Sep 11 05:59:54 2003

***************

*** 365,373 ****

  

      def writefile(self, filename):

          self.fixlastline()

!         chars = self.encode(self.text.get("1.0", "end-1c"))

          if self.eol_convention != "\n":

              chars = chars.replace("\n", 

self.eol_convention)

          try:

              f = open(filename, "wb")

              f.write(chars)

--- 365,374 ----

  

      def writefile(self, filename):

          self.fixlastline()

!         chars = self.text.get("1.0", "end-1c")

          if self.eol_convention != "\n":

              chars = chars.replace("\n", 

self.eol_convention)

+         chars = self.encode(chars)

          try:

              f = open(filename, "wb")

              f.write(chars)



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-15 13:01

Message:
Logged In: YES 
user_id=80475

I believe Kurt already fixed this one for Py2.3.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805728&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 14:03:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 14:04:01 2003
Subject: [Python-bugs-list] [ python-Bugs-804113 ] Crypto terminology for
	crypto hash function
Message-ID: <E19yxhI-0008Bf-00@sc8-sf-web4.sourceforge.net>

Bugs item #804113, was opened at 2003-09-10 20:07
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804113&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Crypto terminology for crypto hash function

Initial Comment:
On web page:



http://www.python.org/dev/doc/devel////lib/module-

sha.html



the documentation should be improved to make it clear 

that the hash function implemented here is really what 

is known as "SHA-1" and not just "SHA".  NIST originally 

proposed a "SHA" hash function.  NSA found a problem 

with SHA, and proposed a small fix to it; the revised 

hash function is typically called "SHA-1".   The version 

implemented is indeed "SHA-1" and not "SHA" (I tested 

it).   The documentation should make this clear, and 

might also include "SHA1" somewhere as a synonym so 

searches will find this common spelling variant too.  

Renaming the module as "sha1" would also be nice...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804113&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 14:25:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 14:25:56 2003
Subject: [Python-bugs-list] [ python-Bugs-804113 ] Crypto terminology for
	crypto hash function
Message-ID: <E19yy2p-0004lv-00@sc8-sf-web3.sourceforge.net>

Bugs item #804113, was opened at 2003-09-10 20:07
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804113&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Crypto terminology for crypto hash function

Initial Comment:
On web page:



http://www.python.org/dev/doc/devel////lib/module-

sha.html



the documentation should be improved to make it clear 

that the hash function implemented here is really what 

is known as "SHA-1" and not just "SHA".  NIST originally 

proposed a "SHA" hash function.  NSA found a problem 

with SHA, and proposed a small fix to it; the revised 

hash function is typically called "SHA-1".   The version 

implemented is indeed "SHA-1" and not "SHA" (I tested 

it).   The documentation should make this clear, and 

might also include "SHA1" somewhere as a synonym so 

searches will find this common spelling variant too.  

Renaming the module as "sha1" would also be nice...



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-15 13:25

Message:
Logged In: YES 
user_id=80475

Fixed the docs.



Renaming the module would be a bigger step that causes 

difficulty for people upgrading to the next Python version, 

challenges for people distributing code expected to work 

under multiple versions, and would outdate existing Python 

publications.  Passing on that step because it gets too little 

benefit for the cost.



See Doc/lib/libsha.tex  1.10.26.1 and 1.11.



Thanks for the report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=804113&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 14:30:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 14:30:26 2003
Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open()
	only in 2.3?
Message-ID: <E19yy78-00053a-00@sc8-sf-web3.sourceforge.net>

Bugs item #789402, was opened at 2003-08-15 13:23
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: David Lambert (jdalambert)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Memory leak on open() only in 2.3?

Initial Comment:




If  for instance /tmp is a directory, then the follwing

code fragment produces a large memory leak on Python

2.3 compiled on Linux 2.4.20. This does not appear to

be a problem with previous versions of the interpreter.





#!/usr/local/bin/python





while 1:

    try:

        open('/tmp')

    except:

        pass



It appears that the exception IOError: [Error 21] Is a

directory leave garbage. If the parameter to open()

does not exist, the problem does not occur.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-15 13:30

Message:
Logged In: YES 
user_id=80475

Did this fix get backported yet?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 18:10

Message:
Logged In: YES 
user_id=357491

Maybe?  =)



I just did a quick check and PyErr_SetObject (in Python/errors.c) 

calls PyErr_Restore in the same file that uses the 'value' argument 

to set the current PyThreadState's curexc_value which holds a 

PyObject.



But there are so many places where PyThreadState is used I don't 

feel up to hunting down where it might cause an issue.  Perhaps 

with more knowledge of the exception framework can answer the 

question.

----------------------------------------------------------------------

Comment By: David Lambert (jdalambert)
Date: 2003-08-19 15:17

Message:
Logged In: YES 
user_id=845425

Good point, but if PyObject_CallFunction fails, is

PyErr_SetObject safe with a NULL second parameter? 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-19 14:12

Message:
Logged In: YES 
user_id=33168

Your fix is the same as what I checked in, except that I

used Py_XDECREF instead of Py_DECREF, since

PyObject_CallFunction could fail and return NULL.  This

still needs a test and backport to 2.3.1.

----------------------------------------------------------------------

Comment By: David Lambert (jdalambert)
Date: 2003-08-19 08:52

Message:
Logged In: YES 
user_id=845425

Over the weekend and through Monday I ran my system 24/7

with the previously attached code. There do not seem to be

any problems, but I am waiting for your "blessing" before

considering it a fix.



----------------------------------------------------------------------

Comment By: David Lambert (jdalambert)
Date: 2003-08-16 18:09

Message:
Logged In: YES 
user_id=845425

I think I may have a fix. Check out the attached file. It

seems to work for me.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-15 15:07

Message:
Logged In: YES 
user_id=33168

Wow, it sure does leak!



Checked in as:  Objects/fileobject.c 2.180



Still needs a test.  Leaving open until I get around to it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 14:26:53 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 14:30:59 2003
Subject: [Python-bugs-list] [ python-Bugs-797844 ] csv.DictWriter --
	inconsistent doc & code
Message-ID: <E19yy3p-0004qh-00@sc8-sf-web3.sourceforge.net>

Bugs item #797844, was opened at 2003-08-30 12:39
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=797844&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 6
Submitted By: Florent Rougon (frougon)
Assigned to: Skip Montanaro (montanaro)
Summary: csv.DictWriter -- inconsistent doc & code

Initial Comment:
csv.DictWriter has similar problems as csv.DictReader

as described in bug #792558.



The signature of csv.DictWriter.__init__ is:



    def __init__(self, f, fieldnames, restval="",

extrasaction="raise",

                 dialect="excel", *args):



but the docs says:



class DictWriter(csvfile, fieldnames[, restval=""[,

extrasaction='raise'[, dialect='excel'[, fmtparam]]]])



Problems:



1. f != csvfile

2. The constructor does not accept **arguments, which

is a problem to pass along the (one or several)

fmtparam mentioned in the doc.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-02 09:49

Message:
Logged In: YES 
user_id=44345

I'm probably the right person for the DictWriter class.  I've been

off the net or basically swamped much of the time lately what

with the stupid virus crap and a house move.  I'll try to get to

it this week sometime.



S



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-30 15:51

Message:
Logged In: YES 
user_id=33168

Andrew are you the right person to look at this and 797853?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=797844&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 14:34:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 14:34:45 2003
Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open()
	only in 2.3?
Message-ID: <E19yyBM-00013R-00@sc8-sf-web4.sourceforge.net>

Bugs item #789402, was opened at 2003-08-15 14:23
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: David Lambert (jdalambert)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Memory leak on open() only in 2.3?

Initial Comment:




If  for instance /tmp is a directory, then the follwing

code fragment produces a large memory leak on Python

2.3 compiled on Linux 2.4.20. This does not appear to

be a problem with previous versions of the interpreter.





#!/usr/local/bin/python





while 1:

    try:

        open('/tmp')

    except:

        pass



It appears that the exception IOError: [Error 21] Is a

directory leave garbage. If the parameter to open()

does not exist, the problem does not occur.



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-15 14:34

Message:
Logged In: YES 
user_id=33168

No, I haven't had time to setup 2.3 branch in my cvs, test,

and check in.  Feel free to take it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-15 14:30

Message:
Logged In: YES 
user_id=80475

Did this fix get backported yet?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-09-06 19:10

Message:
Logged In: YES 
user_id=357491

Maybe?  =)



I just did a quick check and PyErr_SetObject (in Python/errors.c) 

calls PyErr_Restore in the same file that uses the 'value' argument 

to set the current PyThreadState's curexc_value which holds a 

PyObject.



But there are so many places where PyThreadState is used I don't 

feel up to hunting down where it might cause an issue.  Perhaps 

with more knowledge of the exception framework can answer the 

question.

----------------------------------------------------------------------

Comment By: David Lambert (jdalambert)
Date: 2003-08-19 16:17

Message:
Logged In: YES 
user_id=845425

Good point, but if PyObject_CallFunction fails, is

PyErr_SetObject safe with a NULL second parameter? 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-19 15:12

Message:
Logged In: YES 
user_id=33168

Your fix is the same as what I checked in, except that I

used Py_XDECREF instead of Py_DECREF, since

PyObject_CallFunction could fail and return NULL.  This

still needs a test and backport to 2.3.1.

----------------------------------------------------------------------

Comment By: David Lambert (jdalambert)
Date: 2003-08-19 09:52

Message:
Logged In: YES 
user_id=845425

Over the weekend and through Monday I ran my system 24/7

with the previously attached code. There do not seem to be

any problems, but I am waiting for your "blessing" before

considering it a fix.



----------------------------------------------------------------------

Comment By: David Lambert (jdalambert)
Date: 2003-08-16 19:09

Message:
Logged In: YES 
user_id=845425

I think I may have a fix. Check out the attached file. It

seems to work for me.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-15 16:07

Message:
Logged In: YES 
user_id=33168

Wow, it sure does leak!



Checked in as:  Objects/fileobject.c 2.180



Still needs a test.  Leaving open until I get around to it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 14:49:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 14:52:55 2003
Subject: [Python-bugs-list] [ python-Bugs-797844 ] csv.DictWriter --
	inconsistent doc & code
Message-ID: <E19yyPr-0007uY-00@sc8-sf-web2.sourceforge.net>

Bugs item #797844, was opened at 2003-08-30 12:39
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=797844&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Florent Rougon (frougon)
Assigned to: Skip Montanaro (montanaro)
Summary: csv.DictWriter -- inconsistent doc & code

Initial Comment:
csv.DictWriter has similar problems as csv.DictReader

as described in bug #792558.



The signature of csv.DictWriter.__init__ is:



    def __init__(self, f, fieldnames, restval="",

extrasaction="raise",

                 dialect="excel", *args):



but the docs says:



class DictWriter(csvfile, fieldnames[, restval=""[,

extrasaction='raise'[, dialect='excel'[, fmtparam]]]])



Problems:



1. f != csvfile

2. The constructor does not accept **arguments, which

is a problem to pass along the (one or several)

fmtparam mentioned in the doc.



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-15 13:49

Message:
Logged In: YES 
user_id=44345

My apologies.  I actually fixed this in CVS last week but

forgot to close the bug report.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-02 09:49

Message:
Logged In: YES 
user_id=44345

I'm probably the right person for the DictWriter class.  I've been

off the net or basically swamped much of the time lately what

with the stupid virus crap and a house move.  I'll try to get to

it this week sometime.



S



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-30 15:51

Message:
Logged In: YES 
user_id=33168

Andrew are you the right person to look at this and 797853?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=797844&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 19:30:22 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 19:30:31 2003
Subject: [Python-bugs-list] [ python-Bugs-801349 ] New slice behaviour. Bug
	or feature?
Message-ID: <E19z2nW-0000Lq-00@sc8-sf-web1.sourceforge.net>

Bugs item #801349, was opened at 2003-09-05 15:28
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=801349&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Michael Hudson (mwh)
Summary: New slice behaviour.  Bug or feature?

Initial Comment:
Using a slice of x[:None] returns the whole list.  I would 

thing that if this sort of statement is valid, it should 

return an empty list, like x[:0].  In 2.2, you'll get an 

error with this statement.



This bit me when I was using None as a sentinel.



I'll be able to write a patch when I find out what the 

desired behaviour is (fine as-is, None should behave as 

0, it should throw an error, or other) assuming sf's cvs is 

playing nice.





Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.



C:\Documents and Settings\grant>c:\python23\python

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

[1, 2, 3, 4]

>>> ^Z





C:\Documents and Settings\grant>c:\python22\python

'import site' failed; use -v for traceback

Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit 

(Intel)] on win32

Type "help", "copyright", "credits" or "license" for more 

information.

>>> a = [1,2,3,4]

>>> a[:None]

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

TypeError: sequence index must be integer

>>> ^Z





C:\Documents and Settings\grant>

----------------------------------------------------------------------

>Comment By: logistix (logistix)
Date: 2003-09-15 18:30

Message:
Logged In: YES 
user_id=699438

I've attached two patches.  One patches the library 

reference docs.  The other patches the interpreter error you 

get if you try 'a[1.2,5.4]'.  I couldn't find any description of 

slice behaviour in the Langauge Reference, but I always have 

trouble finding things there.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-15 12:42

Message:
Logged In: YES 
user_id=6656

I think passing a slice index of None should be equivalent to not 

passing any value at all.  Can you come up with a doc patch?

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-09-06 16:53

Message:
Logged In: YES 
user_id=699438

Actually I now think this is behaving properly since slice uses 

None as sentinels.  'a[slice(None,None)]' is equivilent to a[:].  

Although 'a[None:None]' isn't a backward-compatible 

statement, it doesn't cause any forward compatibility issues 

with pre-2.3 code.  And changing the definition of 'None' on 

slice attributes would cause some serious breakage on third-

party packages.



However, if this is defined behaviour, I'll need to write some 

documentation patches.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-05 20:31

Message:
Logged In: YES 
user_id=33168

Michael, do you think happened with your extended slice changes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=801349&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 21:01:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 21:01:40 2003
Subject: [Python-bugs-list] [ python-Bugs-798876 ] windows sys.path contains
	nonexistant directory
Message-ID: <E19z4Dm-0007RV-00@sc8-sf-web2.sourceforge.net>

Bugs item #798876, was opened at 2003-09-01 20:31
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798876&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 4
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows sys.path contains nonexistant directory

Initial Comment:
Starting in python 2.3, sys.path on Windows contains 

the nonexistant directory "c:\python23\lib\plat-win".



I don't know if this is really a bug, since we can no 

longer assume that an entry in sys.path exists or is a 

physical directory.  Still, it seems like each entry in 

sys.path should be able to resolve to SOMETHING.



I would've flagged this low priority if I had the capability.

----------------------------------------------------------------------

>Comment By: logistix (logistix)
Date: 2003-09-15 20:01

Message:
Logged In: YES 
user_id=699438

There's a wierd bug on line 255 of getpathp.c.  The malloc 

fails when trying to allocate 42 bytes, which is the length 

of "\Software\Python\PythonCore\X.X\PythonPath" and it 

causes the function to abort.



Just on a hunch, I bumped the malloc size up to 44 since 

that's an even number of dwords, and the malloc magically 

succeeded.



Also, Since I'm running XP, shouldn't the 

sizeof "\Software\Python\PythonCore\X.X\PythonPath" be 84?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-01 20:40

Message:
Logged In: YES 
user_id=31435

Strange.  I see it under Python 2.1.3 too.  So it's not a new 

thing, but somehow 2.2.3 managed to get rid of it temporarily 

<wink>.  Boosting the priority to 4, since it's at least a 

mystery!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798876&group_id=5470

From noreply at sourceforge.net  Mon Sep 15 22:01:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 15 22:01:56 2003
Subject: [Python-bugs-list] [ python-Bugs-798876 ] windows sys.path contains
	nonexistant directory
Message-ID: <E19z5A7-0007iM-00@sc8-sf-web3.sourceforge.net>

Bugs item #798876, was opened at 2003-09-01 20:31
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798876&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 4
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows sys.path contains nonexistant directory

Initial Comment:
Starting in python 2.3, sys.path on Windows contains 

the nonexistant directory "c:\python23\lib\plat-win".



I don't know if this is really a bug, since we can no 

longer assume that an entry in sys.path exists or is a 

physical directory.  Still, it seems like each entry in 

sys.path should be able to resolve to SOMETHING.



I would've flagged this low priority if I had the capability.

----------------------------------------------------------------------

>Comment By: logistix (logistix)
Date: 2003-09-15 21:01

Message:
Logged In: YES 
user_id=699438

Disregard last comment.  I ran a clean and the problem 

disappeared.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-09-15 20:01

Message:
Logged In: YES 
user_id=699438

There's a wierd bug on line 255 of getpathp.c.  The malloc 

fails when trying to allocate 42 bytes, which is the length 

of "\Software\Python\PythonCore\X.X\PythonPath" and it 

causes the function to abort.



Just on a hunch, I bumped the malloc size up to 44 since 

that's an even number of dwords, and the malloc magically 

succeeded.



Also, Since I'm running XP, shouldn't the 

sizeof "\Software\Python\PythonCore\X.X\PythonPath" be 84?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-01 20:40

Message:
Logged In: YES 
user_id=31435

Strange.  I see it under Python 2.1.3 too.  So it's not a new 

thing, but somehow 2.2.3 managed to get rid of it temporarily 

<wink>.  Boosting the priority to 4, since it's at least a 

mystery!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798876&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 00:48:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 00:48:55 2003
Subject: [Python-bugs-list] [ python-Bugs-805304 ] super instances don't
	support item assignment
Message-ID: <E19z7lb-0008Dj-00@sc8-sf-web4.sourceforge.net>

Bugs item #805304, was opened at 2003-09-12 15:10
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: super instances don't support item assignment

Initial Comment:
This snippet produces a TypeError in Python 2.2.3, 2.3,

and CVS:



class C(object):

    def __setitem__(self, name, value):

        print (name, value)



class D(C):

    def __setitem__(self, name, value):

        super(D, self)[name] = value



d = D()

d['foo'] = 'bar'



Here's the traceback:



Traceback (most recent call last):

  File "/home/fdrake/tmp/setitem.py", line 10, in ?

    d['foo'] = 'bar'

  File "/home/fdrake/tmp/setitem.py", line 7, in

__setitem__

    super(D, self)[name] = value

TypeError: object does not support item assignment



The problem appears to be that the item assignment

isn't getting mapped to the __setitem__ of the base

class, so this is probably somewhere deep in

Objects/typeobject.c.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-15 23:48

Message:
Logged In: YES 
user_id=80475

Referring to Guido for pronouncement.



I've been thinking that this one could be left alone and just 

document that super objects only do their magic upon 

explicit attribute lookup.



Otherwise, fixing it completely involves combing Python for 

every place that directly calls functions from the slots table, 

and then adding a followup call using attribute lookup if the 

slot is empty.



When it comes to functions like repr(obj), I think we want 

the super object to identify itself rather than forwarding the 

call to the target object's __repr__() method.



The downside of leaving it alone is that it breaks the 

symmetry between obj[k] and obj.__getitem__[k].





----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 18:19

Message:
Logged In: YES 
user_id=80475

Okay, let's apply the two-step problem solving approach.  

First, declare the problem impossible to solve.  Then, propose 

a solution ;-)



The attached patch is a proof-of-concept.  It teaches 

PyObject_SetItem to use an attribute lookup for super 

objects whenever a direct table lookup fails.



If the approach is approved, the final version of the patch 

should also address PyObject_GetItem and other ways that 

the attribute lookup mechanism can be bypassed. Also, the 

test for super can be improved by adding PySuper_Check() 

to the typeobject.c API.



Of course, there is also the question as to whether fixing this 

is a bug or a feature.  It does enable a whole set of programs 

to run under Py2.3.1 and Py2.2.4 that would not run under 

Py2.3.0 and Py2.2.3.



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 01:50

Message:
Logged In: YES 
user_id=80475

This one is tough.  



All of super's magic happens with descriptors upon attribute 

lookup.  The example above will work fine if the call were 

written as:  "super(D, self).__setitem__(name)".



However, when written as "super(D, self)[name]", ceval.c 

triggers a STORE_SUBSCR opcode which calls 

PyObject_SetItem which in turns looks directly at the super 

object's type table (and finding nothing).  Nowhere in this 

process is an attribute lookup called or a descriptor invoked.



The current implementation waits until attribute binding time 

to search the bases.  Hence, at the time the super object is 

created, it doesn't know enough information to fill out its 

table about which methods will be available.  Consequently, 

direct table probes will fail.



To make a general purpose fix would be a mess and involves 

changing the semantics of super to do its base search at the 

time the super object is created and to fillout its table with 

the appropriate methods.  Unfortunately, any dynamic 

changes to the methods in the base object would *not* get 

reflected at lookup.



There may be a reasonable special purpose fix.  Fill-out the 

entire superobject table with custom methods that trigger an 

attribute lookup.  For instance, fillout the sq_ass_item slot 

with a function that calls self.__setitem__ which will trigger 

the attribute search.  Even this approach has problems 

because the super object has no way of knowing in advance 

whether sq_ass_item or mp_ass_subscript is the appropriate 

method for the object being referred to (is it a mapping or a 

sequence?).



I recommend punting on this one and documenting that 

direct syntax manipulation of super objects is not defined 

and the super().__special_method__ format be used instead.

Perhaps, all of super's unfilled slots can be filled with a 

placeholder method that emits an explanatory error message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 09:11:17 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 09:11:22 2003
Subject: [Python-bugs-list] [ python-Bugs-807107 ] "TypeError: iteration
	over non-sequence" for list of strings
Message-ID: <E19zFbx-000781-00@sc8-sf-web1.sourceforge.net>

Bugs item #807107, was opened at 2003-09-16 13: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=807107&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geir M. Koien (gmkoien)
Assigned to: Nobody/Anonymous (nobody)
Summary: "TypeError: iteration over non-sequence" for list of strings

Initial Comment:
The following code gives me the "TypeError: iteration 

over non-sequence" error.



I don't see why this shouldn't work.



Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "copyright", "credits" or "license()" for more 

information.



list = ["I am a boy", "You are a girl"]

for i in len(list):

	line = list[i]



	

Traceback (most recent call last):

  File "<pyshell#39>", line 1, in ?

    for i in len(list):

TypeError: iteration over non-sequence



***

If I take the steps manually it works....



>>> len(list)

2

>>> list[0]

'I am a boy'

>>> list[1]

'You are a girl'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807107&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 09:11:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 09:11:30 2003
Subject: [Python-bugs-list] [ python-Bugs-807108 ] "TypeError: iteration
	over non-sequence" for list of strings
Message-ID: <E19zFc8-00078P-00@sc8-sf-web1.sourceforge.net>

Bugs item #807108, was opened at 2003-09-16 13: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=807108&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geir M. Koien (gmkoien)
Assigned to: Nobody/Anonymous (nobody)
Summary: "TypeError: iteration over non-sequence" for list of strings

Initial Comment:
The following code gives me the "TypeError: iteration 

over non-sequence" error.



I don't see why this shouldn't work.



Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "copyright", "credits" or "license()" for more 

information.



list = ["I am a boy", "You are a girl"]

for i in len(list):

	line = list[i]



	

Traceback (most recent call last):

  File "<pyshell#39>", line 1, in ?

    for i in len(list):

TypeError: iteration over non-sequence



***

If I take the steps manually it works....



>>> len(list)

2

>>> list[0]

'I am a boy'

>>> list[1]

'You are a girl'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807108&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 09:16:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 09:16:19 2003
Subject: [Python-bugs-list] [ python-Bugs-807108 ] "TypeError: iteration
	over non-sequence" for list of strings
Message-ID: <E19zFgl-0007SE-00@sc8-sf-web1.sourceforge.net>

Bugs item #807108, was opened at 2003-09-16 13:11
Message generated for change (Settings changed) made by gmkoien
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807108&group_id=5470

Category: Parser/Compiler
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geir M. Koien (gmkoien)
Assigned to: Nobody/Anonymous (nobody)
Summary: "TypeError: iteration over non-sequence" for list of strings

Initial Comment:
The following code gives me the "TypeError: iteration 

over non-sequence" error.



I don't see why this shouldn't work.



Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "copyright", "credits" or "license()" for more 

information.



list = ["I am a boy", "You are a girl"]

for i in len(list):

	line = list[i]



	

Traceback (most recent call last):

  File "<pyshell#39>", line 1, in ?

    for i in len(list):

TypeError: iteration over non-sequence



***

If I take the steps manually it works....



>>> len(list)

2

>>> list[0]

'I am a boy'

>>> list[1]

'You are a girl'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807108&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 09:17:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 09:17:35 2003
Subject: [Python-bugs-list] [ python-Bugs-807107 ] "TypeError: iteration
	over non-sequence" for list of strings
Message-ID: <E19zFhu-0007XS-00@sc8-sf-web1.sourceforge.net>

Bugs item #807107, was opened at 2003-09-16 13:11
Message generated for change (Settings changed) made by gmkoien
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807107&group_id=5470

Category: Parser/Compiler
>Group: Trash
Status: Open
>Resolution: Duplicate
>Priority: 1
Submitted By: Geir M. Koien (gmkoien)
Assigned to: Nobody/Anonymous (nobody)
Summary: "TypeError: iteration over non-sequence" for list of strings

Initial Comment:
The following code gives me the "TypeError: iteration 

over non-sequence" error.



I don't see why this shouldn't work.



Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "copyright", "credits" or "license()" for more 

information.



list = ["I am a boy", "You are a girl"]

for i in len(list):

	line = list[i]



	

Traceback (most recent call last):

  File "<pyshell#39>", line 1, in ?

    for i in len(list):

TypeError: iteration over non-sequence



***

If I take the steps manually it works....



>>> len(list)

2

>>> list[0]

'I am a boy'

>>> list[1]

'You are a girl'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807107&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 10:14:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 10:14:57 2003
Subject: [Python-bugs-list] [ python-Bugs-807108 ] "TypeError: iteration
	over non-sequence" for list of strings
Message-ID: <E19zGbO-0007W2-00@sc8-sf-web4.sourceforge.net>

Bugs item #807108, was opened at 2003-09-16 09:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807108&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Geir M. Koien (gmkoien)
Assigned to: Nobody/Anonymous (nobody)
Summary: "TypeError: iteration over non-sequence" for list of strings

Initial Comment:
The following code gives me the "TypeError: iteration 

over non-sequence" error.



I don't see why this shouldn't work.



Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "copyright", "credits" or "license()" for more 

information.



list = ["I am a boy", "You are a girl"]

for i in len(list):

	line = list[i]



	

Traceback (most recent call last):

  File "<pyshell#39>", line 1, in ?

    for i in len(list):

TypeError: iteration over non-sequence



***

If I take the steps manually it works....



>>> len(list)

2

>>> list[0]

'I am a boy'

>>> list[1]

'You are a girl'

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-16 10:14

Message:
Logged In: YES 
user_id=33168

Closing as duplicate of 807107.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807108&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 10:17:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 10:17:39 2003
Subject: [Python-bugs-list] [ python-Bugs-807107 ] "TypeError: iteration
	over non-sequence" for list of strings
Message-ID: <E19zGe6-0002kS-00@sc8-sf-web1.sourceforge.net>

Bugs item #807107, was opened at 2003-09-16 09:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807107&group_id=5470

Category: Parser/Compiler
Group: Trash
>Status: Closed
>Resolution: Invalid
Priority: 1
Submitted By: Geir M. Koien (gmkoien)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: "TypeError: iteration over non-sequence" for list of strings

Initial Comment:
The following code gives me the "TypeError: iteration 

over non-sequence" error.



I don't see why this shouldn't work.



Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "copyright", "credits" or "license()" for more 

information.



list = ["I am a boy", "You are a girl"]

for i in len(list):

	line = list[i]



	

Traceback (most recent call last):

  File "<pyshell#39>", line 1, in ?

    for i in len(list):

TypeError: iteration over non-sequence



***

If I take the steps manually it works....



>>> len(list)

2

>>> list[0]

'I am a boy'

>>> list[1]

'You are a girl'

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-16 10:17

Message:
Logged In: YES 
user_id=33168

You need to do either:



for i in range(len(list)):

    line = list[i]



OR



for line in list:

   ...



The error message is telling you that you are trying to

iterate over an int which is returned from len(list).  Hope

this helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807107&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 12:44:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 12:44:16 2003
Subject: [Python-bugs-list] [ python-Bugs-807253 ] WinCVs & Python 2.3
Message-ID: <E19zIw1-00033D-00@sc8-sf-web1.sourceforge.net>

Bugs item #807253, was opened at 2003-09-16 09: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=807253&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Partho Bhowmick (ypostgresql)
Assigned to: Nobody/Anonymous (nobody)
Summary: WinCVs & Python 2.3

Initial Comment:
I don't know what changed between Python 2.2.3 & 

Python 2.3 but WinCVS1.3.1 cannot detect Python 2.3, 

though it works fine with Python 2.2.3. Curioulsly, the 

Tcl that comes with Python 2.3 is detected

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807253&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 14:27:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 14:27:46 2003
Subject: [Python-bugs-list] [ python-Bugs-807314 ] Crash if getvar of a
	non-existent Tcl variable
Message-ID: <E19zKY5-0004jd-00@sc8-sf-web4.sourceforge.net>

Bugs item #807314, was opened at 2003-09-16 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=807314&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: David Ascher (david_ascher)
Assigned to: Martin v. L?wis (loewis)
Summary: Crash if getvar of a non-existent Tcl variable

Initial Comment:
In 2.3, the code:



    from Tkinter import *

    x = Tk()

    x.getvar('foobar')



will crash.  This is due to bad error checking in 

_tkinter.c, in the GetVar() code.



A possible patch is attached.



Making p7 because it's a crasher. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807314&group_id=5470

From noreply at sourceforge.net  Tue Sep 16 15:31:56 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 16 15:32:21 2003
Subject: [Python-bugs-list] [ python-Bugs-807253 ] WinCVs & Python 2.3
Message-ID: <E19zLYK-00083R-00@sc8-sf-web4.sourceforge.net>

Bugs item #807253, was opened at 2003-09-16 11:44
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807253&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Partho Bhowmick (ypostgresql)
Assigned to: Nobody/Anonymous (nobody)
Summary: WinCVs & Python 2.3

Initial Comment:
I don't know what changed between Python 2.2.3 & 

Python 2.3 but WinCVS1.3.1 cannot detect Python 2.3, 

though it works fine with Python 2.2.3. Curioulsly, the 

Tcl that comes with Python 2.3 is detected

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-16 14:31

Message:
Logged In: YES 
user_id=80475

This may seem obvious but it is worth a try.  See if WinCVS 

has some equivalent of "cvs up -A" which will turn-off the 

sticky flags associated with each file.  The symptoms sound 

like your setup is locked into checking for release22-maint 

when it should be looking for release23-maint (for the most 

current 23) or release23-branch (for the one that went out 

the door).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807253&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 02:04:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 02:04:22 2003
Subject: [Python-bugs-list] [ python-Bugs-793702 ] Section 13.1 HTMLParser
	documentation error
Message-ID: <E19zVQE-0003QA-00@sc8-sf-web1.sourceforge.net>

Bugs item #793702, was opened at 2003-08-23 05:01
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793702&group_id=5470

Category: Documentation
>Group: Python 2.3
>Status: Open
>Resolution: None
>Priority: 5
Submitted By: Martin Baker (kemokid)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Section 13.1 HTMLParser documentation error

Initial Comment:
The description for handle_comment() says:



     The comment argument is a string containing the

text between the "<!-" and "->" delimiters, but not the

delimiters themselves. For example, the comment

"<!-text->" will cause this method to be called with

the argument 'text'.



This is incorrect - the comment delimiters are "<!--"

and "-->" (two hyphens, not just one). Purusing the

code, it appears that the module itself behaves

correctly, so this is only a very minor documentation

bug, but to a HTML newbie, it could be an incredibly

frustrating one.



This was seen on 2003/8/23 at

http://www.python.org/doc/current/lib/module-HTMLParser.html



And a big thank you to all Pythonic volunteers!

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-17 01:04

Message:
Logged In: YES 
user_id=80475

My fix didn't take.

Re-opening and assigning to Fred so the job gets done right.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-24 22:32

Message:
Logged In: YES 
user_id=80475

Thanks for the bug report.

It looks like TeX was considering -- as a special character 

and only printing it once.  Escaping the hyphen ought to fix 

it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793702&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 02:36:54 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 02:37:02 2003
Subject: [Python-bugs-list] [ python-Bugs-807630 ] IDLE fails to start on
	WindowsME
Message-ID: <E19zVvq-0003r8-00@sc8-sf-web3.sourceforge.net>

Bugs item #807630, was opened at 2003-09-17 02: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=807630&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Henry Lenzi (synthespian)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE fails to start on WindowsME

Initial Comment:
 IDLE does not start on WindowsME. Bugs 780451 and

784183 have been consulted. Moving installation to

C:\Python\, or the newer, fixed (in relation to

previous bugs) C:\Python23\ fails to lauch IDLE.

Attempting default to C:\Program files\ fails, too.

 Both HKLM and HKCu installations have been attempted.

 This is unheard of, up to this version there weren't

any problems.

 Pythonwin's IDLE runs but complains "an error with DDE

conversation with Pythonwin" ( I *know* this is

somewhat Off-topic, but maybe it helps_.

 Bug 780451 should be reopened, IMHO.







 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807630&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 02:50:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 02:50:24 2003
Subject: [Python-bugs-list] [ python-Bugs-807107 ] "TypeError: iteration
	over non-sequence" for list of strings
Message-ID: <E19zW8q-0008V0-00@sc8-sf-web2.sourceforge.net>

Bugs item #807107, was opened at 2003-09-16 13:11
Message generated for change (Settings changed) made by gmkoien
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807107&group_id=5470

Category: Parser/Compiler
Group: Trash
>Status: Open
>Resolution: Duplicate
Priority: 1
Submitted By: Geir M. Koien (gmkoien)
>Assigned to: Nobody/Anonymous (nobody)
Summary: "TypeError: iteration over non-sequence" for list of strings

Initial Comment:
The following code gives me the "TypeError: iteration 

over non-sequence" error.



I don't see why this shouldn't work.



Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "copyright", "credits" or "license()" for more 

information.



list = ["I am a boy", "You are a girl"]

for i in len(list):

	line = list[i]



	

Traceback (most recent call last):

  File "<pyshell#39>", line 1, in ?

    for i in len(list):

TypeError: iteration over non-sequence



***

If I take the steps manually it works....



>>> len(list)

2

>>> list[0]

'I am a boy'

>>> list[1]

'You are a girl'

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-16 14:17

Message:
Logged In: YES 
user_id=33168

You need to do either:



for i in range(len(list)):

    line = list[i]



OR



for line in list:

   ...



The error message is telling you that you are trying to

iterate over an int which is returned from len(list).  Hope

this helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807107&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 07:49:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 07:49:20 2003
Subject: [Python-bugs-list] [ python-Bugs-807771 ] Max and min are incorrect
	with one argument
Message-ID: <E19zao2-0001Qy-00@sc8-sf-web1.sourceforge.net>

Bugs item #807771, was opened at 2003-09-17 11:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807771&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Max and min are incorrect with one argument

Initial Comment:
max(1)

raises 'TypeError: iteration over non-sequence',

when it should simply return 1



Min has the same problem.



If there is one person in a room, and you ask for the

tallest person, there is a well-defined answer.

The tallest person is the only person.

So is the shortest person.



I ran across this when I was doing

apply(max, list) / apply(min, list)

to find out the ratio of maximum to minimum entries

in a list.    With a single-element list, I expected

it to return 1, instead of raising an exception.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807771&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 09:34:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 09:34:42 2003
Subject: [Python-bugs-list] [ python-Bugs-807813 ] Typo in
	postinstallation-script.html
Message-ID: <E19zcRx-0007mf-00@sc8-sf-web3.sourceforge.net>

Bugs item #807813, was opened at 2003-09-17 09: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=807813&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric D. Moyer (e_d_moyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in postinstallation-script.html

Initial Comment:
There is a typo in the paragraph containing the 

text "'csidl_string' must be on of the following strings: "



The text should read:



"'csidl_string' must be one of the following strings: "



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807813&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 09:38:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 09:39:09 2003
Subject: [Python-bugs-list] [ python-Bugs-807813 ] Typo in
	postinstallation-script.html
Message-ID: <E19zcVu-0004z2-00@sc8-sf-web4.sourceforge.net>

Bugs item #807813, was opened at 2003-09-17 09:34
Message generated for change (Settings changed) made by e_d_moyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807813&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 1
Submitted By: Eric D. Moyer (e_d_moyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in postinstallation-script.html

Initial Comment:
There is a typo in the paragraph containing the 

text "'csidl_string' must be on of the following strings: "



The text should read:



"'csidl_string' must be one of the following strings: "



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807813&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 11:18:33 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 11:18:37 2003
Subject: [Python-bugs-list] [ python-Bugs-807871 ] tkMessageBox.askyesno
	wrong result
Message-ID: <E19ze4f-0004Q8-00@sc8-sf-web1.sourceforge.net>

Bugs item #807871, was opened at 2003-09-17 11: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=807871&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Perkins (ranger1)
Assigned to: Nobody/Anonymous (nobody)
Summary: tkMessageBox.askyesno wrong result

Initial Comment:
Bug: tkMessageBox.askyesno can return wrong result. 
 
   Bug in python 2.3, built from source on SuSE 8.2 Linux box 
with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). 
 
   To demonstate bug: 
   1. Run attached program in a shell window under X. 
   2. Click "askyesno" button in main window. 
   3. Click "Yes" button in the new window. 
   4. Observe printed result "True" in shell window. 
   5. Click "openfiledialog" button in main window. 
   6. Cancel the file dialog (or select a file, it doesn't matter). 
   7. Click "askyesno" button in main window. 
   8. Click "Yes" button in the new window. 
   9. Observe printed result "False" in shell window. 
 
   Using the debugger in idle, one can see that the 
difference is that Tk returns "yes" to Python in step 3, but 
True in step 8. 
 
   In python 2.2 (as built by SuSE for 8.2), the printed result 
   is always "1" in steps 3 and 8. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 12:37:27 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 12:37:32 2003
Subject: [Python-bugs-list] [ python-Bugs-807107 ] "TypeError: iteration
	over non-sequence" for list of strings
Message-ID: <E19zfJ1-0006so-00@sc8-sf-web1.sourceforge.net>

Bugs item #807107, was opened at 2003-09-16 08:11
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807107&group_id=5470

Category: Parser/Compiler
Group: Trash
>Status: Closed
>Resolution: Invalid
Priority: 1
Submitted By: Geir M. Koien (gmkoien)
Assigned to: Nobody/Anonymous (nobody)
Summary: "TypeError: iteration over non-sequence" for list of strings

Initial Comment:
The following code gives me the "TypeError: iteration 

over non-sequence" error.



I don't see why this shouldn't work.



Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 

32 bit (Intel)] on win32

Type "copyright", "credits" or "license()" for more 

information.



list = ["I am a boy", "You are a girl"]

for i in len(list):

	line = list[i]



	

Traceback (most recent call last):

  File "<pyshell#39>", line 1, in ?

    for i in len(list):

TypeError: iteration over non-sequence



***

If I take the steps manually it works....



>>> len(list)

2

>>> list[0]

'I am a boy'

>>> list[1]

'You are a girl'

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-09-16 09:17

Message:
Logged In: YES 
user_id=33168

You need to do either:



for i in range(len(list)):

    line = list[i]



OR



for line in list:

   ...



The error message is telling you that you are trying to

iterate over an int which is returned from len(list).  Hope

this helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807107&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 13:13:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 13:13:48 2003
Subject: [Python-bugs-list] [ python-Bugs-807813 ] Typo in
	postinstallation-script.html
Message-ID: <E19zfs0-0000JJ-00@sc8-sf-web1.sourceforge.net>

Bugs item #807813, was opened at 2003-09-17 15:34
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807813&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: Eric D. Moyer (e_d_moyer)
>Assigned to: Thomas Heller (theller)
Summary: Typo in postinstallation-script.html

Initial Comment:
There is a typo in the paragraph containing the 

text "'csidl_string' must be on of the following strings: "



The text should read:



"'csidl_string' must be one of the following strings: "



----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-09-17 19:13

Message:
Logged In: YES 
user_id=11105

Thanks, fixed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807813&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 17:16:56 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 17:16:59 2003
Subject: [Python-bugs-list] [ python-Bugs-808164 ] socket.close() doesn't
	play well with __del__
Message-ID: <E19zjfU-0004EL-00@sc8-sf-web4.sourceforge.net>

Bugs item #808164, was opened at 2003-09-17 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=105470&aid=808164&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Perry Greenfield (perrygreenfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.close() doesn't play well with __del__

Initial Comment:
It appears that 2.3 changed how socket.close() works. 

We now find errors when terminating Python when we 

reference socket.close() in a __del__ method. We have 

worked around it by removing calls to socket.close() but 

note the following differences between the same section 

of code between 2.2 and 2.3 which suggest that the 2.3 

behavior is not ideal and should be fixed.



In Python 2.3:



    def close(self):

        self._sock = _closedsocket()

        self.send = self.recv = self.sendto = self.recvfrom \

                        = self._sock._dummy



In Python 2.2:



    def close(self):

        # Avoid referencing globals here

        self._sock = self.__class__._closedsocket()



Note the reference to avoiding globals which is 

presumably the source of the problem with 2.3. Perhaps 

I'm naive but I would guess that calling a close method 

should be considered a safe operation for use in a 

__del__ method.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808164&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 18:13:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 18:13:42 2003
Subject: [Python-bugs-list] [ python-Bugs-808197 ] rlcompleter
	incompatibility
Message-ID: <E19zkYM-0006Lf-00@sc8-sf-web1.sourceforge.net>

Bugs item #808197, was opened at 2003-09-17 18:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808197&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Perry Greenfield (perrygreenfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: rlcompleter incompatibility

Initial Comment:
Changes made as part of patch 490026 have introduced 

a compatility problem into rlcompleter. The new version 

introduces an __init__ that was not present in the 

previous version. Any subclass of Completer must call

the superclass __init__ for completion to work properly. 

Unfortunately, adding a call to __init__ makes code 

incompatible with previous versions of Python so the 

resulting code must be more complex (it must check to 

see if it can call __init__ or not). It is unclear what can 

be done now to fix this problem, but at the very least, 

the problem should be documented (there is no mention 

of the change in the release notes).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808197&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 18:53:57 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 18:54:01 2003
Subject: [Python-bugs-list] [ python-Bugs-798274 ] absolute import patch
	breaks external users of test.regrtest
Message-ID: <E19zlBN-0003lm-00@sc8-sf-web3.sourceforge.net>

Bugs item #798274, was opened at 2003-08-31 16:39
Message generated for change (Comment added) made by nriley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798274&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicholas Riley (nriley)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: absolute import patch breaks external users of test.regrtest

Initial Comment:
I've built a test system using Python's test.regrtest 

mechanism, and it worked very well under Python 2.2.  In 

Python 2.3, the output looks like this:



test_inttypes

test_inttypes skipped -- No module named test_inttypes

test_string

test_unittest

test_unittest skipped -- No module named test_unittest

[...]



I've tracked the problem down to a change made about a 

year ago.



http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/

python/dist/src/Lib/test/regrtest.py.diff?r1=1.91&r2=1.92



test.regrtest is finding the modules, but is failing to import 

them because it is prepending 'test.' to the module names, 

in a mistaken assumption that all tests will be in a package 

named test.



As it happened, I had my test modules inside a directory 

named 'test', and I tried making the directory a module and 

futzing with sys.path to get it to work, but now 

test.regrtest can't find the system implementation of 

test.test_support.  I've also now got the problem of 

namespace pollution - the "test_string" above is Python's 

version, not my version with the same name.



So, it appears non-Python users of test.regrtest are broken 

by this change in Python 2.3.  I was pretty careful to make 

sure that I was doing something supported - the docstring 

for test.regrtest.main explicitly refers to non-Python test 

suite users - and ran into some weird cases like test.* not 

being installed on Mac OS X by default, but it worked very 

well otherwise.



One potential solution would be that if 'testdir' is specified, 

test.regrtest.main() does not attempt to prepend 'test.' to 

the module names.  This seems to match pretty well with 

the spirit of the documentation for that method.

----------------------------------------------------------------------

>Comment By: Nicholas Riley (nriley)
Date: 2003-09-17 17:53

Message:
Logged In: YES 
user_id=34933

Thanks for the helpful response.



Sorry I didn't get around to writing any documentation, but a 

patch is here:



http://sourceforge.net/tracker/index.php?

func=detail&aid=808210&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-01 22:54

Message:
Logged In: YES 
user_id=12800

IIRC, this patch was necessary because some tests required

absolute imports and we cannot mix relative and absolute

imports in the test suite.  IMO, regrtest's primary mission

in life is to support Python's test suite and any other use

is secondary (for example, it isn't documented in the

standard library manual).  OTOH, you might think about

contributing a patch that allows regrtest to be used outside

the Python test suite, but doesn't break the absolute import

requirement while in the test suite.  (You might also

consider adding some standard lib documentation to your

patch <wink>).



The other problems you mention are inherent in Python's

import machinery.  If you have two packages named "test" on

your sys.path, Python will not by default search them both

for submodules.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 11:51

Message:
Logged In: YES 
user_id=80475

Barry, this was your change.

Would you take a look at this bug report?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798274&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 21:30:47 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 21:30:52 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E19znd9-0003tv-00@sc8-sf-web2.sourceforge.net>

Bugs item #808285, was opened at 2003-09-17 18: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=808285&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 21:31:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 21:31:03 2003
Subject: [Python-bugs-list] [ python-Bugs-808286 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E19zndM-0003uL-00@sc8-sf-web2.sourceforge.net>

Bugs item #808286, was opened at 2003-09-17 18: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=808286&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808286&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 21:32:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 21:32:27 2003
Subject: [Python-bugs-list] [ python-Bugs-808286 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E19zned-0003wG-00@sc8-sf-web2.sourceforge.net>

Bugs item #808286, was opened at 2003-09-17 18:31
Message generated for change (Settings changed) made by bescoto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808286&group_id=5470

>Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808286&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 21:33:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 21:33:27 2003
Subject: [Python-bugs-list] [ python-Bugs-808286 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E19znfc-0003yk-00@sc8-sf-web2.sourceforge.net>

Bugs item #808286, was opened at 2003-09-17 18:31
Message generated for change (Comment added) made by bescoto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808286&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

>Comment By: Ben Escoto (bescoto)
Date: 2003-09-17 18:33

Message:
Logged In: YES 
user_id=218965

Oops, accidentally double posted somehow

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808286&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 21:34:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 21:34:15 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E19zngM-00040Y-00@sc8-sf-web2.sourceforge.net>

Bugs item #808285, was opened at 2003-09-17 18:30
Message generated for change (Settings changed) made by bescoto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

>Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Wed Sep 17 22:33:22 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 17 22:37:14 2003
Subject: [Python-bugs-list] [ python-Bugs-705295 ] Error when using
	PyZipFile to create archive
Message-ID: <E19zobi-0006ZK-00@sc8-sf-web1.sourceforge.net>

Bugs item #705295, was opened at 2003-03-17 17:05
Message generated for change (Comment added) made by crc1021
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705295&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Dave Kuhlman (dkuhlman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error when using PyZipFile to create archive

Initial Comment:
I get the following trace back while using the PyZipFile class to create zip import files.



Traceback (most recent call last):

  File "../fsmGenerate.py", line 125, in ?

    main()

  File "../fsmGenerate.py", line 121, in main

    generate(inFileName, outName, app, gui, schema, zip)

  File "../fsmGenerate.py", line 56, in generate

    outZip.write(name)

  File "/usr/local/lib/python2.3/zipfile.py", line 427, in write

    self.fp.write(zinfo.FileHeader())

  File "/usr/local/lib/python2.3/zipfile.py", line 167, in FileHeader

    fileHeader = '%s%s%s' % (header, self.filename, self.extra)

UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 10: ordinal not in range(128)



This error occurs intermitently.  It seems to be related to the time.



Looking in file Lib/zipfile.py, it appears that the call to struct.pack() in method ZipInfo.FileHeader() is creating a string containing bytes with values > 0x7F.  I believe that these values are coming from local variable dostime in ZipInfo.FileHeader().



I'm using Python 2.3a2, built from source on Linux.





----------------------------------------------------------------------

Comment By: Eric Lofstad (crc1021)
Date: 2003-09-17 21:33

Message:
Logged In: YES 
user_id=868802

I get a similar error when the filename passed to "write" is

a unicode string.  I'm using Python 2.3

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 16:22

Message:
Logged In: YES 
user_id=33168

I'm closing this bug report since it can't be reproduced. 

If you have another bug, please open a new bug report.

----------------------------------------------------------------------

Comment By: Dave Kuhlman (dkuhlman)
Date: 2003-04-02 19:34

Message:
Logged In: YES 
user_id=629965

I can no longer reproduce this bug.  I'm the one who originally submitted this bug report. There must have been a bug in my original code.  The test I'm using now executes with no problems.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705295&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 10:43:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 10:43:24 2003
Subject: [Python-bugs-list] [ python-Bugs-808594 ] leak on lambda with
	duplicate arguments error
Message-ID: <E1A0001-0004Vo-00@sc8-sf-web4.sourceforge.net>

Bugs item #808594, was opened at 2003-09-18 15: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=808594&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Jeremy Hylton (jhylton)
Summary: leak on lambda with duplicate arguments error

Initial Comment:
There's a leak on compiling code like 'lambda a,a:0'. 

TrackRefs says the following are being leaked:



<type 'list'>                                         

        4       16

<type 'str'>                                          

        2       10

<type 'symtable entry'>                               

        2        8

<type 'dict'>                                         

        2        8

<type 'int'>                                          

        0        2



It doesn't seem to leak for, e.g. 'def f(a,a):pass'.



I had a look at the code, but got very confused, I'm

afraid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808594&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 10:48:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 10:48:44 2003
Subject: [Python-bugs-list] [ python-Bugs-808596 ] leaking snippet
Message-ID: <E1A005E-0004nD-00@sc8-sf-web4.sourceforge.net>

Bugs item #808596, was opened at 2003-09-18 15: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=808596&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: leaking snippet

Initial Comment:
Raymond Hettinger found that the following:



 fd, fname = tempfile.mkstemp()

 execfile(fname)



leaks a reference.  TrackRefs sez it's a string. 

Haven't dug any further.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 13:08:35 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 13:33:18 2003
Subject: [Python-bugs-list] [ python-Bugs-808719 ] IDLE and encodings
Message-ID: <E1A02Gh-00057M-00@sc8-sf-web1.sourceforge.net>

Bugs item #808719, was opened at 2003-09-18 12: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=808719&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE and encodings

Initial Comment:
A person from Belgium reported this problem in IDLE to 

python-help:



$ python  idle

Traceback (most recent call last):

  File "idle", line 10, in ?

    import PyShell

  File "PyShell.py", line 25, in ?

    from EditorWindow import EditorWindow, fixwordbreaks

  File "EditorWindow.py", line 39, in ?

    class EditorWindow:

  File "EditorWindow.py", line 43, in EditorWindow

    from IOBinding import IOBinding

  File "IOBinding.py", line 54, in ?

    codecs.lookup(encoding)

  File

"/ap/tools/storage/python/v2.2.2.224_ap/lib/python2.2/

encodings/__init__.py",



line 51, in search_function

    mod = __import__(modname,globals(),locals(),'*')

ValueError: Empty module name



It seems that checking for an encoding of "" as well as None 

in IOBinding.py fixes the problem. I'll attach his small patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 14:01:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 14:01:43 2003
Subject: [Python-bugs-list] [ python-Bugs-808756 ] refleaks in _hotshot.c
Message-ID: <E1A0362-0006HN-00@sc8-sf-web2.sourceforge.net>

Bugs item #808756, was opened at 2003-09-18 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=808756&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: refleaks in _hotshot.c

Initial Comment:
My regrtest patches revealed a few leaks in

Modules/_hotshot.c.



Attached patch seems to fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 14:01:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 14:01:55 2003
Subject: [Python-bugs-list] [ python-Bugs-807314 ] Crash if getvar of a
	non-existent Tcl variable
Message-ID: <E1A036A-0007mP-00@sc8-sf-web1.sourceforge.net>

Bugs item #807314, was opened at 2003-09-16 20:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807314&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: David Ascher (david_ascher)
>Assigned to: David Ascher (david_ascher)
Summary: Crash if getvar of a non-existent Tcl variable

Initial Comment:
In 2.3, the code:



    from Tkinter import *

    x = Tk()

    x.getvar('foobar')



will crash.  This is due to bad error checking in 

_tkinter.c, in the GetVar() code.



A possible patch is attached.



Making p7 because it's a crasher. 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:01

Message:
Logged In: YES 
user_id=21627

The patch is fine; please apply (or reassign if you want me

to apply it).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807314&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 14:05:53 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 14:06:00 2003
Subject: [Python-bugs-list] [ python-Bugs-808719 ] IDLE and encodings
Message-ID: <E1A03A9-0006Uc-00@sc8-sf-web2.sourceforge.net>

Bugs item #808719, was opened at 2003-09-18 19:08
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE and encodings

Initial Comment:
A person from Belgium reported this problem in IDLE to 

python-help:



$ python  idle

Traceback (most recent call last):

  File "idle", line 10, in ?

    import PyShell

  File "PyShell.py", line 25, in ?

    from EditorWindow import EditorWindow, fixwordbreaks

  File "EditorWindow.py", line 39, in ?

    class EditorWindow:

  File "EditorWindow.py", line 43, in EditorWindow

    from IOBinding import IOBinding

  File "IOBinding.py", line 54, in ?

    codecs.lookup(encoding)

  File

"/ap/tools/storage/python/v2.2.2.224_ap/lib/python2.2/

encodings/__init__.py",



line 51, in search_function

    mod = __import__(modname,globals(),locals(),'*')

ValueError: Empty module name



It seems that checking for an encoding of "" as well as None 

in IOBinding.py fixes the problem. I'll attach his small patch.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:05

Message:
Logged In: YES 
user_id=21627

Can you report what operating system this was on, and what

locale setting was in place?



What is the value of locale.getpreferredencoding on that system?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 14:07:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 14:07:54 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E1A03Bw-00088n-00@sc8-sf-web1.sourceforge.net>

Bugs item #808285, was opened at 2003-09-18 03:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:07

Message:
Logged In: YES 
user_id=21627

Is this with a 64-bit build? If so, which compiler was used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 14:08:57 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 14:09:12 2003
Subject: [Python-bugs-list] [ python-Bugs-807630 ] IDLE fails to start on
	WindowsME
Message-ID: <E1A03D7-0003PR-00@sc8-sf-web3.sourceforge.net>

Bugs item #807630, was opened at 2003-09-17 08:36
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807630&group_id=5470

Category: Installation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Henry Lenzi (synthespian)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE fails to start on WindowsME

Initial Comment:
 IDLE does not start on WindowsME. Bugs 780451 and

784183 have been consulted. Moving installation to

C:\Python\, or the newer, fixed (in relation to

previous bugs) C:\Python23\ fails to lauch IDLE.

Attempting default to C:\Program files\ fails, too.

 Both HKLM and HKCu installations have been attempted.

 This is unheard of, up to this version there weren't

any problems.

 Pythonwin's IDLE runs but complains "an error with DDE

conversation with Pythonwin" ( I *know* this is

somewhat Off-topic, but maybe it helps_.

 Bug 780451 should be reopened, IMHO.







 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:08

Message:
Logged In: YES 
user_id=21627

See http://www.python.org/2.3/bugs.html; this has been fixed

in the CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807630&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 14:13:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 14:13:20 2003
Subject: [Python-bugs-list] [ python-Bugs-807253 ] WinCVs & Python 2.3
Message-ID: <E1A03HG-0007QB-00@sc8-sf-web4.sourceforge.net>

Bugs item #807253, was opened at 2003-09-16 18:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807253&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Partho Bhowmick (ypostgresql)
Assigned to: Nobody/Anonymous (nobody)
Summary: WinCVs & Python 2.3

Initial Comment:
I don't know what changed between Python 2.2.3 & 

Python 2.3 but WinCVS1.3.1 cannot detect Python 2.3, 

though it works fine with Python 2.2.3. Curioulsly, the 

Tcl that comes with Python 2.3 is detected

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:13

Message:
Logged In: YES 
user_id=21627

ypostgresql, can you please elaborate what you mean by

"detect"? In what way can WinCVS detect Python?



If WinCVS has somehow a mechanism to invoke Python, why do

you think you have found a bug in Python, instead of a bug

in WinCVS?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-16 21:31

Message:
Logged In: YES 
user_id=80475

This may seem obvious but it is worth a try.  See if WinCVS 

has some equivalent of "cvs up -A" which will turn-off the 

sticky flags associated with each file.  The symptoms sound 

like your setup is locked into checking for release22-maint 

when it should be looking for release23-maint (for the most 

current 23) or release23-branch (for the one that went out 

the door).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807253&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 14:15:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 14:15:37 2003
Subject: [Python-bugs-list] [ python-Bugs-805788 ] Minor Python Intro update
Message-ID: <E1A03JU-0006wS-00@sc8-sf-web2.sourceforge.net>

Bugs item #805788, was opened at 2003-09-14 00:40
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805788&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor Python Intro update

Initial Comment:
The little source code on the following web page 

demonstrates outdated patterns:



http://python.org/doc/Introduction.html



def invert(table):

    index = {}                # empty dictionary

    for key in table.keys():

        value = table[key]

        if not index.has_key(value):

            index[value] = [] # empty list

        index[value].append(key)

    return index



Perhaps the following would be cleaner:



def invert(table):

    index = {}                # empty dictionary

    for key in table: #"for key, value in table.iteritems():"?

        value = table[key]

        if value not in index:

            index[value] = [] # empty list

        index[value].append(key)

    return index





----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:15

Message:
Logged In: YES 
user_id=21627

I fail to see the problem. The code is not outdated, it

continues to work just fine. As for clarity, I find explicit

usage of .keys() and .has_key() clearer than with your

proposed change. Explicit is better than implicit.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805788&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 14:26:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 14:26:45 2003
Subject: [Python-bugs-list] [ python-Bugs-805728 ] IDLE can't save UTF-8
	files on Windows
Message-ID: <E1A03UA-0004Ih-00@sc8-sf-web3.sourceforge.net>

Bugs item #805728, was opened at 2003-09-13 22:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805728&group_id=5470

Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sebastian Wangnick (wangnick)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE can't save UTF-8 files on Windows

Initial Comment:
When trying to save a UTF-8-encoded Python source 

code file containing non-ASCII characters, the new IDLE 

of Python 2.3 (final) fails on Windows:



>>> Exception in Tkinter callback

Traceback (most recent call last):

  File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 1345, in 

__call__

    return self.func(*args)

  File "C:\PYTHON23\lib\idlelib\IOBinding.py", line 347, in 

save_as

    if self.writefile(filename):

  File "C:\PYTHON23\lib\idlelib\IOBinding.py", line 370, in 

writefile

    chars = chars.replace("\n", self.eol_convention)

UnicodeDecodeError: 'ascii' codec can't decode byte 

0xc3 in position 241: ordinal not in range(128)





The following patch fixes the problem:



*** iobinding.py	Sun Jun 15 17:12:54 2003

--- iobinding.py.new	Thu Sep 11 05:59:54 2003

***************

*** 365,373 ****

  

      def writefile(self, filename):

          self.fixlastline()

!         chars = self.encode(self.text.get("1.0", "end-1c"))

          if self.eol_convention != "\n":

              chars = chars.replace("\n", 

self.eol_convention)

          try:

              f = open(filename, "wb")

              f.write(chars)

--- 365,374 ----

  

      def writefile(self, filename):

          self.fixlastline()

!         chars = self.text.get("1.0", "end-1c")

          if self.eol_convention != "\n":

              chars = chars.replace("\n", 

self.eol_convention)

+         chars = self.encode(chars)

          try:

              f = open(filename, "wb")

              f.write(chars)



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:26

Message:
Logged In: YES 
user_id=21627

Yes, this is fixed with IOBinding.py 1.20.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-15 20:01

Message:
Logged In: YES 
user_id=80475

I believe Kurt already fixed this one for Py2.3.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805728&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 14:37:57 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 14:38:05 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E1A03fB-0004rp-00@sc8-sf-web3.sourceforge.net>

Bugs item #808285, was opened at 2003-09-17 18:30
Message generated for change (Comment added) made by bescoto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

>Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 11:37

Message:
Logged In: YES 
user_id=218965

Compiler is gcc 2.95.3.  How do I tell if it is a "64-bit

build"?



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 11:07

Message:
Logged In: YES 
user_id=21627

Is this with a 64-bit build? If so, which compiler was used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 15:02:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 15:02:51 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E1A0439-0001Ou-00@sc8-sf-web4.sourceforge.net>

Bugs item #808285, was opened at 2003-09-18 03:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 21:02

Message:
Logged In: YES 
user_id=21627

What is the output of "file python"?

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 20:37

Message:
Logged In: YES 
user_id=218965

Compiler is gcc 2.95.3.  How do I tell if it is a "64-bit

build"?



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:07

Message:
Logged In: YES 
user_id=21627

Is this with a 64-bit build? If so, which compiler was used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 15:12:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 15:12:59 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E1A04Cq-0001pM-00@sc8-sf-web4.sourceforge.net>

Bugs item #808285, was opened at 2003-09-17 18:30
Message generated for change (Comment added) made by bescoto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

>Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 12:12

Message:
Logged In: YES 
user_id=218965

$ file python

python: ELF 64-bit MSB executable, Sparc64, version 1, for

OpenBSD, dynamically linked (uses shared libs), not stripped



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 12:02

Message:
Logged In: YES 
user_id=21627

What is the output of "file python"?

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 11:37

Message:
Logged In: YES 
user_id=218965

Compiler is gcc 2.95.3.  How do I tell if it is a "64-bit

build"?



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 11:07

Message:
Logged In: YES 
user_id=21627

Is this with a 64-bit build? If so, which compiler was used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 15:21:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 15:21:48 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E1A04LU-000318-00@sc8-sf-web1.sourceforge.net>

Bugs item #808285, was opened at 2003-09-18 03:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 21:21

Message:
Logged In: YES 
user_id=21627

I see. It is then pretty certain that you are running into a

compiler bug. Sparc64 floating point just does not work

correctly in gcc 2.95.3. Recompiling Python as a 32-bit

application should fix the problem.

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 21:12

Message:
Logged In: YES 
user_id=218965

$ file python

python: ELF 64-bit MSB executable, Sparc64, version 1, for

OpenBSD, dynamically linked (uses shared libs), not stripped



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 21:02

Message:
Logged In: YES 
user_id=21627

What is the output of "file python"?

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 20:37

Message:
Logged In: YES 
user_id=218965

Compiler is gcc 2.95.3.  How do I tell if it is a "64-bit

build"?



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:07

Message:
Logged In: YES 
user_id=21627

Is this with a 64-bit build? If so, which compiler was used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 16:22:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 16:24:05 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E1A05I7-0005L4-00@sc8-sf-web4.sourceforge.net>

Bugs item #808285, was opened at 2003-09-17 18:30
Message generated for change (Comment added) made by bescoto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

>Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 13:22

Message:
Logged In: YES 
user_id=218965

Ahh.  Probably a stupid question, but how do I recompile as

32 bit?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 12:21

Message:
Logged In: YES 
user_id=21627

I see. It is then pretty certain that you are running into a

compiler bug. Sparc64 floating point just does not work

correctly in gcc 2.95.3. Recompiling Python as a 32-bit

application should fix the problem.

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 12:12

Message:
Logged In: YES 
user_id=218965

$ file python

python: ELF 64-bit MSB executable, Sparc64, version 1, for

OpenBSD, dynamically linked (uses shared libs), not stripped



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 12:02

Message:
Logged In: YES 
user_id=21627

What is the output of "file python"?

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 11:37

Message:
Logged In: YES 
user_id=218965

Compiler is gcc 2.95.3.  How do I tell if it is a "64-bit

build"?



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 11:07

Message:
Logged In: YES 
user_id=21627

Is this with a 64-bit build? If so, which compiler was used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 16:59:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 16:59:54 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E1A05rn-0008RQ-00@sc8-sf-web1.sourceforge.net>

Bugs item #808285, was opened at 2003-09-18 03:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

Category: Python Interpreter Core
>Group: 3rd Party
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 22:59

Message:
Logged In: YES 
user_id=21627

That depends on the exact way how the compiler is installed.

Ask your system vendor. Reading the manual page might also help.



Closing as third-party.

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 22:22

Message:
Logged In: YES 
user_id=218965

Ahh.  Probably a stupid question, but how do I recompile as

32 bit?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 21:21

Message:
Logged In: YES 
user_id=21627

I see. It is then pretty certain that you are running into a

compiler bug. Sparc64 floating point just does not work

correctly in gcc 2.95.3. Recompiling Python as a 32-bit

application should fix the problem.

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 21:12

Message:
Logged In: YES 
user_id=218965

$ file python

python: ELF 64-bit MSB executable, Sparc64, version 1, for

OpenBSD, dynamically linked (uses shared libs), not stripped



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 21:02

Message:
Logged In: YES 
user_id=21627

What is the output of "file python"?

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 20:37

Message:
Logged In: YES 
user_id=218965

Compiler is gcc 2.95.3.  How do I tell if it is a "64-bit

build"?



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:07

Message:
Logged In: YES 
user_id=21627

Is this with a 64-bit build? If so, which compiler was used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Thu Sep 18 21:07:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 18 21:07:46 2003
Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed
Message-ID: <E1A09kG-0007kw-00@sc8-sf-web2.sourceforge.net>

Bugs item #763153, was opened at 2003-06-30 05:35
Message generated for change (Settings changed) made by bcannon
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: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Torsten Will (towi)
Assigned to: Brett Cannon (bcannon)
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: Brett Cannon (bcannon)
Date: 2003-09-18 18:07

Message:
Logged In: YES 
user_id=357491

The patch #762934 has been applied to fix this problem.



Closing this bug report.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-08-07 20:13

Message:
Logged In: YES 
user_id=357491

It's that time again!  =)  Patch #762934 has another patch to test; 

the one called "configure.in.patch.kbk".  Please give it a shot and 

respond with what OS you used and a pass or failure.  Remember 

you need to run autoreconf before you run 'configure'.  The main 

test is to see if time.tzset exists after compilation.

----------------------------------------------------------------------

Comment By: The LinuxDuck (thelinuxduck)
Date: 2003-07-31 09:41

Message:
Logged In: YES 
user_id=490655

Sorry to pollute here, but just an FYI:

Setting line 103 
to:

environ['TZ'] = 'Australia/Victoria'

and changing lines 106-
107 to:

self.failUnless(time.tzname[0] == 'EST', 
str(time.tzname[0]))

self.failUnless(time.tzname[1] == 'EST', 
str(time.tzname[1]))



all subsequent tests pass just fine, and 
the module test completes successfully.



Granted, I don't know 
what the difference between EST and EDT is, but it works. 
(=



With line 103, setting environ['TZ'] as the var 'victoria' and 
setting line 107 to AEST, that test passes, but as I mentioned before, the 
time.daylight test fails.

----------------------------------------------------------------------

Comment By: The LinuxDuck (thelinuxduck)
Date: 2003-07-31 09:30

Message:
Logged In: YES 
user_id=490655

Just a comment..  I was experimenting with ways to make the test pass 
(slack 8.1, glib 2.1.3, gcc 3.0.2), and by telling it to test tzname[1] with 
"AEST" it will pass (though I'm sure this violates whatever the test is for in 
the first place), but it fails on the time.daylight test (daylight = 0 when 
should = 1).



Interestingly enough, if I 
change:

test_time.py:103: environ['TZ'] = victoria

  
to

test_time.py:103: environ['TZ'] = 'Australia/Victoria'

  (as 
per the 'time' module documentation)



  it fails the same way, 
except the tztime[0,1] = EST,EST instead of AEST,*AEST (*as is the 
cause for the failed test in the first place).



Bear in mind I know jack 
diddly about how the timezone stuff works, so I'm just playing, and 
thought I'd share my results.. (=

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-07-28 20:38

Message:
Logged In: YES 
user_id=12800

I'm not sure there's anything we can do about this for

Python 2.3 final.  Lowering the priority, although I will

add a note in known bugs.html page.

----------------------------------------------------------------------

Comment By: Tim Heaney (theaney)
Date: 2003-07-27 16:04

Message:
Logged In: YES 
user_id=827666

Hi.



I just thought I'd mention that I got the same results with

2.3c2.



Tim



----------------------------------------------------------------------

Comment By: Tim Heaney (theaney)
Date: 2003-07-21 20:09

Message:
Logged In: YES 
user_id=827666

Hello.



I just downloaded 2.3c1. I failed test_time as well. I was

going to submit a new bug, but then I saw this thread. I

hope this is the right place.



test_time

test test_time failed -- Traceback (most recent call last):

  File

"/home/tim/Download/Python-2.3c1/Lib/test/test_time.py",

line 107, in test_tzset

    self.failUnless(time.tzname[1] == 'AEDT',

str(time.tzname[1]))

  File "/home/tim/Download/Python-2.3c1/Lib/unittest.py",

line 268, in failUnless

    if not expr: raise self.failureException, msg

AssertionError: AEST



227 tests OK.

1 test failed:

    test_time

27 tests skipped:

    test_aepack test_al test_bsddb185 test_bsddb3 test_cd

test_cl

    test_curses test_email_codecs test_gl test_imgfile

    test_linuxaudiodev test_macfs test_macostools test_nis

    test_normalization test_ossaudiodev test_pep277

test_plistlib

    test_scriptpackages test_socket_ssl test_socketserver

    test_sunaudiodev test_timeout test_unicode_file

test_urllibnet

    test_winreg test_winsound

Those skips are all expected on linux2.

make: *** [test] Error 1



For what it's worth, time seems to work...



$ ./python -c 'import time; print time.tzname'

('EST', 'EDT')



$ cat /proc/version 

Linux version 2.4.20 (root@mrbun) (gcc version 2.95.3

20010315 (release)) #11 Sat Nov 30 05:52:58 EST 2002



Tim



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-12 19:28

Message:
Logged In: YES 
user_id=357491

I uploaded a new version of the patch.  Give it a try and see what 

happens if you could.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-10 10:11

Message:
Logged In: YES 
user_id=357491

Barry says you need to do the following to truly test the patch:



- check out the head

- make distclean

- apply the patch

- autoreconf

- ./configure --with-pydebug

- make test



Apparently autoreconf regenerates something for autoconf and 

that has to be done.  Learn something new everyday.  Can you 

give that a shot, Torsten?  If that still fails it is going to take some 

work to figure this one out.

----------------------------------------------------------------------

Comment By: Torsten Will (towi)
Date: 2003-07-10 00:58

Message:
Logged In: YES 
user_id=269193

no, sorry, no success!



 * re-compiled python, as expected the test failed again.

 * patch -p0 <../tzset4.diff

 * made a "make distclean"

 * ./configure again, looked nice, no chached stuff.

 * make 

 * make test

 >>> failed again !!!



anything i could check to help?



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-09 21:37

Message:
Logged In: YES 
user_id=80475

Tonight, test_time also failed for me and then worked on the 

next pass.  Am using WinME and Py2.3b2+.





----------------------------------------------------------------------

Comment By: Torsten Will (towi)
Date: 2003-07-09 11:30

Message:
Logged In: YES 
user_id=269193

sorry, problem! hard drive scambled.

i have to re-install python anyway. i will see if the test

fails again, and then i try to apply the patch.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-09 10:15

Message:
Logged In: YES 
user_id=357491

Torsten, can you please try the patch that Neal pointed out?  We 

are approaching the release of Python 2.3 (by the end of the 

month) and it would be nice if this bug was settled before it goes 

out.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-30 22:10

Message:
Logged In: YES 
user_id=357491

If you are referring to bug #763047 and its cohort #763052, then 

no, I don't think so.  Those I think were an actual bug in the code.  

But there *is* a possibility since _strptime does call time.tzset 

when it calculates what timezones it knows about.



I am unassigning from myself since I have never touched 

time.tzset (don't remember who wrote time.tzset off the top of my 

head but it is a Python 2.3 feature).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-30 19:38

Message:
Logged In: YES 
user_id=80475

Brett, is this related to the other failures?

----------------------------------------------------------------------

Comment By: Torsten Will (towi)
Date: 2003-06-30 10: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 08: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 at sourceforge.net  Fri Sep 19 05:10:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 19 05:10:25 2003
Subject: [Python-bugs-list] [ python-Bugs-809163 ] Can't add files with
	spaces
Message-ID: <E1A0HHQ-0001GH-00@sc8-sf-web4.sourceforge.net>

Bugs item #809163, was opened at 2003-09-19 09:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809163&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Antonio Beamud Montero (antonio)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't add files with spaces

Initial Comment:
If i try to add data files with blank spaces in its

names using a wildcard in the MANIFEST.in file, it

doesn't do the work well and add only the fisrt part of

the name file. For example:

----- MANIFEST.in ----

images/*

-----------------------

The MANIFEST file generated is ok, but when rpm util

try to process it fail... The solution is to scape the

names or quote the names that are generated inside

INSTALLED_FILES



INSTALLED_FILES

running install

running build

running install_data

writing list of installed files to 'INSTALLED_FILES'

+ /usr/lib/rpm/brp-compress

+ /usr/lib/rpm/brp-strip

+ /usr/lib/rpm/brp-strip-comment-note

Processing files: garra-configurator-0.9.12-1

error: Two files on one line:

/usr/local/apache/htdocs/images/default

error: File must begin with "/": logo-tv-1.png





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809163&group_id=5470

From noreply at sourceforge.net  Fri Sep 19 05:41:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 19 05:42:25 2003
Subject: [Python-bugs-list] [ python-Bugs-809174 ] xmlrpclib's functions
	dumps() and loads() not documented.
Message-ID: <E1A0Hlj-00076i-00@sc8-sf-web3.sourceforge.net>

Bugs item #809174, was opened at 2003-09-19 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=809174&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Arsalan Zaidi (azaidi)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib's functions dumps() and loads() not documented.

Initial Comment:
The documentation does not appear for these two (more?)

functions in the python library reference...



I wouldn't have found them were it not for an article

on XML-RPC.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809174&group_id=5470

From noreply at sourceforge.net  Fri Sep 19 06:04:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 19 06:04:44 2003
Subject: [Python-bugs-list] [ python-Bugs-808594 ] leak on lambda with
	duplicate arguments error
Message-ID: <E1A0I7w-0003lK-00@sc8-sf-web4.sourceforge.net>

Bugs item #808594, was opened at 2003-09-18 15:43
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808594&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Jeremy Hylton (jhylton)
Summary: leak on lambda with duplicate arguments error

Initial Comment:
There's a leak on compiling code like 'lambda a,a:0'. 

TrackRefs says the following are being leaked:



<type 'list'>                                         

        4       16

<type 'str'>                                          

        2       10

<type 'symtable entry'>                               

        2        8

<type 'dict'>                                         

        2        8

<type 'int'>                                          

        0        2



It doesn't seem to leak for, e.g. 'def f(a,a):pass'.



I had a look at the code, but got very confused, I'm

afraid.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-09-19 11:04

Message:
Logged In: YES 
user_id=6656

Well, this was easier to fix than I expected (one line patch

attached, which I'll check in soon).



The mystery has transformed itself into "how the hell did

the code work in the first place?" and "why didn't the

function version leak?".



I think I know the answer to the first one, but I'm not

telling :-) I may go as far as posting it to c.l.py as a

Python Mystery Theatre style poser...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808594&group_id=5470

From noreply at sourceforge.net  Fri Sep 19 09:44:30 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 19 09:44:40 2003
Subject: [Python-bugs-list] [ python-Bugs-809254 ] imp.find_module doesn't
	work in /tmp
Message-ID: <E1A0LYk-0000Zy-00@sc8-sf-web2.sourceforge.net>

Bugs item #809254, was opened at 2003-09-19 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=809254&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Victor T. Ng (vng1)
Assigned to: Nobody/Anonymous (nobody)
Summary: imp.find_module doesn't work in /tmp

Initial Comment:
I'm running OSX 10.2.6 and the imp module seems to 

have a parsing error when I pass it the directory "/"



bash$ cd /tmp

bash$ touch __init__.py

bash$ python

Python 2.3 (#2, Jul 30 2003, 11:45:28) 

[GCC 3.1 20020420 (prerelease)] on darwin

Type "help", "copyright", "credits" or "license" for more 

information.

>>> import imp

>>> imp.find_module("tmp",['/'])

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

ImportError: No module named tmp

>>> imp.find_module("tmp",['//'])

(None, '//tmp', ('', '', 5))



I'm not sure why, but I seem to need a double slash in the 

directory name.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470

From noreply at sourceforge.net  Fri Sep 19 13:22:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 19 13:22:11 2003
Subject: [Python-bugs-list] [ python-Bugs-808719 ] IDLE and encodings
Message-ID: <E1A0OxK-00059D-00@sc8-sf-web3.sourceforge.net>

Bugs item #808719, was opened at 2003-09-18 12:08
Message generated for change (Comment added) made by mdcowles
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE and encodings

Initial Comment:
A person from Belgium reported this problem in IDLE to 

python-help:



$ python  idle

Traceback (most recent call last):

  File "idle", line 10, in ?

    import PyShell

  File "PyShell.py", line 25, in ?

    from EditorWindow import EditorWindow, fixwordbreaks

  File "EditorWindow.py", line 39, in ?

    class EditorWindow:

  File "EditorWindow.py", line 43, in EditorWindow

    from IOBinding import IOBinding

  File "IOBinding.py", line 54, in ?

    codecs.lookup(encoding)

  File

"/ap/tools/storage/python/v2.2.2.224_ap/lib/python2.2/

encodings/__init__.py",



line 51, in search_function

    mod = __import__(modname,globals(),locals(),'*')

ValueError: Empty module name



It seems that checking for an encoding of "" as well as None 

in IOBinding.py fixes the problem. I'll attach his small patch.

----------------------------------------------------------------------

>Comment By: Matthew Cowles (mdcowles)
Date: 2003-09-19 12:22

Message:
Logged In: YES 
user_id=198518

The original poster to python-help replies:



SYSTEM: SunOS indsv07 5.6 Generic_105181-19 sun4u sparc 

SUNW,Ultra-2





????????????????Python2.2???????????????????????????????????????

????????????

>>> locale.getpreferredencoding

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

AttributeError: 'module' object has no attribute 

'getpreferredencoding'

>>> locale.getpreferredencoding()

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

AttributeError: 'module' object has no attribute 

'getpreferredencoding'

>>>

????????????????????????????????????????????????????????????????

??????





ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on

Python 2.2.2 (#1, Nov 26 2002, 10:37:00)

[GCC 2.95.2 19991024 (release)] on sunos5

Type "help", "copyright", "credits" or "license" for more 

information.

>>>

>>> locale._print_locale()

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

<<<<<<

Locale defaults as determined by getdefaultlocale():

------------------------------------------------------------------------

Language:  (undefined)

Encoding:  (undefined)



Locale settings on startup:

------------------------------------------------------------------------

LC_NUMERIC ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_MESSAGES ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_MONETARY ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_COLLATE ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_CTYPE ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_TIME ...

   Language:  (undefined)

   Encoding:  (undefined)



Locale settings after calling resetlocale():

------------------------------------------------------------------------

LC_NUMERIC ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_MESSAGES ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_MONETARY ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_COLLATE ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_CTYPE ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_TIME ...

   Language:  (undefined)

   Encoding:  (undefined)





Locale settings after calling setlocale(LC_ALL, ""):

------------------------------------------------------------------------

C_NUMERIC ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_MESSAGES ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_MONETARY ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_COLLATE ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_CTYPE ...

   Language:  (undefined)

   Encoding:  (undefined)



LC_TIME ...

   Language:  (undefined)

   Encoding:  (undefined)



>>>

>>> locale._test()

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

123456789 is 123456789

3.14 is 3.14

>>> locale.getlocale()

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

(None, None)

>>> locale.getdefaultlocale()

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

(None, None)

>>>

>>> locale.CODESET

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

49



>>> locale.localeconv()

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

{'mon_decimal_point': '', 'int_frac_digits': 127, 'p_sep_by_space': 

127,

'frac_digits': 127, 'thousands_sep': '', 'n_sign_posn': 127,

'decimal_point': '.', 'mon_thousands_sep': '', 'n_cs_precedes': 127,

'p_sign_posn': 127, 'int_curr_symbol': '', 'negative_sign': '',

'currency_symbol': '', 'n_sep_by_space': 127, 'mon_grouping': [],

'p_cs_precedes': 127, 'positive_sign': '', 'grouping': []}

>>>



>>> locale.getdefaultlocale()

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

<

(None, None)





=========================================

=========================================

======

!!!!!!!!!!!!!!!!!!!!!!  Unofficial install of 2.3 (same system)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

=========================================

=========================================

======

Python 2.3 (#1, Jul 31 2003, 09:16:42)

[GCC 2.95.3 20010315 (release)] on sunos5

Type "help", "copyright", "credits" or "license" for more 

information.

>>>

>>> import locale

>>> locale.getpreferredencoding()

''

>>>



############# Here, I have done the same modifications in

"idlelib...IObinding.py" but for Python 2.3 and I succeed in 

launching IDLE

######################



Python 2.3 (#1, Jul 31 2003, 09:16:42)

[GCC 2.95.3 20010315 (release)] on sunos5

Type "copyright", "credits" or "license()" for more information.



    

********************************************************

********

    Personal firewall software may warn about the connection IDLE

    makes to its subprocess using this computer's internal loopback

    interface.  This connection is not visible on any external

    interface and no data is sent to or received from the Internet.

    

********************************************************

********



IDLE 1.0

>>>



>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>



One last remark, last time I remenber that the problem of codec 

lookup also

appeared in other circumstances than starting IDLE.





----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 13:05

Message:
Logged In: YES 
user_id=21627

Can you report what operating system this was on, and what

locale setting was in place?



What is the value of locale.getpreferredencoding on that system?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470

From noreply at sourceforge.net  Fri Sep 19 22:13:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 19 22:13:58 2003
Subject: [Python-bugs-list] [ python-Bugs-809599 ] tex to html convert bug
Message-ID: <E1A0XFz-0006l5-00@sc8-sf-web1.sourceforge.net>

Bugs item #809599, was opened at 2003-09-20 11: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=809599&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: tex to html convert bug

Initial Comment:
At the section "22. MS Windows Specific Services" in 

Python Library Reference, there're strange 

characters in the middle of the sentence.



http://www.python.org/dev/doc/devel/lib/node735.ht

ml

> msvcrt  Miscellaneous useful routines from the

> MS VC++<#67760#><#67760#> runtime 

You can see strange tags, "<#67760#>" after the 

word, "VC++".



In Python 2.2, it looks just fine.

http://www.python.org/doc/2.2.2/lib/node611.html

> msvcrt  Miscellaneous useful routines from the

> MS VC++ runtime. 



It looks like this problem is caused by Fred's last 

commit to libmsvcrt.tex(Jul 2 2003).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809599&group_id=5470

From noreply at sourceforge.net  Sat Sep 20 06:59:56 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 20 07:00:06 2003
Subject: [Python-bugs-list] [ python-Bugs-709491 ]
	sgmllib.SGMLParser.reset() problem
Message-ID: <E1A0fT2-0004HD-00@sc8-sf-web1.sourceforge.net>

Bugs item #709491, was opened at 2003-03-25 16:55
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709491&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chris Gray (cpgray)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib.SGMLParser.reset() problem

Initial Comment:
sgmllib.SGMLParser.reset() doesn't reset

__starttag_text to None



Here's an IDLE session illustrating the problem using

the subclass htmllib.HTMLParser:



Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit

(Intel)] on win32

Type "copyright", "credits" or "license" for more

information.

IDLE 0.8 -- press F1 for help

>>> import formatter

>>> import htmllib

>>> class HTMLP(htmllib.HTMLParser):

	def __init__(self):

		htmllib.HTMLParser.__init__(self,

formatter.NullFormatter())



>>> p = HTMLP()

>>> print p.get_starttag_text()

None

>>> p.feed('<html>')

>>> print p.get_starttag_text()

<html>

>>> p.reset()

>>> print p.get_starttag_text()

<html>



The value for this last call to get_starttag_text()

should be None.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-20 12:59

Message:
Logged In: YES 
user_id=21627

Fixed with said patch for 2.3.1 and 2.4.

----------------------------------------------------------------------

Comment By: Andrew Gaul (gaul)
Date: 2003-08-23 02:35

Message:
Logged In: YES 
user_id=139865

See patch 793559 for a fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709491&group_id=5470

From noreply at sourceforge.net  Sat Sep 20 11:54:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 20 11:54:38 2003
Subject: [Python-bugs-list] [ python-Bugs-682813 ] dircache.listdir doesn't
	signal error
Message-ID: <E1A0k48-0003GV-00@sc8-sf-web4.sourceforge.net>

Bugs item #682813, was opened at 2003-02-08 11:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682813&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: dircache.listdir doesn't signal error

Initial Comment:
dircache.listidir('some_non_existent_directory') simply

returns an empty list.  That's inconsistent with os.listdir

which raises an OSError exception.  I think

dircache.listdir

should also raise an exception if the directory can't

be read.

At minimum, though, the difference should be documented.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-20 17:54

Message:
Logged In: YES 
user_id=21627

Fixed with said patch for 2.4.

----------------------------------------------------------------------

Comment By: Michael Stone (mbrierst)
Date: 2003-03-20 23:16

Message:
Logged In: YES 
user_id=670441

I agree.  I posted patch #707167 to

make it raise the error.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682813&group_id=5470

From noreply at sourceforge.net  Sat Sep 20 13:49:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 20 13:49:42 2003
Subject: [Python-bugs-list] [ python-Bugs-809846 ] distutils/bdistwin32
	doesn't clean up RO files properly
Message-ID: <E1A0lrX-0003OA-00@sc8-sf-web2.sourceforge.net>

Bugs item #809846, was opened at 2003-09-20 11:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809846&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils/bdistwin32 doesn't clean up RO files properly

Initial Comment:
Using Windows XP SP1, Python 2.3, Win32Extensions 

build 159:



I recently added some data_files to my setup script as 

so:



setup( ..., data_files = [ ( 'files', ['file.txt'] ) ] )



and when I ran my setup script with the build 

option 'bdist_wininst', I get the following error at the 

cleanup stage of the build:



removing 'build\bdist.win32\wininst' (and everything 

under it)

error removing build\bdist.win32\wininst: 

build\bdist.win32\wininst\DATA\file.txt: Permission denied



The error is followed by more errors attempting to 

remove the parent directories because they're not 

empty.



The reason permission is denied is because the file is 

marked as read-only (via file attributes, not file 

permissions).  The source file is marked as read-only in 

this case because it is being taken from a Visual 

SourceSafe project which uses the RO attribute to 

indicate check-out status.  If I check out the file or 

remove the RO flag, the script runs without errors.



Regardless of the reason for a file being marked RO, the 

temporary files in wininst\DATA should not be copied 

with their RO attribute or when cleaning up, the routine 

should delete the files regardless of RO status.



I'm not sure what is the best way to approach this 

problem, but I will be willing to provide input or even 

code patches.  I need input from the community, 

however, on how to best fix this issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809846&group_id=5470

From noreply at sourceforge.net  Sun Sep 21 02:01:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 21 02:01:50 2003
Subject: [Python-bugs-list] [ python-Bugs-654783 ] doctest and exception
	messages
Message-ID: <E1A0xI0-0003ii-00@sc8-sf-web4.sourceforge.net>

Bugs item #654783, was opened at 2002-12-16 14:23
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aahz (aahz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: doctest and exception messages

Initial Comment:
doctest should include information something like this:



    doctest docstrings should not rely on the text of internal Python

    exceptions.  Notice the way factorial() uses its own error messages

    with the standard Python exceptions.  The internal messages can

    change even in bugfix releases (as in 2.2.1 to 2.2.2).



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-25 14:08

Message:
Logged In: YES 
user_id=31435

Back to Aahz.  I don't mind if you change this -- edit the docs 

and check it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-12-16 18:39

Message:
Logged In: YES 
user_id=31435

It could, but it shouldn't:  error msgs in docs that don't match 

reality are also an insult to users.  doctest should grow some 

sort of option here, though, as its uses outgrew its original 

purposes.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-12-16 17:01

Message:
Logged In: YES 
user_id=35752

Couldn't doctest be modified so that it only compares the

exception

name only?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470

From noreply at sourceforge.net  Sun Sep 21 14:36:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 21 14:36:26 2003
Subject: [Python-bugs-list] [ python-Bugs-810214 ] exit() raises exception
Message-ID: <E1A194J-0005Bj-00@sc8-sf-web4.sourceforge.net>

Bugs item #810214, was opened at 2003-09-21 20: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=810214&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jozef Behran (jojoworks)
Assigned to: Nobody/Anonymous (nobody)
Summary: exit() raises exception

Initial Comment:
--- BEGIN OF SESSION TRANSCRIPT ---

$ python

Python version: 2.2.2 (#2, Feb 5 2003, 10:40:08)

[GCC 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk)] on linux-i386

Type "help", "copyright", "credits" or "license" for

more information.

>>> <CTRL-D>

$ cat exit.py

exit(1)

$ python exit.py

Traceback (most recent call last):

  File "exit.py", line 1, in ?

    exit(1);

TypeError: 'str' object is not callable

$ cat exitstr.py

exit("Fatal error")

$ python exitstr.py

Traceback (most recent call last):

  File "exitstr.py", line 1, in ?

    exit("Fatal error");

TypeError: 'str' object is not callable

--- END OF SESSION TRANSCRIPT ---



The first "python ..." command shall output nothing and

return 1 as the result. The second "python ..." command

shall output "Fatal error" to stderr and return 1 as

the result. No exception shall be raised there.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810214&group_id=5470

From noreply at sourceforge.net  Sun Sep 21 16:22:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 21 16:22:49 2003
Subject: [Python-bugs-list] [ python-Bugs-808285 ] Bad float->long
	conversion on openbsd/sparc
Message-ID: <E1A1Aj7-0002eH-00@sc8-sf-web3.sourceforge.net>

Bugs item #808285, was opened at 2003-09-17 18:30
Message generated for change (Comment added) made by bescoto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

Category: Python Interpreter Core
Group: 3rd Party
Status: Closed
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad float->long conversion on openbsd/sparc

Initial Comment:
$ uname -srvpm

OpenBSD 3.3 GENERIC#0 sparc64 SUNW,UltraSPARC-IIi @ 333

MHz, version 0 FPU

$ ./python  

Python 2.3 (#1, Sep 17 2003, 21:15:45) 

[GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3

Type "help", "copyright", "credits" or "license" for

more information.

>>> long(1000.0)

0L

>>> long(1000000.0)

00000L

>>> 32767 < long(1000000.0) < 32768

1



----------------------------------------------------------------------

>Comment By: Ben Escoto (bescoto)
Date: 2003-09-21 13:22

Message:
Logged In: YES 
user_id=218965

Yes, you are right, upgrading to GCC 3.2.2 fixes the problem.



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 13:59

Message:
Logged In: YES 
user_id=21627

That depends on the exact way how the compiler is installed.

Ask your system vendor. Reading the manual page might also help.



Closing as third-party.

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 13:22

Message:
Logged In: YES 
user_id=218965

Ahh.  Probably a stupid question, but how do I recompile as

32 bit?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 12:21

Message:
Logged In: YES 
user_id=21627

I see. It is then pretty certain that you are running into a

compiler bug. Sparc64 floating point just does not work

correctly in gcc 2.95.3. Recompiling Python as a 32-bit

application should fix the problem.

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 12:12

Message:
Logged In: YES 
user_id=218965

$ file python

python: ELF 64-bit MSB executable, Sparc64, version 1, for

OpenBSD, dynamically linked (uses shared libs), not stripped



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 12:02

Message:
Logged In: YES 
user_id=21627

What is the output of "file python"?

----------------------------------------------------------------------

Comment By: Ben Escoto (bescoto)
Date: 2003-09-18 11:37

Message:
Logged In: YES 
user_id=218965

Compiler is gcc 2.95.3.  How do I tell if it is a "64-bit

build"?



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 11:07

Message:
Logged In: YES 
user_id=21627

Is this with a 64-bit build? If so, which compiler was used?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808285&group_id=5470

From noreply at sourceforge.net  Sun Sep 21 16:30:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 21 16:30:58 2003
Subject: [Python-bugs-list] [ python-Bugs-810263 ] incorrect "msvc 6.0 not
	found" error
Message-ID: <E1A1Ar9-0000ur-00@sc8-sf-web4.sourceforge.net>

Bugs item #810263, was opened at 2003-09-21 16: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=810263&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect "msvc 6.0 not found" error

Initial Comment:
I am trying to build a program (pylibpcap-0.4, but I

think it doesn't matter which program except for the

fact that it needs to compile a C extension) on Windows

XP (don't laugh, it's better than Windows 98 :-).  I've

installed MS VC 6.0 from CD, and run the vcvars32

script. When I run the setup.py script, I get the message



                   "Python was built with version 0.6

of Visual Studio, "

                   "and extensions need to be built

with the same "

                   "version of the compiler, but it

isn't installed."



from msvccompiler.py.



It is clearly mistaken. When I try Python 2.2, the

compiler is found just fine.



I'd like to see this fixed before 2.3.1 is released.



(I should note that I didn't install any service packs

for the compiler. Maybe the knowledge about registry

entries built into get_msvc_paths() is only correct for

later service packs?  Or for pre-XP? I can't find the

registry key ...\6.0\Build System\, which is looked for

by this function (the part up to and including ...\6.0\

exists); I do notice that the product directory is in

...\6.0\Products\Microsoft Visual C++\ProductDir, which

has the value C:\Program Files\Microsoft Visual

Studio\VC98, and that's where the compiler is installed

(the binaries are in the subdirectory "bin" there).



I do note that the code that raises the error was

installed by a patch that purported to improve VC 7.1

compatibility. Too bad it broke 6.0 compatibility

(especially since that is what we still currently use :-).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810263&group_id=5470

From noreply at sourceforge.net  Sun Sep 21 16:42:48 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 21 16:42:54 2003
Subject: [Python-bugs-list] [ python-Bugs-810214 ] exit() raises exception
Message-ID: <E1A1B2e-0003V8-00@sc8-sf-web3.sourceforge.net>

Bugs item #810214, was opened at 2003-09-21 14:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810214&group_id=5470

Category: None
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jozef Behran (jojoworks)
Assigned to: Nobody/Anonymous (nobody)
Summary: exit() raises exception

Initial Comment:
--- BEGIN OF SESSION TRANSCRIPT ---

$ python

Python version: 2.2.2 (#2, Feb 5 2003, 10:40:08)

[GCC 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk)] on linux-i386

Type "help", "copyright", "credits" or "license" for

more information.

>>> <CTRL-D>

$ cat exit.py

exit(1)

$ python exit.py

Traceback (most recent call last):

  File "exit.py", line 1, in ?

    exit(1);

TypeError: 'str' object is not callable

$ cat exitstr.py

exit("Fatal error")

$ python exitstr.py

Traceback (most recent call last):

  File "exitstr.py", line 1, in ?

    exit("Fatal error");

TypeError: 'str' object is not callable

--- END OF SESSION TRANSCRIPT ---



The first "python ..." command shall output nothing and

return 1 as the result. The second "python ..." command

shall output "Fatal error" to stderr and return 1 as

the result. No exception shall be raised there.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-21 16:42

Message:
Logged In: YES 
user_id=31435

It appears that you want to use the os.exit() function.  If so, 

you must import it from os.  The builtin exit (which you're 

using) is indeed just a string, which displays a message to 

interactive users telling them the correct way to end an 

interpreter session.  This varies across platforms.  For 

example, here under Cygwin:



$ python

Python 2.2.2 (#1, Dec 31 2002, 12:24:34)

[GCC 3.2 20020927 (prerelease)] on cygwin

Type "help", "copyright", "credits" or "license" for more 

information.

>>> exit

'Use Ctrl-D (i.e. EOF) to exit.'

>>>



"'str' object is not callable" is a perfectly appropriate 

exception if you try to (as you are trying to do) *call* a 

string with an argument.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810214&group_id=5470

From noreply at sourceforge.net  Sun Sep 21 16:51:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 21 16:51:20 2003
Subject: [Python-bugs-list] [ python-Bugs-810214 ] exit() raises exception
Message-ID: <E1A1BAn-0005y9-00@sc8-sf-web1.sourceforge.net>

Bugs item #810214, was opened at 2003-09-21 14:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810214&group_id=5470

Category: None
>Group: None
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Jozef Behran (jojoworks)
Assigned to: Nobody/Anonymous (nobody)
Summary: exit() raises exception

Initial Comment:
--- BEGIN OF SESSION TRANSCRIPT ---

$ python

Python version: 2.2.2 (#2, Feb 5 2003, 10:40:08)

[GCC 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk)] on linux-i386

Type "help", "copyright", "credits" or "license" for

more information.

>>> <CTRL-D>

$ cat exit.py

exit(1)

$ python exit.py

Traceback (most recent call last):

  File "exit.py", line 1, in ?

    exit(1);

TypeError: 'str' object is not callable

$ cat exitstr.py

exit("Fatal error")

$ python exitstr.py

Traceback (most recent call last):

  File "exitstr.py", line 1, in ?

    exit("Fatal error");

TypeError: 'str' object is not callable

--- END OF SESSION TRANSCRIPT ---



The first "python ..." command shall output nothing and

return 1 as the result. The second "python ..." command

shall output "Fatal error" to stderr and return 1 as

the result. No exception shall be raised there.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-21 16:51

Message:
Logged In: YES 
user_id=31435

Oops!  Everywhere I wrote "os" read "sys" instead.  The 

sys.exit() function does what you want here.  There is no exit 

function in the os module (although there is a lower-level 

os._exit() function).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-21 16:42

Message:
Logged In: YES 
user_id=31435

It appears that you want to use the os.exit() function.  If so, 

you must import it from os.  The builtin exit (which you're 

using) is indeed just a string, which displays a message to 

interactive users telling them the correct way to end an 

interpreter session.  This varies across platforms.  For 

example, here under Cygwin:



$ python

Python 2.2.2 (#1, Dec 31 2002, 12:24:34)

[GCC 3.2 20020927 (prerelease)] on cygwin

Type "help", "copyright", "credits" or "license" for more 

information.

>>> exit

'Use Ctrl-D (i.e. EOF) to exit.'

>>>



"'str' object is not callable" is a perfectly appropriate 

exception if you try to (as you are trying to do) *call* a 

string with an argument.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810214&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 00:32:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 00:32:35 2003
Subject: [Python-bugs-list] [ python-Bugs-808594 ] leak on lambda with
	duplicate arguments error
Message-ID: <E1A1INB-0002l0-00@sc8-sf-web3.sourceforge.net>

Bugs item #808594, was opened at 2003-09-18 14:43
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808594&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Jeremy Hylton (jhylton)
Summary: leak on lambda with duplicate arguments error

Initial Comment:
There's a leak on compiling code like 'lambda a,a:0'. 

TrackRefs says the following are being leaked:



<type 'list'>                                         

        4       16

<type 'str'>                                          

        2       10

<type 'symtable entry'>                               

        2        8

<type 'dict'>                                         

        2        8

<type 'int'>                                          

        0        2



It doesn't seem to leak for, e.g. 'def f(a,a):pass'.



I had a look at the code, but got very confused, I'm

afraid.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-22 04:32

Message:
Logged In: YES 
user_id=31392

I changed the code, but I think I still see a leak.  At the

interpreter prompt,

f = lambda a,a: None

shows refs growing by one every time.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-19 10:04

Message:
Logged In: YES 
user_id=6656

Well, this was easier to fix than I expected (one line patch

attached, which I'll check in soon).



The mystery has transformed itself into "how the hell did

the code work in the first place?" and "why didn't the

function version leak?".



I think I know the answer to the first one, but I'm not

telling :-) I may go as far as posting it to c.l.py as a

Python Mystery Theatre style poser...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808594&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 00:35:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 00:35:20 2003
Subject: [Python-bugs-list] [ python-Bugs-808594 ] leak on lambda with
	duplicate arguments error
Message-ID: <E1A1IPk-0002qV-00@sc8-sf-web3.sourceforge.net>

Bugs item #808594, was opened at 2003-09-18 14:43
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808594&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Jeremy Hylton (jhylton)
Summary: leak on lambda with duplicate arguments error

Initial Comment:
There's a leak on compiling code like 'lambda a,a:0'. 

TrackRefs says the following are being leaked:



<type 'list'>                                         

        4       16

<type 'str'>                                          

        2       10

<type 'symtable entry'>                               

        2        8

<type 'dict'>                                         

        2        8

<type 'int'>                                          

        0        2



It doesn't seem to leak for, e.g. 'def f(a,a):pass'.



I had a look at the code, but got very confused, I'm

afraid.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-22 04:35

Message:
Logged In: YES 
user_id=31392

But a more careful test shows that totalrefcount doesn't go

up if I compile this code in a loop.  So it looks like it's

fixed.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-22 04:32

Message:
Logged In: YES 
user_id=31392

I changed the code, but I think I still see a leak.  At the

interpreter prompt,

f = lambda a,a: None

shows refs growing by one every time.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-19 10:04

Message:
Logged In: YES 
user_id=6656

Well, this was easier to fix than I expected (one line patch

attached, which I'll check in soon).



The mystery has transformed itself into "how the hell did

the code work in the first place?" and "why didn't the

function version leak?".



I think I know the answer to the first one, but I'm not

telling :-) I may go as far as posting it to c.l.py as a

Python Mystery Theatre style poser...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808594&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 01:26:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 01:26:08 2003
Subject: [Python-bugs-list] [ python-Bugs-810408 ] mkstemp doesn't return
	abspath
Message-ID: <E1A1JD2-00057S-00@sc8-sf-web2.sourceforge.net>

Bugs item #810408, was opened at 2003-09-22 14: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=810408&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: mkstemp doesn't return abspath

Initial Comment:
The document of tempfile.mkstemp says that,

"mkstemp() returns a tuple containing an OS-level 

handle to an open file (as would be returned by 

os.open()) and the absolute pathname of that file, 

in that order."



However, if you specify the directory a relative path,

it doesn't return an absolute pathname.



>>> import tempfile

>>> tempfile.mkstemp()

(5, '/tmp/tmpHBq8rz')

>>> tempfile.mkstemp(dir='.')

(3, './tmpvK7BEr')

>>> tempfile.mkstemp(dir='./test')

(4, './test/tmplB7GZF')



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810408&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 03:03:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 03:03:32 2003
Subject: [Python-bugs-list] [ python-Bugs-810263 ] incorrect "msvc 6.0 not
	found" error
Message-ID: <E1A1KjF-0007Vo-00@sc8-sf-web3.sourceforge.net>

Bugs item #810263, was opened at 2003-09-21 22:30
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810263&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect "msvc 6.0 not found" error

Initial Comment:
I am trying to build a program (pylibpcap-0.4, but I

think it doesn't matter which program except for the

fact that it needs to compile a C extension) on Windows

XP (don't laugh, it's better than Windows 98 :-).  I've

installed MS VC 6.0 from CD, and run the vcvars32

script. When I run the setup.py script, I get the message



                   "Python was built with version 0.6

of Visual Studio, "

                   "and extensions need to be built

with the same "

                   "version of the compiler, but it

isn't installed."



from msvccompiler.py.



It is clearly mistaken. When I try Python 2.2, the

compiler is found just fine.



I'd like to see this fixed before 2.3.1 is released.



(I should note that I didn't install any service packs

for the compiler. Maybe the knowledge about registry

entries built into get_msvc_paths() is only correct for

later service packs?  Or for pre-XP? I can't find the

registry key ...\6.0\Build System\, which is looked for

by this function (the part up to and including ...\6.0\

exists); I do notice that the product directory is in

...\6.0\Products\Microsoft Visual C++\ProductDir, which

has the value C:\Program Files\Microsoft Visual

Studio\VC98, and that's where the compiler is installed

(the binaries are in the subdirectory "bin" there).



I do note that the code that raises the error was

installed by a patch that purported to improve VC 7.1

compatibility. Too bad it broke 6.0 compatibility

(especially since that is what we still currently use :-).

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-09-22 09:03

Message:
Logged In: YES 
user_id=11105

It seems you have to actually *run* MSVC6.0 after the

installation at least once to make it complete the registry

entries. Could that be a problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810263&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 08:01:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 08:01:51 2003
Subject: [Python-bugs-list] [ python-Bugs-808756 ] refleaks in _hotshot.c
Message-ID: <E1A1PNm-00083b-00@sc8-sf-web4.sourceforge.net>

Bugs item #808756, was opened at 2003-09-18 18:01
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: refleaks in _hotshot.c

Initial Comment:
My regrtest patches revealed a few leaks in

Modules/_hotshot.c.



Attached patch seems to fix.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-09-22 12:01

Message:
Logged In: YES 
user_id=4771

Unless I'm mistaken there is a misplaced DECREF.



I'd love to attach my patch but cannot do so. Here it is:

http://arigo.tunes.org/hotshot2.diff



A more general note is about using 'N' in Py_BuildValue. Its

implementation seems to be buggy because it does not always

consume a reference: it won't do so if an error occurs

before it gets there. I guess I'll submit a separate bug

report/patch for this too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 09:28:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 09:29:03 2003
Subject: [Python-bugs-list] [ python-Bugs-808756 ] refleaks in _hotshot.c
Message-ID: <E1A1Qk2-0008Q3-00@sc8-sf-web2.sourceforge.net>

Bugs item #808756, was opened at 2003-09-18 14:01
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: refleaks in _hotshot.c

Initial Comment:
My regrtest patches revealed a few leaks in

Modules/_hotshot.c.



Attached patch seems to fix.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-22 09:28

Message:
Logged In: YES 
user_id=31435

Just attaching Armin's patch (hotshot2.diff).

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-09-22 08:01

Message:
Logged In: YES 
user_id=4771

Unless I'm mistaken there is a misplaced DECREF.



I'd love to attach my patch but cannot do so. Here it is:

http://arigo.tunes.org/hotshot2.diff



A more general note is about using 'N' in Py_BuildValue. Its

implementation seems to be buggy because it does not always

consume a reference: it won't do so if an error occurs

before it gets there. I guess I'll submit a separate bug

report/patch for this too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 10:41:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 10:41:49 2003
Subject: [Python-bugs-list] [ python-Feature Requests-801847 ] Adding
	rsplit() to string and unicode objects.
Message-ID: <E1A1Rsf-0003gU-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #801847, was opened at 2003-09-06 19:52
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Reifschneider (jafo)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Adding rsplit() to string and unicode objects.

Initial Comment:
I'm attaching patches to the library and documentation

for implementing rsplit() on string and unicode

objects.  This works like split(), but working from the

right.



   ./python -c 'print u"foo, bar, baz".rsplit(None, 1)'

   [u'foo, bar,', u'baz']



This was supposed to be against the CVS code, but I've

had a heck of a time getting it checked out -- my

checkout has been hung for half an hour now.



The code patch is against the 2.3 release, the docs

patch is against the CVS.  My checkout got to docs, but

I didn't have the code to a point where I could build

and test it.



Sean

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-09-22 08:10

Message:
Logged In: YES 
user_id=99508

As a comment on the ease with which a programmer can get rsplit 

wrong, note that rhettinger's rsplit implementation is not correct: 

compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). 

 

He forgot to reverse the separator if it's not None. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-11 18:55

Message:
Logged In: YES 
user_id=80475

Guido, do you care to pronounce on this one?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 01:07

Message:
Logged In: YES 
user_id=21627

There is PEP 2, which suggests to write a library PEP for

proposal to extend the library. Now, this probably would be

overkill for a single string method. However, I feel that

there are already too many string methods, so I won't accept

that patch. I'm not rejecting it, either, because I see that

other maintainers might have a different opinion. In short,

you should propose your change to python-dev, finding out

what "a majority" of the maintainers thinks; you might also

propose it on python-list, trying to collect reactions from

users. It would then be good to summarize these discussions

here (instead of carrying them out here).

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2003-09-10 15:40

Message:
Logged In: YES 
user_id=81797

I realize that rsplit() can be implemented, because, well, I

implemented it.



The standard library is there to provide ready-to-use

functionality so that users of python can concentrate on

their program instead of concentrate on re-inventing the

wheel.  find() can be implemented with a short loop, split()

can be implemented with find(), join() can be implemented

with a short loop.    Many things can be implemented with a

little additional effort on the part of the user to develop

or locate the code they're wanting.



These little things can add up quickly and can have quite a

dramatic impact on the programming experience in Python. 

Having to find or implement these functions will cause

distraction from the code at hand, time lost while finding,

implementing, testing, and maintaining the code in question.



One of Python's strengths is a rich standard library.  So,

what are the guidelines for determining when it's rich

enough?  Why is it ok to suggest that users should get

distracted from their code to go implement something else? 

Is there a policy that I'm not aware of that new

functionality should be put in the cookbook instead of the

standard library?  Why is it being ignored that some

programmers would find implementing rsplit() challenging?



I'm not trying to be difficult here, I honestly can't

understand the apparent change from having a rich library to

a "batteries not included" stance.  The response I got from

#python when I mentioned having submitted the patch

indicates to me that other experienced Python developers

expect there to be an rsplit().



So, why is there so much resistance to adding something to

the library?  What are the guidelines for determining if

something should be in the library?



Sean

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-10 14:35

Message:
Logged In: YES 
user_id=80475

I would classify this more as a technique than a fundamental 

string operation implemented by all stringlike objects 

(including UserString).  Accordingly, I recommend that the 

patch be closed and a recipe posted in the ASPN cookbook - 

something along the lines of:



>>> def rsplit(s, sep=None, maxsplit=-1):

...     return  [chunk[::-1] for chunk in s[::-1].split(sep, 

maxsplit)[::-1]]



>>> rsplit(u"foo, bar, baz", None, 1)

[u'foo, bar,', u'baz']

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2003-09-10 14:15

Message:
Logged In: YES 
user_id=81797

os.path.basename/os.path.dirname is an example of where you

could use rsplit. One of the other #python folks said he had

recently wanted rsplit for an application where he was

getting the domain name and user part from a list of e-mail

addresses, but found that some entries contained an "@" in

the user part.



Sean

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 12:08

Message:
Logged In: YES 
user_id=21627

I questioned the usefulness because I could not think of a

meaningful application. Now I see what a potential

application could be, but I doubt its generality, because

that approach would break if there could be two fields that

have commas in them.



I also disagree that symmetry can motivate usefulness: I

also doubt that all of the r* functions are useful, but they

cannot be removed for backwards compatibility. The fact that

rsplit would fit together with the other r* functions

indicates that adding rsplit would provide symmetry, not

that it would provide usefulness.

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2003-09-07 19:56

Message:
Logged In: YES 
user_id=81797

Can you provide more details about why the usefulness of

this function is in question?



First I would like to tell you the story of it coming to be,

then I will answer your incomplete question with a

(probably) incomplete answer.  I had a device which sent me

comma-separated fields, but one of the fields in the middle

could contain a comma.  The answer that seemed obvious to me

was to use split with a maxsplit to get the fields up to

that field, and then a rsplit with a maxsplit on the

remainder.  When I mentioned on #python that I was

implementing rsplit, 4 other fellow python users replied

right away that they had been wanting it.



To answer your question, it's useful because people using

strings are used to having r*() functions like rfind and

rstrip.  The lack of rsplit is kind of glaring in this

context.  Really, though, it's useful because otherwise

people have to implement -- often badly.



Sean

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-07 14:49

Message:
Logged In: YES 
user_id=21627

Why is this function useful?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 13:05:03 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 13:05:14 2003
Subject: [Python-bugs-list] [ python-Bugs-810714 ] nested variables in
	'class:' statements
Message-ID: <E1A1U7T-0003dt-00@sc8-sf-web3.sourceforge.net>

Bugs item #810714, was opened at 2003-09-22 17:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&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: nested variables in 'class:' statements

Initial Comment:
from the user's point of view, variables originating

from nested scopes could erratically become bound in

the 'class' statement.



The 'class:' statements works by capturing all locals()

after executing the body; however, this is not exactly

the same as what an explicit call to locals() would

return because of the missing PyFrame_FastToLocals()

call in the implementation of LOAD_LOCALS in ceval.c.

It was thought that PyFrame_FastToLocals() was

unnecessary at that point because the class body

bytecode only uses LOAD_NAME/STORE_NAME and not fast

locals -- but this is no longer true with nested

scopes. See attached examples.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 14:17:42 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 14:17:51 2003
Subject: [Python-bugs-list] [ python-Feature Requests-801847 ] Adding
	rsplit() to string and unicode objects.
Message-ID: <E1A1VFm-00015g-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #801847, was opened at 2003-09-06 19:52
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470

>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 4
Submitted By: Sean Reifschneider (jafo)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Adding rsplit() to string and unicode objects.

Initial Comment:
I'm attaching patches to the library and documentation

for implementing rsplit() on string and unicode

objects.  This works like split(), but working from the

right.



   ./python -c 'print u"foo, bar, baz".rsplit(None, 1)'

   [u'foo, bar,', u'baz']



This was supposed to be against the CVS code, but I've

had a heck of a time getting it checked out -- my

checkout has been hung for half an hour now.



The code patch is against the 2.3 release, the docs

patch is against the CVS.  My checkout got to docs, but

I didn't have the code to a point where I could build

and test it.



Sean

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 13:17

Message:
Logged In: YES 
user_id=80475

I'll review your patch when I get a chance.

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-09-22 08:10

Message:
Logged In: YES 
user_id=99508

As a comment on the ease with which a programmer can get rsplit 

wrong, note that rhettinger's rsplit implementation is not correct: 

compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). 

 

He forgot to reverse the separator if it's not None. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-11 18:55

Message:
Logged In: YES 
user_id=80475

Guido, do you care to pronounce on this one?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 01:07

Message:
Logged In: YES 
user_id=21627

There is PEP 2, which suggests to write a library PEP for

proposal to extend the library. Now, this probably would be

overkill for a single string method. However, I feel that

there are already too many string methods, so I won't accept

that patch. I'm not rejecting it, either, because I see that

other maintainers might have a different opinion. In short,

you should propose your change to python-dev, finding out

what "a majority" of the maintainers thinks; you might also

propose it on python-list, trying to collect reactions from

users. It would then be good to summarize these discussions

here (instead of carrying them out here).

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2003-09-10 15:40

Message:
Logged In: YES 
user_id=81797

I realize that rsplit() can be implemented, because, well, I

implemented it.



The standard library is there to provide ready-to-use

functionality so that users of python can concentrate on

their program instead of concentrate on re-inventing the

wheel.  find() can be implemented with a short loop, split()

can be implemented with find(), join() can be implemented

with a short loop.    Many things can be implemented with a

little additional effort on the part of the user to develop

or locate the code they're wanting.



These little things can add up quickly and can have quite a

dramatic impact on the programming experience in Python. 

Having to find or implement these functions will cause

distraction from the code at hand, time lost while finding,

implementing, testing, and maintaining the code in question.



One of Python's strengths is a rich standard library.  So,

what are the guidelines for determining when it's rich

enough?  Why is it ok to suggest that users should get

distracted from their code to go implement something else? 

Is there a policy that I'm not aware of that new

functionality should be put in the cookbook instead of the

standard library?  Why is it being ignored that some

programmers would find implementing rsplit() challenging?



I'm not trying to be difficult here, I honestly can't

understand the apparent change from having a rich library to

a "batteries not included" stance.  The response I got from

#python when I mentioned having submitted the patch

indicates to me that other experienced Python developers

expect there to be an rsplit().



So, why is there so much resistance to adding something to

the library?  What are the guidelines for determining if

something should be in the library?



Sean

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-10 14:35

Message:
Logged In: YES 
user_id=80475

I would classify this more as a technique than a fundamental 

string operation implemented by all stringlike objects 

(including UserString).  Accordingly, I recommend that the 

patch be closed and a recipe posted in the ASPN cookbook - 

something along the lines of:



>>> def rsplit(s, sep=None, maxsplit=-1):

...     return  [chunk[::-1] for chunk in s[::-1].split(sep, 

maxsplit)[::-1]]



>>> rsplit(u"foo, bar, baz", None, 1)

[u'foo, bar,', u'baz']

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2003-09-10 14:15

Message:
Logged In: YES 
user_id=81797

os.path.basename/os.path.dirname is an example of where you

could use rsplit. One of the other #python folks said he had

recently wanted rsplit for an application where he was

getting the domain name and user part from a list of e-mail

addresses, but found that some entries contained an "@" in

the user part.



Sean

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 12:08

Message:
Logged In: YES 
user_id=21627

I questioned the usefulness because I could not think of a

meaningful application. Now I see what a potential

application could be, but I doubt its generality, because

that approach would break if there could be two fields that

have commas in them.



I also disagree that symmetry can motivate usefulness: I

also doubt that all of the r* functions are useful, but they

cannot be removed for backwards compatibility. The fact that

rsplit would fit together with the other r* functions

indicates that adding rsplit would provide symmetry, not

that it would provide usefulness.

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2003-09-07 19:56

Message:
Logged In: YES 
user_id=81797

Can you provide more details about why the usefulness of

this function is in question?



First I would like to tell you the story of it coming to be,

then I will answer your incomplete question with a

(probably) incomplete answer.  I had a device which sent me

comma-separated fields, but one of the fields in the middle

could contain a comma.  The answer that seemed obvious to me

was to use split with a maxsplit to get the fields up to

that field, and then a rsplit with a maxsplit on the

remainder.  When I mentioned on #python that I was

implementing rsplit, 4 other fellow python users replied

right away that they had been wanting it.



To answer your question, it's useful because people using

strings are used to having r*() functions like rfind and

rstrip.  The lack of rsplit is kind of glaring in this

context.  Really, though, it's useful because otherwise

people have to implement -- often badly.



Sean

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-07 14:49

Message:
Logged In: YES 
user_id=21627

Why is this function useful?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 14:56:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 14:56:10 2003
Subject: [Python-bugs-list] [ python-Bugs-807314 ] Crash if getvar of a
	non-existent Tcl variable
Message-ID: <E1A1Vqr-0002qs-00@sc8-sf-web1.sourceforge.net>

Bugs item #807314, was opened at 2003-09-16 18:27
Message generated for change (Comment added) made by david_ascher
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807314&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: David Ascher (david_ascher)
>Assigned to: Martin v. L?wis (loewis)
Summary: Crash if getvar of a non-existent Tcl variable

Initial Comment:
In 2.3, the code:



    from Tkinter import *

    x = Tk()

    x.getvar('foobar')



will crash.  This is due to bad error checking in 

_tkinter.c, in the GetVar() code.



A possible patch is attached.



Making p7 because it's a crasher. 

----------------------------------------------------------------------

>Comment By: David Ascher (david_ascher)
Date: 2003-09-22 18:56

Message:
Logged In: YES 
user_id=6114

Sorry, I'm afraid I'll have no time to apply before 2.3.1. -- if 

you do, please apply it.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 18:01

Message:
Logged In: YES 
user_id=21627

The patch is fine; please apply (or reassign if you want me

to apply it).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807314&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 14:57:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 14:57:16 2003
Subject: [Python-bugs-list] [ python-Bugs-472568 ] PyBuffer_New() memory not
	aligned
Message-ID: <E1A1Vrz-0002ux-00@sc8-sf-web1.sourceforge.net>

Bugs item #472568, was opened at 2001-10-18 21:31
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=472568&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyBuffer_New() memory not aligned

Initial Comment:
Memory buffer areas created by PyBuffer_New are

missaligned on 32 bit machines, for doubles (64 bit).



This typically generates a bus error crash on most RISC

machines when a library function tries to write a

double in a memory buffer allocated by PyBuffer_New().



When looking at the bufferobject.c code, this seems to

come from the fact that  the memory buffer points at

'malloc() + sizeof  struct PyBufferObject'; 	[line:

b->b_ptr = (void *)(b + 1); ]



To the extent that struct PyBufferObject is not a

multiple of sizeof (double), the largest value type;

thus the misalignment, and the crashes on most RISC

processors.



A quick and temporary solution would consist in adding

a dummy double field as the last field of the

PyBufferObject structure:



struct PyBufferObject {

...

double dummy; 

} ;



and setting

b->b_ptr = (void*)&b->dummy;  /*was (void*(b+1)*/



In doing so, b->b_ptr will always by aligned on sizeof

(double), on either 32 and 64 bit architectures.





Since I'm on the buffer type problem: It would be nice

(and probably easy to do) to augment the buffer

protocol interface with the ability to specify the

basic value type stored in the buffer.



A possible list of values (enum ...) would be:



- undefined (backward compatibility)

- char, unsigned char, short, ....int, ... long, long

long, float, double, and void* (memory address).



This would enable to check at runtime the type of

values stored in a buffer (and prevent missalignement

buserrors, as well as catching garbage situations when

improper array types are passed by means of the buffer

interface [e.g.: int/float/double/short...).



Frederic Giacometti





Frederic Giacometti











----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-09-22 18:57

Message:
Logged In: YES 
user_id=4771

No more activity around here. I suggest to deprecate this

bug report. Here is a note for the docs saying the memory

PyBuffer_New() gets you isn't specifically aligned. (cannot

attach it, sorry)

http://arigo.tunes.org/api_concrete.diff



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-17 15:30

Message:
Logged In: YES 
user_id=31435

Unassigned -- I don't expect to work on this.

----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-11-01 17:21

Message:
Logged In: YES 
user_id=93657

The solution Tim proposes (2d malloc) will be very fine with

what we do.



Here are some more details on what we're doing (and this is

a standard operation):



- We want to create an array of double that we pass to a C

function, and then return this array to Python as buffer

object (the buffer is passed latter on as arg to other

functions using the buffer interface); and do it so that

Python takes ownership of the buffer memory management.



- We don't want to require Numerical to operate the package;

just for memory allocation.



- We should actually be using the Python array module

interface.

Unfortunately:

  * the Python array object C definitions are not exported

in a .h file

  * the Array python interface does not provide the ability

to create a new array of an arbitrary size (and certainly

initialized to 0). One has to provide a list or a string to

create an array of a given size.  IThis is not workable if

we work we large arrays (e.g.: an array of 1.000.000 doubles

is only 8 MB RAM ...).



Another  solution, then, would consist in extending the

array Python interface, so as to enable the creation of

arrays of arbitrary sizes (prefereably initialized to 0 or

to something alse with a calloc or a memset).



The extension of the array.array() function could be the

better solution, taking into account our needs as well as

Tim's concerns.



FG

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-01 01:31

Message:
Logged In: YES 
user_id=31435

The only portable way to fix this (assuming it's broken -- 

I don't see any alignment promises in the docs, and since 

we never use it we can't mine the source code for clues 

either) is to have PyBuffer_New do a second separate malloc

(size) and set b_ptr to that.  The C std guarantees memory 

returned by malloc is suitably aligned for all purposes; it 

doesn't promise that any standard type captures the 

strictest alignment requirement (indeed, at KSR we returned 

128-byte aligned memory from malloc, to cater to 

our "subpage" type extension).

----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-11-01 00:31

Message:
Logged In: YES 
user_id=93657

A portable solution (im[provement over what I proposed)

would consitst in declaring 'dummy' with a union type,

'unionizing' all C-ANSI value types (and including 'long

long' optionally by mean of an #ifdef).



 { .... union { int Int; long Long; double Double; void*

Pvoid ...} dummy; }



All (void*)obj->dummy can be replaced with obj->dummy.Pvoid



FG



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-10-22 20:19

Message:
Logged In: YES 
user_id=31392

Note to whomever take this bug: PyBuffer_New() is not called

anywhere in the Python source tree; nor are there any tests

for buffer objects that I'm aware of.  A few simple test

cases would have caught this bug already.  (And for the case

of the builtin buffer() call, it might be good if it used

PyBuffer_New().)



----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-10-18 21:35

Message:
Logged In: YES 
user_id=93657

I wasn't looged in when I submitted the item. Don't think

I'm becoming anonymous :))



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=472568&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 15:07:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 15:07:29 2003
Subject: [Python-bugs-list] [ python-Bugs-794140 ] cygwin builds do not embed
Message-ID: <E1A1W1r-0003Jw-00@sc8-sf-web1.sourceforge.net>

Bugs item #794140, was opened at 2003-08-24 09:18
Message generated for change (Comment added) made by jdsumsion
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794140&group_id=5470

Category: Build
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alejandro Lopez-Valencia (dradul)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin builds do not embed

Initial Comment:
As an example case, try to build a copy of vim with an 

embeded python interpreter:



"""

indow.o   objects/if_python.o objects/py_config.o     

objects/netbeans.o  object

s/version.o       -lncurses   -liconv -lintl   -

L/usr/lib/python2.3/config -lpyt

hon2.3 -lutil -lm

objects/py_config.o(.data+0x4):config.c: referencia a 

`_initthread' sin definir

objects/py_config.o(.data+0xc):config.c: referencia a 

`_initsignal' sin definir

objects/py_config.o(.data+0x14):config.c: referencia a 

`_initposix' sin definir

objects/py_config.o(.data+0x1c):config.c: referencia a 

`_initerrno' sin definir

objects/py_config.o(.data+0x24):config.c: referencia a 

`_init_sre' sin definir

objects/py_config.o(.data+0x2c):config.c: referencia a 

`_init_codecs' sin defini

r

"""



As you can see, it doesn't embed. 



I have tracked down the failure to a problem in the 

LDSHARED defaults provided by configure.in. The default 

supplied is:



LDSHARED="gcc -shared -Wl,--enable-auto-image-

base";;



but this *does not* work. As per Cygwin documentation 

on the creation of DLLs, this works (already tested 

compiling vim under the same conditions):



LDSHARED="gcc -shared -Wl,--enable-auto-image-base -

Wl,--export-all-symbols -Wl,--enable-auto-import";;



As a side note, please notice that this problem, proper 

user of GNU ld flags under win32, has a direct impact on 

the possible success of a true Mingw32 port (which I 

expect eagerly).



----------------------------------------------------------------------

Comment By: John Sumsion (jdsumsion)
Date: 2003-09-22 13:07

Message:
Logged In: YES 
user_id=867854

I'm a newbie at building O/S software, but at least I figured 

this one out (running Cygwin 1.5.5-1 on XP Pro).  Thanks to 

Jason who provided the embed2 patch and helped me 

understand this more fully.



Running on cygwin, if you get the python package (2.3-2), 

follow these steps to get an updated libpython2.3.dll.a 

(and .dll):



cd /usr/src/python-2.3-2

patch -p0 < embed2.diff (attached to this issue, don't use 

embed.diff or pyport.h.diff)

./configure

make

make install (only if you want to install these files)



Now look in the current directory for the .dll.a and the .dll.  I 

was able to build vim 6.2.98 (src also from cygwin dist) with 

an embedded python interpreter with the resulting files (I 

copied the .dll.a to /usr/lib/python2.3/config and the .dll 

to /usr/bin).

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 06:01

Message:
Logged In: YES 
user_id=86216

> python import vim; vim.current.line = vim.current.line.upper

()



The above example works fine with embed2.diff applied.



I tested (builing Python) under Red Hat Linux 8.0 too.



Commited as:

Include/pyport.h 2.63

Modules/gcmodule.c 2.72

Python/import.c 2.223

Python/marshal.c 1.75

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 05:51

Message:
Logged In: YES 
user_id=86216

I should have mentioned that the patch assumes Python's

builtin modules are only written in C (not C++). If this

assumption is incorrect, then I will add the standard

__cplusplus/extern "C" idiom.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 05:37

Message:
Logged In: YES 
user_id=86216

Combined the original two patches into one and refreshed

against current CVS.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-09-02 14:11

Message:
Logged In: YES 
user_id=86216

Please try again with the second patch applied too.  The

combination of them seem to work for me.



> I have tested it against the release23-maint CVS branch,

>and unfortunately it doesn't work.. 



BTW, it would have been helpful it you indicated that the

first patch eliminated all but 3 link errors.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 09:31

Message:
Logged In: YES 
user_id=86216

What do you get when you execute the following?



$ objdump -p libpython2.3.dll | fgrep '] init'



Are you building vim against the newly built Python?

----------------------------------------------------------------------

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 09:13

Message:
Logged In: YES 
user_id=659006

I have tested it against the release23-maint CVS branch, and

unfortunately it doesn't work.. 



*Sigh* I mentioned the autotools because I didn't see the

patch at first (the wonders of top posting, who designed

this bug-tracker?). But now... I think we need an export

symbols definition file... :-(



----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 08:12

Message:
Logged In: YES 
user_id=86216

> Yes, I am willing to test it.



Thanks. Are you willing to build against Python CVS? Or,

do you need me to provide you with replacements for

libpython2.3.dll.a and libpython2.3.dll?



> Yet... Don't you think you are complicating the issue, the

> autotool files and your life, too much?



I don't think so. Note that my approach does not affect

any autotools files.



> There are no obvious security issues involved and...



IIRC, exporting all symbols under Win32 can cause

multiple definition link errors.



> Anyway, it's your ballgame, it's your call.



I appreciate your willingness to acquiesce.

----------------------------------------------------------------------

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 07:06

Message:
Logged In: YES 
user_id=659006

Yes, I am willing to test it.



Yet... Don't you think you are complicating the issue, the

autotool files and your life, too much? There are no obvious

security issues involved and the procedure only adds extra

text to the DATA segment in the DLLs, there are no changes

in the actual object code; it won't become a hybrid

DLL/implib such as cygwin1.dll! Take any Unix shared library

(Linux, Solaris, BSD, whatever), and it is already exporting

*all symbols*, how else would you be able to link to them?

There are no import libs, that's a Windows/MacOS Classic

abomination as far as I am concerned :-)



Anyway, it's your ballgame, it's your call.



Cheers



----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-08-26 07:46

Message:
Logged In: YES 
user_id=86216

I would prefer to just export the missing symbols than

all of them which is unnecessary and possibly problematic.



The attached patch (against Python CVS) exports the

following additionally symbols:



$ objdump -p libpython2.3.dll | fgrep '] init'

        [ 794] init_codecs

        [ 795] init_sre

        [ 796] init_symtable

        [ 797] initerrno

        [ 798] initposix

        [ 799] initsignal

        [ 800] initthread

        [ 801] initxxsubtype

        [ 802] initzipimport



Does the above meet your needs? Are you willing to test

your vim build against it?

----------------------------------------------------------------------

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 05:05

Message:
Logged In: YES 
user_id=659006

Opps!



Sorry, my link fell down in the middle of submitting the form. 

----------------------------------------------------------------------

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 05:00

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).



Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.



On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:



1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()



And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.



Cheers.



----------------------------------------------------------------------

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 04:57

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).



Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.



On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:



1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()



And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.



Cheers.



----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-08-25 12:32

Message:
Logged In: YES 
user_id=86216

AFAICT, changing LDSHARED will affect building extensions

too. So, I am very hesitant to change its definition without

fully understanding the ramifications. Note that Cygwin

Python extensions have been working for almost three

years now. Additionally, I WAG that there are many more

people building extensions than embedding.



> LDSHARED="gcc -shared -Wl,--enable-auto-image-base

> -Wl,--export-all-symbols -Wl,--enable-auto-import";;



I can understand why adding "-Wl,--export-all-symbols"

fixes the above link errors. However, I don't understand

why "-Wl,--enable-auto-import" would help. IIRC, it

defaults to enabled anyway. Does vim with an 

embeded python interpreter build without this option?



Can you provide me a small embedded example so I

can do some testing? Using vim seems a bit unwieldy.



> As a side note, please notice that this problem, proper 

> user of GNU ld flags under win32, has a direct impact on 

> the possible success of a true Mingw32 port (which I 

> expect eagerly).



Huh? How is this related to the report Cygwin problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794140&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 15:16:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 15:16:20 2003
Subject: [Python-bugs-list] [ python-Bugs-810714 ] nested variables in
	'class:' statements
Message-ID: <E1A1WAS-000666-00@sc8-sf-web4.sourceforge.net>

Bugs item #810714, was opened at 2003-09-22 12:05
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&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: nested variables in 'class:' statements

Initial Comment:
from the user's point of view, variables originating

from nested scopes could erratically become bound in

the 'class' statement.



The 'class:' statements works by capturing all locals()

after executing the body; however, this is not exactly

the same as what an explicit call to locals() would

return because of the missing PyFrame_FastToLocals()

call in the implementation of LOAD_LOCALS in ceval.c.

It was thought that PyFrame_FastToLocals() was

unnecessary at that point because the class body

bytecode only uses LOAD_NAME/STORE_NAME and not fast

locals -- but this is no longer true with nested

scopes. See attached examples.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 14:16

Message:
Logged In: YES 
user_id=80475

Do you have a proposed patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 15:24:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 15:24:47 2003
Subject: [Python-bugs-list] [ python-Bugs-807771 ] Max and min are incorrect
	with one argument
Message-ID: <E1A1WIY-0006XX-00@sc8-sf-web4.sourceforge.net>

Bugs item #807771, was opened at 2003-09-17 06:49
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807771&group_id=5470

Category: Python Library
Group: Python 2.2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Max and min are incorrect with one argument

Initial Comment:
max(1)

raises 'TypeError: iteration over non-sequence',

when it should simply return 1



Min has the same problem.



If there is one person in a room, and you ask for the

tallest person, there is a well-defined answer.

The tallest person is the only person.

So is the shortest person.



I ran across this when I was doing

apply(max, list) / apply(min, list)

to find out the ratio of maximum to minimum entries

in a list.    With a single-element list, I expected

it to return 1, instead of raising an exception.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 14:24

Message:
Logged In: YES 
user_id=80475

That behavior is consequence of interpreting a single 

argument as an input sequence while interpreting multiple 

arguments as the sequence itself.



Given a single argument, Python could make some 

reasonable guesses:  max(3) --> 3  and max((3,4)) --> 4, 

but guessing is not the Pythonic way.  Also, I think max(x) 

tends to be an error condition when x is not iterable, so it 

would be unwise to simply return x and let the error pass 

silently.



If it makes you feels better, you *are* the tallest, smartest, 

and richest OP for this bug report ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807771&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 16:38:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 16:38:29 2003
Subject: [Python-bugs-list] [ python-Bugs-755080 ] AssertionError from
	urllib.retrieve / httplib
Message-ID: <E1A1XRr-0007Hc-00@sc8-sf-web2.sourceforge.net>

Bugs item #755080, was opened at 2003-06-15 19:37
Message generated for change (Comment added) made by jmoses
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: Jon Moses (jmoses)
Date: 2003-09-22 15:38

Message:
Logged In: YES 
user_id=55110

I also experience this problem, and it's repeatable.  When

trying to talk with CrossRef (www.crossref.com) server, I

get this same error.  I don't know why.  All the crossref

server does is spit back text.  It normally takes between 10

and 20 seconds to recieve all the data.  I've successfully

viewed the results with mozilla, and with wget.



I'd post the URL i'm hitting, but it's a for-pay service. 

This is the code I'm using:



...

( name, headers ) = urllib.urlretrieve( url )

...



While attempting to recieve this data, I tried doing a:



...

u = urllib.urlopen( url )

for line in u.readlines():

  print line

...



but program execution seemed to continue while the data was

being received, which is not cool.  I'm not sure if that's

expected behaviour or not.



Let me know if I can provide you with any more information.



-jon



----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-24 07: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-16 14: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-15 19: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 at sourceforge.net  Mon Sep 22 17:58:21 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 17:58:25 2003
Subject: [Python-bugs-list] [ python-Bugs-810843 ] Support for non-string
	data in ConfigParser unclear/buggy
Message-ID: <E1A1YhJ-0002fL-00@sc8-sf-web2.sourceforge.net>

Bugs item #810843, was opened at 2003-09-22 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=810843&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: curby (kirbysdl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for non-string data in ConfigParser unclear/buggy

Initial Comment:
In my current project, I'm using ConfigParser to read

configuration files as well as manage internal

configuration.  The following test script generates an

error because values of options must be strings in

order for ConfigParser to run smoothly.  (It's short

enough that I'm including it here for reference; I'm

also attaching it).



#----- BEGIN TEST -----

#!/usr/bin/env python



import ConfigParser

import sys



conf = ConfigParser.ConfigParser()

conf.add_section("sect")

conf.set("sect","option",2)

conf.write(sys.stderr)

conf.get("sect","option")

#----- END TEST -----



>From the ConfigParser code, I see that the value isn't

checked to make sure it is a string before string

methods are applied to it.



I'm currently using the raw parameter to get() (see

http://www.python.org/doc/lib/ConfigParser-objects.html#l2h-1261)

in order to circumvent the problem.



I'd suggest one or more of the following:

(1) Casting the option to a string explicitly instead

of assuming it is a string (this could also be done in

the set() method).

(2) Checking that the option is a string instead of

assuming it is a string.

(3) Stating in the documentation that the set() method

should only take values of type string.

(4) Stating in the documentation that the raw parameter

should be used when an option's value might not be of

type string (this might be the intended usage, but it

isn't made clear).



I hope none of these are too difficult to implement,

but I understand that this is a noncritical problem. 

Nonetheless, I was shocked to see what I thought was a

straightforward use of ConfigParser throw off errors.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810843&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 19:21:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 19:21:21 2003
Subject: [Python-bugs-list] [ python-Bugs-810879 ] shutil.copyfile fails
	when dst exists read-only
Message-ID: <E1A1ZzW-00008Q-00@sc8-sf-web4.sourceforge.net>

Bugs item #810879, was opened at 2003-09-22 19: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=810879&group_id=5470

Category: Windows
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Tim Peters (tim_one)
Summary: shutil.copyfile fails when dst exists read-only

Initial Comment:
(WIN32):  shutil.copyfile fails when the dst file already 

exists, but in read-only mode.  As the old file is

about to be

clobbered, a fix I've been using is to delete the

orginal file

first.   The attached my be inelegant, but works fine







----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810879&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 19:37:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 19:37:11 2003
Subject: [Python-bugs-list] [ python-Bugs-810887 ] os.stat returning a time
	= -1
Message-ID: <E1A1aEt-0004wG-00@sc8-sf-web3.sourceforge.net>

Bugs item #810887, was opened at 2003-09-22 19: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=810887&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat returning a time = -1

Initial Comment:
(WIN32)  copystat's call to os.stat sometimes returns a

time

value = -1, on which the following call to os.utime

bombs.  

A temporary work-around is attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810887&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 19:37:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 19:37:16 2003
Subject: [Python-bugs-list] [ python-Bugs-810883 ] os.stat returning a time
	= -1
Message-ID: <E1A1aEu-0000lY-00@sc8-sf-web4.sourceforge.net>

Bugs item #810883, was opened at 2003-09-22 19: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=810883&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat returning a time = -1

Initial Comment:
(WIN32)  copystat's call to os.stat sometimes returns a

time

value = -1, on which the following call to os.utime

bombs.  

A temporary work-around is attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810883&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 19:37:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 19:37:19 2003
Subject: [Python-bugs-list] [ python-Bugs-810885 ] os.stat returning a time
	= -1
Message-ID: <E1A1aEu-0006Nd-00@sc8-sf-web2.sourceforge.net>

Bugs item #810885, was opened at 2003-09-22 19: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=810885&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat returning a time = -1

Initial Comment:
(WIN32)  copystat's call to os.stat sometimes returns a

time

value = -1, on which the following call to os.utime

bombs.  

A temporary work-around is attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810885&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 22:57:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 22:57:42 2003
Subject: [Python-bugs-list] [ python-Bugs-810263 ] incorrect "msvc 6.0 not
	found" error
Message-ID: <E1A1dMv-0003wp-00@sc8-sf-web2.sourceforge.net>

Bugs item #810263, was opened at 2003-09-21 15:30
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810263&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect "msvc 6.0 not found" error

Initial Comment:
I am trying to build a program (pylibpcap-0.4, but I

think it doesn't matter which program except for the

fact that it needs to compile a C extension) on Windows

XP (don't laugh, it's better than Windows 98 :-).  I've

installed MS VC 6.0 from CD, and run the vcvars32

script. When I run the setup.py script, I get the message



                   "Python was built with version 0.6

of Visual Studio, "

                   "and extensions need to be built

with the same "

                   "version of the compiler, but it

isn't installed."



from msvccompiler.py.



It is clearly mistaken. When I try Python 2.2, the

compiler is found just fine.



I'd like to see this fixed before 2.3.1 is released.



(I should note that I didn't install any service packs

for the compiler. Maybe the knowledge about registry

entries built into get_msvc_paths() is only correct for

later service packs?  Or for pre-XP? I can't find the

registry key ...\6.0\Build System\, which is looked for

by this function (the part up to and including ...\6.0\

exists); I do notice that the product directory is in

...\6.0\Products\Microsoft Visual C++\ProductDir, which

has the value C:\Program Files\Microsoft Visual

Studio\VC98, and that's where the compiler is installed

(the binaries are in the subdirectory "bin" there).



I do note that the code that raises the error was

installed by a patch that purported to improve VC 7.1

compatibility. Too bad it broke 6.0 compatibility

(especially since that is what we still currently use :-).

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-09-22 21:57

Message:
Logged In: YES 
user_id=699438

I'm running stock XP and VS6.0 and couldn't reproduce this 

error.  (And yes, XP is better than 98)

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-09-22 02:03

Message:
Logged In: YES 
user_id=11105

It seems you have to actually *run* MSVC6.0 after the

installation at least once to make it complete the registry

entries. Could that be a problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810263&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 23:01:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 23:01:12 2003
Subject: [Python-bugs-list] [ python-Bugs-810263 ] incorrect "msvc 6.0 not
	found" error
Message-ID: <E1A1dQK-0002mZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #810263, was opened at 2003-09-21 15:30
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810263&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect "msvc 6.0 not found" error

Initial Comment:
I am trying to build a program (pylibpcap-0.4, but I

think it doesn't matter which program except for the

fact that it needs to compile a C extension) on Windows

XP (don't laugh, it's better than Windows 98 :-).  I've

installed MS VC 6.0 from CD, and run the vcvars32

script. When I run the setup.py script, I get the message



                   "Python was built with version 0.6

of Visual Studio, "

                   "and extensions need to be built

with the same "

                   "version of the compiler, but it

isn't installed."



from msvccompiler.py.



It is clearly mistaken. When I try Python 2.2, the

compiler is found just fine.



I'd like to see this fixed before 2.3.1 is released.



(I should note that I didn't install any service packs

for the compiler. Maybe the knowledge about registry

entries built into get_msvc_paths() is only correct for

later service packs?  Or for pre-XP? I can't find the

registry key ...\6.0\Build System\, which is looked for

by this function (the part up to and including ...\6.0\

exists); I do notice that the product directory is in

...\6.0\Products\Microsoft Visual C++\ProductDir, which

has the value C:\Program Files\Microsoft Visual

Studio\VC98, and that's where the compiler is installed

(the binaries are in the subdirectory "bin" there).



I do note that the code that raises the error was

installed by a patch that purported to improve VC 7.1

compatibility. Too bad it broke 6.0 compatibility

(especially since that is what we still currently use :-).

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-09-22 22:01

Message:
Logged In: YES 
user_id=699438

Also noticed this pending patch that looks applicable:



http://sourceforge.net/tracker/index.php?

func=detail&aid=780821&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-09-22 21:57

Message:
Logged In: YES 
user_id=699438

I'm running stock XP and VS6.0 and couldn't reproduce this 

error.  (And yes, XP is better than 98)

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-09-22 02:03

Message:
Logged In: YES 
user_id=11105

It seems you have to actually *run* MSVC6.0 after the

installation at least once to make it complete the registry

entries. Could that be a problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810263&group_id=5470

From noreply at sourceforge.net  Mon Sep 22 23:09:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 22 23:09:26 2003
Subject: [Python-bugs-list] [ python-Bugs-755080 ] AssertionError from
	urllib.retrieve / httplib
Message-ID: <E1A1dYF-00035k-00@sc8-sf-web3.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-09-23 03:09

Message:
Logged In: YES 
user_id=31392

jmoses: Are you seeing this problem with Python 2.3?  I

thought we had fixed the problem in the original report.



Also, I'm not sure what you mean by program execution

continuing.  Do you mean that the for loop finished and the

rest of the program continued executing, even though there

was data left to read?  



What would probably help most is a trace of the session with

httplib's set_debuglevel() enabled.  If that's got sensitive

data, you can email it to me privately.



----------------------------------------------------------------------

Comment By: Jon Moses (jmoses)
Date: 2003-09-22 20:38

Message:
Logged In: YES 
user_id=55110

I also experience this problem, and it's repeatable.  When

trying to talk with CrossRef (www.crossref.com) server, I

get this same error.  I don't know why.  All the crossref

server does is spit back text.  It normally takes between 10

and 20 seconds to recieve all the data.  I've successfully

viewed the results with mozilla, and with wget.



I'd post the URL i'm hitting, but it's a for-pay service. 

This is the code I'm using:



...

( name, headers ) = urllib.urlretrieve( url )

...



While attempting to recieve this data, I tried doing a:



...

u = urllib.urlopen( url )

for line in u.readlines():

  print line

...



but program execution seemed to continue while the data was

being received, which is not cool.  I'm not sure if that's

expected behaviour or not.



Let me know if I can provide you with any more information.



-jon



----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-24 12: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-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 at sourceforge.net  Tue Sep 23 03:50:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 03:50:31 2003
Subject: [Python-bugs-list] [ python-Bugs-811028 ] 2.3.1 configure bug
Message-ID: <E1A1hwK-0004G0-00@sc8-sf-web3.sourceforge.net>

Bugs item #811028, was opened at 2003-09-23 17: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=811028&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.1 configure bug

Initial Comment:
Anthony said to log this:



checking ncurses.h presence... yes

configure: WARNING: ncurses.h: present but cannot be 

compiled

configure: WARNING: ncurses.h: check for missing 

prerequisite headers?

configure: WARNING: ncurses.h: proceeding with the 

preprocessor's result

configure: WARNING:     ## 

------------------------------------ ##

configure: WARNING:     ## Report this to bug-

autoconf@gnu.org. ##

configure: WARNING:     ## 

------------------------------------ ##



I'll attach the text of the report and the configure output 

too since I'm pretty sure the above won't be ligible once 

sf's tracker's finished with it.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 03:55:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 03:55:34 2003
Subject: [Python-bugs-list] [ python-Bugs-811031 ] 2.3.1 compile warnings on
	OSX
Message-ID: <E1A1i1D-0004WJ-00@sc8-sf-web3.sourceforge.net>

Bugs item #811031, was opened at 2003-09-23 17: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=811031&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.1 compile warnings on OSX

Initial Comment:
During build, every compile on OSX produces:



cc1: warning: changing search order for system directory 

"/usr/local/include"

cc1: warning:   as it has already been specified as a non-

system directory



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811031&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 04:14:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 04:14:26 2003
Subject: [Python-bugs-list] [ python-Bugs-811028 ] 2.3.1 configure bug
Message-ID: <E1A1iJH-0007yb-00@sc8-sf-web4.sourceforge.net>

Bugs item #811028, was opened at 2003-09-23 17:50
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.1 configure bug

Initial Comment:
Anthony said to log this:



checking ncurses.h presence... yes

configure: WARNING: ncurses.h: present but cannot be 

compiled

configure: WARNING: ncurses.h: check for missing 

prerequisite headers?

configure: WARNING: ncurses.h: proceeding with the 

preprocessor's result

configure: WARNING:     ## 

------------------------------------ ##

configure: WARNING:     ## Report this to bug-

autoconf@gnu.org. ##

configure: WARNING:     ## 

------------------------------------ ##



I'll attach the text of the report and the configure output 

too since I'm pretty sure the above won't be ligible once 

sf's tracker's finished with it.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 18:14

Message:
Logged In: YES 
user_id=29957

creosote (which is a freebsd machine) also sees this.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 04:28:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 04:28:15 2003
Subject: [Python-bugs-list] [ python-Bugs-811028 ] 2.3.1 configure bug
Message-ID: <E1A1iWl-0000sT-00@sc8-sf-web1.sourceforge.net>

Bugs item #811028, was opened at 2003-09-23 17:50
Message generated for change (Comment added) made by richard
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.1 configure bug

Initial Comment:
Anthony said to log this:



checking ncurses.h presence... yes

configure: WARNING: ncurses.h: present but cannot be 

compiled

configure: WARNING: ncurses.h: check for missing 

prerequisite headers?

configure: WARNING: ncurses.h: proceeding with the 

preprocessor's result

configure: WARNING:     ## 

------------------------------------ ##

configure: WARNING:     ## Report this to bug-

autoconf@gnu.org. ##

configure: WARNING:     ## 

------------------------------------ ##



I'll attach the text of the report and the configure output 

too since I'm pretty sure the above won't be ligible once 

sf's tracker's finished with it.



----------------------------------------------------------------------

>Comment By: Richard Jones (richard)
Date: 2003-09-23 18:28

Message:
Logged In: YES 
user_id=6405

"make test" also reports:



test_curses

test test_curses crashed -- _curses.error: curs_set() returned 

ERR



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 18:14

Message:
Logged In: YES 
user_id=29957

creosote (which is a freebsd machine) also sees this.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 05:52:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 05:52:33 2003
Subject: [Python-bugs-list] [ python-Bugs-811031 ] 2.3.1 compile warnings on
	OSX
Message-ID: <E1A1jqL-0004CL-00@sc8-sf-web4.sourceforge.net>

Bugs item #811031, was opened at 2003-09-23 08:55
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811031&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.1 compile warnings on OSX

Initial Comment:
During build, every compile on OSX produces:



cc1: warning: changing search order for system directory 

"/usr/local/include"

cc1: warning:   as it has already been specified as a non-

system directory



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-09-23 10:52

Message:
Logged In: YES 
user_id=6656

Yeah, we know.  Ignore it, it's a gcc (3.1 only, I think)

bogosity and will be gone soon.



There was discussion (both on python-dev and in the tracker,

IIRC) about this if you care enough to dig it up.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811031&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 06:00:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 06:04:08 2003
Subject: [Python-bugs-list] [ python-Bugs-811070 ] Py2.2.3: Problem with
	Expat/XML/Zope on MacOSX 10.2.8
Message-ID: <E1A1jxw-000272-00@sc8-sf-web3.sourceforge.net>

Bugs item #811070, was opened at 2003-09-23 06: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=811070&group_id=5470

Category: XML
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py2.2.3: Problem with Expat/XML/Zope on MacOSX 10.2.8

Initial Comment:
Trying to run Python 2.2.3 under MacOSX with Zope fails:



Python has been built against the latest Expat Sources

(1.96.6)



Traceback (most recent call last):

  File

"/Users/ajung/sandboxes/plone1.1/Zope/lib/python/Zope/Startup/run.py",

line 14, in ?

    run()

  File

"/Users/ajung/sandboxes/plone1.1/Zope/lib/python/Zope/Startup/run.py",

line 8, in run

    opts.realize()

  File

"/Users/ajung/sandboxes/plone1.1/Zope/lib/python/zdaemon/zdoptions.py",

line 257, in realize

    self.load_schema()

  File

"/Users/ajung/sandboxes/plone1.1/Zope/lib/python/zdaemon/zdoptions.py",

line 298, in load_schema

    self.schema = ZConfig.loadSchema(self.schemafile)

  File

"/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/loader.py",

line 36, in loadSchema

    return SchemaLoader().loadURL(url)

  File

"/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/loader.py",

line 70, in loadURL

    return self.loadResource(r)

  File

"/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/loader.py",

line 134, in loadResource

    self.registry, self)

  File

"/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/schema.py",

line 42, in parseResource

    xml.sax.parse(resource.file, parser)

  File

"/opt/python-2.2.3/lib/python2.2/site-packages/_xmlplus/sax/__init__.py",

line 31, in parse

    parser.parse(filename_or_stream)

  File

"/opt/python-2.2.3/lib/python2.2/site-packages/_xmlplus/sax/expatreader.py",

line 106, in parse

    self.reset()

  File

"/opt/python-2.2.3/lib/python2.2/site-packages/_xmlplus/sax/expatreader.py",

line 261, in reset

    self._parser = expat.ParserCreate(intern =

self._interning)

TypeError: 'intern' is an invalid keyword argument for

this function



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811070&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 06:31:09 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 06:31:12 2003
Subject: [Python-bugs-list] [ python-Bugs-811082 ] test_tempfile fails on
	windows if space in install path
Message-ID: <E1A1kRp-0005eK-00@sc8-sf-web4.sourceforge.net>

Bugs item #811082, was opened at 2003-09-23 20: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=811082&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_tempfile fails on windows if space in install path

Initial Comment:
test_tempfile fails for me on XP when Python is

installed into

\Program Files\Python2.3



I can't cut'n'paste from the window, but the error is

C:\Program: Can't open file 'Files\Python23\python.exe'

from test_tempfile, line 299.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 06:36:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 06:36:48 2003
Subject: [Python-bugs-list] [ python-Bugs-811082 ] test_tempfile fails on
	windows if space in install path
Message-ID: <E1A1kXD-0005zN-00@sc8-sf-web4.sourceforge.net>

Bugs item #811082, was opened at 2003-09-23 20:31
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_tempfile fails on windows if space in install path

Initial Comment:
test_tempfile fails for me on XP when Python is

installed into

\Program Files\Python2.3



I can't cut'n'paste from the window, but the error is

C:\Program: Can't open file 'Files\Python23\python.exe'

from test_tempfile, line 299.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 20:36

Message:
Logged In: YES 
user_id=29957

test_popen seems to have the same problem. 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 06:44:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 06:44:45 2003
Subject: [Python-bugs-list] [ python-Bugs-811082 ] test_tempfile fails on
	windows if space in install path
Message-ID: <E1A1keu-0006fw-00@sc8-sf-web1.sourceforge.net>

Bugs item #811082, was opened at 2003-09-23 20:31
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_tempfile fails on windows if space in install path

Initial Comment:
test_tempfile fails for me on XP when Python is

installed into

\Program Files\Python2.3



I can't cut'n'paste from the window, but the error is

C:\Program: Can't open file 'Files\Python23\python.exe'

from test_tempfile, line 299.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 20:44

Message:
Logged In: YES 
user_id=29957

Attempting the obvious fix of " " quoting sys.executable

gives me a Invalid argument error from os.spawnv, so that's

my windows knowledge exhausted. 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 20:36

Message:
Logged In: YES 
user_id=29957

test_popen seems to have the same problem. 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 07:01:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 07:01:21 2003
Subject: [Python-bugs-list] [ python-Bugs-810887 ] os.stat returning a time
	= -1
Message-ID: <E1A1kuy-00074T-00@sc8-sf-web4.sourceforge.net>

Bugs item #810887, was opened at 2003-09-23 09:37
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810887&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat returning a time = -1

Initial Comment:
(WIN32)  copystat's call to os.stat sometimes returns a

time

value = -1, on which the following call to os.utime

bombs.  

A temporary work-around is attached.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 21:01

Message:
Logged In: YES 
user_id=29957

There's no file attached! You have to upload the file and

check the  little box.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810887&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 07:01:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 07:01:50 2003
Subject: [Python-bugs-list] [ python-Bugs-810883 ] os.stat returning a time
	= -1
Message-ID: <E1A1kvR-00054o-00@sc8-sf-web2.sourceforge.net>

Bugs item #810883, was opened at 2003-09-23 09:35
Message generated for change (Settings changed) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810883&group_id=5470

Category: Python Library
Group: Python 2.2.3
>Status: Deleted
>Resolution: Duplicate
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat returning a time = -1

Initial Comment:
(WIN32)  copystat's call to os.stat sometimes returns a

time

value = -1, on which the following call to os.utime

bombs.  

A temporary work-around is attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810883&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 07:02:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 07:02:09 2003
Subject: [Python-bugs-list] [ python-Bugs-810885 ] os.stat returning a time
	= -1
Message-ID: <E1A1kvn-00078b-00@sc8-sf-web4.sourceforge.net>

Bugs item #810885, was opened at 2003-09-23 09:35
Message generated for change (Settings changed) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810885&group_id=5470

Category: Python Library
Group: Python 2.2.3
>Status: Deleted
>Resolution: Duplicate
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat returning a time = -1

Initial Comment:
(WIN32)  copystat's call to os.stat sometimes returns a

time

value = -1, on which the following call to os.utime

bombs.  

A temporary work-around is attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810885&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 07:03:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 07:03:23 2003
Subject: [Python-bugs-list] [ python-Bugs-810408 ] mkstemp doesn't return
	abspath
Message-ID: <E1A1kwk-0004tp-00@sc8-sf-web3.sourceforge.net>

Bugs item #810408, was opened at 2003-09-22 15:26
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810408&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: mkstemp doesn't return abspath

Initial Comment:
The document of tempfile.mkstemp says that,

"mkstemp() returns a tuple containing an OS-level 

handle to an open file (as would be returned by 

os.open()) and the absolute pathname of that file, 

in that order."



However, if you specify the directory a relative path,

it doesn't return an absolute pathname.



>>> import tempfile

>>> tempfile.mkstemp()

(5, '/tmp/tmpHBq8rz')

>>> tempfile.mkstemp(dir='.')

(3, './tmpvK7BEr')

>>> tempfile.mkstemp(dir='./test')

(4, './test/tmplB7GZF')



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 21:03

Message:
Logged In: YES 
user_id=29957

Anyone got an opinion on this one? Should the docs be fixed,

or the code?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810408&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 07:34:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 07:34:21 2003
Subject: [Python-bugs-list] [ python-Bugs-810408 ] mkstemp doesn't return
	abspath
Message-ID: <E1A1lQr-0000SB-00@sc8-sf-web1.sourceforge.net>

Bugs item #810408, was opened at 2003-09-22 14:26
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810408&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: mkstemp doesn't return abspath

Initial Comment:
The document of tempfile.mkstemp says that,

"mkstemp() returns a tuple containing an OS-level 

handle to an open file (as would be returned by 

os.open()) and the absolute pathname of that file, 

in that order."



However, if you specify the directory a relative path,

it doesn't return an absolute pathname.



>>> import tempfile

>>> tempfile.mkstemp()

(5, '/tmp/tmpHBq8rz')

>>> tempfile.mkstemp(dir='.')

(3, './tmpvK7BEr')

>>> tempfile.mkstemp(dir='./test')

(4, './test/tmplB7GZF')



----------------------------------------------------------------------

>Comment By: George Yoshida (quiver)
Date: 2003-09-23 20:34

Message:
Logged In: YES 
user_id=671362

Michael has submitted a patch to return absolute 

pathname.



http://www.python.org/sf/810914

fix for mkstemp with relative paths (bug #810408)



His fix looks good to me.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 20:03

Message:
Logged In: YES 
user_id=29957

Anyone got an opinion on this one? Should the docs be fixed,

or the code?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810408&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 07:52:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 07:53:03 2003
Subject: [Python-bugs-list] [ python-Bugs-755080 ] AssertionError from
	urllib.retrieve / httplib
Message-ID: <E1A1lix-0001F6-00@sc8-sf-web1.sourceforge.net>

Bugs item #755080, was opened at 2003-06-15 19:37
Message generated for change (Comment added) made by jmoses
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: Jon Moses (jmoses)
Date: 2003-09-23 06:52

Message:
Logged In: YES 
user_id=55110

Whups, my bad, I just assumed (and we know what happens

then) that this was for python 2.2, since that's what I was

having the problem with.  My next step was to try with

Python 2.3.  I'll let you know if it works (since it sounds

like it should).



And yes, that's what I meant.  Data from the http read was

still being outputted to the screen, while other output from

_past_ where the read was occuring was also being output. 

I'd end up with output like this:



[data from http read]

[data from after]

[data from http read]



and the data was from the same connection.



Hopefully the switch to 2.3 makes my issues moot.  Thanks

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-22 22:09

Message:
Logged In: YES 
user_id=31392

jmoses: Are you seeing this problem with Python 2.3?  I

thought we had fixed the problem in the original report.



Also, I'm not sure what you mean by program execution

continuing.  Do you mean that the for loop finished and the

rest of the program continued executing, even though there

was data left to read?  



What would probably help most is a trace of the session with

httplib's set_debuglevel() enabled.  If that's got sensitive

data, you can email it to me privately.



----------------------------------------------------------------------

Comment By: Jon Moses (jmoses)
Date: 2003-09-22 15:38

Message:
Logged In: YES 
user_id=55110

I also experience this problem, and it's repeatable.  When

trying to talk with CrossRef (www.crossref.com) server, I

get this same error.  I don't know why.  All the crossref

server does is spit back text.  It normally takes between 10

and 20 seconds to recieve all the data.  I've successfully

viewed the results with mozilla, and with wget.



I'd post the URL i'm hitting, but it's a for-pay service. 

This is the code I'm using:



...

( name, headers ) = urllib.urlretrieve( url )

...



While attempting to recieve this data, I tried doing a:



...

u = urllib.urlopen( url )

for line in u.readlines():

  print line

...



but program execution seemed to continue while the data was

being received, which is not cool.  I'm not sure if that's

expected behaviour or not.



Let me know if I can provide you with any more information.



-jon



----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-24 07: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-16 14: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-15 19: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 at sourceforge.net  Tue Sep 23 08:15:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 08:15:54 2003
Subject: [Python-bugs-list] [ python-Bugs-811111 ] testdrive hp-ux/pa results
Message-ID: <E1A1m54-0008Gx-00@sc8-sf-web3.sourceforge.net>

Bugs item #811111, was opened at 2003-09-23 13: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=811111&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: testdrive hp-ux/pa results

Initial Comment:
You asked:



205 tests OK.

12 tests failed:

    test_calendar test_datetime test_email test_imaplib

test_pty

    test_pwd test_random test_socket test_strftime

test_strptime

    test_tempfile test_time

38 tests skipped:

    test_aepack test_al test_bsddb test_bsddb185

test_bsddb3 test_bz2

    test_cd test_cl test_curses test_dl

test_email_codecs test_gdbm

    test_gl test_gzip test_hotshot test_imgfile

test_linuxaudiodev

    test_locale test_macfs test_macostools test_mpz

test_nis

    test_normalization test_ossaudiodev test_pep277

test_plistlib

    test_scriptpackages test_socket_ssl test_socketserver

    test_sunaudiodev test_timeout test_unicode_file

test_urllibnet

    test_winreg test_winsound test_zipfile

test_zipimport test_zlib

5 skips unexpected on hp-ux11:

    test_zipimport test_hotshot test_bz2

test_email_codecs test_mpz

gmake: *** [test] Error 1



I doubt much of this is new since 2.3.0...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811111&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 08:35:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 08:35:54 2003
Subject: [Python-bugs-list] [ python-Bugs-755080 ] AssertionError from
	urllib.retrieve / httplib
Message-ID: <E1A1mOJ-000102-00@sc8-sf-web2.sourceforge.net>

Bugs item #755080, was opened at 2003-06-15 19:37
Message generated for change (Comment added) made by jmoses
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: Jon Moses (jmoses)
Date: 2003-09-23 07:35

Message:
Logged In: YES 
user_id=55110

I switched from using urllib.urlretrieve / urllib.urlopen to

using httplib, since I can debug with it.  I no longer get

the error this bug is about.



The other problem I seemed to be having was related to the

data I was recieving, which was generated in part from the

data I was passing to the server.  I changed the data I was

sending (changed ' ' to '%20') and ever thing works fine. 

Even using urllib.urlopen().  Sorry for the confusion.



The data that the server was sending back to the broken

request was outputted like this, using

httplib.http.set_debuglevel(1):



------start

Getting: doi.crossref.org

connect: (doi.crossref.org, 80)

send: 'GET

/servlet/query?usr=<deleted>&pwd=<deleted>&qdata=|Canadian

Journal of Fisheries and Aquatic

Sciences|Adkison|52||2762||full_text|1|<snip> HTTP/1.0\r\n\r\n'

reply: '\n'



|Canadian



-----------end



I don't know if that helps, but maybe.



Thanks much.

----------------------------------------------------------------------

Comment By: Jon Moses (jmoses)
Date: 2003-09-23 06:52

Message:
Logged In: YES 
user_id=55110

Whups, my bad, I just assumed (and we know what happens

then) that this was for python 2.2, since that's what I was

having the problem with.  My next step was to try with

Python 2.3.  I'll let you know if it works (since it sounds

like it should).



And yes, that's what I meant.  Data from the http read was

still being outputted to the screen, while other output from

_past_ where the read was occuring was also being output. 

I'd end up with output like this:



[data from http read]

[data from after]

[data from http read]



and the data was from the same connection.



Hopefully the switch to 2.3 makes my issues moot.  Thanks

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-22 22:09

Message:
Logged In: YES 
user_id=31392

jmoses: Are you seeing this problem with Python 2.3?  I

thought we had fixed the problem in the original report.



Also, I'm not sure what you mean by program execution

continuing.  Do you mean that the for loop finished and the

rest of the program continued executing, even though there

was data left to read?  



What would probably help most is a trace of the session with

httplib's set_debuglevel() enabled.  If that's got sensitive

data, you can email it to me privately.



----------------------------------------------------------------------

Comment By: Jon Moses (jmoses)
Date: 2003-09-22 15:38

Message:
Logged In: YES 
user_id=55110

I also experience this problem, and it's repeatable.  When

trying to talk with CrossRef (www.crossref.com) server, I

get this same error.  I don't know why.  All the crossref

server does is spit back text.  It normally takes between 10

and 20 seconds to recieve all the data.  I've successfully

viewed the results with mozilla, and with wget.



I'd post the URL i'm hitting, but it's a for-pay service. 

This is the code I'm using:



...

( name, headers ) = urllib.urlretrieve( url )

...



While attempting to recieve this data, I tried doing a:



...

u = urllib.urlopen( url )

for line in u.readlines():

  print line

...



but program execution seemed to continue while the data was

being received, which is not cool.  I'm not sure if that's

expected behaviour or not.



Let me know if I can provide you with any more information.



-jon



----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-06-24 07: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-16 14: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-15 19: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 at sourceforge.net  Tue Sep 23 09:47:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 09:47:52 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A1nVr-0007Fz-00@sc8-sf-web1.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 23: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=811160&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 09:56:41 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 09:57:53 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A1nej-0007M4-00@sc8-sf-web4.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 23:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:56

Message:
Logged In: YES 
user_id=29957

the functions that fail (erroneously) are

HAVE_CLOCK HAVE_GETTIMEOFDAY HAVE_MKTIME HAVE_SELECT

HAVE_STRFTIME HAVE_STRPTIME HAVE_UTIMES





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 09:58:49 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 09:59:11 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A1ngn-0004v6-00@sc8-sf-web3.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 23:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:58

Message:
Logged In: YES 
user_id=29957

Oh, and the problem also occurs if you use gcc instead of cc -Ae





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:56

Message:
Logged In: YES 
user_id=29957

the functions that fail (erroneously) are

HAVE_CLOCK HAVE_GETTIMEOFDAY HAVE_MKTIME HAVE_SELECT

HAVE_STRFTIME HAVE_STRPTIME HAVE_UTIMES





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 10:26:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 10:26:22 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A1o7L-0006NB-00@sc8-sf-web3.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 23:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-24 00:26

Message:
Logged In: YES 
user_id=29957

mwh points out that the snakefarm is having the same problem:

http://www.lysator.liu.se/xenofarm/python/files/792_10/python-testlog.txt

(we discovered and debugged this on one of the

DEC^WDigital^WCompaq^WHP "testdrive" boxes)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:58

Message:
Logged In: YES 
user_id=29957

Oh, and the problem also occurs if you use gcc instead of cc -Ae





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:56

Message:
Logged In: YES 
user_id=29957

the functions that fail (erroneously) are

HAVE_CLOCK HAVE_GETTIMEOFDAY HAVE_MKTIME HAVE_SELECT

HAVE_STRFTIME HAVE_STRPTIME HAVE_UTIMES





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 10:44:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 10:44:58 2003
Subject: [Python-bugs-list] [ python-Bugs-811111 ] testdrive hp-ux/pa results
Message-ID: <E1A1oPL-0008Uk-00@sc8-sf-web2.sourceforge.net>

Bugs item #811111, was opened at 2003-09-23 22:15
Message generated for change (Settings changed) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811111&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: testdrive hp-ux/pa results

Initial Comment:
You asked:



205 tests OK.

12 tests failed:

    test_calendar test_datetime test_email test_imaplib

test_pty

    test_pwd test_random test_socket test_strftime

test_strptime

    test_tempfile test_time

38 tests skipped:

    test_aepack test_al test_bsddb test_bsddb185

test_bsddb3 test_bz2

    test_cd test_cl test_curses test_dl

test_email_codecs test_gdbm

    test_gl test_gzip test_hotshot test_imgfile

test_linuxaudiodev

    test_locale test_macfs test_macostools test_mpz

test_nis

    test_normalization test_ossaudiodev test_pep277

test_plistlib

    test_scriptpackages test_socket_ssl test_socketserver

    test_sunaudiodev test_timeout test_unicode_file

test_urllibnet

    test_winreg test_winsound test_zipfile

test_zipimport test_zlib

5 skips unexpected on hp-ux11:

    test_zipimport test_hotshot test_bz2

test_email_codecs test_mpz

gmake: *** [test] Error 1



I doubt much of this is new since 2.3.0...

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-24 00:44

Message:
Logged In: YES 
user_id=29957

Subsumed into bug 811160. Rejecting this bug because at the

current time, rejecting anything to do with HP/UX feels good ;)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811111&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 11:09:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 11:09:25 2003
Subject: [Python-bugs-list] [ python-Bugs-810263 ] incorrect "msvc 6.0 not
	found" error
Message-ID: <E1A1omy-0008VI-00@sc8-sf-web3.sourceforge.net>

Bugs item #810263, was opened at 2003-09-21 16:30
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810263&group_id=5470

Category: Distutils
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
>Priority: 1
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect "msvc 6.0 not found" error

Initial Comment:
I am trying to build a program (pylibpcap-0.4, but I

think it doesn't matter which program except for the

fact that it needs to compile a C extension) on Windows

XP (don't laugh, it's better than Windows 98 :-).  I've

installed MS VC 6.0 from CD, and run the vcvars32

script. When I run the setup.py script, I get the message



                   "Python was built with version 0.6

of Visual Studio, "

                   "and extensions need to be built

with the same "

                   "version of the compiler, but it

isn't installed."



from msvccompiler.py.



It is clearly mistaken. When I try Python 2.2, the

compiler is found just fine.



I'd like to see this fixed before 2.3.1 is released.



(I should note that I didn't install any service packs

for the compiler. Maybe the knowledge about registry

entries built into get_msvc_paths() is only correct for

later service packs?  Or for pre-XP? I can't find the

registry key ...\6.0\Build System\, which is looked for

by this function (the part up to and including ...\6.0\

exists); I do notice that the product directory is in

...\6.0\Products\Microsoft Visual C++\ProductDir, which

has the value C:\Program Files\Microsoft Visual

Studio\VC98, and that's where the compiler is installed

(the binaries are in the subdirectory "bin" there).



I do note that the code that raises the error was

installed by a patch that purported to improve VC 7.1

compatibility. Too bad it broke 6.0 compatibility

(especially since that is what we still currently use :-).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-09-23 11:09

Message:
Logged In: YES 
user_id=6380

Ouch. Running VC 6.0 does indeed seem to have added the

missing registry entries to my system. I'm guessing this is

a documentation issue at best, and will withdraw the bug report.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-09-22 23:01

Message:
Logged In: YES 
user_id=699438

Also noticed this pending patch that looks applicable:



http://sourceforge.net/tracker/index.php?

func=detail&aid=780821&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-09-22 22:57

Message:
Logged In: YES 
user_id=699438

I'm running stock XP and VS6.0 and couldn't reproduce this 

error.  (And yes, XP is better than 98)

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-09-22 03:03

Message:
Logged In: YES 
user_id=11105

It seems you have to actually *run* MSVC6.0 after the

installation at least once to make it complete the registry

entries. Could that be a problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810263&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 13:23:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 13:23:42 2003
Subject: [Python-bugs-list] [ python-Bugs-811294 ] dis.disassemble_string()
	broken
Message-ID: <E1A1qt1-0000Op-00@sc8-sf-web2.sourceforge.net>

Bugs item #811294, was opened at 2003-09-23 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=811294&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: dis.disassemble_string() broken

Initial Comment:
dis.disassemble_string(), called by

dis.dis("some-bytecode-string"), still relies on the

dead SET_LINENO opcode.



I'll propose a patch for this at some later time.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 13:23:49 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 13:23:51 2003
Subject: [Python-bugs-list] [ python-Bugs-811295 ] ntohs on Solaris can
	return negative values
Message-ID: <E1A1qtB-0002Xt-00@sc8-sf-web1.sourceforge.net>

Bugs item #811295, was opened at 2003-09-23 13:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811295&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: ntohs on Solaris can return negative values

Initial Comment:
On Solaris, socket.ntohs() can return a negative number

when the argument has bit 15 set. This is not according

to spec or intention or expectation. The bug is because

on Solaris, ntohs() is defined as a macro that returns

its argument unchanged, roughly:



  #define ntohs(x) (x)



The socket extension casts the argument to (short); it

should use (unsigned short) or something similar.



Here's a program showing the problem (run this on

Solaris, or on another big-endian machine where ntohs()

is defined away):



import socket

print socket.ntohs(-1)



This should print 65535 but prints -1.



(Credit to Andrew Davis for finding this!)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811295&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 13:26:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 13:26:55 2003
Subject: [Python-bugs-list] [ python-Bugs-811295 ] ntohs on Solaris can
	return negative values
Message-ID: <E1A1qw8-0002j9-00@sc8-sf-web1.sourceforge.net>

Bugs item #811295, was opened at 2003-09-23 13:23
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811295&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: ntohs on Solaris can return negative values

Initial Comment:
On Solaris, socket.ntohs() can return a negative number

when the argument has bit 15 set. This is not according

to spec or intention or expectation. The bug is because

on Solaris, ntohs() is defined as a macro that returns

its argument unchanged, roughly:



  #define ntohs(x) (x)



The socket extension casts the argument to (short); it

should use (unsigned short) or something similar.



Here's a program showing the problem (run this on

Solaris, or on another big-endian machine where ntohs()

is defined away):



import socket

print socket.ntohs(-1)



This should print 65535 but prints -1.



(Credit to Andrew Davis for finding this!)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-09-23 13:26

Message:
Logged In: YES 
user_id=6380

Of course, htons has the same problem.  The 'l' versions are

unaffected.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811295&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 16:12:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 16:12:24 2003
Subject: [Python-bugs-list] [ python-Bugs-809599 ] tex to html convert bug
Message-ID: <E1A1tWB-00006F-00@sc8-sf-web2.sourceforge.net>

Bugs item #809599, was opened at 2003-09-19 22:13
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809599&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tex to html convert bug

Initial Comment:
At the section "22. MS Windows Specific Services" in 

Python Library Reference, there're strange 

characters in the middle of the sentence.



http://www.python.org/dev/doc/devel/lib/node735.ht

ml

> msvcrt  Miscellaneous useful routines from the

> MS VC++<#67760#><#67760#> runtime 

You can see strange tags, "<#67760#>" after the 

word, "VC++".



In Python 2.2, it looks just fine.

http://www.python.org/doc/2.2.2/lib/node611.html

> msvcrt  Miscellaneous useful routines from the

> MS VC++ runtime. 



It looks like this problem is caused by Fred's last 

commit to libmsvcrt.tex(Jul 2 2003).

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-23 16:12

Message:
Logged In: YES 
user_id=3066

I was just about to post a report on this myself when I saw

this.



The ugly <#67760#> junk is a representation of syntactical

curly braces used internally in LaTeX2HTML; these should be

be produced in the final output.  I'm pretty sure I know

what needs to be done to fix this, but won't be able to get

to it in time for Python 2.3.1.  This will be fixed for

Python 2.3.2 and 2.4.



Assigned to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809599&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 16:15:54 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 16:15:59 2003
Subject: [Python-bugs-list] [ python-Bugs-805788 ] Minor Python Intro update
Message-ID: <E1A1tZi-0000Kn-00@sc8-sf-web2.sourceforge.net>

Bugs item #805788, was opened at 2003-09-13 18:40
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805788&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor Python Intro update

Initial Comment:
The little source code on the following web page 

demonstrates outdated patterns:



http://python.org/doc/Introduction.html



def invert(table):

    index = {}                # empty dictionary

    for key in table.keys():

        value = table[key]

        if not index.has_key(value):

            index[value] = [] # empty list

        index[value].append(key)

    return index



Perhaps the following would be cleaner:



def invert(table):

    index = {}                # empty dictionary

    for key in table: #"for key, value in table.iteritems():"?

        value = table[key]

        if value not in index:

            index[value] = [] # empty list

        index[value].append(key)

    return index





----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-23 16:15

Message:
Logged In: YES 
user_id=3066

Martin's right; there's no clear reason to make the

suggested change.  Closing the report.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 14:15

Message:
Logged In: YES 
user_id=21627

I fail to see the problem. The code is not outdated, it

continues to work just fine. As for clarity, I find explicit

usage of .keys() and .has_key() clearer than with your

proposed change. Explicit is better than implicit.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805788&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 16:27:47 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 16:27:59 2003
Subject: [Python-bugs-list] [ python-Bugs-725265 ] urlopen object's read()
	doesn't read to EOF
Message-ID: <E1A1tlD-0000S8-00@sc8-sf-web3.sourceforge.net>

Bugs item #725265, was opened at 2003-04-21 16:49
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725265&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Smith (smichr)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: urlopen object's read() doesn't read to EOF

Initial Comment:
On http://python.org/doc/current/lib/module-urllib.html it says that 

the object returned by urlopen supports the read()method and that 

this and other methods "have the same interface as for file objects 

-- see section 2.2.8".  In that section on page 

http://python.org/doc/current/lib/bltin-file-objects.html it says about 

the read() method that "if the size argument is negative or omitted, 

[read should] read all data until EOF is reached."



I was a bit surprised when a project that students of mine were 

working on were failing when they tried to process the data 

obtained by the read() method on a connection made to a web 

page.  The problem, apparently, is that the read may not obtain all 

of the data requested in the first request and the total response 

has to be built up someting like follows:



import urllib

c=urllib.urlopen("http://www.blakeschool.org")

data = ''

while 1:

	packet=c.read()

	if packet == '': break

	data+=packet

	

I'm not sure if this is a feature or a bug.  Could a file's read method 

fail to obtain the whole file in one read(), too?  It seems that either 

the documentation should be changed or the read() method for at 

least urllib objects should be changed.



/c



Christopher P. Smith

The Blake School

Minneapolis, MN



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725265&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 18:00:24 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 18:00:51 2003
Subject: [Python-bugs-list] [ python-Bugs-653542 ]
	PyLong_AsVoidPtr()/PyLong_FromVoidPtr()
Message-ID: <E1A1vCq-0004lT-00@sc8-sf-web3.sourceforge.net>

Bugs item #653542, was opened at 2002-12-13 20:02
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Tim Peters (tim_one)
Summary: PyLong_AsVoidPtr()/PyLong_FromVoidPtr()

Initial Comment:
These two functions have mutually-recursive definitions 

in the docs (which is to say, none).

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-23 18:00

Message:
Logged In: YES 
user_id=3066

Tim, aren't these your babies?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-12-14 11:15

Message:
Logged In: YES 
user_id=21627

Something very simple:



PyObject *

PyLong_FromVoidPtr(void *p)

{

#if SIZEOF_VOID_P <= SIZEOF_LONG

	return PyInt_FromLong((long)p);

#else



#ifndef HAVE_LONG_LONG

#   error "PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), 

but no long long"

#endif

#if SIZEOF_LONG_LONG < SIZEOF_VOID_P

#   error "PyLong_FromVoidPtr: sizeof(LONG_LONG) < sizeof

(void*)"

#endif

	/* optimize null pointers */

	if (p == NULL)

		return PyInt_FromLong(0);

	return PyLong_FromLongLong((LONG_LONG)p);



#endif /* SIZEOF_VOID_P <= SIZEOF_LONG */

}



----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-12-14 09:37

Message:
Logged In: YES 
user_id=52572

Thanks for asking but the problem is that I don't know what 

they do!

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-12-14 09:15

Message:
Logged In: YES 
user_id=21627

Would you like to provide a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 18:01:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 18:01:58 2003
Subject: [Python-bugs-list] [ python-Bugs-654783 ] doctest and exception
	messages
Message-ID: <E1A1vEG-000585-00@sc8-sf-web2.sourceforge.net>

Bugs item #654783, was opened at 2002-12-16 14:23
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aahz (aahz)
>Assigned to: Aahz (aahz)
Summary: doctest and exception messages

Initial Comment:
doctest should include information something like this:



    doctest docstrings should not rely on the text of internal Python

    exceptions.  Notice the way factorial() uses its own error messages

    with the standard Python exceptions.  The internal messages can

    change even in bugfix releases (as in 2.2.1 to 2.2.2).



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-23 18:01

Message:
Logged In: YES 
user_id=3066

Tim sent this back to Aahz, so I'm assigning it to him as a

reminder.

;-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-25 15:08

Message:
Logged In: YES 
user_id=31435

Back to Aahz.  I don't mind if you change this -- edit the docs 

and check it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-12-16 18:39

Message:
Logged In: YES 
user_id=31435

It could, but it shouldn't:  error msgs in docs that don't match 

reality are also an insult to users.  doctest should grow some 

sort of option here, though, as its uses outgrew its original 

purposes.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-12-16 17:01

Message:
Logged In: YES 
user_id=35752

Couldn't doctest be modified so that it only compares the

exception

name only?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 18:34:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 18:34:56 2003
Subject: [Python-bugs-list] [ python-Bugs-666700 ] os.popen+() can take
	string list and bypass shell.
Message-ID: <E1A1vkC-00082O-00@sc8-sf-web4.sourceforge.net>

Bugs item #666700, was opened at 2003-01-12 11:45
Message generated for change (Comment added) made by jemfinch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dani (asqui)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen+() can take string list and bypass shell.

Initial Comment:
After being somewhat dumbfounded by the fact that there

is no easy way to securely give user input as

parameters to an external utility (because of the fact

that os.popen*() runs things in the shell), I was happy

to find that (os | popen2).popen[234]() will accept

either a string as the command and execute it within a

shell, or a string list which is executed directly.



This does not apply to os.popen(), however

popen2.popen[234]() all use this piece of code to

execute the command in the child process:



/usr/lib/python2.2/popen2.py

    def _run_child(self, cmd):

        if isinstance(cmd, types.StringTypes):

            cmd = ['/bin/sh', '-c', cmd]

        for i in range(3, MAXFD):

            try:

                os.close(i)

            except:

                pass

        try:

            os.execvp(cmd[0], cmd)

        finally:

            os._exit(1)



Meaning that unless cmd is a string it will be run

directly, outside of any shell.



This appears to be the case for os.popen[234]() as well

as popen2.popen*()

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-09-23 18:34

Message:
Logged In: YES 
user_id=99508

Can I second that the documentation should definitely be

updated to reflect this possibility, even if it's only

available on *nix-like systems?  This is something that many

other languages in the same realm as Python (Perl, PHP,

etc.) support and document, and I can't see any good reason

why we *shouldn't* document a more secure way to give data

to external programs.

----------------------------------------------------------------------

Comment By: Bernhard Herzog (bernhard)
Date: 2003-08-05 12:04

Message:
Logged In: YES 
user_id=2369

Given that the command as list of strings feature only works

on Unix-like systems, ISTM it should perhaps only be

documented for the PopenN classes. Maybe the documentation

for the functions should state that on unix they accept

lists of strings, though.

----------------------------------------------------------------------

Comment By: Dani (asqui)
Date: 2003-01-12 11:49

Message:
Logged In: YES 
user_id=569758

(The punch line which I omitted was that this fact is not

documented anywhere.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470

From noreply at sourceforge.net  Tue Sep 23 21:25:21 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 23 21:25:33 2003
Subject: [Python-bugs-list] [ python-Bugs-653542 ]
	PyLong_AsVoidPtr()/PyLong_FromVoidPtr()
Message-ID: <E1A1yPB-00038L-00@sc8-sf-web4.sourceforge.net>

Bugs item #653542, was opened at 2002-12-13 20:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Nobody/Anonymous (nobody)
Summary: PyLong_AsVoidPtr()/PyLong_FromVoidPtr()

Initial Comment:
These two functions have mutually-recursive definitions 

in the docs (which is to say, none).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-23 21:25

Message:
Logged In: YES 
user_id=31435

Nope.  Guido checked them in 5 years ago, in rev 1.48.  To 

judge from the checkin comment, the code may actually have 

come from Greg Stein.  I don't have time for it, so unassigning.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-23 18:00

Message:
Logged In: YES 
user_id=3066

Tim, aren't these your babies?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-12-14 11:15

Message:
Logged In: YES 
user_id=21627

Something very simple:



PyObject *

PyLong_FromVoidPtr(void *p)

{

#if SIZEOF_VOID_P <= SIZEOF_LONG

	return PyInt_FromLong((long)p);

#else



#ifndef HAVE_LONG_LONG

#   error "PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), 

but no long long"

#endif

#if SIZEOF_LONG_LONG < SIZEOF_VOID_P

#   error "PyLong_FromVoidPtr: sizeof(LONG_LONG) < sizeof

(void*)"

#endif

	/* optimize null pointers */

	if (p == NULL)

		return PyInt_FromLong(0);

	return PyLong_FromLongLong((LONG_LONG)p);



#endif /* SIZEOF_VOID_P <= SIZEOF_LONG */

}



----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-12-14 09:37

Message:
Logged In: YES 
user_id=52572

Thanks for asking but the problem is that I don't know what 

they do!

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-12-14 09:15

Message:
Logged In: YES 
user_id=21627

Would you like to provide a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 00:14:57 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 00:15:02 2003
Subject: [Python-bugs-list] [ python-Bugs-453684 ] In 2.2,
	types are inheritable, &c
Message-ID: <E1A213J-0003HD-00@sc8-sf-web1.sourceforge.net>

Bugs item #453684, was opened at 2001-08-21 07:37
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453684&group_id=5470

Category: Documentation
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: In 2.2, types are inheritable, &c

Initial Comment:
http://python.sourceforge.net/devel-

docs/ref/class.html says that "Each item in the 

inheritance list should evaluate to a class object" -- 

no mention of 2.2's highlight, that a type can also be 

there?



Is there any mention anywhere in the 2.2a2 language 

reference manual of 2.2's new features?  Maybe I'm 

missing something, but I can't see any -- iterators, 

generators, __slots__, etc, etc.





----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-24 00:14

Message:
Logged In: YES 
user_id=3066

Dealt with first part of this in Doc/ref/ref7.tex revision 1.37.



Regarding the second part of this:  How much of this belongs

in the language reference?  Is Jython following CPython

regarding new-style classes, or does it differ?



Marked "pending" so I can ignore the issue until someone

comments on it.  ;-)

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 16:27

Message:
Logged In: YES 
user_id=31392

Is it worth keeping this bug report?  We know that the

documentation is incomplete.  I'd say close it.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453684&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 04:20:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 04:20:25 2003
Subject: [Python-bugs-list] [ python-Bugs-811604 ] "string".split behaviour
Message-ID: <E1A24sm-0001NU-00@sc8-sf-web4.sourceforge.net>

Bugs item #811604, was opened at 2003-09-24 13: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=811604&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: T.Meyarivan (meyarivan)
Assigned to: Nobody/Anonymous (nobody)
Summary: "string".split behaviour

Initial Comment:


"".split() -> []



"".split(' ') -> ['']



It is not clear from the documentation as to what is

the defined behaviour in the above case. To say the

least, it is 

completely counter-intuitive..(splitting an empty

string should

return the list [''] in both cases).



>From stringobject.c, the behaviour of split_whitespace

(i.e split called without sep) and string_split (split

called with sep) is different for empty

strings..perhaps the function split_whitespace needs to

be patched.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 04:45:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 04:46:30 2003
Subject: [Python-bugs-list] [ python-Bugs-811604 ] "string".split behaviour
	for empty strings
Message-ID: <E1A25HS-0001rt-00@sc8-sf-web3.sourceforge.net>

Bugs item #811604, was opened at 2003-09-24 13:50
Message generated for change (Settings changed) made by meyarivan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: T.Meyarivan (meyarivan)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "string".split behaviour for empty strings

Initial Comment:


"".split() -> []



"".split(' ') -> ['']



It is not clear from the documentation as to what is

the defined behaviour in the above case. To say the

least, it is 

completely counter-intuitive..(splitting an empty

string should

return the list [''] in both cases).



>From stringobject.c, the behaviour of split_whitespace

(i.e split called without sep) and string_split (split

called with sep) is different for empty

strings..perhaps the function split_whitespace needs to

be patched.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 04:51:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 04:51:32 2003
Subject: [Python-bugs-list] [ python-Bugs-811604 ] "string".split behaviour
	for empty strings
Message-ID: <E1A25Mu-0002iA-00@sc8-sf-web4.sourceforge.net>

Bugs item #811604, was opened at 2003-09-24 13:50
Message generated for change (Comment added) made by meyarivan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: T.Meyarivan (meyarivan)
Assigned to: Nobody/Anonymous (nobody)
Summary: "string".split behaviour for empty strings

Initial Comment:


"".split() -> []



"".split(' ') -> ['']



It is not clear from the documentation as to what is

the defined behaviour in the above case. To say the

least, it is 

completely counter-intuitive..(splitting an empty

string should

return the list [''] in both cases).



>From stringobject.c, the behaviour of split_whitespace

(i.e split called without sep) and string_split (split

called with sep) is different for empty

strings..perhaps the function split_whitespace needs to

be patched.

----------------------------------------------------------------------

>Comment By: T.Meyarivan (meyarivan)
Date: 2003-09-24 14:21

Message:
Logged In: YES 
user_id=30470

"".split(None) -> [] 



which is expected because in the case when no sep is

specified and when sep == None, split_whitespace is called..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 06:44:33 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 06:44:38 2003
Subject: [Python-bugs-list] [ python-Bugs-811681 ] Module asynchat not
	documented
Message-ID: <E1A278L-0002Jr-00@sc8-sf-web1.sourceforge.net>

Bugs item #811681, was opened at 2003-09-24 12:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811681&group_id=5470

Category: Documentation
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Zgoda (zgoda)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module asynchat not documented

Initial Comment:
There's no documentation at all for this module, the

only reference seems to be docstrings in module and

part of 7th chapter of F. Lundh's Python Standard Library.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811681&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 08:47:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 08:47:26 2003
Subject: [Python-bugs-list] [ python-Bugs-810714 ] nested variables in
	'class:' statements
Message-ID: <E1A292u-0005Vb-00@sc8-sf-web3.sourceforge.net>

Bugs item #810714, was opened at 2003-09-22 17:05
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&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: nested variables in 'class:' statements

Initial Comment:
from the user's point of view, variables originating

from nested scopes could erratically become bound in

the 'class' statement.



The 'class:' statements works by capturing all locals()

after executing the body; however, this is not exactly

the same as what an explicit call to locals() would

return because of the missing PyFrame_FastToLocals()

call in the implementation of LOAD_LOCALS in ceval.c.

It was thought that PyFrame_FastToLocals() was

unnecessary at that point because the class body

bytecode only uses LOAD_NAME/STORE_NAME and not fast

locals -- but this is no longer true with nested

scopes. See attached examples.



----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2003-09-24 12:47

Message:
Logged In: YES 
user_id=4771

I'm not sure how to solve this. I could make a patch to

LOAD_LOCALS to prevent free variables from showing up in the

class.__dict__. For the 2nd problem I'm not familiar enough

with compile.c to know how to make the binding 'b="foo"'

sufficient to prevent 'b' from also being considered free in

the class definition (which is what occurs).



Note also that bare 'exec' statements should then be

forbidden in class definitions in the presence of free

variables, for the same reason as it is forbidden in

functions: you cannot tell whether a variable is free or

local.



As an example of this, if in the attached example we replace

b="foo" with exec 'b="foo"' then the last print correctly

outputs 'foo' instead of 6 but what actually occurs is that

the value of the argument b in f(a,b) was modified by the

class definition -- it is a way to change the binding of a

variable in an enclosing frame, which should not be

possible.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 19:16

Message:
Logged In: YES 
user_id=80475

Do you have a proposed patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 08:56:57 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 08:57:05 2003
Subject: [Python-bugs-list] [ python-Bugs-811681 ] Module asynchat not
	documented in 2.2.3
Message-ID: <E1A29CT-0006Lg-00@sc8-sf-web2.sourceforge.net>

Bugs item #811681, was opened at 2003-09-24 12:44
Message generated for change (Settings changed) made by zgoda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811681&group_id=5470

Category: Documentation
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Zgoda (zgoda)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Module asynchat not documented in 2.2.3

Initial Comment:
There's no documentation at all for this module, the

only reference seems to be docstrings in module and

part of 7th chapter of F. Lundh's Python Standard Library.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811681&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 09:01:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 09:01:45 2003
Subject: [Python-bugs-list] [ python-Bugs-810408 ] mkstemp doesn't return
	abspath
Message-ID: <E1A29H1-0006Pe-00@sc8-sf-web3.sourceforge.net>

Bugs item #810408, was opened at 2003-09-22 07:26
Message generated for change (Comment added) made by midramas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810408&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: mkstemp doesn't return abspath

Initial Comment:
The document of tempfile.mkstemp says that,

"mkstemp() returns a tuple containing an OS-level 

handle to an open file (as would be returned by 

os.open()) and the absolute pathname of that file, 

in that order."



However, if you specify the directory a relative path,

it doesn't return an absolute pathname.



>>> import tempfile

>>> tempfile.mkstemp()

(5, '/tmp/tmpHBq8rz')

>>> tempfile.mkstemp(dir='.')

(3, './tmpvK7BEr')

>>> tempfile.mkstemp(dir='./test')

(4, './test/tmplB7GZF')



----------------------------------------------------------------------

Comment By: Michael Bartl (midramas)
Date: 2003-09-24 15:01

Message:
Logged In: YES 
user_id=31511

As I have written the patch, my comment:



I think the code should be fixed, because the filename is 

instantly usable if returned with an absolute path. If the 

patch is not accepted please consider to use at least the 

additional testcase which catches the bug.

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2003-09-23 13:34

Message:
Logged In: YES 
user_id=671362

Michael has submitted a patch to return absolute 

pathname.



http://www.python.org/sf/810914

fix for mkstemp with relative paths (bug #810408)



His fix looks good to me.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 13:03

Message:
Logged In: YES 
user_id=29957

Anyone got an opinion on this one? Should the docs be fixed,

or the code?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810408&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 09:41:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 09:41:31 2003
Subject: [Python-bugs-list] [ python-Bugs-807871 ] tkMessageBox.askyesno
	wrong result
Message-ID: <E1A29tY-00009q-00@sc8-sf-web4.sourceforge.net>

Bugs item #807871, was opened at 2003-09-17 11:18
Message generated for change (Settings changed) made by ranger1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 8
Submitted By: Paul Perkins (ranger1)
Assigned to: Nobody/Anonymous (nobody)
Summary: tkMessageBox.askyesno wrong result

Initial Comment:
Bug: tkMessageBox.askyesno can return wrong result. 
 
   Bug in python 2.3, built from source on SuSE 8.2 Linux box 
with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). 
 
   To demonstate bug: 
   1. Run attached program in a shell window under X. 
   2. Click "askyesno" button in main window. 
   3. Click "Yes" button in the new window. 
   4. Observe printed result "True" in shell window. 
   5. Click "openfiledialog" button in main window. 
   6. Cancel the file dialog (or select a file, it doesn't matter). 
   7. Click "askyesno" button in main window. 
   8. Click "Yes" button in the new window. 
   9. Observe printed result "False" in shell window. 
 
   Using the debugger in idle, one can see that the 
difference is that Tk returns "yes" to Python in step 3, but 
True in step 8. 
 
   In python 2.2 (as built by SuSE for 8.2), the printed result 
   is always "1" in steps 3 and 8. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 11:46:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 11:47:04 2003
Subject: [Python-bugs-list] [ python-Bugs-811844 ] readline+no threads =
	core dump
Message-ID: <E1A2Bql-0002ah-00@sc8-sf-web1.sourceforge.net>

Bugs item #811844, was opened at 2003-09-24 08:46
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=811844&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TEd Drain (teddrain)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline+no threads = core dump

Initial Comment:
Build 2.3 or 2.3.1 on linux with the following

configure command:



./configure --enable-shared --without-threads



Try running the rlcompleter example.  If you hit TAB

with completions enabled, you'll get a core dump after

you hit return on that line.  Works fine if I build

with threads enabled.  



This is a major problem for me since we have to deliver

our software on machines that do not support pthreads

(hpux 10.2 for example).



~: uname -a

Linux XXXX 2.4.9-21 #1 Thu Jan 17 14:16:30 EST 2002

i686 unknown



~/builds-gcc2: python

Python 2.3.1 (#1, Sep 24 2003, 08:13:26)

[GCC 2.95.3 20010315 (release)] on linux2

Type "help", "copyright", "credits" or "license" for

more information.

>>> import readline, rlcompleter

>>> readline.parse_and_bind("tab: complete")

>>> readline.par<TAB> se_and_bind()

Fatal Python error: PyThreadState_Get: no current thread

Abort (core dumped)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811844&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 12:17:12 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 12:17:21 2003
Subject: [Python-bugs-list] [ python-Bugs-811844 ] readline+no threads =
	core dump
Message-ID: <E1A2CKG-0001kF-00@sc8-sf-web2.sourceforge.net>

Bugs item #811844, was opened at 2003-09-24 16:46
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811844&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TEd Drain (teddrain)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline+no threads = core dump

Initial Comment:
Build 2.3 or 2.3.1 on linux with the following

configure command:



./configure --enable-shared --without-threads



Try running the rlcompleter example.  If you hit TAB

with completions enabled, you'll get a core dump after

you hit return on that line.  Works fine if I build

with threads enabled.  



This is a major problem for me since we have to deliver

our software on machines that do not support pthreads

(hpux 10.2 for example).



~: uname -a

Linux XXXX 2.4.9-21 #1 Thu Jan 17 14:16:30 EST 2002

i686 unknown



~/builds-gcc2: python

Python 2.3.1 (#1, Sep 24 2003, 08:13:26)

[GCC 2.95.3 20010315 (release)] on linux2

Type "help", "copyright", "credits" or "license" for

more information.

>>> import readline, rlcompleter

>>> readline.parse_and_bind("tab: complete")

>>> readline.par<TAB> se_and_bind()

Fatal Python error: PyThreadState_Get: no current thread

Abort (core dumped)



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-09-24 17:17

Message:
Logged In: YES 
user_id=6656

i see this too.



oops.  hopefully easy to fix...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811844&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 12:44:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 12:44:06 2003
Subject: [Python-bugs-list] [ python-Bugs-811898 ] int ("ffffffd3",
	16) gives error
Message-ID: <E1A2CkG-00037k-00@sc8-sf-web2.sourceforge.net>

Bugs item #811898, was opened at 2003-09-24 12:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811898&group_id=5470

Category: None
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal D. Becker (nbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: int ("ffffffd3", 16) gives error

Initial Comment:
Subject says it all.  This should not give an error 
on a machine that uses 32-bit 2's complement 
representation for int. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811898&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 16:01:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 16:02:37 2003
Subject: [Python-bugs-list] [ python-Bugs-812007 ] Wrong symbol for fsync in
	2.3.1
Message-ID: <E1A2Fp4-0000Rq-00@sc8-sf-web1.sourceforge.net>

Bugs item #812007, was opened at 2003-09-24 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=812007&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong symbol for fsync in 2.3.1

Initial Comment:
In 2.3.1, pyconfig.h defines HAVE_SYNC if fsync is present:



/* Define if you have the 'fsync' function. */

#define HAVE_SYNC 1



but posixmodule.c looks for HAVE_FSYNC



#ifdef HAVE_FSYNC

PyDoc_STRVAR(posix_fsync__doc__,

"fsync(fildes)\n\n\



I expect that that's a typo in configure.in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812007&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 17:24:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 17:25:48 2003
Subject: [Python-bugs-list] [ python-Bugs-812050 ] Inconsistent exceptions
	raised (OSError/IOError)
Message-ID: <E1A2H7Z-0005hR-00@sc8-sf-web3.sourceforge.net>

Bugs item #812050, was opened at 2003-09-24 17:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812050&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistent exceptions raised (OSError/IOError)

Initial Comment:
It seems odd that functions seem to randomly choose

which they'll raise.  Example:



>>> import os

>>> os.stat("I don't exist.")

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

OSError: [Errno 2] No such file or directory: "I don't

exist."

>>> file("I don't exist.")

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

IOError: [Errno 2] No such file or directory: "I don't

exist."

>>> isinstance(OSError, IOError)

False

>>> isinstance(IOError, OSError)

False

>>> issubclass(OSError, IOError)

False

>>> issubclass(IOError, OSError)

False



For backwards compatibility, it's probably hard to

change the actual exception raised, but shouldn't

IOError be a subclass of OSError?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812050&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 17:42:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 17:44:53 2003
Subject: [Python-bugs-list] [ python-Bugs-812050 ] Inconsistent exceptions
	raised (OSError/IOError)
Message-ID: <E1A2HOk-0002Ce-00@sc8-sf-web2.sourceforge.net>

Bugs item #812050, was opened at 2003-09-24 17:24
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812050&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistent exceptions raised (OSError/IOError)

Initial Comment:
It seems odd that functions seem to randomly choose

which they'll raise.  Example:



>>> import os

>>> os.stat("I don't exist.")

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

OSError: [Errno 2] No such file or directory: "I don't

exist."

>>> file("I don't exist.")

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

IOError: [Errno 2] No such file or directory: "I don't

exist."

>>> isinstance(OSError, IOError)

False

>>> isinstance(IOError, OSError)

False

>>> issubclass(OSError, IOError)

False

>>> issubclass(IOError, OSError)

False



For backwards compatibility, it's probably hard to

change the actual exception raised, but shouldn't

IOError be a subclass of OSError?

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-24 17:42

Message:
Logged In: YES 
user_id=12800

In programs where it matters, use EnvironmentError, which is

the common superclass of OSError and IOError.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812050&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 18:38:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 18:38:52 2003
Subject: [Python-bugs-list] [ python-Bugs-812089 ] webbrowser.open_new()
	opens in an existing browser window
Message-ID: <E1A2IHa-0000MG-00@sc8-sf-web3.sourceforge.net>

Bugs item #812089, was opened at 2003-09-24 15:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Cohen (bram_cohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser.open_new() opens in an existing browser window

Initial Comment:
I'm running Windows with Mozilla (version 1.4) as my

default web browser. When I call webbrowser.open_new()

using Python 2.3 it opens the url in an existing window

(if there are any) rather than opening a new one like

it's supposed to. This might in some way be an

interaction with tabbed browsing, since I always have a

bunch of tabs open.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 19:09:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 19:09:47 2003
Subject: [Python-bugs-list] [ python-Bugs-683061 ] gzip module cannot write
	large files
Message-ID: <E1A2IlF-0005oR-00@sc8-sf-web4.sourceforge.net>

Bugs item #683061, was opened at 2003-02-08 20:52
Message generated for change (Comment added) made by midramas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683061&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip module cannot write large files

Initial Comment:
Something like this:



import gzip

fin = open("/dev/urandom", "rb")

fout = gzip.GzipFile("out", "wb")

for i in range(4500): fout.write(fin.read(1024*1024))

fout.close()



will result in an error like:



Exception 'long int too large to convert to int' raised

of class 'exceptions.OverflowError':

...

  File "/usr/local/lib/python2.2/gzip.py", line 253, in

close

    write32(self.fileobj, self.size)

  File "/usr/local/lib/python2.2/gzip.py", line 19, in

write32

    output.write(struct.pack("<l", value))



Tested in python 2.2.1



----------------------------------------------------------------------

Comment By: Michael Bartl (midramas)
Date: 2003-09-25 01:09

Message:
Logged In: YES 
user_id=31511

I'd propose to close this bug (fixed in the 2.3 series).



The fix can't be backported, because 2.2.3 was the final

version of the 2.2 series.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-29 03:20

Message:
Logged In: YES 
user_id=357491

>From what I can gather from cvs log this was not backported.  Should it be?

----------------------------------------------------------------------

Comment By: Steven Taschuk (staschuk)
Date: 2003-03-30 20:42

Message:
Logged In: YES 
user_id=666873

Current CVS has a fix for this, as of revision 1.37 (part of 2.3a1).



See patch 618135: http://www.python.org/sf/618135.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683061&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 19:36:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 19:37:14 2003
Subject: [Python-bugs-list] [ python-Bugs-683061 ] gzip module cannot write
	large files
Message-ID: <E1A2JBS-0002PZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #683061, was opened at 2003-02-08 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=683061&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip module cannot write large files

Initial Comment:
Something like this:



import gzip

fin = open("/dev/urandom", "rb")

fout = gzip.GzipFile("out", "wb")

for i in range(4500): fout.write(fin.read(1024*1024))

fout.close()



will result in an error like:



Exception 'long int too large to convert to int' raised

of class 'exceptions.OverflowError':

...

  File "/usr/local/lib/python2.2/gzip.py", line 253, in

close

    write32(self.fileobj, self.size)

  File "/usr/local/lib/python2.2/gzip.py", line 19, in

write32

    output.write(struct.pack("<l", value))



Tested in python 2.2.1



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-24 16:36

Message:
Logged In: YES 
user_id=357491

No one ever said 2.2.3 was the final release of the 2.2 branch.  

There was talk just last month about a 2.2.4 release towards the 

end of the year.

----------------------------------------------------------------------

Comment By: Michael Bartl (midramas)
Date: 2003-09-24 16:09

Message:
Logged In: YES 
user_id=31511

I'd propose to close this bug (fixed in the 2.3 series).



The fix can't be backported, because 2.2.3 was the final

version of the 2.2 series.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-28 18:20

Message:
Logged In: YES 
user_id=357491

>From what I can gather from cvs log this was not backported.  Should it be?

----------------------------------------------------------------------

Comment By: Steven Taschuk (staschuk)
Date: 2003-03-30 10:42

Message:
Logged In: YES 
user_id=666873

Current CVS has a fix for this, as of revision 1.37 (part of 2.3a1).



See patch 618135: http://www.python.org/sf/618135.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683061&group_id=5470

From noreply at sourceforge.net  Wed Sep 24 21:21:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Sep 24 21:21:51 2003
Subject: [Python-bugs-list] [ python-Bugs-812152 ] Distributing Python
	Modules: cap 10
Message-ID: <E1A2KpF-0005tN-00@sc8-sf-web3.sourceforge.net>

Bugs item #812152, was opened at 2003-09-25 03: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=812152&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Riccardo Attilio Galli (riquito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distributing Python Modules: cap 10

Initial Comment:
There are two wrong words in chapter 10 of distutils

documentation ("distutils.sysconfig -- System

configuration information").



in particular is wrote:

PREFIX

    The result of os.path.normpath(sys.prefex). 



EXEC_PREFIX

    The result of os.path.normpath(sys.exec_prefex). 



instead of 



PREFIX

    The result of os.path.normpath(sys.prefix). 



EXEC_PREFIX

    The result of os.path.normpath(sys.exec_prefix).





Riccardo Galli

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812152&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 00:52:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 00:52:35 2003
Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even
Message-ID: <E1A2O77-0003X9-00@sc8-sf-web1.sourceforge.net>

Bugs item #812202, was opened at 2003-09-24 23: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=812202&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: randint is always even

Initial Comment:
The result of 

    random.randint(2**64,2**65-1) 

is always even!



(I was trying to find some large prime numbers, and

was puzzled by the fact that none were turning

up.  Finally, I discovered that randint wasn't really

returning "random" integers as desired, but only

even ones.)



I'm not sure what the cause of the problem is, but

randint should work properly, even when the given

endpoints are large...



Thanks...



        Ron Rivest



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 01:16:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 01:16:05 2003
Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even
Message-ID: <E1A2OTw-0004Dd-00@sc8-sf-web1.sourceforge.net>

Bugs item #812202, was opened at 2003-09-25 00:52
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: randint is always even

Initial Comment:
The result of 

    random.randint(2**64,2**65-1) 

is always even!



(I was trying to find some large prime numbers, and

was puzzled by the fact that none were turning

up.  Finally, I discovered that randint wasn't really

returning "random" integers as desired, but only

even ones.)



I'm not sure what the cause of the problem is, but

randint should work properly, even when the given

endpoints are large...



Thanks...



        Ron Rivest



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-25 01:16

Message:
Logged In: YES 
user_id=31435

The cause is that randint takes a pseudo-random float (C 

double in [0, 1),), multiplies it by (hi-lo+1), then truncates 

and adds that to lo.  Since a double on your box almost 

certainly has only 53 bits of precision, and your multiplier 

effectively moves the radix point 64 bits "to the right", I 

expect the last 11 bits you see will always be 0.



Under Python 2.3, which uses the Mersenne Twister to 

generate random doubles, this does appear to be the case:



>>> from random import randint

>>> def f():

...     return randint(2**64, 2**65-1)

...

>>> hex(f())

'0x11EDD95B72CEF4000L'

>>> hex(f())

'0x1DD69BF4B39C65000L'

>>> hex(f())

'0x13328DC9C1C733800L'

>>> hex(f())

'0x1E65B47170C057800L'

>>>



Under earlier versions of Python, it may be even worse than 

that.



It takes a fundamentally different kind of algorithm to 

generate arbitrarily long random ints.  Here's a link to one 

such for Python:



http://www.faqts.com/knowledge_base/view.phtml/aid/4406



I doubt the implementation of randint() will change, since 

most people want fast-as-possible generation of mountains of 

small integers, and there's a tradeoff between catering to 

that and catering to extreme inputs.  The randint docs should 

change, though (I think randint() used to raise an exception 

when fed arguments as large as the ones you're using; I 

suspect, but don't know, that we lost the helpful exception 

as an unintended consequence of the long-term effort to 

eradicate the user-visible distinction between Python ints 

(machine C longs) and Python longs (unbounded integers)).



BTW, given what you're doing, you may want to install one of 

the Python wrappers for GNU GMP.  Python's unbounded-int 

arithmetic implementation is extremely portable and reliable, 

but buys those in part by not caring much about speed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 02:27:54 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 02:30:33 2003
Subject: [Python-bugs-list] [ python-Bugs-812152 ] Distributing Python
	Modules: cap 10
Message-ID: <E1A2PbW-00034S-00@sc8-sf-web4.sourceforge.net>

Bugs item #812152, was opened at 2003-09-25 03:21
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812152&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Riccardo Attilio Galli (riquito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distributing Python Modules: cap 10

Initial Comment:
There are two wrong words in chapter 10 of distutils

documentation ("distutils.sysconfig -- System

configuration information").



in particular is wrote:

PREFIX

    The result of os.path.normpath(sys.prefex). 



EXEC_PREFIX

    The result of os.path.normpath(sys.exec_prefex). 



instead of 



PREFIX

    The result of os.path.normpath(sys.prefix). 



EXEC_PREFIX

    The result of os.path.normpath(sys.exec_prefix).





Riccardo Galli

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-09-25 08:27

Message:
Logged In: YES 
user_id=11105

Fixed in sysconfig.tex, 1.2.



Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812152&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 04:53:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 04:54:04 2003
Subject: [Python-bugs-list] [ python-Bugs-683061 ] gzip module cannot write
	large files
Message-ID: <E1A2Rsp-0000ON-00@sc8-sf-web2.sourceforge.net>

Bugs item #683061, was opened at 2003-02-08 20:52
Message generated for change (Comment added) made by midramas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683061&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip module cannot write large files

Initial Comment:
Something like this:



import gzip

fin = open("/dev/urandom", "rb")

fout = gzip.GzipFile("out", "wb")

for i in range(4500): fout.write(fin.read(1024*1024))

fout.close()



will result in an error like:



Exception 'long int too large to convert to int' raised

of class 'exceptions.OverflowError':

...

  File "/usr/local/lib/python2.2/gzip.py", line 253, in

close

    write32(self.fileobj, self.size)

  File "/usr/local/lib/python2.2/gzip.py", line 19, in

write32

    output.write(struct.pack("<l", value))



Tested in python 2.2.1



----------------------------------------------------------------------

Comment By: Michael Bartl (midramas)
Date: 2003-09-25 10:53

Message:
Logged In: YES 
user_id=31511

Sorry for the error in my last comment: a backport can still

be done for 2.2.4 or later. It seems the "final" confused

me. I found it out some minutes after I wrote the comment.



As the error is still present in 2.2.3, I will provide a

patch that backports it (you can then vote for it <wink> :)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-09-25 01:36

Message:
Logged In: YES 
user_id=357491

No one ever said 2.2.3 was the final release of the 2.2 branch.  

There was talk just last month about a 2.2.4 release towards the 

end of the year.

----------------------------------------------------------------------

Comment By: Michael Bartl (midramas)
Date: 2003-09-25 01:09

Message:
Logged In: YES 
user_id=31511

I'd propose to close this bug (fixed in the 2.3 series).



The fix can't be backported, because 2.2.3 was the final

version of the 2.2 series.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-29 03:20

Message:
Logged In: YES 
user_id=357491

>From what I can gather from cvs log this was not backported.  Should it be?

----------------------------------------------------------------------

Comment By: Steven Taschuk (staschuk)
Date: 2003-03-30 20:42

Message:
Logged In: YES 
user_id=666873

Current CVS has a fix for this, as of revision 1.37 (part of 2.3a1).



See patch 618135: http://www.python.org/sf/618135.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683061&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 05:08:12 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 05:08:16 2003
Subject: [Python-bugs-list] [ python-Bugs-812325 ] tarfile violates bufsize
Message-ID: <E1A2S6e-0002HJ-00@sc8-sf-web4.sourceforge.net>

Bugs item #812325, was opened at 2003-09-25 11: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=812325&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Johan Fredrik ?hman (johanfo)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile violates bufsize

Initial Comment:
tf = tarfile.open(mode = 'w|gz', fileobj=fileName, 

bufsize=20*512)





The following text says how many bytes tarfile writes to 

the 'fileName.write' function. Notice that when closing 

the tarfile it writes way to many bytes!  This happes 

just sometimes. Some directories might work, other 

might not.





...

write len: 10240

write len: 10240

Closing archive

write len: 24815  # Somthing is wrong?

write len: 4

write len: 4

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812325&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 05:24:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 05:24:19 2003
Subject: [Python-bugs-list] [ python-Bugs-812340 ] BasHTTPServer IE Mac 5.1
	size problem
Message-ID: <E1A2SMB-00073W-00@sc8-sf-web3.sourceforge.net>

Bugs item #812340, was opened at 2003-09-25 09:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812340&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Sven Passig (coderscom)
Assigned to: Nobody/Anonymous (nobody)
Summary: BasHTTPServer IE Mac 5.1 size problem

Initial Comment:
I run a BaseHTTPServer that way:



import CGIHTTPServer

import BaseHTTPServer

Handler = CGIHTTPServer.CGIHTTPRequestHandler

PORT = 8080

httpd = BaseHTTPServer.HTTPServer(("", PORT), Handler)

print "Serving at port ", PORT

httpd.serve_forever()



on a linux, windows or OSX System, doasn't matter for 

the problem



When i try to get a a big html-side (static html or cgi, 

doasn't matter) with InternetExplorer 5.1 on OSX or OS9 

the server hangs itself up.



I try to figure out the reason. It deppends on the size:



BaseHTTPServer (V. 06) do in line 43 :

self.copyfile(f, self.wfile)



copyfile is defined in line 146 and just do a



shutil.copyfileobj(source, outputfile)



copyfileobj in shutil is defined in line 14 and try to read 

and write blocks of 16*1024 size.



I changed that and read 1024 byte blocks.

It worked 116 times. After that the IE seams to block. 

(shutil (line 20) try to make the fdst.write(buf) but never 

finished)



Other WebBrowsers (f.e. Apache) are able to support 

bigger sides for the Mac IE 5.1. So it's (at least not only)

an IE problem and should be fixed in the Python Web 

Server (IMHO).

Any ideas how to fix ?





I us Python 2.2 but I installed the newest versions of 

BasHTTPServer, CGIHTTPServer, SimpleHTTPServer and 

SocketServer.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812340&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 05:55:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 05:55:43 2003
Subject: [Python-bugs-list] [ python-Bugs-812007 ] Wrong symbol for fsync in
	2.3.1
Message-ID: <E1A2SqR-0003Na-00@sc8-sf-web2.sourceforge.net>

Bugs item #812007, was opened at 2003-09-24 21:01
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812007&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong symbol for fsync in 2.3.1

Initial Comment:
In 2.3.1, pyconfig.h defines HAVE_SYNC if fsync is present:



/* Define if you have the 'fsync' function. */

#define HAVE_SYNC 1



but posixmodule.c looks for HAVE_FSYNC



#ifdef HAVE_FSYNC

PyDoc_STRVAR(posix_fsync__doc__,

"fsync(fildes)\n\n\



I expect that that's a typo in configure.in.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-09-25 10:55

Message:
Logged In: YES 
user_id=6656

Is this changed since 2.3?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812007&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 06:22:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 06:22:10 2003
Subject: [Python-bugs-list] [ python-Bugs-812007 ] Wrong symbol for fsync in
	2.3.1
Message-ID: <E1A2TG4-0000t1-00@sc8-sf-web3.sourceforge.net>

Bugs item #812007, was opened at 2003-09-24 21:01
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812007&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong symbol for fsync in 2.3.1

Initial Comment:
In 2.3.1, pyconfig.h defines HAVE_SYNC if fsync is present:



/* Define if you have the 'fsync' function. */

#define HAVE_SYNC 1



but posixmodule.c looks for HAVE_FSYNC



#ifdef HAVE_FSYNC

PyDoc_STRVAR(posix_fsync__doc__,

"fsync(fildes)\n\n\



I expect that that's a typo in configure.in.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-09-25 11:22

Message:
Logged In: YES 
user_id=6656

I can answer that: yes.



I assume this is a simple typo in configure.in, but if we're

using autconf 2.57 now, I'll need to install that before

checking the fix in...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-25 10:55

Message:
Logged In: YES 
user_id=6656

Is this changed since 2.3?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812007&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 06:23:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 06:23:34 2003
Subject: [Python-bugs-list] [ python-Bugs-812353 ] a Py_DECREF() too much
Message-ID: <E1A2THY-0000az-00@sc8-sf-web1.sourceforge.net>

Bugs item #812353, was opened at 2003-09-25 10: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=812353&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a Py_DECREF() too much

Initial Comment:
frameobject.c:PyFrame_FastToLocals() has a

Py_DECREF(locals) that shouldn't be done. It didn't get

noticed because it is in an unprobable path.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812353&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 07:10:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 07:11:15 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A2U1G-00032t-00@sc8-sf-web3.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 12:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 08:45:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 08:45:55 2003
Subject: [Python-bugs-list] [ python-Bugs-812007 ] Wrong symbol for fsync in
	2.3.1
Message-ID: <E1A2VV6-0003J7-00@sc8-sf-web2.sourceforge.net>

Bugs item #812007, was opened at 2003-09-24 15:01
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812007&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong symbol for fsync in 2.3.1

Initial Comment:
In 2.3.1, pyconfig.h defines HAVE_SYNC if fsync is present:



/* Define if you have the 'fsync' function. */

#define HAVE_SYNC 1



but posixmodule.c looks for HAVE_FSYNC



#ifdef HAVE_FSYNC

PyDoc_STRVAR(posix_fsync__doc__,

"fsync(fildes)\n\n\



I expect that that's a typo in configure.in.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-25 07:45

Message:
Logged In: YES 
user_id=44345

I have 2.57.  I can take care of it.





----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-25 05:22

Message:
Logged In: YES 
user_id=6656

I can answer that: yes.



I assume this is a simple typo in configure.in, but if we're

using autconf 2.57 now, I'll need to install that before

checking the fix in...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-25 04:55

Message:
Logged In: YES 
user_id=6656

Is this changed since 2.3?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812007&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 08:54:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 08:54:27 2003
Subject: [Python-bugs-list] [ python-Bugs-758241 ] asyncore with non-default
	map problems
Message-ID: <E1A2VdL-0008Eb-00@sc8-sf-web3.sourceforge.net>

Bugs item #758241, was opened at 2003-06-20 21:41
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758241&group_id=5470

Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Halley (rthalley)
>Assigned to: A.M. Kuchling (akuchling)
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 at sourceforge.net  Thu Sep 25 08:58:53 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 08:58:59 2003
Subject: [Python-bugs-list] [ python-Bugs-811681 ] Module asynchat not
	documented in 2.2.3
Message-ID: <E1A2Vht-00005X-00@sc8-sf-web3.sourceforge.net>

Bugs item #811681, was opened at 2003-09-24 06:44
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811681&group_id=5470

Category: Documentation
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Zgoda (zgoda)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Module asynchat not documented in 2.2.3

Initial Comment:
There's no documentation at all for this module, the

only reference seems to be docstrings in module and

part of 7th chapter of F. Lundh's Python Standard Library.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811681&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 10:06:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 10:06:24 2003
Subject: [Python-bugs-list] [ python-Bugs-812461 ] fsync and fdatasync
	should be check for separately
Message-ID: <E1A2Wl9-0003Fu-00@sc8-sf-web1.sourceforge.net>

Bugs item #812461, was opened at 2003-09-25 14:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812461&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoffrey Mainland (mainland)
Assigned to: Nobody/Anonymous (nobody)
Summary: fsync and fdatasync should be check for separately

Initial Comment:
Some platforms, in particular FreeBSD, have fsync but

not fdatasync. However, the configure script only

checks for fdatasync, and if it does not exists,

neither os.fsync not os.fdatasync are available form

the os module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812461&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 10:47:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 10:47:36 2003
Subject: [Python-bugs-list] [ python-Bugs-812461 ] fsync and fdatasync
	should be check for separately
Message-ID: <E1A2XOo-0006tn-00@sc8-sf-web3.sourceforge.net>

Bugs item #812461, was opened at 2003-09-25 09:06
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812461&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoffrey Mainland (mainland)
Assigned to: Nobody/Anonymous (nobody)
Summary: fsync and fdatasync should be check for separately

Initial Comment:
Some platforms, in particular FreeBSD, have fsync but

not fdatasync. However, the configure script only

checks for fdatasync, and if it does not exists,

neither os.fsync not os.fdatasync are available form

the os module.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-25 09:47

Message:
Logged In: YES 
user_id=44345

Current CVS does have separate checks, though the fsync test

was messed up (HAVE_SYNC was defined instead of 

HAVE_FSYNC).  See bug 812007.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812461&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 10:56:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 11:06:17 2003
Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even
Message-ID: <E1A2XXy-0006w3-00@sc8-sf-web1.sourceforge.net>

Bugs item #812202, was opened at 2003-09-24 23:52
Message generated for change (Comment added) made by ronrivest
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: randint is always even

Initial Comment:
The result of 

    random.randint(2**64,2**65-1) 

is always even!



(I was trying to find some large prime numbers, and

was puzzled by the fact that none were turning

up.  Finally, I discovered that randint wasn't really

returning "random" integers as desired, but only

even ones.)



I'm not sure what the cause of the problem is, but

randint should work properly, even when the given

endpoints are large...



Thanks...



        Ron Rivest



----------------------------------------------------------------------

>Comment By: Ronald L. Rivest (ronrivest)
Date: 2003-09-25 09:56

Message:
Logged In: YES 
user_id=863876

If the code is not going to be fixed, then the

documentation should be updated.  I am well aware

of other approaches to generating large random numbers,

but was misled by the documentation Python provides.  The

documentation should make it clear when the code violates

its "contract" (i.e. doesn't generate all integers in the range).

I prefer the code being fixed best, but also feel that the code 

should raise an exception if it can't honor the contract implied 

in its documentation.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 00:16

Message:
Logged In: YES 
user_id=31435

The cause is that randint takes a pseudo-random float (C 

double in [0, 1),), multiplies it by (hi-lo+1), then truncates 

and adds that to lo.  Since a double on your box almost 

certainly has only 53 bits of precision, and your multiplier 

effectively moves the radix point 64 bits "to the right", I 

expect the last 11 bits you see will always be 0.



Under Python 2.3, which uses the Mersenne Twister to 

generate random doubles, this does appear to be the case:



>>> from random import randint

>>> def f():

...     return randint(2**64, 2**65-1)

...

>>> hex(f())

'0x11EDD95B72CEF4000L'

>>> hex(f())

'0x1DD69BF4B39C65000L'

>>> hex(f())

'0x13328DC9C1C733800L'

>>> hex(f())

'0x1E65B47170C057800L'

>>>



Under earlier versions of Python, it may be even worse than 

that.



It takes a fundamentally different kind of algorithm to 

generate arbitrarily long random ints.  Here's a link to one 

such for Python:



http://www.faqts.com/knowledge_base/view.phtml/aid/4406



I doubt the implementation of randint() will change, since 

most people want fast-as-possible generation of mountains of 

small integers, and there's a tradeoff between catering to 

that and catering to extreme inputs.  The randint docs should 

change, though (I think randint() used to raise an exception 

when fed arguments as large as the ones you're using; I 

suspect, but don't know, that we lost the helpful exception 

as an unintended consequence of the long-term effort to 

eradicate the user-visible distinction between Python ints 

(machine C longs) and Python longs (unbounded integers)).



BTW, given what you're doing, you may want to install one of 

the Python wrappers for GNU GMP.  Python's unbounded-int 

arithmetic implementation is extremely portable and reliable, 

but buys those in part by not caring much about speed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 11:12:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 11:13:04 2003
Subject: [Python-bugs-list] [ python-Bugs-812007 ] Wrong symbol for fsync in
	2.3.1
Message-ID: <E1A2XnX-00055j-00@sc8-sf-web4.sourceforge.net>

Bugs item #812007, was opened at 2003-09-24 15:01
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812007&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
>Assigned to: Skip Montanaro (montanaro)
Summary: Wrong symbol for fsync in 2.3.1

Initial Comment:
In 2.3.1, pyconfig.h defines HAVE_SYNC if fsync is present:



/* Define if you have the 'fsync' function. */

#define HAVE_SYNC 1



but posixmodule.c looks for HAVE_FSYNC



#ifdef HAVE_FSYNC

PyDoc_STRVAR(posix_fsync__doc__,

"fsync(fildes)\n\n\



I expect that that's a typo in configure.in.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-25 10:12

Message:
Logged In: YES 
user_id=44345

Fixed in:

   pyconfig.h.in 1.86

   configure.in 1.436

   configure 1.425



will backport



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-25 07:45

Message:
Logged In: YES 
user_id=44345

I have 2.57.  I can take care of it.





----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-25 05:22

Message:
Logged In: YES 
user_id=6656

I can answer that: yes.



I assume this is a simple typo in configure.in, but if we're

using autconf 2.57 now, I'll need to install that before

checking the fix in...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-25 04:55

Message:
Logged In: YES 
user_id=6656

Is this changed since 2.3?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812007&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 11:21:58 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 11:22:02 2003
Subject: [Python-bugs-list] [ python-Bugs-812461 ] fsync and fdatasync
	should be check for separately
Message-ID: <E1A2XwM-0005g5-00@sc8-sf-web4.sourceforge.net>

Bugs item #812461, was opened at 2003-09-25 09:06
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812461&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Geoffrey Mainland (mainland)
>Assigned to: Skip Montanaro (montanaro)
Summary: fsync and fdatasync should be check for separately

Initial Comment:
Some platforms, in particular FreeBSD, have fsync but

not fdatasync. However, the configure script only

checks for fdatasync, and if it does not exists,

neither os.fsync not os.fdatasync are available form

the os module.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-25 10:21

Message:
Logged In: YES 
user_id=44345

closing as a duplicate.  I checked in changes for the trunk and

the release23_maint branch.  If these don't fix it for you, reopen

the bug report.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-25 09:47

Message:
Logged In: YES 
user_id=44345

Current CVS does have separate checks, though the fsync test

was messed up (HAVE_SYNC was defined instead of 

HAVE_FSYNC).  See bug 812007.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812461&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 11:23:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 11:23:18 2003
Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even
Message-ID: <E1A2XxW-0000Ac-00@sc8-sf-web1.sourceforge.net>

Bugs item #812202, was opened at 2003-09-25 00:52
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: randint is always even

Initial Comment:
The result of 

    random.randint(2**64,2**65-1) 

is always even!



(I was trying to find some large prime numbers, and

was puzzled by the fact that none were turning

up.  Finally, I discovered that randint wasn't really

returning "random" integers as desired, but only

even ones.)



I'm not sure what the cause of the problem is, but

randint should work properly, even when the given

endpoints are large...



Thanks...



        Ron Rivest



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-25 11:23

Message:
Logged In: YES 
user_id=31435

No disagreement here.  I'd rather fix the code than the docs, 

and a fix can take two forms:  raise an exception if the full 

range of ints can't be delivered, or deliver the full range of 

ints.



If anyone wants to take this on, I think the latter ("do a right 

thing") may be much more practical than it used to be, given 

the new-in-2.3 Twister impelementation -- we can generate 

long pseudo-random bitstrings quickly now (at least at the C 

level), but couldn't before 2.3.

----------------------------------------------------------------------

Comment By: Ronald L. Rivest (ronrivest)
Date: 2003-09-25 10:56

Message:
Logged In: YES 
user_id=863876

If the code is not going to be fixed, then the

documentation should be updated.  I am well aware

of other approaches to generating large random numbers,

but was misled by the documentation Python provides.  The

documentation should make it clear when the code violates

its "contract" (i.e. doesn't generate all integers in the range).

I prefer the code being fixed best, but also feel that the code 

should raise an exception if it can't honor the contract implied 

in its documentation.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 01:16

Message:
Logged In: YES 
user_id=31435

The cause is that randint takes a pseudo-random float (C 

double in [0, 1),), multiplies it by (hi-lo+1), then truncates 

and adds that to lo.  Since a double on your box almost 

certainly has only 53 bits of precision, and your multiplier 

effectively moves the radix point 64 bits "to the right", I 

expect the last 11 bits you see will always be 0.



Under Python 2.3, which uses the Mersenne Twister to 

generate random doubles, this does appear to be the case:



>>> from random import randint

>>> def f():

...     return randint(2**64, 2**65-1)

...

>>> hex(f())

'0x11EDD95B72CEF4000L'

>>> hex(f())

'0x1DD69BF4B39C65000L'

>>> hex(f())

'0x13328DC9C1C733800L'

>>> hex(f())

'0x1E65B47170C057800L'

>>>



Under earlier versions of Python, it may be even worse than 

that.



It takes a fundamentally different kind of algorithm to 

generate arbitrarily long random ints.  Here's a link to one 

such for Python:



http://www.faqts.com/knowledge_base/view.phtml/aid/4406



I doubt the implementation of randint() will change, since 

most people want fast-as-possible generation of mountains of 

small integers, and there's a tradeoff between catering to 

that and catering to extreme inputs.  The randint docs should 

change, though (I think randint() used to raise an exception 

when fed arguments as large as the ones you're using; I 

suspect, but don't know, that we lost the helpful exception 

as an unintended consequence of the long-term effort to 

eradicate the user-visible distinction between Python ints 

(machine C longs) and Python longs (unbounded integers)).



BTW, given what you're doing, you may want to install one of 

the Python wrappers for GNU GMP.  Python's unbounded-int 

arithmetic implementation is extremely portable and reliable, 

but buys those in part by not caring much about speed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 13:10:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 13:11:10 2003
Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even
Message-ID: <E1A2Zdr-0003RP-00@sc8-sf-web2.sourceforge.net>

Bugs item #812202, was opened at 2003-09-24 23:52
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: randint is always even

Initial Comment:
The result of 

    random.randint(2**64,2**65-1) 

is always even!



(I was trying to find some large prime numbers, and

was puzzled by the fact that none were turning

up.  Finally, I discovered that randint wasn't really

returning "random" integers as desired, but only

even ones.)



I'm not sure what the cause of the problem is, but

randint should work properly, even when the given

endpoints are large...



Thanks...



        Ron Rivest



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-25 12:10

Message:
Logged In: YES 
user_id=80475

If the range is too large, instead of raising an exception,

how about  

calling a _randbigint routine that builds up the random

selection using repeated calls to the underlying generator. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 10:23

Message:
Logged In: YES 
user_id=31435

No disagreement here.  I'd rather fix the code than the docs, 

and a fix can take two forms:  raise an exception if the full 

range of ints can't be delivered, or deliver the full range of 

ints.



If anyone wants to take this on, I think the latter ("do a right 

thing") may be much more practical than it used to be, given 

the new-in-2.3 Twister impelementation -- we can generate 

long pseudo-random bitstrings quickly now (at least at the C 

level), but couldn't before 2.3.

----------------------------------------------------------------------

Comment By: Ronald L. Rivest (ronrivest)
Date: 2003-09-25 09:56

Message:
Logged In: YES 
user_id=863876

If the code is not going to be fixed, then the

documentation should be updated.  I am well aware

of other approaches to generating large random numbers,

but was misled by the documentation Python provides.  The

documentation should make it clear when the code violates

its "contract" (i.e. doesn't generate all integers in the range).

I prefer the code being fixed best, but also feel that the code 

should raise an exception if it can't honor the contract implied 

in its documentation.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 00:16

Message:
Logged In: YES 
user_id=31435

The cause is that randint takes a pseudo-random float (C 

double in [0, 1),), multiplies it by (hi-lo+1), then truncates 

and adds that to lo.  Since a double on your box almost 

certainly has only 53 bits of precision, and your multiplier 

effectively moves the radix point 64 bits "to the right", I 

expect the last 11 bits you see will always be 0.



Under Python 2.3, which uses the Mersenne Twister to 

generate random doubles, this does appear to be the case:



>>> from random import randint

>>> def f():

...     return randint(2**64, 2**65-1)

...

>>> hex(f())

'0x11EDD95B72CEF4000L'

>>> hex(f())

'0x1DD69BF4B39C65000L'

>>> hex(f())

'0x13328DC9C1C733800L'

>>> hex(f())

'0x1E65B47170C057800L'

>>>



Under earlier versions of Python, it may be even worse than 

that.



It takes a fundamentally different kind of algorithm to 

generate arbitrarily long random ints.  Here's a link to one 

such for Python:



http://www.faqts.com/knowledge_base/view.phtml/aid/4406



I doubt the implementation of randint() will change, since 

most people want fast-as-possible generation of mountains of 

small integers, and there's a tradeoff between catering to 

that and catering to extreme inputs.  The randint docs should 

change, though (I think randint() used to raise an exception 

when fed arguments as large as the ones you're using; I 

suspect, but don't know, that we lost the helpful exception 

as an unintended consequence of the long-term effort to 

eradicate the user-visible distinction between Python ints 

(machine C longs) and Python longs (unbounded integers)).



BTW, given what you're doing, you may want to install one of 

the Python wrappers for GNU GMP.  Python's unbounded-int 

arithmetic implementation is extremely portable and reliable, 

but buys those in part by not caring much about speed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 13:12:58 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 13:13:21 2003
Subject: [Python-bugs-list] [ python-Bugs-812353 ] a Py_DECREF() too much
Message-ID: <E1A2Zfm-0003Yz-00@sc8-sf-web2.sourceforge.net>

Bugs item #812353, was opened at 2003-09-25 05:23
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812353&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: a Py_DECREF() too much

Initial Comment:
frameobject.c:PyFrame_FastToLocals() has a

Py_DECREF(locals) that shouldn't be done. It didn't get

noticed because it is in an unprobable path.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812353&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 14:28:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 14:28:42 2003
Subject: [Python-bugs-list] [ python-Bugs-811681 ] Module asynchat not
	documented in 2.2.3
Message-ID: <E1A2ar0-0002sV-00@sc8-sf-web1.sourceforge.net>

Bugs item #811681, was opened at 2003-09-24 06:44
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811681&group_id=5470

Category: Documentation
>Group: Python 2.2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jarek Zgoda (zgoda)
Assigned to: A.M. Kuchling (akuchling)
Summary: Module asynchat not documented in 2.2.3

Initial Comment:
There's no documentation at all for this module, the

only reference seems to be docstrings in module and

part of 7th chapter of F. Lundh's Python Standard Library.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-25 14:28

Message:
Logged In: YES 
user_id=11375

I've added libasynchat.tex to the release22-maint branch in CVS.  

However, I can't regenerate the 2.2 docs on the python.org site (and a 2.

2.4 release seems unlikely), so I don't know when or if the module's 

documentation will actually become visible as part of the 2.2 docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811681&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 14:33:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 14:33:26 2003
Subject: [Python-bugs-list] [ python-Bugs-812325 ] tarfile violates bufsize
Message-ID: <E1A2avW-00034q-00@sc8-sf-web3.sourceforge.net>

Bugs item #812325, was opened at 2003-09-25 05:08
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812325&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Johan Fredrik ?hman (johanfo)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile violates bufsize

Initial Comment:
tf = tarfile.open(mode = 'w|gz', fileobj=fileName, 

bufsize=20*512)





The following text says how many bytes tarfile writes to 

the 'fileName.write' function. Notice that when closing 

the tarfile it writes way to many bytes!  This happes 

just sometimes. Some directories might work, other 

might not.





...

write len: 10240

write len: 10240

Closing archive

write len: 24815  # Somthing is wrong?

write len: 4

write len: 4

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-25 14:33

Message:
Logged In: YES 
user_id=11375

The close() method just writes the contents of self.buf to the file without 

breaking it up into blocks.  



Please try the attached patch and let us know if it fixes the problem.





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812325&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 14:37:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 14:37:54 2003
Subject: [Python-bugs-list] [ python-Bugs-810879 ] shutil.copyfile fails
	when dst exists read-only
Message-ID: <E1A2azq-0003MK-00@sc8-sf-web3.sourceforge.net>

Bugs item #810879, was opened at 2003-09-22 19:21
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810879&group_id=5470

Category: Windows
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Tim Peters (tim_one)
Summary: shutil.copyfile fails when dst exists read-only

Initial Comment:
(WIN32):  shutil.copyfile fails when the dst file already 

exists, but in read-only mode.  As the old file is

about to be

clobbered, a fix I've been using is to delete the

orginal file

first.   The attached my be inelegant, but works fine







----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-25 14:37

Message:
Logged In: YES 
user_id=11375

There's no uploaded file!  You have to check the

checkbox labeled "Check to Upload & Attach File"

when you upload a file.



Please try again.



(This is a SourceForge annoyance that we can do

nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810879&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 14:38:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 14:38:35 2003
Subject: [Python-bugs-list] [ python-Bugs-809174 ] xmlrpclib's functions
	dumps() and loads() not documented.
Message-ID: <E1A2b0Z-0003OO-00@sc8-sf-web3.sourceforge.net>

Bugs item #809174, was opened at 2003-09-19 05:41
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809174&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Arsalan Zaidi (azaidi)
>Assigned to: A.M. Kuchling (akuchling)
Summary: xmlrpclib's functions dumps() and loads() not documented.

Initial Comment:
The documentation does not appear for these two (more?)

functions in the python library reference...



I wouldn't have found them were it not for an article

on XML-RPC.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809174&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 14:42:42 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 15:04:09 2003
Subject: [Python-bugs-list] [ python-Bugs-812089 ] webbrowser.open_new()
	opens in an existing browser window
Message-ID: <E1A2b4c-0003Za-00@sc8-sf-web3.sourceforge.net>

Bugs item #812089, was opened at 2003-09-24 18:38
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Cohen (bram_cohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser.open_new() opens in an existing browser window

Initial Comment:
I'm running Windows with Mozilla (version 1.4) as my

default web browser. When I call webbrowser.open_new()

using Python 2.3 it opens the url in an existing window

(if there are any) rather than opening a new one like

it's supposed to. This might in some way be an

interaction with tabbed browsing, since I always have a

bunch of tabs open.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-25 14:42

Message:
Logged In: YES 
user_id=11375

It's invoking Mozilla with -remote "openURL(http://example.com, 

new-window)".  



According to http://www.mozilla.org/unix/remote.html, this should create 

a new window.  Try to run this command yourself and set if it opens a 

new tab; if it does, this is a Mozilla bug (or perhaps a feature?).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 17:52:02 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 17:52:06 2003
Subject: [Python-bugs-list] [ python-Bugs-812750 ] OSA support for
	properties broken
Message-ID: <E1A2e1q-0005Uo-00@sc8-sf-web3.sourceforge.net>

Bugs item #812750, was opened at 2003-09-25 23: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=812750&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: OSA support for properties broken

Initial Comment:
In 2.3 the handling of elements in OSA classes was 

revamped, so that accessing an element would cause an 

object of the right type (the Python class handling the OSA 

class for the element) was returned, but this wasn't done for 

properties. So at the moment it is possible to say 

"finder.get(finder.window(0).name)", but not 

"finder.get(finder.desktop.url)".



This seriously hampers the usefulness of the OSA stuff in 

some cases.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812750&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 19:43:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 19:43:58 2003
Subject: [Python-bugs-list] [ python-Bugs-812804 ] 2.3.1 re_test causes
	sigsegv
Message-ID: <E1A2flx-00028T-00@sc8-sf-web1.sourceforge.net>

Bugs item #812804, was opened at 2003-09-26 01: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=812804&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin L?thi (tnoo)
Assigned to: Fredrik Lundh (effbot)
Summary: 2.3.1 re_test causes sigsegv

Initial Comment:
I compiled Python 2.3.1 on a SuSE Linux 8.1 system 
 
Python 2.3.1 (#1, Sep 25 2003, 14:13:07)  
[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2 
 
running the test, I get sigsev 
 
python test/test_re.py 
test_anyall (__main__.ReTests) ... ok 
test_basic_re_sub (__main__.ReTests) ... ok 
test_bigcharset (__main__.ReTests) ... ok 
test_bug_113254 (__main__.ReTests) ... ok 
test_bug_114660 (__main__.ReTests) ... ok 
test_bug_117612 (__main__.ReTests) ... ok 
Segmentation fault 
 
Thanks 
 
Martin 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812804&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 20:07:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 20:07:41 2003
Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even
Message-ID: <E1A2g92-000373-00@sc8-sf-web1.sourceforge.net>

Bugs item #812202, was opened at 2003-09-25 00:52
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: randint is always even

Initial Comment:
The result of 

    random.randint(2**64,2**65-1) 

is always even!



(I was trying to find some large prime numbers, and

was puzzled by the fact that none were turning

up.  Finally, I discovered that randint wasn't really

returning "random" integers as desired, but only

even ones.)



I'm not sure what the cause of the problem is, but

randint should work properly, even when the given

endpoints are large...



Thanks...



        Ron Rivest



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-25 20:07

Message:
Logged In: YES 
user_id=31435

Ya, something like that indeed.  You might enjoy writing the 

core in C <wink>.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-25 13:10

Message:
Logged In: YES 
user_id=80475

If the range is too large, instead of raising an exception,

how about  

calling a _randbigint routine that builds up the random

selection using repeated calls to the underlying generator. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 11:23

Message:
Logged In: YES 
user_id=31435

No disagreement here.  I'd rather fix the code than the docs, 

and a fix can take two forms:  raise an exception if the full 

range of ints can't be delivered, or deliver the full range of 

ints.



If anyone wants to take this on, I think the latter ("do a right 

thing") may be much more practical than it used to be, given 

the new-in-2.3 Twister impelementation -- we can generate 

long pseudo-random bitstrings quickly now (at least at the C 

level), but couldn't before 2.3.

----------------------------------------------------------------------

Comment By: Ronald L. Rivest (ronrivest)
Date: 2003-09-25 10:56

Message:
Logged In: YES 
user_id=863876

If the code is not going to be fixed, then the

documentation should be updated.  I am well aware

of other approaches to generating large random numbers,

but was misled by the documentation Python provides.  The

documentation should make it clear when the code violates

its "contract" (i.e. doesn't generate all integers in the range).

I prefer the code being fixed best, but also feel that the code 

should raise an exception if it can't honor the contract implied 

in its documentation.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 01:16

Message:
Logged In: YES 
user_id=31435

The cause is that randint takes a pseudo-random float (C 

double in [0, 1),), multiplies it by (hi-lo+1), then truncates 

and adds that to lo.  Since a double on your box almost 

certainly has only 53 bits of precision, and your multiplier 

effectively moves the radix point 64 bits "to the right", I 

expect the last 11 bits you see will always be 0.



Under Python 2.3, which uses the Mersenne Twister to 

generate random doubles, this does appear to be the case:



>>> from random import randint

>>> def f():

...     return randint(2**64, 2**65-1)

...

>>> hex(f())

'0x11EDD95B72CEF4000L'

>>> hex(f())

'0x1DD69BF4B39C65000L'

>>> hex(f())

'0x13328DC9C1C733800L'

>>> hex(f())

'0x1E65B47170C057800L'

>>>



Under earlier versions of Python, it may be even worse than 

that.



It takes a fundamentally different kind of algorithm to 

generate arbitrarily long random ints.  Here's a link to one 

such for Python:



http://www.faqts.com/knowledge_base/view.phtml/aid/4406



I doubt the implementation of randint() will change, since 

most people want fast-as-possible generation of mountains of 

small integers, and there's a tradeoff between catering to 

that and catering to extreme inputs.  The randint docs should 

change, though (I think randint() used to raise an exception 

when fed arguments as large as the ones you're using; I 

suspect, but don't know, that we lost the helpful exception 

as an unintended consequence of the long-term effort to 

eradicate the user-visible distinction between Python ints 

(machine C longs) and Python longs (unbounded integers)).



BTW, given what you're doing, you may want to install one of 

the Python wrappers for GNU GMP.  Python's unbounded-int 

arithmetic implementation is extremely portable and reliable, 

but buys those in part by not caring much about speed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

From noreply at sourceforge.net  Thu Sep 25 21:34:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Sep 25 21:34:21 2003
Subject: [Python-bugs-list] [ python-Bugs-812089 ] webbrowser.open_new()
	opens in an existing browser window
Message-ID: <E1A2hUr-0005C7-00@sc8-sf-web3.sourceforge.net>

Bugs item #812089, was opened at 2003-09-24 15:38
Message generated for change (Comment added) made by bram_cohen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Cohen (bram_cohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser.open_new() opens in an existing browser window

Initial Comment:
I'm running Windows with Mozilla (version 1.4) as my

default web browser. When I call webbrowser.open_new()

using Python 2.3 it opens the url in an existing window

(if there are any) rather than opening a new one like

it's supposed to. This might in some way be an

interaction with tabbed browsing, since I always have a

bunch of tabs open.

----------------------------------------------------------------------

>Comment By: Bram Cohen (bram_cohen)
Date: 2003-09-25 18:34

Message:
Logged In: YES 
user_id=52561

This is very bizzare. When I execute this command -



C:\>"Program Files\mozilla.org\Mozilla\mozilla.exe" -remote

"openURL(http://www.bitconjurer.org/, new-window)"



it opens a new browser window with no page open in it. Are

you sure it's executing the command you said?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-25 11:42

Message:
Logged In: YES 
user_id=11375

It's invoking Mozilla with -remote "openURL(http://example.com, 

new-window)".  



According to http://www.mozilla.org/unix/remote.html, this should create 

a new window.  Try to run this command yourself and set if it opens a 

new tab; if it does, this is a Mozilla bug (or perhaps a feature?).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 00:03:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 00:03:17 2003
Subject: [Python-bugs-list] [ python-Bugs-811294 ] dis.disassemble_string()
	broken
Message-ID: <E1A2jp3-0001ti-00@sc8-sf-web3.sourceforge.net>

Bugs item #811294, was opened at 2003-09-23 12:23
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: dis.disassemble_string() broken

Initial Comment:
dis.disassemble_string(), called by

dis.dis("some-bytecode-string"), still relies on the

dead SET_LINENO opcode.



I'll propose a patch for this at some later time.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 00:04:03 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 00:04:08 2003
Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even
Message-ID: <E1A2jpr-0001vc-00@sc8-sf-web3.sourceforge.net>

Bugs item #812202, was opened at 2003-09-24 23:52
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: randint is always even

Initial Comment:
The result of 

    random.randint(2**64,2**65-1) 

is always even!



(I was trying to find some large prime numbers, and

was puzzled by the fact that none were turning

up.  Finally, I discovered that randint wasn't really

returning "random" integers as desired, but only

even ones.)



I'm not sure what the cause of the problem is, but

randint should work properly, even when the given

endpoints are large...



Thanks...



        Ron Rivest



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 19:07

Message:
Logged In: YES 
user_id=31435

Ya, something like that indeed.  You might enjoy writing the 

core in C <wink>.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-25 12:10

Message:
Logged In: YES 
user_id=80475

If the range is too large, instead of raising an exception,

how about  

calling a _randbigint routine that builds up the random

selection using repeated calls to the underlying generator. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 10:23

Message:
Logged In: YES 
user_id=31435

No disagreement here.  I'd rather fix the code than the docs, 

and a fix can take two forms:  raise an exception if the full 

range of ints can't be delivered, or deliver the full range of 

ints.



If anyone wants to take this on, I think the latter ("do a right 

thing") may be much more practical than it used to be, given 

the new-in-2.3 Twister impelementation -- we can generate 

long pseudo-random bitstrings quickly now (at least at the C 

level), but couldn't before 2.3.

----------------------------------------------------------------------

Comment By: Ronald L. Rivest (ronrivest)
Date: 2003-09-25 09:56

Message:
Logged In: YES 
user_id=863876

If the code is not going to be fixed, then the

documentation should be updated.  I am well aware

of other approaches to generating large random numbers,

but was misled by the documentation Python provides.  The

documentation should make it clear when the code violates

its "contract" (i.e. doesn't generate all integers in the range).

I prefer the code being fixed best, but also feel that the code 

should raise an exception if it can't honor the contract implied 

in its documentation.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 00:16

Message:
Logged In: YES 
user_id=31435

The cause is that randint takes a pseudo-random float (C 

double in [0, 1),), multiplies it by (hi-lo+1), then truncates 

and adds that to lo.  Since a double on your box almost 

certainly has only 53 bits of precision, and your multiplier 

effectively moves the radix point 64 bits "to the right", I 

expect the last 11 bits you see will always be 0.



Under Python 2.3, which uses the Mersenne Twister to 

generate random doubles, this does appear to be the case:



>>> from random import randint

>>> def f():

...     return randint(2**64, 2**65-1)

...

>>> hex(f())

'0x11EDD95B72CEF4000L'

>>> hex(f())

'0x1DD69BF4B39C65000L'

>>> hex(f())

'0x13328DC9C1C733800L'

>>> hex(f())

'0x1E65B47170C057800L'

>>>



Under earlier versions of Python, it may be even worse than 

that.



It takes a fundamentally different kind of algorithm to 

generate arbitrarily long random ints.  Here's a link to one 

such for Python:



http://www.faqts.com/knowledge_base/view.phtml/aid/4406



I doubt the implementation of randint() will change, since 

most people want fast-as-possible generation of mountains of 

small integers, and there's a tradeoff between catering to 

that and catering to extreme inputs.  The randint docs should 

change, though (I think randint() used to raise an exception 

when fed arguments as large as the ones you're using; I 

suspect, but don't know, that we lost the helpful exception 

as an unintended consequence of the long-term effort to 

eradicate the user-visible distinction between Python ints 

(machine C longs) and Python longs (unbounded integers)).



BTW, given what you're doing, you may want to install one of 

the Python wrappers for GNU GMP.  Python's unbounded-int 

arithmetic implementation is extremely portable and reliable, 

but buys those in part by not caring much about speed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 00:35:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 00:35:42 2003
Subject: [Python-bugs-list] [ python-Bugs-811604 ] "string".split behaviour
	for empty strings
Message-ID: <E1A2kKO-00046p-00@sc8-sf-web1.sourceforge.net>

Bugs item #811604, was opened at 2003-09-24 03:20
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: T.Meyarivan (meyarivan)
Assigned to: Nobody/Anonymous (nobody)
Summary: "string".split behaviour for empty strings

Initial Comment:


"".split() -> []



"".split(' ') -> ['']



It is not clear from the documentation as to what is

the defined behaviour in the above case. To say the

least, it is 

completely counter-intuitive..(splitting an empty

string should

return the list [''] in both cases).



>From stringobject.c, the behaviour of split_whitespace

(i.e split called without sep) and string_split (split

called with sep) is different for empty

strings..perhaps the function split_whitespace needs to

be patched.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-25 23:35

Message:
Logged In: YES 
user_id=80475

And so it is.  The whitespace version (no args) and the

specified separator version work differently -- the second

version can never return an empty list.



This code has been around for a good while and it is likely

that much code relies on the behavior, so I recommend

classifying it as a beauty spot and closing the bug.



"One man's bug is another man's feature"



----------------------------------------------------------------------

Comment By: T.Meyarivan (meyarivan)
Date: 2003-09-24 03:51

Message:
Logged In: YES 
user_id=30470

"".split(None) -> [] 



which is expected because in the case when no sep is

specified and when sep == None, split_whitespace is called..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 01:05:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 01:05:15 2003
Subject: [Python-bugs-list] [ python-Bugs-812353 ] a Py_DECREF() too much
Message-ID: <E1A2kmy-0001Aw-00@sc8-sf-web2.sourceforge.net>

Bugs item #812353, was opened at 2003-09-25 05:23
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812353&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Jeremy Hylton (jhylton)
Summary: a Py_DECREF() too much

Initial Comment:
frameobject.c:PyFrame_FastToLocals() has a

Py_DECREF(locals) that shouldn't be done. It didn't get

noticed because it is in an unprobable path.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-26 00:05

Message:
Logged In: YES 
user_id=80475

Jeremy, this is your code fragment.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812353&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 04:00:03 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 04:00:10 2003
Subject: [Python-bugs-list] [ python-Bugs-812936 ] Wrong documentation for
	RotatingFileHandler
Message-ID: <E1A2nWF-0007wh-00@sc8-sf-web2.sourceforge.net>

Bugs item #812936, was opened at 2003-09-26 12: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=812936&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong documentation for RotatingFileHandler

Initial Comment:
Docs describe wrong behavior of the

RotatingFileHandler. Right documentation in

RotatingFileHandler.__init__.__doc__

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812936&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 04:06:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 04:07:01 2003
Subject: [Python-bugs-list] [ python-Bugs-812936 ] Wrong documentation for
	RotatingFileHandler
Message-ID: <E1A2nca-00028g-00@sc8-sf-web3.sourceforge.net>

Bugs item #812936, was opened at 2003-09-26 12:00
Message generated for change (Comment added) made by hdima
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812936&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong documentation for RotatingFileHandler

Initial Comment:
Docs describe wrong behavior of the

RotatingFileHandler. Right documentation in

RotatingFileHandler.__init__.__doc__

----------------------------------------------------------------------

>Comment By: Dmitry Vasiliev (hdima)
Date: 2003-09-26 12:06

Message:
Logged In: YES 
user_id=388573

Full path: logging.handlers.RotatingFileHandler

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812936&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 06:20:09 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 06:20:14 2003
Subject: [Python-bugs-list] [ python-Bugs-811294 ] dis.disassemble_string()
	broken
Message-ID: <E1A2php-0008OB-00@sc8-sf-web3.sourceforge.net>

Bugs item #811294, was opened at 2003-09-23 17:23
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Raymond Hettinger (rhettinger)
Summary: dis.disassemble_string() broken

Initial Comment:
dis.disassemble_string(), called by

dis.dis("some-bytecode-string"), still relies on the

dead SET_LINENO opcode.



I'll propose a patch for this at some later time.

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2003-09-26 10:20

Message:
Logged In: YES 
user_id=4771

ah well. I didn't realize that disassemble_string() never

tried to *display* line numbers. It only detects SET_LINENO

so that it can write a nice blank line before it.



Attached a patch that removes this behavior (no longer

possible in a function that doesn't have access to a

co_lnotab).



I'll submit another more constructive patch anyway, in which

I try to factor out the subtle decoding algorithm for

co_lnotabs into an easy-to-use generator.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 06:33:58 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 06:34:02 2003
Subject: [Python-bugs-list] [ python-Bugs-812986 ] turtle.py deferres exec
	of stmnts with tracer(0)
Message-ID: <E1A2pvC-0001Bt-00@sc8-sf-web1.sourceforge.net>

Bugs item #812986, was opened at 2003-09-26 12: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=812986&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Martin v. L?wis (loewis)
Summary: turtle.py deferres exec of stmnts with tracer(0)

Initial Comment:
interactive use of turtle.py becomes impossible,

e.g.when issuing tracer(0) because in this

case apparently updating of Canvas-Widget is

deferred ...

... until the next tracer(1)

(one can observe this when running the demo() )



Inserting a _canvas.update() call in _draw_turtle()

for the case that tracing is off seems to work:



    def _draw_turtle(self,position=[]):

        if not self._tracing:

            self._canvas.update()  # <== insert this line!

            return

        if position == []:  # etc.etc.





I have attached a corrected version as turtle_.py



Gregor Lingl 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812986&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 07:04:54 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 07:04:59 2003
Subject: [Python-bugs-list] [ python-Bugs-811604 ] "string".split behaviour
	for empty strings
Message-ID: <E1A2qP8-0007u6-00@sc8-sf-web2.sourceforge.net>

Bugs item #811604, was opened at 2003-09-24 13:50
Message generated for change (Comment added) made by meyarivan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: T.Meyarivan (meyarivan)
Assigned to: Nobody/Anonymous (nobody)
Summary: "string".split behaviour for empty strings

Initial Comment:


"".split() -> []



"".split(' ') -> ['']



It is not clear from the documentation as to what is

the defined behaviour in the above case. To say the

least, it is 

completely counter-intuitive..(splitting an empty

string should

return the list [''] in both cases).



>From stringobject.c, the behaviour of split_whitespace

(i.e split called without sep) and string_split (split

called with sep) is different for empty

strings..perhaps the function split_whitespace needs to

be patched.

----------------------------------------------------------------------

>Comment By: T.Meyarivan (meyarivan)
Date: 2003-09-26 16:34

Message:
Logged In: YES 
user_id=30470



Thats so counter intuitive.. :-(



At least the documentation should specify the fact that the

behaviour of "string".split for empty strings is so and so....



The reason this probably never came up ( or mostly ignored

by majority ) is that people probably check if the string is

empty before proceeding to process it.. 



I am not closing the bug before the specific behaviour of

"string".split for empty strings gets to the docs..

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-26 10:05

Message:
Logged In: YES 
user_id=80475

And so it is.  The whitespace version (no args) and the

specified separator version work differently -- the second

version can never return an empty list.



This code has been around for a good while and it is likely

that much code relies on the behavior, so I recommend

classifying it as a beauty spot and closing the bug.



"One man's bug is another man's feature"



----------------------------------------------------------------------

Comment By: T.Meyarivan (meyarivan)
Date: 2003-09-24 14:21

Message:
Logged In: YES 
user_id=30470

"".split(None) -> [] 



which is expected because in the case when no sep is

specified and when sep == None, split_whitespace is called..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 07:07:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 07:07:45 2003
Subject: [Python-bugs-list] [ python-Bugs-811294 ] dis.disassemble_string()
	broken
Message-ID: <E1A2qRg-00082Q-00@sc8-sf-web2.sourceforge.net>

Bugs item #811294, was opened at 2003-09-23 17:23
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Raymond Hettinger (rhettinger)
Summary: dis.disassemble_string() broken

Initial Comment:
dis.disassemble_string(), called by

dis.dis("some-bytecode-string"), still relies on the

dead SET_LINENO opcode.



I'll propose a patch for this at some later time.

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2003-09-26 11:07

Message:
Logged In: YES 
user_id=4771

Here is a patch with a separate generator function that

enumerates all (offset, lineno) pairs, as they where in the

compiler before they got obfuscated into lnotab. For

simplicity, disassemble() just turns them into a dict, so it

didn't really have to be a generator at all, but it is just

nicer this way. Maybe pdb could use it too.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-09-26 10:20

Message:
Logged In: YES 
user_id=4771

ah well. I didn't realize that disassemble_string() never

tried to *display* line numbers. It only detects SET_LINENO

so that it can write a nice blank line before it.



Attached a patch that removes this behavior (no longer

possible in a function that doesn't have access to a

co_lnotab).



I'll submit another more constructive patch anyway, in which

I try to factor out the subtle decoding algorithm for

co_lnotabs into an easy-to-use generator.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 07:39:35 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 07:39:44 2003
Subject: [Python-bugs-list] [ python-Bugs-812089 ] webbrowser.open_new()
	opens in an existing browser window
Message-ID: <E1A2qwh-00018v-00@sc8-sf-web2.sourceforge.net>

Bugs item #812089, was opened at 2003-09-24 18:38
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Cohen (bram_cohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser.open_new() opens in an existing browser window

Initial Comment:
I'm running Windows with Mozilla (version 1.4) as my

default web browser. When I call webbrowser.open_new()

using Python 2.3 it opens the url in an existing window

(if there are any) rather than opening a new one like

it's supposed to. This might in some way be an

interaction with tabbed browsing, since I always have a

bunch of tabs open.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-26 07:39

Message:
Logged In: YES 
user_id=11375

Looking at the code. this is what webbrowser.py should be doing.  I can't 

debug this problem, because I'm not seeing it on my Linux box with 

Mozilla 1.4.  



I suggest you make a copy of webbrowser.py and insert debugging prints 

into it.  Is it instantiating the Netscape class, as I expect?  And what 

arguments is it really using?



----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2003-09-25 21:34

Message:
Logged In: YES 
user_id=52561

This is very bizzare. When I execute this command -



C:\>"Program Files\mozilla.org\Mozilla\mozilla.exe" -remote

"openURL(http://www.bitconjurer.org/, new-window)"



it opens a new browser window with no page open in it. Are

you sure it's executing the command you said?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-25 14:42

Message:
Logged In: YES 
user_id=11375

It's invoking Mozilla with -remote "openURL(http://example.com, 

new-window)".  



According to http://www.mozilla.org/unix/remote.html, this should create 

a new window.  Try to run this command yourself and set if it opens a 

new tab; if it does, this is a Mozilla bug (or perhaps a feature?).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 08:37:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 08:37:05 2003
Subject: [Python-bugs-list] [ python-Bugs-812089 ] webbrowser.open_new()
	opens in an existing browser window
Message-ID: <E1A2rqG-0002c5-00@sc8-sf-web2.sourceforge.net>

Bugs item #812089, was opened at 2003-09-25 00:38
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Cohen (bram_cohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser.open_new() opens in an existing browser window

Initial Comment:
I'm running Windows with Mozilla (version 1.4) as my

default web browser. When I call webbrowser.open_new()

using Python 2.3 it opens the url in an existing window

(if there are any) rather than opening a new one like

it's supposed to. This might in some way be an

interaction with tabbed browsing, since I always have a

bunch of tabs open.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-09-26 14:37

Message:
Logged In: YES 
user_id=11105

I can confirm (and possibly explain) everything that Bram

reports.



1. The '-remote' switch on the command line for mozilla only

works on Unix/Linux, as documented in

http://www.mozilla.org/docs/command-line-args.html. So

executing the command line



"Program Files\mozilla.org\Mozilla\mozilla.exe" - remote

"openURL(...)"



doesn't load this url, it only starts mozilla.



2. webbrowser.py on Windows (for me at least) doesn't

instantiate the Netscape class - it uses WindowsDefault,

which simply uses startfile(url). So, the 'new' and

'autoraise' arguments are not even used.



Looking at the docs for the webbrowser module, the words 'if

possible' are used very often. So it seems, it simply is not

possible on windows.



(The only thing which should be fixed in the docs is that

the win32api and win32con modules are mentioned, but they

are not used in the code - so this should be removed IMO).



I suggest to close the bug if noone comes up with a patch.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-26 13:39

Message:
Logged In: YES 
user_id=11375

Looking at the code. this is what webbrowser.py should be doing.  I can't 

debug this problem, because I'm not seeing it on my Linux box with 

Mozilla 1.4.  



I suggest you make a copy of webbrowser.py and insert debugging prints 

into it.  Is it instantiating the Netscape class, as I expect?  And what 

arguments is it really using?



----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2003-09-26 03:34

Message:
Logged In: YES 
user_id=52561

This is very bizzare. When I execute this command -



C:\>"Program Files\mozilla.org\Mozilla\mozilla.exe" -remote

"openURL(http://www.bitconjurer.org/, new-window)"



it opens a new browser window with no page open in it. Are

you sure it's executing the command you said?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-25 20:42

Message:
Logged In: YES 
user_id=11375

It's invoking Mozilla with -remote "openURL(http://example.com, 

new-window)".  



According to http://www.mozilla.org/unix/remote.html, this should create 

a new window.  Try to run this command yourself and set if it opens a 

new tab; if it does, this is a Mozilla bug (or perhaps a feature?).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 09:19:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 09:19:32 2003
Subject: [Python-bugs-list] [ python-Bugs-811082 ] test_tempfile fails on
	windows if space in install path
Message-ID: <E1A2sVE-0000uv-00@sc8-sf-web1.sourceforge.net>

Bugs item #811082, was opened at 2003-09-23 12:31
Message generated for change (Comment added) made by midramas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_tempfile fails on windows if space in install path

Initial Comment:
test_tempfile fails for me on XP when Python is

installed into

\Program Files\Python2.3



I can't cut'n'paste from the window, but the error is

C:\Program: Can't open file 'Files\Python23\python.exe'

from test_tempfile, line 299.



----------------------------------------------------------------------

Comment By: Michael Bartl (midramas)
Date: 2003-09-26 15:19

Message:
Logged In: YES 
user_id=31511

I'm not at home so I have to paste it in here (could provide a 

patch later). Took me ~2 hours to fix this one (horrible 

win32). For more information visit 

http://mail.python.org/pipermail/python-dev/2003-

August/037556.html:



test_tempfile.py (295-297):



  decorated = '"%s"' % sys.executable

  tester = '"%s"' % tester

  retval = os.spawnl(os.P_WAIT, sys.executable, decorated, 

tester, v, fd)

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 12:44

Message:
Logged In: YES 
user_id=29957

Attempting the obvious fix of " " quoting sys.executable

gives me a Invalid argument error from os.spawnv, so that's

my windows knowledge exhausted. 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 12:36

Message:
Logged In: YES 
user_id=29957

test_popen seems to have the same problem. 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 09:31:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 09:32:03 2003
Subject: [Python-bugs-list] [ python-Bugs-812936 ] Wrong documentation for
	RotatingFileHandler
Message-ID: <E1A2shL-0001ba-00@sc8-sf-web1.sourceforge.net>

Bugs item #812936, was opened at 2003-09-26 04:00
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812936&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong documentation for RotatingFileHandler

Initial Comment:
Docs describe wrong behavior of the

RotatingFileHandler. Right documentation in

RotatingFileHandler.__init__.__doc__

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-26 09:31

Message:
Logged In: YES 
user_id=11375

Please be more specific about what's wrong.  As far as I can tell, the 

documentation is just a slightly edited version of that docstring.



----------------------------------------------------------------------

Comment By: Dmitry Vasiliev (hdima)
Date: 2003-09-26 04:06

Message:
Logged In: YES 
user_id=388573

Full path: logging.handlers.RotatingFileHandler

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812936&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 09:39:12 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 09:39:28 2003
Subject: [Python-bugs-list] [ python-Bugs-812936 ] Wrong documentation for
	RotatingFileHandler
Message-ID: <E1A2soS-0001B6-00@sc8-sf-web3.sourceforge.net>

Bugs item #812936, was opened at 2003-09-26 04:00
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812936&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong documentation for RotatingFileHandler

Initial Comment:
Docs describe wrong behavior of the

RotatingFileHandler. Right documentation in

RotatingFileHandler.__init__.__doc__

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-26 09:39

Message:
Logged In: YES 
user_id=11375

Oh, hang on, I see what you mean; it doesn't write to app.log.1, .2, it 

renames them and always writes to app.log.  Editing it now...

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-26 09:31

Message:
Logged In: YES 
user_id=11375

Please be more specific about what's wrong.  As far as I can tell, the 

documentation is just a slightly edited version of that docstring.



----------------------------------------------------------------------

Comment By: Dmitry Vasiliev (hdima)
Date: 2003-09-26 04:06

Message:
Logged In: YES 
user_id=388573

Full path: logging.handlers.RotatingFileHandler

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812936&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 09:48:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 09:48:46 2003
Subject: [Python-bugs-list] [ python-Bugs-812936 ] Wrong documentation for
	RotatingFileHandler
Message-ID: <E1A2sxZ-0001ia-00@sc8-sf-web3.sourceforge.net>

Bugs item #812936, was opened at 2003-09-26 04:00
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812936&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong documentation for RotatingFileHandler

Initial Comment:
Docs describe wrong behavior of the

RotatingFileHandler. Right documentation in

RotatingFileHandler.__init__.__doc__

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-26 09:48

Message:
Logged In: YES 
user_id=11375

Checked in as rev. 1.14 of liblogging.tex.  Thanks for reporting this!

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-26 09:39

Message:
Logged In: YES 
user_id=11375

Oh, hang on, I see what you mean; it doesn't write to app.log.1, .2, it 

renames them and always writes to app.log.  Editing it now...

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-26 09:31

Message:
Logged In: YES 
user_id=11375

Please be more specific about what's wrong.  As far as I can tell, the 

documentation is just a slightly edited version of that docstring.



----------------------------------------------------------------------

Comment By: Dmitry Vasiliev (hdima)
Date: 2003-09-26 04:06

Message:
Logged In: YES 
user_id=388573

Full path: logging.handlers.RotatingFileHandler

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812936&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 12:37:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 12:37:41 2003
Subject: [Python-bugs-list] [ python-Bugs-813159 ] duplicated return
	statement in unittest.py
Message-ID: <E1A2vay-0005Mg-00@sc8-sf-web2.sourceforge.net>

Bugs item #813159, was opened at 2003-09-27 01:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813159&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: duplicated return statement in unittest.py

Initial Comment:
After Steve Purcell's recent commit to unittest.py

(Revision 1.27), TestLoader.loadTestsFromName 

has a duplicated return statement.



        elif type(obj) == types.UnboundMethodType:

            return parent(obj.__name__)

            return obj.im_class(obj.__name__)

        elif isinstance(obj, unittest.TestSuite):



Somehow it doesn't raise SyntaxError, but I think it 

needs to be fixed.

obj.im_class(obj.__name__) is never returned.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813159&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:04:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:04:57 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A2w1I-0003zm-00@sc8-sf-web1.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 21:10
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:13:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:13:26 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A2w9U-0007PX-00@sc8-sf-web2.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 23:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:13

Message:
Logged In: YES 
user_id=29957

There's three ways we can fix this:

1. Hand-edit configure after running autoconf (yuk)

2. Run a CVS version of autoconf (yuk)

3. Supply an aclocal.m4 in the same way that the gcc guys

used to fix the problem (a bit yuk).



The aclocal fix would only be needed until the next release

of autoconf is out. I've attached an aclocal.m4 that

includes the GCC fix. Trying it here shows that it generates

a "fixed" configure scipt - I've not yet logged onto the HP

testdrive boxes to confirm it absolutely works, but it looks

like the fixes I did by hand in order to get it to work.



MvL, your thoughts? You seem to be the local autoconf guru... 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-24 00:26

Message:
Logged In: YES 
user_id=29957

mwh points out that the snakefarm is having the same problem:

http://www.lysator.liu.se/xenofarm/python/files/792_10/python-testlog.txt

(we discovered and debugged this on one of the

DEC^WDigital^WCompaq^WHP "testdrive" boxes)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:58

Message:
Logged In: YES 
user_id=29957

Oh, and the problem also occurs if you use gcc instead of cc -Ae





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:56

Message:
Logged In: YES 
user_id=29957

the functions that fail (erroneously) are

HAVE_CLOCK HAVE_GETTIMEOFDAY HAVE_MKTIME HAVE_SELECT

HAVE_STRFTIME HAVE_STRPTIME HAVE_UTIMES





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:14:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:14:20 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A2wAO-0007Tj-00@sc8-sf-web2.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 23:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:14

Message:
Logged In: YES 
user_id=29957

argh. sf tracker strikes again. this time for sure.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:13

Message:
Logged In: YES 
user_id=29957

There's three ways we can fix this:

1. Hand-edit configure after running autoconf (yuk)

2. Run a CVS version of autoconf (yuk)

3. Supply an aclocal.m4 in the same way that the gcc guys

used to fix the problem (a bit yuk).



The aclocal fix would only be needed until the next release

of autoconf is out. I've attached an aclocal.m4 that

includes the GCC fix. Trying it here shows that it generates

a "fixed" configure scipt - I've not yet logged onto the HP

testdrive boxes to confirm it absolutely works, but it looks

like the fixes I did by hand in order to get it to work.



MvL, your thoughts? You seem to be the local autoconf guru... 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-24 00:26

Message:
Logged In: YES 
user_id=29957

mwh points out that the snakefarm is having the same problem:

http://www.lysator.liu.se/xenofarm/python/files/792_10/python-testlog.txt

(we discovered and debugged this on one of the

DEC^WDigital^WCompaq^WHP "testdrive" boxes)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:58

Message:
Logged In: YES 
user_id=29957

Oh, and the problem also occurs if you use gcc instead of cc -Ae





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:56

Message:
Logged In: YES 
user_id=29957

the functions that fail (erroneously) are

HAVE_CLOCK HAVE_GETTIMEOFDAY HAVE_MKTIME HAVE_SELECT

HAVE_STRFTIME HAVE_STRPTIME HAVE_UTIMES





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:21:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:21:36 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A2wHT-0007qE-00@sc8-sf-web2.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 12:10
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2003-09-26 18:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.



I don't think configure was broken with Python 2.3 - and it 

was with 2.3 that I first noticed the problem.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:30:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:30:22 2003
Subject: [Python-bugs-list] [ python-Bugs-811844 ] readline+no threads =
	core dump
Message-ID: <E1A2wPw-0005BC-00@sc8-sf-web1.sourceforge.net>

Bugs item #811844, was opened at 2003-09-25 01:46
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811844&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TEd Drain (teddrain)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline+no threads = core dump

Initial Comment:
Build 2.3 or 2.3.1 on linux with the following

configure command:



./configure --enable-shared --without-threads



Try running the rlcompleter example.  If you hit TAB

with completions enabled, you'll get a core dump after

you hit return on that line.  Works fine if I build

with threads enabled.  



This is a major problem for me since we have to deliver

our software on machines that do not support pthreads

(hpux 10.2 for example).



~: uname -a

Linux XXXX 2.4.9-21 #1 Thu Jan 17 14:16:30 EST 2002

i686 unknown



~/builds-gcc2: python

Python 2.3.1 (#1, Sep 24 2003, 08:13:26)

[GCC 2.95.3 20010315 (release)] on linux2

Type "help", "copyright", "credits" or "license" for

more information.

>>> import readline, rlcompleter

>>> readline.parse_and_bind("tab: complete")

>>> readline.par<TAB> se_and_bind()

Fatal Python error: PyThreadState_Get: no current thread

Abort (core dumped)



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:30

Message:
Logged In: YES 
user_id=29957

Assuming the problem is just a shallow one, would the

following patch "fix" the problem?



It makes the crashes go away for me.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-25 02:17

Message:
Logged In: YES 
user_id=6656

i see this too.



oops.  hopefully easy to fix...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811844&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:30:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:31:01 2003
Subject: [Python-bugs-list] [ python-Bugs-743692 ] test_socketserver: Fatal
	error: Invalid thread state
Message-ID: <E1A2wQR-0008Nj-00@sc8-sf-web2.sourceforge.net>

Bugs item #743692, was opened at 2003-05-26 16:30
Message generated for change (Comment added) made by jcea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Mark Hammond (mhammond)
Summary: test_socketserver: Fatal error: Invalid thread state

Initial Comment:
Mark, I believe this started happening on Solaris 8

(only AFAIK) after some of your thread changes.  Do you

have access to a Solaris 8 box?  I can try to debug if

you give me some ideas.  This is happening on the snake

farm.  Actually, we have a Sol8 box here.  I can try to

fire it up and see if the problem exists on that box. 

If so, I can give you access.



When running test_socketserver, some way through the

test there's the fatal error.



Fatal Python error: Invalid thread state for this thread



Let me know what more info I can provide.  Sorry, short

on ideas/time, just wanted to get this documented.

----------------------------------------------------------------------

Comment By: Jes?s Cea Avi?n (jcea)
Date: 2003-09-26 19:30

Message:
Logged In: YES 
user_id=97460

With Python 2.3.1 out, is this bug still alive?

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-07-29 05:59

Message:
Logged In: YES 
user_id=12800

What can we do about this for 2.3 final?  Probably nothing

given the deadline.  Lowering the priority.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-10 06:25

Message:
Logged In: YES 
user_id=33168

I changed the DELAY in the test to be zero.  The test fails,

but it's interesting that it also hangs in

lock_PyThread_acquire_lock (line 63):



Lib/threading.py (195): wait

Lib/threading.py (468): join

Lib/threading.py (564): __exitfunc

Lib/atexit.py (11): _run_exitfuncs



In looking at threadmodule.c I notice that most of the time 

Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS is not used

around PyThread_acquire_lock, but it is in

lock_PyThread_acquire_lock.  I'm not sure all of these are safe.



Here's some more detail on the Sun:



test_socketserver

ADDR = ('localhost', 17231)

CLASS = SocketServer.ForkingTCPServer

server created

thread: creating server

server running

thread: serving three times

test client 0

Fatal Python error: Invalid thread state for this thread



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-10 06:08

Message:
Logged In: YES 
user_id=33168

Doesn't seem real helpful.  I'll see if I can do more on this.



#0  PyThreadState_Swap (new=0x2b1160) at Python/pystate.c:274

#1  PyEval_RestoreThread (tstate=0x2b1160) at Python/ceval.c:391

#2  floatsleep (secs=0) at Modules/timemodule.c:831

#3  time_sleep (self=0x0, args=0x2b3968) at

Modules/timemodule.c:208

#4  PyCFunction_Call (func=0x2bd938, arg=0x2b3968, kw=0x0)

at Objects/methodobject.c:73

#5  call_function (pp_stack=0xdf142f04, oparg=1) at

Python/ceval.c:3439

#6  eval_frame (f=0x2890c8) at Python/ceval.c:2116



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-07-08 06:39

Message:
Logged In: YES 
user_id=14198

I don't have access to a sol8 box, nor would I really know

what to do when I got there :)  Any chance of a stack-trace?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:32:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:32:40 2003
Subject: [Python-bugs-list] [ python-Bugs-812804 ] 2.3.1 re_test causes
	sigsegv
Message-ID: <E1A2wS7-0005Gp-00@sc8-sf-web1.sourceforge.net>

Bugs item #812804, was opened at 2003-09-26 09:43
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812804&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin L?thi (tnoo)
Assigned to: Fredrik Lundh (effbot)
Summary: 2.3.1 re_test causes sigsegv

Initial Comment:
I compiled Python 2.3.1 on a SuSE Linux 8.1 system 
 
Python 2.3.1 (#1, Sep 25 2003, 14:13:07)  
[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2 
 
running the test, I get sigsev 
 
python test/test_re.py 
test_anyall (__main__.ReTests) ... ok 
test_basic_re_sub (__main__.ReTests) ... ok 
test_bigcharset (__main__.ReTests) ... ok 
test_bug_113254 (__main__.ReTests) ... ok 
test_bug_114660 (__main__.ReTests) ... ok 
test_bug_117612 (__main__.ReTests) ... ok 
Segmentation fault 
 
Thanks 
 
Martin 

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:32

Message:
Logged In: YES 
user_id=29957

Hm. What version of libc is that system running? I've not

got a gcc 3.3 anywhere handy - could you try rebuilding the

_sre.c file without optimisation?

touch Modules/_sre.c

make OPT="-g" 

should do it.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812804&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:34:21 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:34:35 2003
Subject: [Python-bugs-list] [ python-Bugs-813159 ] duplicated return
	statement in unittest.py
Message-ID: <E1A2wU1-0005NR-00@sc8-sf-web1.sourceforge.net>

Bugs item #813159, was opened at 2003-09-27 02:37
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813159&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Steve Purcell (purcell)
Summary: duplicated return statement in unittest.py

Initial Comment:
After Steve Purcell's recent commit to unittest.py

(Revision 1.27), TestLoader.loadTestsFromName 

has a duplicated return statement.



        elif type(obj) == types.UnboundMethodType:

            return parent(obj.__name__)

            return obj.im_class(obj.__name__)

        elif isinstance(obj, unittest.TestSuite):



Somehow it doesn't raise SyntaxError, but I think it 

needs to be fixed.

obj.im_class(obj.__name__) is never returned.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:34

Message:
Logged In: YES 
user_id=29957

Assigning to Steve Purcell, the author of the patch.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813159&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:38:41 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:39:05 2003
Subject: [Python-bugs-list] [ python-Bugs-800432 ] color highlighting not
	working on EDIT windows
Message-ID: <E1A2wYD-0005L1-00@sc8-sf-web3.sourceforge.net>

Bugs item #800432, was opened at 2003-09-04 08:03
Message generated for change (Settings changed) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800432&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 4
Submitted By: F. Javier Jarava Jarava (developjavier)
Assigned to: Kurt B. Kaiser (kbk)
Summary: color highlighting not working on EDIT windows

Initial Comment:
ON idle 1.0/python 2.3/Tk 8.4:



When starting IDLE "normally" (ie: with Shell window),

and using File->New Window (Ctrl-N) to get a new Edit

window, syntax higlihting is off until the contents of

the file are saved with a .py extension.



BUT, when starting IDLE after configuring it to start

with a EDIT window, syntax highlighting is ON for that

first window (although not for any other new Edit windows)



The behaviour happens both on IDLE as shipped with the

python.org 2.3 installer and with cygwin's idle:

(idle 1.0, Python 2.3 (#1, Aug  5 2003, 09:49:11)

[GCC 3.2 20020927 (prerelease)] on cygwin) - started

with -n switch to avoid the "missing menus" bug on cygwin)



On idle 0.8 (as shipped with ActiveState ActivePython

2.2.2 Build 224) syntax highlighting is ON in edit

("new") windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800432&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:49:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:49:48 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A2wiR-00013V-00@sc8-sf-web2.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 21:10
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd

work for 2.3 and not 2.3.1, unless 2.3.1's script was

generated with a newer version of autoconf - aha. Yes, it was. 

If you could check if the fix in 

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

"makes it all better", that would be great. Put aclocal.m4

alongside configure &c, re-run autoconf, then ./configure ; make



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-27 03:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.



I don't think configure was broken with Python 2.3 - and it 

was with 2.3 that I first noticed the problem.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:50:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:50:43 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A2wjc-00017D-00@sc8-sf-web2.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 21:10
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:50

Message:
Logged In: YES 
user_id=29957

Hm. I'm obviously having reading difficulties. There's

obviously something else going on entirely. Damn. I will try

to grab some time on one of the HP test boxes to see if I

can figure what's going on...



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd

work for 2.3 and not 2.3.1, unless 2.3.1's script was

generated with a newer version of autoconf - aha. Yes, it was. 

If you could check if the fix in 

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

"makes it all better", that would be great. Put aclocal.m4

alongside configure &c, re-run autoconf, then ./configure ; make



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-27 03:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.



I don't think configure was broken with Python 2.3 - and it 

was with 2.3 that I first noticed the problem.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:58:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:58:33 2003
Subject: [Python-bugs-list] [ python-Bugs-813198 ] Migrate PEP material to
	docs
Message-ID: <E1A2wrA-0001TK-00@sc8-sf-web2.sourceforge.net>

Bugs item #813198, was opened at 2003-09-26 12: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=813198&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Migrate PEP material to docs

Initial Comment:
Much of the basic information is still missing.  MRO, 

descriptors, most of PEPs 252 and 253 are ones I can 

think of off the top of my head, but I'm certain there's 

more.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813198&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 13:58:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 13:59:05 2003
Subject: [Python-bugs-list] [ python-Bugs-813198 ] Migrate PEP material to
	docs
Message-ID: <E1A2wri-0001Uv-00@sc8-sf-web2.sourceforge.net>

Bugs item #813198, was opened at 2003-09-26 12:58
Message generated for change (Settings changed) made by david_abrahams
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813198&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Skip Montanaro (montanaro)
Summary: Migrate PEP material to docs

Initial Comment:
Much of the basic information is still missing.  MRO, 

descriptors, most of PEPs 252 and 253 are ones I can 

think of off the top of my head, but I'm certain there's 

more.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813198&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 14:01:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 14:10:28 2003
Subject: [Python-bugs-list] [ python-Bugs-811082 ] test_tempfile fails on
	windows if space in install path
Message-ID: <E1A2wuQ-0006aA-00@sc8-sf-web3.sourceforge.net>

Bugs item #811082, was opened at 2003-09-23 12:31
Message generated for change (Comment added) made by midramas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_tempfile fails on windows if space in install path

Initial Comment:
test_tempfile fails for me on XP when Python is

installed into

\Program Files\Python2.3



I can't cut'n'paste from the window, but the error is

C:\Program: Can't open file 'Files\Python23\python.exe'

from test_tempfile, line 299.



----------------------------------------------------------------------

Comment By: Michael Bartl (midramas)
Date: 2003-09-26 20:01

Message:
Logged In: YES 
user_id=31511

Submitted patch #813200 to fix this issue. Please review 

and apply if correct. 

----------------------------------------------------------------------

Comment By: Michael Bartl (midramas)
Date: 2003-09-26 15:19

Message:
Logged In: YES 
user_id=31511

I'm not at home so I have to paste it in here (could provide a 

patch later). Took me ~2 hours to fix this one (horrible 

win32). For more information visit 

http://mail.python.org/pipermail/python-dev/2003-

August/037556.html:



test_tempfile.py (295-297):



  decorated = '"%s"' % sys.executable

  tester = '"%s"' % tester

  retval = os.spawnl(os.P_WAIT, sys.executable, decorated, 

tester, v, fd)

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 12:44

Message:
Logged In: YES 
user_id=29957

Attempting the obvious fix of " " quoting sys.executable

gives me a Invalid argument error from os.spawnv, so that's

my windows knowledge exhausted. 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 12:36

Message:
Logged In: YES 
user_id=29957

test_popen seems to have the same problem. 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 14:47:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 14:47:52 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A2xcq-0000LM-00@sc8-sf-web3.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 23:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 04:47

Message:
Logged In: YES 
user_id=29957

I'll also attach a patch for the (generated) configure

script, for those folks without autoconf on their systems.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:14

Message:
Logged In: YES 
user_id=29957

argh. sf tracker strikes again. this time for sure.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:13

Message:
Logged In: YES 
user_id=29957

There's three ways we can fix this:

1. Hand-edit configure after running autoconf (yuk)

2. Run a CVS version of autoconf (yuk)

3. Supply an aclocal.m4 in the same way that the gcc guys

used to fix the problem (a bit yuk).



The aclocal fix would only be needed until the next release

of autoconf is out. I've attached an aclocal.m4 that

includes the GCC fix. Trying it here shows that it generates

a "fixed" configure scipt - I've not yet logged onto the HP

testdrive boxes to confirm it absolutely works, but it looks

like the fixes I did by hand in order to get it to work.



MvL, your thoughts? You seem to be the local autoconf guru... 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-24 00:26

Message:
Logged In: YES 
user_id=29957

mwh points out that the snakefarm is having the same problem:

http://www.lysator.liu.se/xenofarm/python/files/792_10/python-testlog.txt

(we discovered and debugged this on one of the

DEC^WDigital^WCompaq^WHP "testdrive" boxes)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:58

Message:
Logged In: YES 
user_id=29957

Oh, and the problem also occurs if you use gcc instead of cc -Ae





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:56

Message:
Logged In: YES 
user_id=29957

the functions that fail (erroneously) are

HAVE_CLOCK HAVE_GETTIMEOFDAY HAVE_MKTIME HAVE_SELECT

HAVE_STRFTIME HAVE_STRPTIME HAVE_UTIMES





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 17:20:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 17:20:23 2003
Subject: [Python-bugs-list] [ python-Bugs-813299 ] Weak references and bound
	functions interact in a bad way
Message-ID: <E1A300Z-00008R-00@sc8-sf-web1.sourceforge.net>

Bugs item #813299, was opened at 2003-09-26 21:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813299&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Weak references and bound functions interact in a bad way

Initial Comment:
[forwarded from http://bugs.debian.org/211129]



>>> import weakref

>>> class Foo:

...     def bar(self):

...             print 'Hello'

... 

>>> x=Foo()

>>> y=weakref.ref(x.bar)

>>> y

<weakref at 0x4021cb94; dead>



  This behavior is self-evidently wrong, and seems to

be due to an

implementation detail of Python.  There is a workaround

available here:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81253

(I haven't

examined it closely, but it looks like it should work)

 Nevertheless, this

should be fixed eventually IMO.





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813299&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 19:18:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 19:18:20 2003
Subject: [Python-bugs-list] [ python-Bugs-813342 ] -Qnew switch doesn't work
Message-ID: <E1A31qg-0006wN-00@sc8-sf-web2.sourceforge.net>

Bugs item #813342, was opened at 2003-09-27 01: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=813342&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: -Qnew switch doesn't work

Initial Comment:
When starting IDLE 1.0 with Python's -Qnew option

new division ist *not* in action! (Whereas this worked

well with IDLE 0.8 and Python 2.2)



Exception: new division works, when additionally the -n

switch of IDLE is used (no subprocesses).









----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813342&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 19:44:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 19:44:28 2003
Subject: [Python-bugs-list] [ python-Bugs-813348 ] wrong fsync() test
Message-ID: <E1A32Fz-0005LG-00@sc8-sf-web1.sourceforge.net>

Bugs item #813348, was opened at 2003-09-27 01: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=813348&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Arkadiusz Miskiewicz (arekm)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong fsync() test

Initial Comment:
configure.in checks for fsync() and defines HAVE_SYNC 
but only HAVE_FSYNC is used all arount the source. 
There is no HAVE_SYNC checks there. Bug exists on 
head and 2.3 banch. 
 
Fix is to s/HAVE_SYNC/HAVE_FSYNC/ configure.in. 
 
Also it would be good to have some simple fsync test. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813348&group_id=5470

From noreply at sourceforge.net  Fri Sep 26 23:21:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Sep 26 23:21:40 2003
Subject: [Python-bugs-list] [ python-Bugs-813159 ] duplicated return
	statement in unittest.py
Message-ID: <E1A35e7-000227-00@sc8-sf-web3.sourceforge.net>

Bugs item #813159, was opened at 2003-09-26 11:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813159&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Steve Purcell (purcell)
Summary: duplicated return statement in unittest.py

Initial Comment:
After Steve Purcell's recent commit to unittest.py

(Revision 1.27), TestLoader.loadTestsFromName 

has a duplicated return statement.



        elif type(obj) == types.UnboundMethodType:

            return parent(obj.__name__)

            return obj.im_class(obj.__name__)

        elif isinstance(obj, unittest.TestSuite):



Somehow it doesn't raise SyntaxError, but I think it 

needs to be fixed.

obj.im_class(obj.__name__) is never returned.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-26 22:21

Message:
Logged In: YES 
user_id=80475

The current CVS shows that this has already been fixed. 

Thanks for the bug report.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 12:34

Message:
Logged In: YES 
user_id=29957

Assigning to Steve Purcell, the author of the patch.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813159&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 00:40:46 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 00:41:00 2003
Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even
Message-ID: <E1A36sw-0007sd-00@sc8-sf-web2.sourceforge.net>

Bugs item #812202, was opened at 2003-09-24 23:52
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Raymond Hettinger (rhettinger)
Summary: randint is always even

Initial Comment:
The result of 

    random.randint(2**64,2**65-1) 

is always even!



(I was trying to find some large prime numbers, and

was puzzled by the fact that none were turning

up.  Finally, I discovered that randint wasn't really

returning "random" integers as desired, but only

even ones.)



I'm not sure what the cause of the problem is, but

randint should work properly, even when the given

endpoints are large...



Thanks...



        Ron Rivest



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-26 23:40

Message:
Logged In: YES 
user_id=80475

Attached is a first draft of a patch.



It works but I don't like the globals for 53 bits per random

float because the WichmannHill generator supplies fewer bits

than that.  I don't see a general way to find out how many

bits per random call are offered by an underlying generator.

 A more conservative, but slower approach is to assume on 32

bits and, if there are more, just throw them away.  Ideas

are welcome.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 19:07

Message:
Logged In: YES 
user_id=31435

Ya, something like that indeed.  You might enjoy writing the 

core in C <wink>.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-25 12:10

Message:
Logged In: YES 
user_id=80475

If the range is too large, instead of raising an exception,

how about  

calling a _randbigint routine that builds up the random

selection using repeated calls to the underlying generator. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 10:23

Message:
Logged In: YES 
user_id=31435

No disagreement here.  I'd rather fix the code than the docs, 

and a fix can take two forms:  raise an exception if the full 

range of ints can't be delivered, or deliver the full range of 

ints.



If anyone wants to take this on, I think the latter ("do a right 

thing") may be much more practical than it used to be, given 

the new-in-2.3 Twister impelementation -- we can generate 

long pseudo-random bitstrings quickly now (at least at the C 

level), but couldn't before 2.3.

----------------------------------------------------------------------

Comment By: Ronald L. Rivest (ronrivest)
Date: 2003-09-25 09:56

Message:
Logged In: YES 
user_id=863876

If the code is not going to be fixed, then the

documentation should be updated.  I am well aware

of other approaches to generating large random numbers,

but was misled by the documentation Python provides.  The

documentation should make it clear when the code violates

its "contract" (i.e. doesn't generate all integers in the range).

I prefer the code being fixed best, but also feel that the code 

should raise an exception if it can't honor the contract implied 

in its documentation.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 00:16

Message:
Logged In: YES 
user_id=31435

The cause is that randint takes a pseudo-random float (C 

double in [0, 1),), multiplies it by (hi-lo+1), then truncates 

and adds that to lo.  Since a double on your box almost 

certainly has only 53 bits of precision, and your multiplier 

effectively moves the radix point 64 bits "to the right", I 

expect the last 11 bits you see will always be 0.



Under Python 2.3, which uses the Mersenne Twister to 

generate random doubles, this does appear to be the case:



>>> from random import randint

>>> def f():

...     return randint(2**64, 2**65-1)

...

>>> hex(f())

'0x11EDD95B72CEF4000L'

>>> hex(f())

'0x1DD69BF4B39C65000L'

>>> hex(f())

'0x13328DC9C1C733800L'

>>> hex(f())

'0x1E65B47170C057800L'

>>>



Under earlier versions of Python, it may be even worse than 

that.



It takes a fundamentally different kind of algorithm to 

generate arbitrarily long random ints.  Here's a link to one 

such for Python:



http://www.faqts.com/knowledge_base/view.phtml/aid/4406



I doubt the implementation of randint() will change, since 

most people want fast-as-possible generation of mountains of 

small integers, and there's a tradeoff between catering to 

that and catering to extreme inputs.  The randint docs should 

change, though (I think randint() used to raise an exception 

when fed arguments as large as the ones you're using; I 

suspect, but don't know, that we lost the helpful exception 

as an unintended consequence of the long-term effort to 

eradicate the user-visible distinction between Python ints 

(machine C longs) and Python longs (unbounded integers)).



BTW, given what you're doing, you may want to install one of 

the Python wrappers for GNU GMP.  Python's unbounded-int 

arithmetic implementation is extremely portable and reliable, 

but buys those in part by not caring much about speed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 01:39:53 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 01:40:15 2003
Subject: [Python-bugs-list] [ python-Bugs-813348 ] wrong fsync() test
Message-ID: <E1A37o9-0005ZD-00@sc8-sf-web3.sourceforge.net>

Bugs item #813348, was opened at 2003-09-27 09:44
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813348&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Arkadiusz Miskiewicz (arekm)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong fsync() test

Initial Comment:
configure.in checks for fsync() and defines HAVE_SYNC 
but only HAVE_FSYNC is used all arount the source. 
There is no HAVE_SYNC checks there. Bug exists on 
head and 2.3 banch. 
 
Fix is to s/HAVE_SYNC/HAVE_FSYNC/ configure.in. 
 
Also it would be good to have some simple fsync test. 

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 15:39

Message:
Logged In: YES 
user_id=29957

This is fixed in CVS on both the trunk and the release23-maint

branch, and will be in Python 2.3.2.



Thanks for the bug report!



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813348&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 03:40:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 03:40:57 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A39gn-0000Mu-00@sc8-sf-web3.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 15:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

Category: Build
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-27 09:40

Message:
Logged In: YES 
user_id=21627

The patch is fine; please apply.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 20:47

Message:
Logged In: YES 
user_id=29957

I'll also attach a patch for the (generated) configure

script, for those folks without autoconf on their systems.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 19:14

Message:
Logged In: YES 
user_id=29957

argh. sf tracker strikes again. this time for sure.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 19:13

Message:
Logged In: YES 
user_id=29957

There's three ways we can fix this:

1. Hand-edit configure after running autoconf (yuk)

2. Run a CVS version of autoconf (yuk)

3. Supply an aclocal.m4 in the same way that the gcc guys

used to fix the problem (a bit yuk).



The aclocal fix would only be needed until the next release

of autoconf is out. I've attached an aclocal.m4 that

includes the GCC fix. Trying it here shows that it generates

a "fixed" configure scipt - I've not yet logged onto the HP

testdrive boxes to confirm it absolutely works, but it looks

like the fixes I did by hand in order to get it to work.



MvL, your thoughts? You seem to be the local autoconf guru... 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 16:26

Message:
Logged In: YES 
user_id=29957

mwh points out that the snakefarm is having the same problem:

http://www.lysator.liu.se/xenofarm/python/files/792_10/python-testlog.txt

(we discovered and debugged this on one of the

DEC^WDigital^WCompaq^WHP "testdrive" boxes)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 15:58

Message:
Logged In: YES 
user_id=29957

Oh, and the problem also occurs if you use gcc instead of cc -Ae





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 15:56

Message:
Logged In: YES 
user_id=29957

the functions that fail (erroneously) are

HAVE_CLOCK HAVE_GETTIMEOFDAY HAVE_MKTIME HAVE_SELECT

HAVE_STRFTIME HAVE_STRPTIME HAVE_UTIMES





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 03:50:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 03:50:14 2003
Subject: [Python-bugs-list] [ python-Bugs-813299 ] Weak references and bound
	functions interact in a bad way
Message-ID: <E1A39q5-0000ct-00@sc8-sf-web3.sourceforge.net>

Bugs item #813299, was opened at 2003-09-26 23:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813299&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Weak references and bound functions interact in a bad way

Initial Comment:
[forwarded from http://bugs.debian.org/211129]



>>> import weakref

>>> class Foo:

...     def bar(self):

...             print 'Hello'

... 

>>> x=Foo()

>>> y=weakref.ref(x.bar)

>>> y

<weakref at 0x4021cb94; dead>



  This behavior is self-evidently wrong, and seems to

be due to an

implementation detail of Python.  There is a workaround

available here:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81253

(I haven't

examined it closely, but it looks like it should work)

 Nevertheless, this

should be fixed eventually IMO.





----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-27 09:50

Message:
Logged In: YES 
user_id=21627

I fail to see a bug here. x.bar creates a new object (a

bound method),

for which then a weak reference is created. Since there is

no strong

reference to the same bound method, the bound method is

deleted, and

the weak reference dies.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813299&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 03:53:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 03:53:45 2003
Subject: [Python-bugs-list] [ python-Bugs-811028 ] 2.3.1 configure bug
Message-ID: <E1A39tR-0000lU-00@sc8-sf-web3.sourceforge.net>

Bugs item #811028, was opened at 2003-09-23 09:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.1 configure bug

Initial Comment:
Anthony said to log this:



checking ncurses.h presence... yes

configure: WARNING: ncurses.h: present but cannot be 

compiled

configure: WARNING: ncurses.h: check for missing 

prerequisite headers?

configure: WARNING: ncurses.h: proceeding with the 

preprocessor's result

configure: WARNING:     ## 

------------------------------------ ##

configure: WARNING:     ## Report this to bug-

autoconf@gnu.org. ##

configure: WARNING:     ## 

------------------------------------ ##



I'll attach the text of the report and the configure output 

too since I'm pretty sure the above won't be ligible once 

sf's tracker's finished with it.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-27 09:53

Message:
Logged In: YES 
user_id=21627

Can you try the patch in python.org/sf/806800 ?

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2003-09-23 10:28

Message:
Logged In: YES 
user_id=6405

"make test" also reports:



test_curses

test test_curses crashed -- _curses.error: curs_set() returned 

ERR



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 10:14

Message:
Logged In: YES 
user_id=29957

creosote (which is a freebsd machine) also sees this.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 03:55:54 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 03:56:08 2003
Subject: [Python-bugs-list] [ python-Bugs-807253 ] WinCVs & Python 2.3
Message-ID: <E1A39vm-0000pH-00@sc8-sf-web3.sourceforge.net>

Bugs item #807253, was opened at 2003-09-16 18:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807253&group_id=5470

Category: None
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Partho Bhowmick (ypostgresql)
Assigned to: Nobody/Anonymous (nobody)
Summary: WinCVs & Python 2.3

Initial Comment:
I don't know what changed between Python 2.2.3 & 

Python 2.3 but WinCVS1.3.1 cannot detect Python 2.3, 

though it works fine with Python 2.2.3. Curioulsly, the 

Tcl that comes with Python 2.3 is detected

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-27 09:55

Message:
Logged In: YES 
user_id=21627

Assuming this is indeed a WinCVS bug, closing it as third-party.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-18 20:13

Message:
Logged In: YES 
user_id=21627

ypostgresql, can you please elaborate what you mean by

"detect"? In what way can WinCVS detect Python?



If WinCVS has somehow a mechanism to invoke Python, why do

you think you have found a bug in Python, instead of a bug

in WinCVS?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-16 21:31

Message:
Logged In: YES 
user_id=80475

This may seem obvious but it is worth a try.  See if WinCVS 

has some equivalent of "cvs up -A" which will turn-off the 

sticky flags associated with each file.  The symptoms sound 

like your setup is locked into checking for release22-maint 

when it should be looking for release23-maint (for the most 

current 23) or release23-branch (for the one that went out 

the door).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807253&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 04:36:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 04:36:38 2003
Subject: [Python-bugs-list] [ python-Bugs-811028 ] 2.3.1 configure bug
Message-ID: <E1A3AYs-0003Vs-00@sc8-sf-web1.sourceforge.net>

Bugs item #811028, was opened at 2003-09-23 17:50
Message generated for change (Comment added) made by richard
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.1 configure bug

Initial Comment:
Anthony said to log this:



checking ncurses.h presence... yes

configure: WARNING: ncurses.h: present but cannot be 

compiled

configure: WARNING: ncurses.h: check for missing 

prerequisite headers?

configure: WARNING: ncurses.h: proceeding with the 

preprocessor's result

configure: WARNING:     ## 

------------------------------------ ##

configure: WARNING:     ## Report this to bug-

autoconf@gnu.org. ##

configure: WARNING:     ## 

------------------------------------ ##



I'll attach the text of the report and the configure output 

too since I'm pretty sure the above won't be ligible once 

sf's tracker's finished with it.



----------------------------------------------------------------------

>Comment By: Richard Jones (richard)
Date: 2003-09-27 18:36

Message:
Logged In: YES 
user_id=6405

(I didn't mention it in the report, only to Anthony : this is on 

OSX)



The patch doesn't alter the configure behaviour.



I can't remember how to run the curses test - "make test" skips 

it (the curses module is built though).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-27 17:53

Message:
Logged In: YES 
user_id=21627

Can you try the patch in python.org/sf/806800 ?

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2003-09-23 18:28

Message:
Logged In: YES 
user_id=6405

"make test" also reports:



test_curses

test test_curses crashed -- _curses.error: curs_set() returned 

ERR



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 18:14

Message:
Logged In: YES 
user_id=29957

creosote (which is a freebsd machine) also sees this.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 04:54:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 04:54:51 2003
Subject: [Python-bugs-list] [ python-Bugs-813449 ] locale.getdefaultlocale
	doesnt handle all locales gracefully
Message-ID: <E1A3Aqa-0002gf-00@sc8-sf-web3.sourceforge.net>

Bugs item #813449, was opened at 2003-09-27 08: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=813449&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.getdefaultlocale doesnt handle all locales gracefully

Initial Comment:
[forwarded from http://bugs.debian.org/185776]



$ LC_ALL=en_ZA python

Python 2.3.1 (#2, Sep 24 2003, 11:39:14) 

[GCC 3.3.2 20030908 (Debian prerelease)] on linux2

Type "help", "copyright", "credits" or "license" for

more information.

>>> import locale

>>> locale.getdefaultlocale()

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

  File "/usr/lib/python2.3/locale.py", line 346, in

getdefaultlocale

    return _parse_localename(localename)

  File "/usr/lib/python2.3/locale.py", line 280, in

_parse_localename

    raise ValueError, 'unknown locale: %s' % localename

ValueError: unknown locale: en_ZA



Note that locale.getlocale correctly returns (None, None)



locale.getdefaultlocale() calls _parse_localename,

which throws a ValueError if normalize e.g. does not

return an encoding.



If this behaviour in python is "as it should be",

locale.getdefaultlocale should document it as such, to

make it clear to apps using getdefaultlocale that they

*must indeed* handle such an exception gracefully. (In

this case, it could probably be a "normal" bug, then

the "important" bug belongs with apt-listchanges.)



The problem might be (depending on "specifications")

either getlocale returning ValueError in the "unknown"

case, or it could be because locale_alias does not

contain an entry for en_ZA...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813449&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 05:08:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 05:09:12 2003
Subject: [Python-bugs-list] [ python-Bugs-813453 ] restrictions in _tkinter
	built with threaded tk undocumented
Message-ID: <E1A3B4V-0004Y0-00@sc8-sf-web1.sourceforge.net>

Bugs item #813453, was opened at 2003-09-27 09: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=813453&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: restrictions in _tkinter built with threaded tk undocumented

Initial Comment:
Basically, raise some comments from the _tkinter.c

module to the library reference:



   If Tcl is threaded, this approach won't work

anymore. The Tcl interpreter is only valid in the

thread that created it, and all Tk activity must happen

in this thread, also. That means that the mainloop must

be invoked in the thread that created the interpreter.

Invoking commands from other threads is possible;

_tkinter will queue an event for the interpreter

thread, which will then execute the command and pass

back the result. If the main thread is not in the

mainloop, and invoking commands causes an exception; if

the main loop is running but not processing events, the

command invocation will block.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813453&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 14:10:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 14:10:53 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A3JWe-00077j-00@sc8-sf-web1.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 21:29
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-27 13:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 17:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 14:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 14:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 11:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 18:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 03:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Sat Sep 27 19:08:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Sep 27 19:08:30 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A3OAh-0007FE-00@sc8-sf-web3.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 19:29
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2003-09-27 16:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-27 11:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 15:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 12:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 12:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 12:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 12:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 10:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 09:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 09:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 16:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 01:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 01:11:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 01:11:38 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A3Tq4-0008R4-00@sc8-sf-web3.sourceforge.net>

Bugs item #775414, was opened at 2003-07-22 12:29
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-28 15:11

Message:
Logged In: YES 
user_id=29957

Could you check that it (and the test_bsddb3) works on

Solaris? There's a couple of solaris boxes on the SF compile

farm (cf.sf.net). I was unable to get test_bsddb3 to complete

at all on Solaris 2.6, 7 or 8, when using DB 4.1.25.



As far as 2.3.2, I really really don't think it's appropriate to

throw it in at this late point. Particularly given the 2.3.1 

screwups, I don't want to risk it.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-28 09:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-28 04:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-13 08:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-13 05:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-13 05:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 05:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-13 05:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-13 05:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 05:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-13 05:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-13 04:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-13 04:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 04:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-13 04:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-13 04:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 03:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 02:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-13 02:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-14 09:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 18:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 03:42:30 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 03:42:45 2003
Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even
Message-ID: <E1A3WCM-0000aH-00@sc8-sf-web2.sourceforge.net>

Bugs item #812202, was opened at 2003-09-24 23:52
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Raymond Hettinger (rhettinger)
Summary: randint is always even

Initial Comment:
The result of 

    random.randint(2**64,2**65-1) 

is always even!



(I was trying to find some large prime numbers, and

was puzzled by the fact that none were turning

up.  Finally, I discovered that randint wasn't really

returning "random" integers as desired, but only

even ones.)



I'm not sure what the cause of the problem is, but

randint should work properly, even when the given

endpoints are large...



Thanks...



        Ron Rivest



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-28 02:42

Message:
Logged In: YES 
user_id=80475

A cleaner, faster patch is attached along with tests. 

Before it goes in, the second assert can be commented out.



Unless Tim comes-up with a better idea about obtaining the

information content of a call to random(), I think the

53-bit assumption is fine (a bar for core generators to live

up to).  

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-26 23:40

Message:
Logged In: YES 
user_id=80475

Attached is a first draft of a patch.



It works but I don't like the globals for 53 bits per random

float because the WichmannHill generator supplies fewer bits

than that.  I don't see a general way to find out how many

bits per random call are offered by an underlying generator.

 A more conservative, but slower approach is to assume on 32

bits and, if there are more, just throw them away.  Ideas

are welcome.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 19:07

Message:
Logged In: YES 
user_id=31435

Ya, something like that indeed.  You might enjoy writing the 

core in C <wink>.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-25 12:10

Message:
Logged In: YES 
user_id=80475

If the range is too large, instead of raising an exception,

how about  

calling a _randbigint routine that builds up the random

selection using repeated calls to the underlying generator. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 10:23

Message:
Logged In: YES 
user_id=31435

No disagreement here.  I'd rather fix the code than the docs, 

and a fix can take two forms:  raise an exception if the full 

range of ints can't be delivered, or deliver the full range of 

ints.



If anyone wants to take this on, I think the latter ("do a right 

thing") may be much more practical than it used to be, given 

the new-in-2.3 Twister impelementation -- we can generate 

long pseudo-random bitstrings quickly now (at least at the C 

level), but couldn't before 2.3.

----------------------------------------------------------------------

Comment By: Ronald L. Rivest (ronrivest)
Date: 2003-09-25 09:56

Message:
Logged In: YES 
user_id=863876

If the code is not going to be fixed, then the

documentation should be updated.  I am well aware

of other approaches to generating large random numbers,

but was misled by the documentation Python provides.  The

documentation should make it clear when the code violates

its "contract" (i.e. doesn't generate all integers in the range).

I prefer the code being fixed best, but also feel that the code 

should raise an exception if it can't honor the contract implied 

in its documentation.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-25 00:16

Message:
Logged In: YES 
user_id=31435

The cause is that randint takes a pseudo-random float (C 

double in [0, 1),), multiplies it by (hi-lo+1), then truncates 

and adds that to lo.  Since a double on your box almost 

certainly has only 53 bits of precision, and your multiplier 

effectively moves the radix point 64 bits "to the right", I 

expect the last 11 bits you see will always be 0.



Under Python 2.3, which uses the Mersenne Twister to 

generate random doubles, this does appear to be the case:



>>> from random import randint

>>> def f():

...     return randint(2**64, 2**65-1)

...

>>> hex(f())

'0x11EDD95B72CEF4000L'

>>> hex(f())

'0x1DD69BF4B39C65000L'

>>> hex(f())

'0x13328DC9C1C733800L'

>>> hex(f())

'0x1E65B47170C057800L'

>>>



Under earlier versions of Python, it may be even worse than 

that.



It takes a fundamentally different kind of algorithm to 

generate arbitrarily long random ints.  Here's a link to one 

such for Python:



http://www.faqts.com/knowledge_base/view.phtml/aid/4406



I doubt the implementation of randint() will change, since 

most people want fast-as-possible generation of mountains of 

small integers, and there's a tradeoff between catering to 

that and catering to extreme inputs.  The randint docs should 

change, though (I think randint() used to raise an exception 

when fed arguments as large as the ones you're using; I 

suspect, but don't know, that we lost the helpful exception 

as an unintended consequence of the long-term effort to 

eradicate the user-visible distinction between Python ints 

(machine C longs) and Python longs (unbounded integers)).



BTW, given what you're doing, you may want to install one of 

the Python wrappers for GNU GMP.  Python's unbounded-int 

arithmetic implementation is extremely portable and reliable, 

but buys those in part by not caring much about speed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 05:12:05 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 05:12:19 2003
Subject: [Python-bugs-list] [ python-Feature Requests-813922 ] Zero
	Configuration Networking?
Message-ID: <E1A3Xb3-0003F0-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #813922, was opened at 2003-09-28 11:12
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=813922&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Elfring (elfring)
Assigned to: Nobody/Anonymous (nobody)
Summary: Zero Configuration Networking?

Initial Comment:
Would you like to support this proposed standard?



1. 
http://www.zeroconf.org/

2. 
http://www.ietf.org/html.charters/zeroconf-
charter.html

3. 
http://citeseer.org/cs?q=Zero+Configuration+Networking

4. 
http://www.oreillynet.com/pub/wlg/3137

5. 
http://www.spack.org/index.cgi/ZeroConf

6. 
http://sourceforge.net/projects/zeroconf/

7. 
http://sourceforge.net/projects/howl/

8. 
http://www.uow.edu.au/~dfs/projects/2003/projects2003.html

9. 
http://www.apple.com/macosx/jaguar/rendezvous.html

10. 
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/NetServices/Concepts/AboutRendezvous.html

11. 
http://developer.apple.com/darwin/projects/rendezvous/

12. 
http://www.neato.org/~femur/iu/

13. 
http://homepage.mac.com/macdomeeu/dev/current/mod_rendezvous/

14. 
http://www.macdevcenter.com/pub/a/mac/2003/04/08/mod_rendezvous.html

15. 
http://groups.google.de/groups?selm=40ed1d8f.0309272247.58b3abbc%40posting.google.com

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=813922&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 09:06:03 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 09:06:17 2003
Subject: [Python-bugs-list] [ python-Bugs-813986 ] robotparser interactively
	prompts for username and password
Message-ID: <E1A3bFT-0007QT-00@sc8-sf-web3.sourceforge.net>

Bugs item #813986, was opened at 2003-09-28 09:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: robotparser interactively prompts for username and password

Initial Comment:
This is a rare occurrence, but if a /robots.txt file is

password-protected on an http server, robotparser

interactively prompts (via raw_input) for a username

and password, because that is urllib's default

behavior.  One example of such a URL, at least at the

time of this writing, is



http://www.cosc.canterbury.ac.nz/robots.txt



Given that robotparser and robots.txt is all about

*robots* (not interactive users), I don't think this

interactive behavior is terribly appropriate.  Attached

is a simple patch to robotparser.py to fix this

behavior, forcing urllib to return the 401 error that

it ought to.



Another issue is whether a 401 (Authorization Required)

URL means that everything should be allowed or

everything should be disallowed.  I'm not sure what's

"right".  Reading the spec, it says 'This file must be

accessible via HTTP on the local URL "/robots.txt"'

which I would read to mean it should be accessible

without username/password.  On the other hand, the

current robotparser.py code says "if self.errcode ==

401 or self.errcode == 403: self.disallow_all = 1"

which has the opposite effect.  I'll leave deciding

which is most appropriate to the powers that be.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 10:52:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 10:52:45 2003
Subject: [Python-bugs-list] [ python-Bugs-812986 ] turtle.py deferres exec
	of stmnts with tracer(0)
Message-ID: <E1A3cuS-00062P-00@sc8-sf-web1.sourceforge.net>

Bugs item #812986, was opened at 2003-09-26 05:33
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812986&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Martin v. L?wis (loewis)
Summary: turtle.py deferres exec of stmnts with tracer(0)

Initial Comment:
interactive use of turtle.py becomes impossible,

e.g.when issuing tracer(0) because in this

case apparently updating of Canvas-Widget is

deferred ...

... until the next tracer(1)

(one can observe this when running the demo() )



Inserting a _canvas.update() call in _draw_turtle()

for the case that tracing is off seems to work:



    def _draw_turtle(self,position=[]):

        if not self._tracing:

            self._canvas.update()  # <== insert this line!

            return

        if position == []:  # etc.etc.





I have attached a corrected version as turtle_.py



Gregor Lingl 



----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-09-28 09:52

Message:
Logged In: YES 
user_id=2772

You did not attach a file.  You must select a filename *and* turn on the checkbox to do so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812986&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 11:27:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 11:28:15 2003
Subject: [Python-bugs-list] [ python-Bugs-810214 ] exit() raises exception
Message-ID: <E1A3dSH-0001jA-00@sc8-sf-web2.sourceforge.net>

Bugs item #810214, was opened at 2003-09-21 20:36
Message generated for change (Comment added) made by jojoworks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810214&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jozef Behran (jojoworks)
Assigned to: Nobody/Anonymous (nobody)
Summary: exit() raises exception

Initial Comment:
--- BEGIN OF SESSION TRANSCRIPT ---

$ python

Python version: 2.2.2 (#2, Feb 5 2003, 10:40:08)

[GCC 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk)] on linux-i386

Type "help", "copyright", "credits" or "license" for

more information.

>>> <CTRL-D>

$ cat exit.py

exit(1)

$ python exit.py

Traceback (most recent call last):

  File "exit.py", line 1, in ?

    exit(1);

TypeError: 'str' object is not callable

$ cat exitstr.py

exit("Fatal error")

$ python exitstr.py

Traceback (most recent call last):

  File "exitstr.py", line 1, in ?

    exit("Fatal error");

TypeError: 'str' object is not callable

--- END OF SESSION TRANSCRIPT ---



The first "python ..." command shall output nothing and

return 1 as the result. The second "python ..." command

shall output "Fatal error" to stderr and return 1 as

the result. No exception shall be raised there.



----------------------------------------------------------------------

>Comment By: Jozef Behran (jojoworks)
Date: 2003-09-28 17:27

Message:
Logged In: YES 
user_id=688090

Thanks. Now I looked at the example I was looking in my book

before and I did realized that they used unobtrusive "from

sys import exit" line at the *bottom* of the example script.

When you are working with compiled languages such as C for

so long time, the way you reads programs will be affected so

that you will get *really* confused if you see such a piece

of example code. So when I looked at the code and saw

"exit()" call, I thought that the exit() is a builtin

function (it was very long example and the exit() call was

on different page as the "from sys import exit" line, so I

didn't notice the import at first look) and when I got that

exception, I began to think about a bug being in Python

(after I really carefully compared to the example I was

looking on ;) ).



P.S. I'm closing this "bug" when I realized that there is no

such a bug in Python.



P.SS. I suggest you to not define the builtin "exit" when

you are not in the interactive mode (i.e. running a script)

to avoid further such confusions.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-21 22:51

Message:
Logged In: YES 
user_id=31435

Oops!  Everywhere I wrote "os" read "sys" instead.  The 

sys.exit() function does what you want here.  There is no exit 

function in the os module (although there is a lower-level 

os._exit() function).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-21 22:42

Message:
Logged In: YES 
user_id=31435

It appears that you want to use the os.exit() function.  If so, 

you must import it from os.  The builtin exit (which you're 

using) is indeed just a string, which displays a message to 

interactive users telling them the correct way to end an 

interpreter session.  This varies across platforms.  For 

example, here under Cygwin:



$ python

Python 2.2.2 (#1, Dec 31 2002, 12:24:34)

[GCC 3.2 20020927 (prerelease)] on cygwin

Type "help", "copyright", "credits" or "license" for more 

information.

>>> exit

'Use Ctrl-D (i.e. EOF) to exit.'

>>>



"'str' object is not callable" is a perfectly appropriate 

exception if you try to (as you are trying to do) *call* a 

string with an argument.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810214&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 18:05:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 18:05:58 2003
Subject: [Python-bugs-list] [ python-Bugs-813342 ] -Qnew switch doesn't work
Message-ID: <E1A3jfk-0007iP-00@sc8-sf-web1.sourceforge.net>

Bugs item #813342, was opened at 2003-09-27 01:18
Message generated for change (Comment added) made by glingl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813342&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: -Qnew switch doesn't work

Initial Comment:
When starting IDLE 1.0 with Python's -Qnew option

new division ist *not* in action! (Whereas this worked

well with IDLE 0.8 and Python 2.2)



Exception: new division works, when additionally the -n

switch of IDLE is used (no subprocesses).









----------------------------------------------------------------------

>Comment By: Gregor Lingl (glingl)
Date: 2003-09-29 00:05

Message:
Logged In: YES 
user_id=505031

Oh! Here is the file mentioned above,

Gregor



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813342&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 18:08:49 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 18:09:05 2003
Subject: [Python-bugs-list] [ python-Bugs-812986 ] turtle.py deferres exec
	of stmnts with tracer(0)
Message-ID: <E1A3jij-0007oY-00@sc8-sf-web1.sourceforge.net>

Bugs item #812986, was opened at 2003-09-26 12:33
Message generated for change (Comment added) made by glingl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812986&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Martin v. L?wis (loewis)
Summary: turtle.py deferres exec of stmnts with tracer(0)

Initial Comment:
interactive use of turtle.py becomes impossible,

e.g.when issuing tracer(0) because in this

case apparently updating of Canvas-Widget is

deferred ...

... until the next tracer(1)

(one can observe this when running the demo() )



Inserting a _canvas.update() call in _draw_turtle()

for the case that tracing is off seems to work:



    def _draw_turtle(self,position=[]):

        if not self._tracing:

            self._canvas.update()  # <== insert this line!

            return

        if position == []:  # etc.etc.





I have attached a corrected version as turtle_.py



Gregor Lingl 



----------------------------------------------------------------------

>Comment By: Gregor Lingl (glingl)
Date: 2003-09-29 00:08

Message:
Logged In: YES 
user_id=505031

OH! Here is the file mentioned above

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-09-28 16:52

Message:
Logged In: YES 
user_id=2772

You did not attach a file.  You must select a filename *and* turn on the checkbox to do so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812986&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 18:12:27 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 18:12:47 2003
Subject: [Python-bugs-list] [ python-Bugs-813342 ] -Qnew switch doesn't work
Message-ID: <E1A3jmF-0003yB-00@sc8-sf-web3.sourceforge.net>

Bugs item #813342, was opened at 2003-09-27 01:18
Message generated for change (Comment added) made by glingl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813342&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 6
Submitted By: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: -Qnew switch doesn't work

Initial Comment:
When starting IDLE 1.0 with Python's -Qnew option

new division ist *not* in action! (Whereas this worked

well with IDLE 0.8 and Python 2.2)



Exception: new division works, when additionally the -n

switch of IDLE is used (no subprocesses).









----------------------------------------------------------------------

>Comment By: Gregor Lingl (glingl)
Date: 2003-09-29 00:12

Message:
Logged In: YES 
user_id=505031

Sorry, adding turtle.py was an error (wrong bug-thread, see bug

812986)

Gregor

----------------------------------------------------------------------

Comment By: Gregor Lingl (glingl)
Date: 2003-09-29 00:05

Message:
Logged In: YES 
user_id=505031

Oh! Here is the file mentioned above,

Gregor



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813342&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 19:50:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 19:50:24 2003
Subject: [Python-bugs-list] [ python-Bugs-811604 ] "string".split behaviour
	for empty strings
Message-ID: <E1A3lIp-0002PR-00@sc8-sf-web2.sourceforge.net>

Bugs item #811604, was opened at 2003-09-24 04:20
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: T.Meyarivan (meyarivan)
Assigned to: Nobody/Anonymous (nobody)
Summary: "string".split behaviour for empty strings

Initial Comment:


"".split() -> []



"".split(' ') -> ['']



It is not clear from the documentation as to what is

the defined behaviour in the above case. To say the

least, it is 

completely counter-intuitive..(splitting an empty

string should

return the list [''] in both cases).



>From stringobject.c, the behaviour of split_whitespace

(i.e split called without sep) and string_split (split

called with sep) is different for empty

strings..perhaps the function split_whitespace needs to

be patched.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-09-28 19:50

Message:
Logged In: YES 
user_id=593130

Suggestion: find section of Lib Ref discussing str.split, quote 

existing def, and add succinct sentence that you think is 

needed.  Then change category to 'documentation' so 

appropriate person(s) will see proposal.

----------------------------------------------------------------------

Comment By: T.Meyarivan (meyarivan)
Date: 2003-09-26 07:04

Message:
Logged In: YES 
user_id=30470



Thats so counter intuitive.. :-(



At least the documentation should specify the fact that the

behaviour of "string".split for empty strings is so and so....



The reason this probably never came up ( or mostly ignored

by majority ) is that people probably check if the string is

empty before proceeding to process it.. 



I am not closing the bug before the specific behaviour of

"string".split for empty strings gets to the docs..

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-26 00:35

Message:
Logged In: YES 
user_id=80475

And so it is.  The whitespace version (no args) and the

specified separator version work differently -- the second

version can never return an empty list.



This code has been around for a good while and it is likely

that much code relies on the behavior, so I recommend

classifying it as a beauty spot and closing the bug.



"One man's bug is another man's feature"



----------------------------------------------------------------------

Comment By: T.Meyarivan (meyarivan)
Date: 2003-09-24 04:51

Message:
Logged In: YES 
user_id=30470

"".split(None) -> [] 



which is expected because in the case when no sep is

specified and when sep == None, split_whitespace is called..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 20:47:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 20:47:49 2003
Subject: [Python-bugs-list] [ python-Bugs-807771 ] Max and min are incorrect
	with one argument
Message-ID: <E1A3mC6-0004m8-00@sc8-sf-web1.sourceforge.net>

Bugs item #807771, was opened at 2003-09-17 07:49
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807771&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Max and min are incorrect with one argument

Initial Comment:
max(1)

raises 'TypeError: iteration over non-sequence',

when it should simply return 1



Min has the same problem.



If there is one person in a room, and you ask for the

tallest person, there is a well-defined answer.

The tallest person is the only person.

So is the shortest person.



I ran across this when I was doing

apply(max, list) / apply(min, list)

to find out the ratio of maximum to minimum entries

in a list.    With a single-element list, I expected

it to return 1, instead of raising an exception.



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-09-28 20:47

Message:
Logged In: YES 
user_id=593130

I think the gimmick of having a function of 1-m arguments 

treat one arg as a sequence is a design bug that asks for 

problems.  With the addition of *seq, it is even more 

unnecessary.  But for backwards compatibility, it must 

remain until 3.0.



Greg: you faked yourself out by using apply.

Go with the flow and just use max(list)/min(list):

>>> max([2])/min([2])

1



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 15:24

Message:
Logged In: YES 
user_id=80475

That behavior is consequence of interpreting a single 

argument as an input sequence while interpreting multiple 

arguments as the sequence itself.



Given a single argument, Python could make some 

reasonable guesses:  max(3) --> 3  and max((3,4)) --> 4, 

but guessing is not the Pythonic way.  Also, I think max(x) 

tends to be an error condition when x is not iterable, so it 

would be unwise to simply return x and let the error pass 

silently.



If it makes you feels better, you *are* the tallest, smartest, 

and richest OP for this bug report ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807771&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 21:28:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 21:28:38 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A3mph-0001jo-00@sc8-sf-web3.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 22: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=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-28 21:28

Message:
Logged In: YES 
user_id=31435

About studly_hammer.py:



[Skip Montanaro]

> ...

> Attached is a modified version of the hammer.py script 

which seems to

> not fail for me on either Windows run from IDLE (Python 

2.3, BDB

> 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1).  The original 

script

> failed for me on Windows but not Mac OS X.  Can some 

other people for

> whom the original script fails please try it?  (I also attached 

it to

> bug #775414.) 



On Win98SE with current Python 2.3.1, it doesn't fail, but it 

never seemed to finish for me either.  Staring at WinTop 

showed that the Python process stopped accumulating 

cycles.  Can't be killed with Ctrl+C (no visible effect).  Can be 

killed with Ctrl+Break.



Dumping



        print "%s %s" % (thread.get_ident(), i)



at the top of the hammer loop showed that the threads get 

through several hundred iterations, then all printing stops.



Attaching to a debug-build Python from the debugger when a 

freeze occurs isn't terribly illuminating.  One thread's stack 

shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __ham_get_meta + 120 bytes

_BSDDB_D! __ham_c_dup + 4201 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, 

__db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 

562 + 35 bytes



The main thread's stack shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __db_lget + 365 bytes

_BSDDB_D! __ham_lock_bucket + 105 bytes

_BSDDB_D! __ham_get_cpage + 195 bytes

_BSDDB_D! __ham_item_next + 25 bytes

_BSDDB_D! __ham_call_hash + 2479 bytes

_BSDDB_D! __ham_c_dup + 4307 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, 

__db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 

562 + 35 bytes

DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, 

_object * 0x00b83370) line 2330 + 23 bytes

PyObject_SetItem(_object * 0x008fe2e8, _object * 

0x00b83178, _object * 0x00b83370) line 123 + 18 bytes

eval_frame(_frame * 0x00984948) line 1448 + 17 bytes

...



The other threads are somewhere in the OS kernel and don't 

have useful tracebacks.  This varies from run to run, but all 

threads with a useful stack are always stuck at the same 

place in __db_win32_mutex_lock.



All in all, looks like it's simply deadlocked.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-28 01:11

Message:
Logged In: YES 
user_id=29957

Could you check that it (and the test_bsddb3) works on

Solaris? There's a couple of solaris boxes on the SF compile

farm (cf.sf.net). I was unable to get test_bsddb3 to complete

at all on Solaris 2.6, 7 or 8, when using DB 4.1.25.



As far as 2.3.2, I really really don't think it's appropriate to

throw it in at this late point. Particularly given the 2.3.1 

screwups, I don't want to risk it.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-27 19:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-27 14:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 15:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 15:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 15:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 15:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 15:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 15:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 15:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 19:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 04:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 21:27:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 21:31:04 2003
Subject: [Python-bugs-list] [ python-Bugs-803634 ] urllib/urllib2(?) timeouts
Message-ID: <E1A3mpA-00067m-00@sc8-sf-web1.sourceforge.net>

Bugs item #803634, was opened at 2003-09-10 00:43
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803634&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib/urllib2(?) timeouts

Initial Comment:
Could Skip's example from 

http://groups.google.com/groups?hl=en&lr=&ie=UTF-

8&selm=mailman.1051711375.3445.python-list%

40python.org be added to the documentation? 



(slightly re-worded)

You can set the default timeout for sockets before 

opening the URL (use 0.0 for non-blocking sockets):



    dto = socket.getdefaulttimeout()

    socket.setdefaulttimeout(mytimeout)

    try:

        try:

            f = urllib2.urlopen("http://www.python.org/")

            x = f.read()

        except socket.error, msg:  ### Note2

            print "timeout"

    finally:

        # restore default

        socket.setdefaulttimeout(dto)



Note1: urllib, urllib2, or both? (and should there be 

a "see also: urllib2" in the urllib docs?)



Note2: Experimenting (and digressing -- it's late :-)



  urllib.urlopen, timeout=0.0: IOError(?) [1]

  urllib.urlopen, timeout=0.1: IOError(?) [2]

  urllib2.urlopen, timeout=0.0: urllib2.URLError [3]

  urllib2.urlopen, timeout=0.1: socket.timeout



I can understand the last one... sort of. The 

exception "reporting" is part of a module's interface, so 

I'd expect to be able to "Except urllib.exception" (modulo 

consistent naming) to catch all reasonable[0] 

exceptions resulting from calling into the module, and 

urllib.timeout to catch timeouts.



I can see the argument that the user set the timeout in 

the socket module, so should expect them, but then 

handling timeouts are routine for web programming...



IOError is not related to socket.timeout, so I'm not sure 

why it's left free to escape, especially with that errno :-)



-- bjorn



[0] of course not urllib.MemoryError or other 

catastrophic events



[1]

  File "E:\Python23\lib\httplib.py", line 564, in send

    self.connect()

  File "E:\Python23\lib\httplib.py", line 548, in connect

    raise socket.error, msg <--### see below

IOError: [Errno socket error] (10035, 'The socket 

operation could not complete without blocking')

>>> x = 0

>>> try:

...   urllib.urlopen

('http://www.comcast.net/memberservices/index.jsp')

... except Exception, e:

...   x = e

...

>>> x   

<exceptions.IOError instance at 0x00A63288> ###

 

[2]

  File "E:\Python23\lib\httplib.py", line 564, in send

    self.connect()

  File "E:\Python23\lib\httplib.py", line 548, in connect

    raise socket.error, msg

IOError: [Errno socket error] timed out



...and also...



  File "E:\Python23\lib\socket.py", line 323, in readline

    data = recv(1)

IOError: [Errno socket error] timed out



[3]

  File "e:\python23\lib\urllib2.py", line 849, in http_open

    return self.do_open(httplib.HTTP, req)

  File "e:\python23\lib\urllib2.py", line 834, in do_open

    raise URLError(err)

urllib2.URLError: <urlopen error (10035, 'The socket 

operation could not complete without blocking')>



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-28 18:27

Message:
Logged In: YES 
user_id=357491

This cannot be added to the docs.  urllib and urllib2 do not 

officially support the socket timeout feature.  It just happens to 

work that way because of the current implementation.



Without changing the docs to explicitly support the socket timeouts 

this example is not valid.  And the docs cannot be changed without 

guaranteeing that urllib and urllib2 will always support the feature.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803634&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 21:38:05 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 21:38:22 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A3mzF-00027w-00@sc8-sf-web3.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 22: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=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-28 21:38

Message:
Logged In: YES 
user_id=31435

Running the original hammer.py under current CVS Python 

freezes in the same way (as in my immediately preceding 

note) now too; again Win98SE.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 21:28

Message:
Logged In: YES 
user_id=31435

About studly_hammer.py:



[Skip Montanaro]

> ...

> Attached is a modified version of the hammer.py script 

which seems to

> not fail for me on either Windows run from IDLE (Python 

2.3, BDB

> 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1).  The original 

script

> failed for me on Windows but not Mac OS X.  Can some 

other people for

> whom the original script fails please try it?  (I also attached 

it to

> bug #775414.) 



On Win98SE with current Python 2.3.1, it doesn't fail, but it 

never seemed to finish for me either.  Staring at WinTop 

showed that the Python process stopped accumulating 

cycles.  Can't be killed with Ctrl+C (no visible effect).  Can be 

killed with Ctrl+Break.



Dumping



        print "%s %s" % (thread.get_ident(), i)



at the top of the hammer loop showed that the threads get 

through several hundred iterations, then all printing stops.



Attaching to a debug-build Python from the debugger when a 

freeze occurs isn't terribly illuminating.  One thread's stack 

shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __ham_get_meta + 120 bytes

_BSDDB_D! __ham_c_dup + 4201 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, 

__db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 

562 + 35 bytes



The main thread's stack shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __db_lget + 365 bytes

_BSDDB_D! __ham_lock_bucket + 105 bytes

_BSDDB_D! __ham_get_cpage + 195 bytes

_BSDDB_D! __ham_item_next + 25 bytes

_BSDDB_D! __ham_call_hash + 2479 bytes

_BSDDB_D! __ham_c_dup + 4307 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, 

__db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 

562 + 35 bytes

DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, 

_object * 0x00b83370) line 2330 + 23 bytes

PyObject_SetItem(_object * 0x008fe2e8, _object * 

0x00b83178, _object * 0x00b83370) line 123 + 18 bytes

eval_frame(_frame * 0x00984948) line 1448 + 17 bytes

...



The other threads are somewhere in the OS kernel and don't 

have useful tracebacks.  This varies from run to run, but all 

threads with a useful stack are always stuck at the same 

place in __db_win32_mutex_lock.



All in all, looks like it's simply deadlocked.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-28 01:11

Message:
Logged In: YES 
user_id=29957

Could you check that it (and the test_bsddb3) works on

Solaris? There's a couple of solaris boxes on the SF compile

farm (cf.sf.net). I was unable to get test_bsddb3 to complete

at all on Solaris 2.6, 7 or 8, when using DB 4.1.25.



As far as 2.3.2, I really really don't think it's appropriate to

throw it in at this late point. Particularly given the 2.3.1 

screwups, I don't want to risk it.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-27 19:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-27 14:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 15:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 15:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 15:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 15:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 15:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 15:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 15:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 19:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 04:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 23:31:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 23:32:49 2003
Subject: [Python-bugs-list] [ python-Bugs-814253 ] Grouprefs in lookbehind
	assertions
Message-ID: <E1A3olP-0001AK-00@sc8-sf-web2.sourceforge.net>

Bugs item #814253, was opened at 2003-09-28 19: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=814253&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fredrik Lundh (effbot)
Summary: Grouprefs in lookbehind assertions

Initial Comment:
I was trying to get a pattern like this to work:



   pat = re.compile(r'(?<=(...)\1)abc')

   pat.match('jkljklabc', 6)



Unfortunately, that doesn't work.  The problem is that 

sre_parse.Subpattern.getwidth() ignores GROUPREFs 

when calculating the width, so the subpattern in the 

assertion is deemed to have length of 3 (I was hoping 

that sre could detect that the group 1 had a fixed 

length, so the reference to it would also have a fixed 

length).



I've since discovered that both Perl and PerlRE cannot 

handle the above pattern, but they both generate 

exceptions indicating that the assertion has a variable 

length pattern.  I think it would be a good idea if sre 

generated an exception as well (rather than silently 

ignoring GROUPREFs).





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814253&group_id=5470

From noreply at sourceforge.net  Sun Sep 28 23:51:12 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Sep 28 23:51:21 2003
Subject: [Python-bugs-list] [ python-Bugs-814259 ] LDFLAGS ignored in
	Makefile
Message-ID: <E1A3p44-0001j5-00@sc8-sf-web2.sourceforge.net>

Bugs item #814259, was opened at 2003-09-28 20: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=814259&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Randy Davis (randydavis1)
Assigned to: Nobody/Anonymous (nobody)
Summary: LDFLAGS ignored in Makefile

Initial Comment:
Under IRIX 6.3 gcc 3.2.2, building python results in the 

normal IRIX o32/n32 stupidity. However, attempting to 

correct it by specifying LDFLAGS of -n32 is ignored.  

Inspecting the Makefile produced by configure shows 

that the environment variable LDFLAGS is properly 

imported and is set as the environment variable is set (in 

this case; "LDFLAGS = -n32").  **HOWEVER**, it is 

NEVER used on any "ld" command line.



I was able to fix it by changing the lines:



LDSHARED=       ld  -shared -all

BLDSHARED=      ld  -shared -all



to:



LDSHARED=       ld  -shared -all $(LDFLAGS)

BLDSHARED=      ld  -shared -all $(LDFLAGS)



While I do not profess that this is the best way to fix it, 

I do note that the LDFLAGS Makefile variable seems to 

be ignored unless this is done.  Making this change got 

rid of the FATAL ld errors complaining about expecting 

o32 binaries but getting n32 versions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814259&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 01:31:05 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 01:31:19 2003
Subject: [Python-bugs-list] [ python-Bugs-814266 ] new.function raises
	TypeError for some strange reason...
Message-ID: <E1A3qcj-0003tT-00@sc8-sf-web1.sourceforge.net>

Bugs item #814266, was opened at 2003-09-29 01: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=814266&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: new.function raises TypeError for some strange reason...

Initial Comment:
Here's an example pasted directly from the interpreter: 
 
>>> def thread(f): 
...     """Makes sure a command spawns a thread when called.""" 
...     def newf(self, irc, msg, args, *L): 
...         ff = new.instancemethod(f, self, self.__class__) 
...         t = callbacks.CommandThread(self.callCommand, ff, irc, 
msg, args, *L) 
...         t.start() 
...     newf = new.function(newf.func_code, newf.func_globals, 
f.func_name) 
...     newf.__doc__ = f.__doc__ 
...     return newf 
... 
>>> import new 
>>> def groovy(): 
...   pass 
... 
>>> thread(groovy) 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "<stdin>", line 7, in thread 
TypeError: arg 5 (closure) must be tuple 
 
Given that I didn't even give the (optional) arg 5, there's some bug 
here, even if it's only documentation/error message. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814266&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 01:38:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 01:38:44 2003
Subject: [Python-bugs-list] [ python-Feature Requests-801847 ] Adding
	rsplit() to string and unicode objects.
Message-ID: <E1A3qjq-00047B-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #801847, was opened at 2003-09-07 00:52
Message generated for change (Comment added) made by jafo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Sean Reifschneider (jafo)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Adding rsplit() to string and unicode objects.

Initial Comment:
I'm attaching patches to the library and documentation

for implementing rsplit() on string and unicode

objects.  This works like split(), but working from the

right.



   ./python -c 'print u"foo, bar, baz".rsplit(None, 1)'

   [u'foo, bar,', u'baz']



This was supposed to be against the CVS code, but I've

had a heck of a time getting it checked out -- my

checkout has been hung for half an hour now.



The code patch is against the 2.3 release, the docs

patch is against the CVS.  My checkout got to docs, but

I didn't have the code to a point where I could build

and test it.



Sean

----------------------------------------------------------------------

>Comment By: Sean Reifschneider (jafo)
Date: 2003-09-29 05:38

Message:
Logged In: YES 
user_id=81797

This seems to have generated nothing but positive comment

from the folks on python-dev.  Thoughts?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 18:17

Message:
Logged In: YES 
user_id=80475

I'll review your patch when I get a chance.

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-09-22 13:10

Message:
Logged In: YES 
user_id=99508

As a comment on the ease with which a programmer can get rsplit 

wrong, note that rhettinger's rsplit implementation is not correct: 

compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). 

 

He forgot to reverse the separator if it's not None. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-11 23:55

Message:
Logged In: YES 
user_id=80475

Guido, do you care to pronounce on this one?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 06:07

Message:
Logged In: YES 
user_id=21627

There is PEP 2, which suggests to write a library PEP for

proposal to extend the library. Now, this probably would be

overkill for a single string method. However, I feel that

there are already too many string methods, so I won't accept

that patch. I'm not rejecting it, either, because I see that

other maintainers might have a different opinion. In short,

you should propose your change to python-dev, finding out

what "a majority" of the maintainers thinks; you might also

propose it on python-list, trying to collect reactions from

users. It would then be good to summarize these discussions

here (instead of carrying them out here).

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2003-09-10 20:40

Message:
Logged In: YES 
user_id=81797

I realize that rsplit() can be implemented, because, well, I

implemented it.



The standard library is there to provide ready-to-use

functionality so that users of python can concentrate on

their program instead of concentrate on re-inventing the

wheel.  find() can be implemented with a short loop, split()

can be implemented with find(), join() can be implemented

with a short loop.    Many things can be implemented with a

little additional effort on the part of the user to develop

or locate the code they're wanting.



These little things can add up quickly and can have quite a

dramatic impact on the programming experience in Python. 

Having to find or implement these functions will cause

distraction from the code at hand, time lost while finding,

implementing, testing, and maintaining the code in question.



One of Python's strengths is a rich standard library.  So,

what are the guidelines for determining when it's rich

enough?  Why is it ok to suggest that users should get

distracted from their code to go implement something else? 

Is there a policy that I'm not aware of that new

functionality should be put in the cookbook instead of the

standard library?  Why is it being ignored that some

programmers would find implementing rsplit() challenging?



I'm not trying to be difficult here, I honestly can't

understand the apparent change from having a rich library to

a "batteries not included" stance.  The response I got from

#python when I mentioned having submitted the patch

indicates to me that other experienced Python developers

expect there to be an rsplit().



So, why is there so much resistance to adding something to

the library?  What are the guidelines for determining if

something should be in the library?



Sean

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-10 19:35

Message:
Logged In: YES 
user_id=80475

I would classify this more as a technique than a fundamental 

string operation implemented by all stringlike objects 

(including UserString).  Accordingly, I recommend that the 

patch be closed and a recipe posted in the ASPN cookbook - 

something along the lines of:



>>> def rsplit(s, sep=None, maxsplit=-1):

...     return  [chunk[::-1] for chunk in s[::-1].split(sep, 

maxsplit)[::-1]]



>>> rsplit(u"foo, bar, baz", None, 1)

[u'foo, bar,', u'baz']

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2003-09-10 19:15

Message:
Logged In: YES 
user_id=81797

os.path.basename/os.path.dirname is an example of where you

could use rsplit. One of the other #python folks said he had

recently wanted rsplit for an application where he was

getting the domain name and user part from a list of e-mail

addresses, but found that some entries contained an "@" in

the user part.



Sean

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 17:08

Message:
Logged In: YES 
user_id=21627

I questioned the usefulness because I could not think of a

meaningful application. Now I see what a potential

application could be, but I doubt its generality, because

that approach would break if there could be two fields that

have commas in them.



I also disagree that symmetry can motivate usefulness: I

also doubt that all of the r* functions are useful, but they

cannot be removed for backwards compatibility. The fact that

rsplit would fit together with the other r* functions

indicates that adding rsplit would provide symmetry, not

that it would provide usefulness.

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2003-09-08 00:56

Message:
Logged In: YES 
user_id=81797

Can you provide more details about why the usefulness of

this function is in question?



First I would like to tell you the story of it coming to be,

then I will answer your incomplete question with a

(probably) incomplete answer.  I had a device which sent me

comma-separated fields, but one of the fields in the middle

could contain a comma.  The answer that seemed obvious to me

was to use split with a maxsplit to get the fields up to

that field, and then a rsplit with a maxsplit on the

remainder.  When I mentioned on #python that I was

implementing rsplit, 4 other fellow python users replied

right away that they had been wanting it.



To answer your question, it's useful because people using

strings are used to having r*() functions like rfind and

rstrip.  The lack of rsplit is kind of glaring in this

context.  Really, though, it's useful because otherwise

people have to implement -- often badly.



Sean

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-07 19:49

Message:
Logged In: YES 
user_id=21627

Why is this function useful?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 02:25:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 02:25:46 2003
Subject: [Python-bugs-list] [ python-Bugs-791410 ] Make logging consistent
	in the standard library
Message-ID: <E1A3rTP-0005lE-00@sc8-sf-web1.sourceforge.net>

Bugs item #791410, was opened at 2003-08-19 13:32
Message generated for change (Comment added) made by mfbarnes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791410&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew F. Barnes (mfbarnes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make logging consistent in the standard library

Initial Comment:
Logging should be consistent in the standard library. 

Standard library modules that currently define their

own logging functions should be updated to use the

standard 'logging' module instead.



Such modules include (not necessarily a complete list):



asyncore.py

BaseHTTPServer.py

cgi.py

doctest.py

imaplib.py

unittest.py

distutils package

----------------------------------------------------------------------

>Comment By: Matthew F. Barnes (mfbarnes)
Date: 2003-09-29 01:25

Message:
Logged In: YES 
user_id=843448

Remove doctest.py and unittest.py from this list.  Steve

Purcell and Tim Peters have indicated that logging is not

applicable to those modules.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791410&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 02:57:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 02:57:16 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A3rxs-0006Nh-00@sc8-sf-web2.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 19:29
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2003-09-28 23:57

Message:
Logged In: YES 
user_id=413

Deadlocks only occurring under DOS-based "windows"

(win95/98/me) aren't something the python module can

prevent.  I suggest submitting the sample code and info from

studly_hammer.py to sleepycat.  They're usually very

responsive to questions of that nature.



btw, i'll give things a go on solaris later this week.  if

the test suite never completes i again suspect it is a

berkeleydb library issue on that platform rather than python

module.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 18:38

Message:
Logged In: YES 
user_id=31435

Running the original hammer.py under current CVS Python 

freezes in the same way (as in my immediately preceding 

note) now too; again Win98SE.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 18:28

Message:
Logged In: YES 
user_id=31435

About studly_hammer.py:



[Skip Montanaro]

> ...

> Attached is a modified version of the hammer.py script 

which seems to

> not fail for me on either Windows run from IDLE (Python 

2.3, BDB

> 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1).  The original 

script

> failed for me on Windows but not Mac OS X.  Can some 

other people for

> whom the original script fails please try it?  (I also attached 

it to

> bug #775414.) 



On Win98SE with current Python 2.3.1, it doesn't fail, but it 

never seemed to finish for me either.  Staring at WinTop 

showed that the Python process stopped accumulating 

cycles.  Can't be killed with Ctrl+C (no visible effect).  Can be 

killed with Ctrl+Break.



Dumping



        print "%s %s" % (thread.get_ident(), i)



at the top of the hammer loop showed that the threads get 

through several hundred iterations, then all printing stops.



Attaching to a debug-build Python from the debugger when a 

freeze occurs isn't terribly illuminating.  One thread's stack 

shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __ham_get_meta + 120 bytes

_BSDDB_D! __ham_c_dup + 4201 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, 

__db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 

562 + 35 bytes



The main thread's stack shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __db_lget + 365 bytes

_BSDDB_D! __ham_lock_bucket + 105 bytes

_BSDDB_D! __ham_get_cpage + 195 bytes

_BSDDB_D! __ham_item_next + 25 bytes

_BSDDB_D! __ham_call_hash + 2479 bytes

_BSDDB_D! __ham_c_dup + 4307 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, 

__db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 

562 + 35 bytes

DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, 

_object * 0x00b83370) line 2330 + 23 bytes

PyObject_SetItem(_object * 0x008fe2e8, _object * 

0x00b83178, _object * 0x00b83370) line 123 + 18 bytes

eval_frame(_frame * 0x00984948) line 1448 + 17 bytes

...



The other threads are somewhere in the OS kernel and don't 

have useful tracebacks.  This varies from run to run, but all 

threads with a useful stack are always stuck at the same 

place in __db_win32_mutex_lock.



All in all, looks like it's simply deadlocked.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 22:11

Message:
Logged In: YES 
user_id=29957

Could you check that it (and the test_bsddb3) works on

Solaris? There's a couple of solaris boxes on the SF compile

farm (cf.sf.net). I was unable to get test_bsddb3 to complete

at all on Solaris 2.6, 7 or 8, when using DB 4.1.25.



As far as 2.3.2, I really really don't think it's appropriate to

throw it in at this late point. Particularly given the 2.3.1 

screwups, I don't want to risk it.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-27 16:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-27 11:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 15:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 12:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 12:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 12:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 12:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 10:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 09:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 09:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 16:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 01:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 03:02:09 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 03:02:24 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A3s2r-0006aI-00@sc8-sf-web2.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 19:29
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2003-09-29 00:02

Message:
Logged In: YES 
user_id=413

anthony - if we don't put this patch into python 2.3.2, the

python 2.3.x bsddb module documentation should be updated to

say that multithreaded access is not supported and will

cause problems, possibly even python interpreter crashes.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-28 23:57

Message:
Logged In: YES 
user_id=413

Deadlocks only occurring under DOS-based "windows"

(win95/98/me) aren't something the python module can

prevent.  I suggest submitting the sample code and info from

studly_hammer.py to sleepycat.  They're usually very

responsive to questions of that nature.



btw, i'll give things a go on solaris later this week.  if

the test suite never completes i again suspect it is a

berkeleydb library issue on that platform rather than python

module.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 18:38

Message:
Logged In: YES 
user_id=31435

Running the original hammer.py under current CVS Python 

freezes in the same way (as in my immediately preceding 

note) now too; again Win98SE.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 18:28

Message:
Logged In: YES 
user_id=31435

About studly_hammer.py:



[Skip Montanaro]

> ...

> Attached is a modified version of the hammer.py script 

which seems to

> not fail for me on either Windows run from IDLE (Python 

2.3, BDB

> 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1).  The original 

script

> failed for me on Windows but not Mac OS X.  Can some 

other people for

> whom the original script fails please try it?  (I also attached 

it to

> bug #775414.) 



On Win98SE with current Python 2.3.1, it doesn't fail, but it 

never seemed to finish for me either.  Staring at WinTop 

showed that the Python process stopped accumulating 

cycles.  Can't be killed with Ctrl+C (no visible effect).  Can be 

killed with Ctrl+Break.



Dumping



        print "%s %s" % (thread.get_ident(), i)



at the top of the hammer loop showed that the threads get 

through several hundred iterations, then all printing stops.



Attaching to a debug-build Python from the debugger when a 

freeze occurs isn't terribly illuminating.  One thread's stack 

shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __ham_get_meta + 120 bytes

_BSDDB_D! __ham_c_dup + 4201 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, 

__db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 

562 + 35 bytes



The main thread's stack shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __db_lget + 365 bytes

_BSDDB_D! __ham_lock_bucket + 105 bytes

_BSDDB_D! __ham_get_cpage + 195 bytes

_BSDDB_D! __ham_item_next + 25 bytes

_BSDDB_D! __ham_call_hash + 2479 bytes

_BSDDB_D! __ham_c_dup + 4307 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, 

__db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 

562 + 35 bytes

DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, 

_object * 0x00b83370) line 2330 + 23 bytes

PyObject_SetItem(_object * 0x008fe2e8, _object * 

0x00b83178, _object * 0x00b83370) line 123 + 18 bytes

eval_frame(_frame * 0x00984948) line 1448 + 17 bytes

...



The other threads are somewhere in the OS kernel and don't 

have useful tracebacks.  This varies from run to run, but all 

threads with a useful stack are always stuck at the same 

place in __db_win32_mutex_lock.



All in all, looks like it's simply deadlocked.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 22:11

Message:
Logged In: YES 
user_id=29957

Could you check that it (and the test_bsddb3) works on

Solaris? There's a couple of solaris boxes on the SF compile

farm (cf.sf.net). I was unable to get test_bsddb3 to complete

at all on Solaris 2.6, 7 or 8, when using DB 4.1.25.



As far as 2.3.2, I really really don't think it's appropriate to

throw it in at this late point. Particularly given the 2.3.1 

screwups, I don't want to risk it.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-27 16:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-27 11:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 15:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 12:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 12:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 12:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 12:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 11:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 11:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 10:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 09:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 09:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 16:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 01:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 03:08:58 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 03:09:11 2003
Subject: [Python-bugs-list] [ python-Bugs-814290 ] int() weirdness (Python
	2.3.1, GCC 3.3.1)
Message-ID: <E1A3s9S-0003Mf-00@sc8-sf-web3.sourceforge.net>

Bugs item #814290, was opened at 2003-09-29 16: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=814290&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Church (achurch)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() weirdness (Python 2.3.1, GCC 3.3.1)

Initial Comment:
int() is behaving very strangely for me:

>>> int(42)

42

>>> int(42.5)

0

>>> int(429.777407345)

17126444324755L



What could cause this?  This is from a compile from

source using GCC 3.3.1; turning optimization on or off

does not seem to affect it (-O0, -O2, -O3 all tried).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814290&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 03:42:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 03:43:03 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A3sg9-0000sK-00@sc8-sf-web1.sourceforge.net>

Bugs item #775414, was opened at 2003-07-22 12:29
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-29 17:42

Message:
Logged In: YES 
user_id=29957

I'd be much happier with a documentation fix for 2.3.2. 



Note that when I said "fails to complete" on Solaris, I

meant that it crashes out, not that it deadlocks. I can post

the tracebacks here if you'd like.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-29 17:02

Message:
Logged In: YES 
user_id=413

anthony - if we don't put this patch into python 2.3.2, the

python 2.3.x bsddb module documentation should be updated to

say that multithreaded access is not supported and will

cause problems, possibly even python interpreter crashes.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-29 16:57

Message:
Logged In: YES 
user_id=413

Deadlocks only occurring under DOS-based "windows"

(win95/98/me) aren't something the python module can

prevent.  I suggest submitting the sample code and info from

studly_hammer.py to sleepycat.  They're usually very

responsive to questions of that nature.



btw, i'll give things a go on solaris later this week.  if

the test suite never completes i again suspect it is a

berkeleydb library issue on that platform rather than python

module.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-29 11:38

Message:
Logged In: YES 
user_id=31435

Running the original hammer.py under current CVS Python 

freezes in the same way (as in my immediately preceding 

note) now too; again Win98SE.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-29 11:28

Message:
Logged In: YES 
user_id=31435

About studly_hammer.py:



[Skip Montanaro]

> ...

> Attached is a modified version of the hammer.py script 

which seems to

> not fail for me on either Windows run from IDLE (Python 

2.3, BDB

> 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1).  The original 

script

> failed for me on Windows but not Mac OS X.  Can some 

other people for

> whom the original script fails please try it?  (I also attached 

it to

> bug #775414.) 



On Win98SE with current Python 2.3.1, it doesn't fail, but it 

never seemed to finish for me either.  Staring at WinTop 

showed that the Python process stopped accumulating 

cycles.  Can't be killed with Ctrl+C (no visible effect).  Can be 

killed with Ctrl+Break.



Dumping



        print "%s %s" % (thread.get_ident(), i)



at the top of the hammer loop showed that the threads get 

through several hundred iterations, then all printing stops.



Attaching to a debug-build Python from the debugger when a 

freeze occurs isn't terribly illuminating.  One thread's stack 

shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __ham_get_meta + 120 bytes

_BSDDB_D! __ham_c_dup + 4201 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, 

__db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 

562 + 35 bytes



The main thread's stack shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __db_lget + 365 bytes

_BSDDB_D! __ham_lock_bucket + 105 bytes

_BSDDB_D! __ham_get_cpage + 195 bytes

_BSDDB_D! __ham_item_next + 25 bytes

_BSDDB_D! __ham_call_hash + 2479 bytes

_BSDDB_D! __ham_c_dup + 4307 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, 

__db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 

562 + 35 bytes

DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, 

_object * 0x00b83370) line 2330 + 23 bytes

PyObject_SetItem(_object * 0x008fe2e8, _object * 

0x00b83178, _object * 0x00b83370) line 123 + 18 bytes

eval_frame(_frame * 0x00984948) line 1448 + 17 bytes

...



The other threads are somewhere in the OS kernel and don't 

have useful tracebacks.  This varies from run to run, but all 

threads with a useful stack are always stuck at the same 

place in __db_win32_mutex_lock.



All in all, looks like it's simply deadlocked.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-28 15:11

Message:
Logged In: YES 
user_id=29957

Could you check that it (and the test_bsddb3) works on

Solaris? There's a couple of solaris boxes on the SF compile

farm (cf.sf.net). I was unable to get test_bsddb3 to complete

at all on Solaris 2.6, 7 or 8, when using DB 4.1.25.



As far as 2.3.2, I really really don't think it's appropriate to

throw it in at this late point. Particularly given the 2.3.1 

screwups, I don't want to risk it.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-28 09:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-28 04:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-13 08:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-13 05:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-13 05:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 05:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-13 05:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-13 05:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 05:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-13 05:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-13 04:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-13 04:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 04:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-13 04:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-13 04:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 03:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-13 02:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-13 02:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-14 09:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 18:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 04:09:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 04:09:28 2003
Subject: [Python-bugs-list] [ python-Bugs-814290 ] int() weirdness (Python
	2.3.1, GCC 3.3.1)
Message-ID: <E1A3t5Z-0000mw-00@sc8-sf-web2.sourceforge.net>

Bugs item #814290, was opened at 2003-09-29 17:08
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814290&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Church (achurch)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() weirdness (Python 2.3.1, GCC 3.3.1)

Initial Comment:
int() is behaving very strangely for me:

>>> int(42)

42

>>> int(42.5)

0

>>> int(429.777407345)

17126444324755L



What could cause this?  This is from a compile from

source using GCC 3.3.1; turning optimization on or off

does not seem to affect it (-O0, -O2, -O3 all tried).

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-29 18:09

Message:
Logged In: YES 
user_id=29957

Which platform is this on? Also if it's a linux machine,

which version of libc is it using?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814290&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 04:11:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 04:12:15 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A3t7t-0000vW-00@sc8-sf-web2.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 23:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-29 18:11

Message:
Logged In: YES 
user_id=29957

assigning to self to test.



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-27 17:40

Message:
Logged In: YES 
user_id=21627

The patch is fine; please apply.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 04:47

Message:
Logged In: YES 
user_id=29957

I'll also attach a patch for the (generated) configure

script, for those folks without autoconf on their systems.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:14

Message:
Logged In: YES 
user_id=29957

argh. sf tracker strikes again. this time for sure.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:13

Message:
Logged In: YES 
user_id=29957

There's three ways we can fix this:

1. Hand-edit configure after running autoconf (yuk)

2. Run a CVS version of autoconf (yuk)

3. Supply an aclocal.m4 in the same way that the gcc guys

used to fix the problem (a bit yuk).



The aclocal fix would only be needed until the next release

of autoconf is out. I've attached an aclocal.m4 that

includes the GCC fix. Trying it here shows that it generates

a "fixed" configure scipt - I've not yet logged onto the HP

testdrive boxes to confirm it absolutely works, but it looks

like the fixes I did by hand in order to get it to work.



MvL, your thoughts? You seem to be the local autoconf guru... 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-24 00:26

Message:
Logged In: YES 
user_id=29957

mwh points out that the snakefarm is having the same problem:

http://www.lysator.liu.se/xenofarm/python/files/792_10/python-testlog.txt

(we discovered and debugged this on one of the

DEC^WDigital^WCompaq^WHP "testdrive" boxes)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:58

Message:
Logged In: YES 
user_id=29957

Oh, and the problem also occurs if you use gcc instead of cc -Ae





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:56

Message:
Logged In: YES 
user_id=29957

the functions that fail (erroneously) are

HAVE_CLOCK HAVE_GETTIMEOFDAY HAVE_MKTIME HAVE_SELECT

HAVE_STRFTIME HAVE_STRPTIME HAVE_UTIMES





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 04:21:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 04:21:37 2003
Subject: [Python-bugs-list] [ python-Bugs-814290 ] int() weirdness (Python
	2.3.1, GCC 3.3.1)
Message-ID: <E1A3tHT-0001Sv-00@sc8-sf-web2.sourceforge.net>

Bugs item #814290, was opened at 2003-09-29 16:08
Message generated for change (Comment added) made by achurch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814290&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Church (achurch)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() weirdness (Python 2.3.1, GCC 3.3.1)

Initial Comment:
int() is behaving very strangely for me:

>>> int(42)

42

>>> int(42.5)

0

>>> int(429.777407345)

17126444324755L



What could cause this?  This is from a compile from

source using GCC 3.3.1; turning optimization on or off

does not seem to affect it (-O0, -O2, -O3 all tried).

----------------------------------------------------------------------

>Comment By: Andrew Church (achurch)
Date: 2003-09-29 17:21

Message:
Logged In: YES 
user_id=527960

i386 (really Pentium 4), glibc 2.2.5.



I think I've located the problem: modf() from libm is

returning bogus values, so this looks like a glibc bug, not

a Python bug.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-29 17:09

Message:
Logged In: YES 
user_id=29957

Which platform is this on? Also if it's a linux machine,

which version of libc is it using?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814290&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 09:24:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 09:24:24 2003
Subject: [Python-bugs-list] [ python-Bugs-813986 ] robotparser interactively
	prompts for username and password
Message-ID: <E1A3y0W-0008EA-00@sc8-sf-web2.sourceforge.net>

Bugs item #813986, was opened at 2003-09-28 15:06
Message generated for change (Comment added) made by calvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: robotparser interactively prompts for username and password

Initial Comment:
This is a rare occurrence, but if a /robots.txt file is

password-protected on an http server, robotparser

interactively prompts (via raw_input) for a username

and password, because that is urllib's default

behavior.  One example of such a URL, at least at the

time of this writing, is



http://www.cosc.canterbury.ac.nz/robots.txt



Given that robotparser and robots.txt is all about

*robots* (not interactive users), I don't think this

interactive behavior is terribly appropriate.  Attached

is a simple patch to robotparser.py to fix this

behavior, forcing urllib to return the 401 error that

it ought to.



Another issue is whether a 401 (Authorization Required)

URL means that everything should be allowed or

everything should be disallowed.  I'm not sure what's

"right".  Reading the spec, it says 'This file must be

accessible via HTTP on the local URL "/robots.txt"'

which I would read to mean it should be accessible

without username/password.  On the other hand, the

current robotparser.py code says "if self.errcode ==

401 or self.errcode == 403: self.disallow_all = 1"

which has the opposite effect.  I'll leave deciding

which is most appropriate to the powers that be.



----------------------------------------------------------------------

Comment By: Bastian Kleineidam (calvin)
Date: 2003-09-29 15:24

Message:
Logged In: YES 
user_id=9205

http://www.robotstxt.org/wc/norobots-rfc.html specifies the

401 and 403 return code consequences as restricting the

whole site (ie disallow_all = 1).



For the password input, the patch looks good to me. On the

long term, robotparser.py should switch to urllib2.py

anyway, and it should handle Transfer-Encoding: gzip.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 10:15:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 10:16:07 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A3yoR-0007ja-00@sc8-sf-web3.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 22: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=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-29 10:15

Message:
Logged In: YES 
user_id=31435

Greg, I'm in a constant state of debugging (in other apps) 

thread problems that *appear* unique to Win9x.  But in years 

of this, I have yet to see one that actually is unique to 

Win9x -- in the end, they always turn out to be legit races in 

the app I'm debugging, and can always be reproduced on 

other platforms if the test is made stressful enough and/or 

run long enough.  Win9x appears especially good at provoking 

thread problems just because its scheduling is erratic, often 

acting like a Linux system under extreme load that way.



IOW, unless there's a bug in Sleepycat's implementation of 

locking on Win9x, I bet dollars to doughnuts this program will 

eventually deadlock everywhere.  In Python's lifetime, across 

dozens of miserable thread problems, we haven't pinned the 

blame once on Win9x.  That wasn't for lack of trying <wink>.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-29 03:42

Message:
Logged In: YES 
user_id=29957

I'd be much happier with a documentation fix for 2.3.2. 



Note that when I said "fails to complete" on Solaris, I

meant that it crashes out, not that it deadlocks. I can post

the tracebacks here if you'd like.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-29 03:02

Message:
Logged In: YES 
user_id=413

anthony - if we don't put this patch into python 2.3.2, the

python 2.3.x bsddb module documentation should be updated to

say that multithreaded access is not supported and will

cause problems, possibly even python interpreter crashes.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-29 02:57

Message:
Logged In: YES 
user_id=413

Deadlocks only occurring under DOS-based "windows"

(win95/98/me) aren't something the python module can

prevent.  I suggest submitting the sample code and info from

studly_hammer.py to sleepycat.  They're usually very

responsive to questions of that nature.



btw, i'll give things a go on solaris later this week.  if

the test suite never completes i again suspect it is a

berkeleydb library issue on that platform rather than python

module.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 21:38

Message:
Logged In: YES 
user_id=31435

Running the original hammer.py under current CVS Python 

freezes in the same way (as in my immediately preceding 

note) now too; again Win98SE.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 21:28

Message:
Logged In: YES 
user_id=31435

About studly_hammer.py:



[Skip Montanaro]

> ...

> Attached is a modified version of the hammer.py script 

which seems to

> not fail for me on either Windows run from IDLE (Python 

2.3, BDB

> 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1).  The original 

script

> failed for me on Windows but not Mac OS X.  Can some 

other people for

> whom the original script fails please try it?  (I also attached 

it to

> bug #775414.) 



On Win98SE with current Python 2.3.1, it doesn't fail, but it 

never seemed to finish for me either.  Staring at WinTop 

showed that the Python process stopped accumulating 

cycles.  Can't be killed with Ctrl+C (no visible effect).  Can be 

killed with Ctrl+Break.



Dumping



        print "%s %s" % (thread.get_ident(), i)



at the top of the hammer loop showed that the threads get 

through several hundred iterations, then all printing stops.



Attaching to a debug-build Python from the debugger when a 

freeze occurs isn't terribly illuminating.  One thread's stack 

shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __ham_get_meta + 120 bytes

_BSDDB_D! __ham_c_dup + 4201 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, 

__db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 

562 + 35 bytes



The main thread's stack shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __db_lget + 365 bytes

_BSDDB_D! __ham_lock_bucket + 105 bytes

_BSDDB_D! __ham_get_cpage + 195 bytes

_BSDDB_D! __ham_item_next + 25 bytes

_BSDDB_D! __ham_call_hash + 2479 bytes

_BSDDB_D! __ham_c_dup + 4307 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, 

__db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 

562 + 35 bytes

DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, 

_object * 0x00b83370) line 2330 + 23 bytes

PyObject_SetItem(_object * 0x008fe2e8, _object * 

0x00b83178, _object * 0x00b83370) line 123 + 18 bytes

eval_frame(_frame * 0x00984948) line 1448 + 17 bytes

...



The other threads are somewhere in the OS kernel and don't 

have useful tracebacks.  This varies from run to run, but all 

threads with a useful stack are always stuck at the same 

place in __db_win32_mutex_lock.



All in all, looks like it's simply deadlocked.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-28 01:11

Message:
Logged In: YES 
user_id=29957

Could you check that it (and the test_bsddb3) works on

Solaris? There's a couple of solaris boxes on the SF compile

farm (cf.sf.net). I was unable to get test_bsddb3 to complete

at all on Solaris 2.6, 7 or 8, when using DB 4.1.25.



As far as 2.3.2, I really really don't think it's appropriate to

throw it in at this late point. Particularly given the 2.3.1 

screwups, I don't want to risk it.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-27 19:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-27 14:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 18:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 15:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 15:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 15:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 15:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 15:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 15:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 15:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 12:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 19:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 04:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 10:51:54 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 11:25:45 2003
Subject: [Python-bugs-list] [ python-Bugs-758241 ] asyncore with non-default
	map problems
Message-ID: <E1A3zNS-0001LS-00@sc8-sf-web3.sourceforge.net>

Bugs item #758241, was opened at 2003-06-21 03:41
Message generated for change (Comment added) made by stephane_ninin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758241&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Halley (rthalley)
Assigned to: A.M. Kuchling (akuchling)
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.



----------------------------------------------------------------------

Comment By: Stephane Ninin (stephane_ninin)
Date: 2003-09-29 16:51

Message:
Logged In: YES 
user_id=874382



I think this should solve the problem with non-default maps 

in asyncore.dispatcher. Hope this helps.



*** asyncore.py Mon Sep 29 16:20:13 2003

--- asyncore-new.py     Mon Sep 29 16:20:26 2003

***************

*** 201,206 ****

--- 201,211 ----

      addr = None



      def __init__(self, sock=None, map=None):

+         if (map is None):

+             self.map = socket_map

+         else:

+             self.map=map

+

          if sock:

              self.set_socket(sock, map)

              # I think it should inherit this anyway

***************

*** 248,254 ****

          self.socket = socket.socket(family, type)

          self.socket.setblocking(0)

          self._fileno = self.socket.fileno()

!         self.add_channel()



      def set_socket(self, sock, map=None):

          self.socket = sock

--- 253,259 ----

          self.socket = socket.socket(family, type)

          self.socket.setblocking(0)

          self._fileno = self.socket.fileno()

!         self.add_channel(self.map)



      def set_socket(self, sock, map=None):

          self.socket = sock

***************

*** 353,359 ****

                  raise socket.error, why



      def close(self):

!         self.del_channel()

          self.socket.close()



      # cheap inheritance, used to pass all other attribute

--- 358,364 ----

                  raise socket.error, why



      def close(self):

!         self.del_channel(self.map)

          self.socket.close()



      # cheap inheritance, used to pass all other attribute 





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758241&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 11:49:42 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 11:49:54 2003
Subject: [Python-bugs-list] [ python-Bugs-814524 ] libpython2.3.so.1.0 can't
	be found with -l
Message-ID: <E1A40HO-00006k-00@sc8-sf-web2.sourceforge.net>

Bugs item #814524, was opened at 2003-09-29 11:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814524&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: benson margulies (benson_basis)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython2.3.so.1.0 can't be found with -l

Initial Comment:
The linux 'ld' does not know how to find 

libpython2.3.so.1.0. The convention here is to add a 

symbolic link named 'libpython2.3.so' for use at link time, 

and then the use of the SONAME option causes the 

dynamic linker to search for the longer name at runtime.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814524&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 12:27:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 12:27:55 2003
Subject: [Python-bugs-list] [ python-Bugs-814544 ] AIX configure;make fails
Message-ID: <E1A40sB-0007YN-00@sc8-sf-web3.sourceforge.net>

Bugs item #814544, was opened at 2003-09-29 12: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=814544&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ruttenberg (rutt)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX configure;make fails

Initial Comment:
Standard ./configure and make fails for me with both

2.2.3 and 2.3.1 on AIX.



On AIX-5.1 with IBM's visualage compiler installed the

build fails with the following:



./Modules/ld_so_aix cc_r -bI:Modules/python.exp

build/temp.aix-5.1-2.2/cryptmodule.o -L/usr/local/lib

-lcrypt -o \

build/lib.aix-5.1-2.2/crypt.so

building '_socket' extension

cc_r -DNDEBUG -O -DUSE_SSL=1 -I/usr/local/ssl/include

-I. -I/home/rutt/src/Python-2.2.3/./Include

-I/usr/local/in\

clude -I/home/rutt/src/Python-2.2.3/Include

-I/home/rutt/src/Python-2.2.3 -c

/home/rutt/src/Python-2.2.3/Modules/\

socketmodule.c -o build/temp.aix-5.1-2.2/socketmodule.o

./Modules/ld_so_aix cc_r -bI:Modules/python.exp

build/temp.aix-5.1-2.2/socketmodule.o

-L/usr/local/ssl/lib -L/usr\

/local/lib -lssl -lcrypto -o

build/lib.aix-5.1-2.2/_socket.so

ld: 0711-317 ERROR: Undefined symbol: .__umoddi3

ld: 0711-317 ERROR: Undefined symbol: .__udivdi3

ld: 0711-345 Use the -bloadmap or -bnoquiet option to

obtain more information.

*** WARNING: renaming "_socket" since importing it

failed: from module build/lib.aix-5.1-2.2/_socket.so No

such f\

ile or directory

error: No such file or directory

make: *** [sharedmods] Error 1



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814544&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 12:41:56 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 12:42:12 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A415w-00030w-00@sc8-sf-web2.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 21:29
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-29 11:41

Message:
Logged In: YES 
user_id=44345

I built from CVS head on a Solaris machine.  bsddb.__version__

reports '4.2.1'.  When run, the studly_hammer.py script

completes the dbenv.open() call, but appears to hang during

the hashopen() call.  Adding some print statements to hashopen()

indicates that it hangs during d.open().



I don't know what to make of this.  If others have some

suggestions, I'll be happy to try them out.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-29 09:15

Message:
Logged In: YES 
user_id=31435

Greg, I'm in a constant state of debugging (in other apps) 

thread problems that *appear* unique to Win9x.  But in years 

of this, I have yet to see one that actually is unique to 

Win9x -- in the end, they always turn out to be legit races in 

the app I'm debugging, and can always be reproduced on 

other platforms if the test is made stressful enough and/or 

run long enough.  Win9x appears especially good at provoking 

thread problems just because its scheduling is erratic, often 

acting like a Linux system under extreme load that way.



IOW, unless there's a bug in Sleepycat's implementation of 

locking on Win9x, I bet dollars to doughnuts this program will 

eventually deadlock everywhere.  In Python's lifetime, across 

dozens of miserable thread problems, we haven't pinned the 

blame once on Win9x.  That wasn't for lack of trying <wink>.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-29 02:42

Message:
Logged In: YES 
user_id=29957

I'd be much happier with a documentation fix for 2.3.2. 



Note that when I said "fails to complete" on Solaris, I

meant that it crashes out, not that it deadlocks. I can post

the tracebacks here if you'd like.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-29 02:02

Message:
Logged In: YES 
user_id=413

anthony - if we don't put this patch into python 2.3.2, the

python 2.3.x bsddb module documentation should be updated to

say that multithreaded access is not supported and will

cause problems, possibly even python interpreter crashes.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-29 01:57

Message:
Logged In: YES 
user_id=413

Deadlocks only occurring under DOS-based "windows"

(win95/98/me) aren't something the python module can

prevent.  I suggest submitting the sample code and info from

studly_hammer.py to sleepycat.  They're usually very

responsive to questions of that nature.



btw, i'll give things a go on solaris later this week.  if

the test suite never completes i again suspect it is a

berkeleydb library issue on that platform rather than python

module.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 20:38

Message:
Logged In: YES 
user_id=31435

Running the original hammer.py under current CVS Python 

freezes in the same way (as in my immediately preceding 

note) now too; again Win98SE.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 20:28

Message:
Logged In: YES 
user_id=31435

About studly_hammer.py:



[Skip Montanaro]

> ...

> Attached is a modified version of the hammer.py script 

which seems to

> not fail for me on either Windows run from IDLE (Python 

2.3, BDB

> 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1).  The original 

script

> failed for me on Windows but not Mac OS X.  Can some 

other people for

> whom the original script fails please try it?  (I also attached 

it to

> bug #775414.) 



On Win98SE with current Python 2.3.1, it doesn't fail, but it 

never seemed to finish for me either.  Staring at WinTop 

showed that the Python process stopped accumulating 

cycles.  Can't be killed with Ctrl+C (no visible effect).  Can be 

killed with Ctrl+Break.



Dumping



        print "%s %s" % (thread.get_ident(), i)



at the top of the hammer loop showed that the threads get 

through several hundred iterations, then all printing stops.



Attaching to a debug-build Python from the debugger when a 

freeze occurs isn't terribly illuminating.  One thread's stack 

shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __ham_get_meta + 120 bytes

_BSDDB_D! __ham_c_dup + 4201 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, 

__db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 

562 + 35 bytes



The main thread's stack shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __db_lget + 365 bytes

_BSDDB_D! __ham_lock_bucket + 105 bytes

_BSDDB_D! __ham_get_cpage + 195 bytes

_BSDDB_D! __ham_item_next + 25 bytes

_BSDDB_D! __ham_call_hash + 2479 bytes

_BSDDB_D! __ham_c_dup + 4307 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, 

__db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 

562 + 35 bytes

DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, 

_object * 0x00b83370) line 2330 + 23 bytes

PyObject_SetItem(_object * 0x008fe2e8, _object * 

0x00b83178, _object * 0x00b83370) line 123 + 18 bytes

eval_frame(_frame * 0x00984948) line 1448 + 17 bytes

...



The other threads are somewhere in the OS kernel and don't 

have useful tracebacks.  This varies from run to run, but all 

threads with a useful stack are always stuck at the same 

place in __db_win32_mutex_lock.



All in all, looks like it's simply deadlocked.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-28 00:11

Message:
Logged In: YES 
user_id=29957

Could you check that it (and the test_bsddb3) works on

Solaris? There's a couple of solaris boxes on the SF compile

farm (cf.sf.net). I was unable to get test_bsddb3 to complete

at all on Solaris 2.6, 7 or 8, when using DB 4.1.25.



As far as 2.3.2, I really really don't think it's appropriate to

throw it in at this late point. Particularly given the 2.3.1 

screwups, I don't want to risk it.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-27 18:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-27 13:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 17:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 14:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 14:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 11:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 18:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 03:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 13:05:40 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 13:05:59 2003
Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out
	with threads
Message-ID: <E1A41Su-0004Xd-00@sc8-sf-web2.sourceforge.net>

Bugs item #775414, was opened at 2003-07-21 21:29
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb3 hash craps out with threads

Initial Comment:
Richie Hindle presented something like the attached 

(hammer.py) on the spambayes-dev mailing list.  On 

Win98SE and Win2K w/ Python 2.3c1 I usually see this 

death pretty quickly:



Traceback (most recent call last):

  File "hammer.py", line 36, in ?

    main()

  File "hammer.py", line 33, in main

    hammer(db)

  File "hammer.py", line 15, in hammer

    x = db[str(int(random.random() * 100000))]

  File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, 

in __getitem__

    return self.db[key]

bsddb._db.DBRunRecoveryError: (-30982,

     'DB_RUNRECOVERY: Fatal error, run database 

recovery -- fatal region error detected; run recovery')



Richie also reported "illegal operation" crashes on 

Win98SE.



It's not clear whether a bsddb3 hash *can* be used 

with threads like this.  If it can't, there's a doc bug.  If it 

should be able to, there's a more serious problem.  Note 

that it looks like hashopen() always merges DB_THREAD 

into the flags, so the absence of specifying DB_THREAD 

probably isn't the problem.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-09-29 12:05

Message:
Logged In: YES 
user_id=44345

Forgot to mention that without the DBEnv() object, it gets a

segmentation violation on Solaris 8 seg faults pretty quickly

(within 10,000 iterations for each thread) or raises

bsddb._db.DBRunRecoveryError.





----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-29 11:41

Message:
Logged In: YES 
user_id=44345

I built from CVS head on a Solaris machine.  bsddb.__version__

reports '4.2.1'.  When run, the studly_hammer.py script

completes the dbenv.open() call, but appears to hang during

the hashopen() call.  Adding some print statements to hashopen()

indicates that it hangs during d.open().



I don't know what to make of this.  If others have some

suggestions, I'll be happy to try them out.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-29 09:15

Message:
Logged In: YES 
user_id=31435

Greg, I'm in a constant state of debugging (in other apps) 

thread problems that *appear* unique to Win9x.  But in years 

of this, I have yet to see one that actually is unique to 

Win9x -- in the end, they always turn out to be legit races in 

the app I'm debugging, and can always be reproduced on 

other platforms if the test is made stressful enough and/or 

run long enough.  Win9x appears especially good at provoking 

thread problems just because its scheduling is erratic, often 

acting like a Linux system under extreme load that way.



IOW, unless there's a bug in Sleepycat's implementation of 

locking on Win9x, I bet dollars to doughnuts this program will 

eventually deadlock everywhere.  In Python's lifetime, across 

dozens of miserable thread problems, we haven't pinned the 

blame once on Win9x.  That wasn't for lack of trying <wink>.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-29 02:42

Message:
Logged In: YES 
user_id=29957

I'd be much happier with a documentation fix for 2.3.2. 



Note that when I said "fails to complete" on Solaris, I

meant that it crashes out, not that it deadlocks. I can post

the tracebacks here if you'd like.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-29 02:02

Message:
Logged In: YES 
user_id=413

anthony - if we don't put this patch into python 2.3.2, the

python 2.3.x bsddb module documentation should be updated to

say that multithreaded access is not supported and will

cause problems, possibly even python interpreter crashes.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-29 01:57

Message:
Logged In: YES 
user_id=413

Deadlocks only occurring under DOS-based "windows"

(win95/98/me) aren't something the python module can

prevent.  I suggest submitting the sample code and info from

studly_hammer.py to sleepycat.  They're usually very

responsive to questions of that nature.



btw, i'll give things a go on solaris later this week.  if

the test suite never completes i again suspect it is a

berkeleydb library issue on that platform rather than python

module.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 20:38

Message:
Logged In: YES 
user_id=31435

Running the original hammer.py under current CVS Python 

freezes in the same way (as in my immediately preceding 

note) now too; again Win98SE.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-28 20:28

Message:
Logged In: YES 
user_id=31435

About studly_hammer.py:



[Skip Montanaro]

> ...

> Attached is a modified version of the hammer.py script 

which seems to

> not fail for me on either Windows run from IDLE (Python 

2.3, BDB

> 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1).  The original 

script

> failed for me on Windows but not Mac OS X.  Can some 

other people for

> whom the original script fails please try it?  (I also attached 

it to

> bug #775414.) 



On Win98SE with current Python 2.3.1, it doesn't fail, but it 

never seemed to finish for me either.  Staring at WinTop 

showed that the Python process stopped accumulating 

cycles.  Can't be killed with Ctrl+C (no visible effect).  Can be 

killed with Ctrl+Break.



Dumping



        print "%s %s" % (thread.get_ident(), i)



at the top of the hammer loop showed that the threads get 

through several hundred iterations, then all printing stops.



Attaching to a debug-build Python from the debugger when a 

freeze occurs isn't terribly illuminating.  One thread's stack 

shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __ham_get_meta + 120 bytes

_BSDDB_D! __ham_c_dup + 4201 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, 

__db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 

562 + 35 bytes



The main thread's stack shows



_BSDDB_D! __db_win32_mutex_lock + 134 bytes

_BSDDB_D! __lock_get + 2264 bytes

_BSDDB_D! __lock_get + 197 bytes

_BSDDB_D! __db_lget + 365 bytes

_BSDDB_D! __ham_lock_bucket + 105 bytes

_BSDDB_D! __ham_get_cpage + 195 bytes

_BSDDB_D! __ham_item_next + 25 bytes

_BSDDB_D! __ham_call_hash + 2479 bytes

_BSDDB_D! __ham_c_dup + 4307 bytes

_BSDDB_D! __db_c_put + 2544 bytes

_BSDDB_D! __db_put + 507 bytes

_DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, 

__db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 

562 + 35 bytes

DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, 

_object * 0x00b83370) line 2330 + 23 bytes

PyObject_SetItem(_object * 0x008fe2e8, _object * 

0x00b83178, _object * 0x00b83370) line 123 + 18 bytes

eval_frame(_frame * 0x00984948) line 1448 + 17 bytes

...



The other threads are somewhere in the OS kernel and don't 

have useful tracebacks.  This varies from run to run, but all 

threads with a useful stack are always stuck at the same 

place in __db_win32_mutex_lock.



All in all, looks like it's simply deadlocked.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-28 00:11

Message:
Logged In: YES 
user_id=29957

Could you check that it (and the test_bsddb3) works on

Solaris? There's a couple of solaris boxes on the SF compile

farm (cf.sf.net). I was unable to get test_bsddb3 to complete

at all on Solaris 2.6, 7 or 8, when using DB 4.1.25.



As far as 2.3.2, I really really don't think it's appropriate to

throw it in at this late point. Particularly given the 2.3.1 

screwups, I don't want to risk it.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-27 18:08

Message:
Logged In: YES 
user_id=413

I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database.  hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25.  (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters).



After others have tested this on other platforms with success I believe we can close this bug.  This patch would probably be good for python 2.3.2.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-27 13:10

Message:
Logged In: YES 
user_id=44345

If hammer.py fails for you, please try this slightly modified

version (studly_hammer.py).



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 17:28

Message:
Logged In: YES 
user_id=413

I don't see any problem in _bsddb.c:_DB_put(), what memory

are you talking about?  All of the DBT key and data

parameters are allocated on the local stack on the various

DB methods that call _DB_put.  What do you see that could be

clobbered?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:52

Message:
Logged In: YES 
user_id=44345

The sleepycat mails (there are two of them - Keith's is

second) are in the attached sleepy.txt file.





----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-09-12 14:25

Message:
Logged In: YES 
user_id=85414

Sorry to muddy the waters, but I'm 99% sure that this

is not a threading issue.  Today I had the same

DBRunRecoveryError for my Spambayes POP3 proxy

classifier database, which only ever gets accessed

from the main program thread.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:22

Message:
Logged In: YES 
user_id=31392

I don't want to sound like a broken record, but I will: Can

anyone comment on the lack of thread-safety in _DB_put()? 

It appears that there is nothing to prevent the memory used

by one call from being stomped on by another call in a

different thread.  This problem would exist even in an

application using the modern interface and specifying DB_THREAD.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 14:10

Message:
Logged In: YES 
user_id=413

Looking at bsddb/__init__.py (where the old bsddb compatibility 
interface is implemented) I don't see why the hammer.py attached 
below should cause a problem.  The database is opened with 
DB_THREAD using a private environment (no DBEnv passed to DB()). 
 
I definately see potential threading problems with the _DBWithCursor 
class defined there if any of the methods using a cursor are used (the 
cursor could be shared across threads; that's a no-no).  But in the 
context of hammer.py that doesn't happen so I wouldn't have expected 
a problem.  Unless perhaps creating the DB withou a DBEnv implies 
that the DB_THREAD flag won't work.  The DB_RECOVER flag is only 
useful for opening existing DBEnv's; we have none. 
 
I've got to pop offline for a bit now but i'll try a hammer.py modified to 
use direct DB calls (for easier playing around with and bug reporting to 
sleepycat if turns out to be a bug on their end) later tonight. 
 
PS  keiths response is in the sleepycat.txt attachment if you open the 
URL to this bug report on sourceforge. 
 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 14:07

Message:
Logged In: YES 
user_id=31435

Jeremy, Keith's response is in the sleepy.txt file attached to 

the bug report.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 14:03

Message:
Logged In: YES 
user_id=31392

I don't see Keith's response anywhere in this thread.  Can

you add it for the record?  The only call to db->put() that

I see is in _DB_put().  It does not look thread-safe to me.



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 14:00

Message:
Logged In: YES 
user_id=44345

    The bsddb module emulates the old bsddb module's 1.85-ish

    interface using modern DB/DBEnv objects underneath.  So his

    comments about that not being threadsafe don't apply here.



But the low-level open() call isn't made with a DBEnv argument

is it?  Nor is the DB_RECOVER flag set.  Would the compatibility

interface be able to do both things?



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:57

Message:
Logged In: YES 
user_id=44345

In theory, yes, we could special case the bsddb stuff.  However,

the code currently is run indirectly via the anydbm module.  It

will take a little effort on our part to do something special for 

bsddb.  It would be nice if other apps using the naive interface

were able to use multiple threads.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:45

Message:
Logged In: YES 
user_id=413

ah, Keith's response from sleepycat assumed that we were using the 
DB 1.85 compatibility interface.  We do not.  The bsddb module 
emulates the old bsddb module's 1.85-ish interface using modern 
DB/DBEnv objects underneath.  So his comments about that not being 
threadsafe don't apply here. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 13:37

Message:
Logged In: YES 
user_id=31392

Are the DB_mapping methods only used the old interface?  My

question is about those methods, which I assumed were used

by the old and new interfaces.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-09-12 13:30

Message:
Logged In: YES 
user_id=413

The old bsddb interface compatibility code could be modified to use a 
single DBEnv per process opened with the DB_SYSTEM_MEM flag.  Do 
we want to do this?  Shouldn't we encourage the use of the real 
pybsddb DB/DBEnv object interface for threads instead?  AFAIK the old 
bsddb module + libs were not thread safe. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-09-12 13:23

Message:
Logged In: YES 
user_id=44345

>From what I got back from Sleepycat on this, I'm pretty sure the 

old bsddb interface is not going to be thread safe.  Attached are 

two messages from Sleepycat.



Is there some way for the old interface to create a default

environment shared by all the bsddb.*open() calls and then set

the DB_RECOVER flag in the low-level open() call?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 12:14

Message:
Logged In: YES 
user_id=31392

How does the bsddb wrapper achieve thread safety?



I know very little about the wrapper or the underlying bsddb

libraries.  I found the following comment in the C API docs:



http://www.sleepycat.com/docs/ref/program/mt.html#2

> When using the non-cursor Berkeley DB calls to retrieve 

> key/data items (for example, DB->get), the memory to which

the 

> pointer stored into the Dbt refers is valid only until the

next call 

> using the DB handle returned by DB->open. This includes any 

> use of the returned DB handle, including by another thread 

> within the process.



This suggests that a call to a self->db->get() must process

its results (copy them into Python-owned memory) before any

other operation on the same db object can proceed.  Is that

right?



The bsddb wrapper releases the GIL before calling the

low-level DB API functions and the acquires it after the

call returns.  Is there some other lock that prevents

multiple simultaneous calls from stomping on each other?



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-09-12 11:46

Message:
Logged In: YES 
user_id=31392

I'm running this test with CVS Python (built on 9/11/03) on

RH Linux 9 with bsddb 4.1.25.  I see the same error although

it takes a relatively long time to provoke -- a minute or two.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-12 11:08

Message:
Logged In: YES 
user_id=31435

Greg, any luck?  We're starting to see the same error ("fatal 

region error detected") in some ZODB tests using bsddb3, and 

that's an infinitely more complicated setup than this little 

program.  Jeremy Hylton also sees "fatal region" errors on 

Linux, in the ZODB context.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2003-08-13 18:26

Message:
Logged In: YES 
user_id=413

i'll try and reproduce this.

----------------------------------------------------------------------

Comment By: Richie Hindle (richiehindle)
Date: 2003-07-22 03:50

Message:
Logged In: YES 
user_id=85414

Minor correction: I'm on Plain Old Win98, not SE.



For what it's worth, the script seems more often than not

to provoke an application error when there's background

load, and a DBRunRecoveryError when there isn't.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 14:09:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 14:09:44 2003
Subject: [Python-bugs-list] [ python-Bugs-814602 ]
	socket.gethostbyaddr('www.google.com')
Message-ID: <E1A42Se-0002ur-00@sc8-sf-web1.sourceforge.net>

Bugs item #814602, was opened at 2003-09-29 20: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=814602&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerd Schulz (spikeee)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.gethostbyaddr('www.google.com')

Initial Comment:
Results in error!





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814602&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 14:16:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 14:17:15 2003
Subject: [Python-bugs-list] [ python-Bugs-814606 ] 5454 - documentation
	wrong for ossaudiodev mixer device
Message-ID: <E1A42Z5-0003JQ-00@sc8-sf-web1.sourceforge.net>

Bugs item #814606, was opened at 2003-09-29 11: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=814606&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alfred Morgan (zectbumo)
Assigned to: Nobody/Anonymous (nobody)
Summary: 5454 - documentation wrong for ossaudiodev mixer device

Initial Comment:
http://www.python.org/doc/current/lib/mixer-device-objects.html



methods controls() in the mixer device object have

sample code that does not work.  It seems that every

reference in the document to the channels() method

should be controls().  Also stereocontrols() references

channels() and that should be controls() as well.







-alfred

python: 2.3







----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814606&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 14:22:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 14:22:29 2003
Subject: [Python-bugs-list] [ python-Bugs-814613 ] socketmodule.c fails
	build, INET_ADDRSTRLEN not defined
Message-ID: <E1A42f1-0003gY-00@sc8-sf-web1.sourceforge.net>

Bugs item #814613, was opened at 2003-09-29 11:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Randy Davis (randydavis1)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c fails build, INET_ADDRSTRLEN not defined

Initial Comment:
Modules/socketmodule.c fails to built on IRIX 6.3 gcc 

3.2.2 due to INET_ADDRSTRLEN not being defined.  

Adding an additional "#define INET_ADDRSTRLEN 16" 

outside of the #ifdef's fixes it (so the #ifdefs would 

seem to not be taking into account IRIX 6.3).



Here's the error:



building '_socket' extension

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -

shared -fno-strict-aliasing -I. -

I/usr2/admin/src/dev/python-2.3.1/./Include -

I/usr/local/include -I/usr2/admin/src/dev/python-

2.3.1/Include -I/usr2/admin/src/dev/python-2.3.1 -

c /usr2/admin/src/dev/pyth

on-2.3.1/Modules/socketmodule.c -o build/temp.irix-6.3-

2.3/socketmodule.o

/usr2/admin/src/dev/python-

2.3.1/Modules/socketmodule.c: In function 

`socket_gethostname':

/usr2/admin/src/dev/python-

2.3.1/Modules/socketmodule.c:2319: warning: implicit 

declaration of function `gethostname'

/usr2/admin/src/dev/python-

2.3.1/Modules/socketmodule.c: In function 

`socket_inet_ntop':

/usr2/admin/src/dev/python-

2.3.1/Modules/socketmodule.c:3016: 

`INET_ADDRSTRLEN' undeclared (first use in this 

function)

/usr2/admin/src/dev/python-

2.3.1/Modules/socketmodule.c:3016: (Each undeclared 

identifier is reported only once

/usr2/admin/src/dev/python-

2.3.1/Modules/socketmodule.c:3016: for each function it 

appears in.)

/usr2/admin/src/dev/python-

2.3.1/Modules/socketmodule.c:3016: warning: unused 

variable `ip'









----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 15:01:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 15:01:40 2003
Subject: [Python-bugs-list] [ python-Bugs-814654 ] 'import Tkinter' causes
	windows missing-DLL popup
Message-ID: <E1A43Gw-0002g9-00@sc8-sf-web2.sourceforge.net>

Bugs item #814654, was opened at 2003-09-29 12: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=814654&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cory Dodt (xant)
Assigned to: Martin v. L?wis (loewis)
Summary: 'import Tkinter' causes windows missing-DLL popup

Initial Comment:
Python.org's official windows installer makes

installing Tkinter optional; there is a component you

can uncheck during installation.  If this box is

unchecked, tk84.dll and friends are not installed but

Tkinter.py, _tkinter.pyd and a few others are installed.



This makes it difficult to write code that does:



.try:

.    import Tkinter

.except ImportError:

.    # fallback to textmode operation





When 'import Tkinter' executes on Windows, Windows

attempts to load tk84.dll, and the result is a popup

error saying

.    "The dynamic link library tk84.dll could not be

found in the specified path (...my system path...)"



I recommend that Tkinter.py and friends not be

installed when that box is unchecked, since they can't

do anything useful anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814654&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 15:53:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 15:54:02 2003
Subject: [Python-bugs-list] [ python-Feature Requests-516762 ] have a way to
	search backwards for re
Message-ID: <E1A445j-0000MI-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #516762, was opened at 2002-02-13 03:22
Message generated for change (Comment added) made by phr
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: paul rubin (phr)
Date: 2003-09-29 19:53

Message:
Logged In: YES 
user_id=72053

Another way to do this would be add a direction flag to the 

regexp itself, like re.R (for reverse) if R isn't already in use:



   group  = re.search(pat, str, start, end, re.R)



or something like that.



I continue to want this feature.  It's very handy for writing 

web scrapers, which I do fairly frequently.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-03-27 20: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 at sourceforge.net  Mon Sep 29 15:58:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 15:58:46 2003
Subject: [Python-bugs-list] [ python-Feature Requests-814689 ] sendmsg
	operation for unix sockets
Message-ID: <E1A44AN-0002hj-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #814689, was opened at 2003-09-29 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=355470&aid=814689&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: sendmsg operation for unix sockets

Initial Comment:
The socket module doesn't seem to support the sendmsg 

operation for AF_UNIX sockets, at least in Python 2.2.2 

under Linux.  This is needed to send ancillary messages 

to sockets.  Those in turn allow a process to see the 

user id of its peer, allows sending file descriptors to 

other processes (needed for anything like User Mode 

Linux so that non-root processes can open privileged 

ports), and so forth.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=814689&group_id=5470

From noreply at sourceforge.net  Mon Sep 29 16:55:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Sep 29 16:55:14 2003
Subject: [Python-bugs-list] [ python-Bugs-814726 ] RedHat 9 blows up at
	dlclose of pyexpat.so
Message-ID: <E1A4530-0005jW-00@sc8-sf-web3.sourceforge.net>

Bugs item #814726, was opened at 2003-09-29 16:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: benson margulies (benson_basis)
Assigned to: Nobody/Anonymous (nobody)
Summary: RedHat 9 blows up at dlclose of pyexpat.so

Initial Comment:
With python 2.3, built with GCC 3.2.



With RedHat 9.0 ... glibc-2.3.2-27.9



With python linked into the application as a shared 

library...



a SIGSEGV at exit. Perhaps the modules should be 

marked -z nodelete to duck this latest incarnation of an 

old familiar glibc bug?



atexit:



(gdb) where

#0  0x42073771 in free () from /lib/tls/libc.so.6

#1  0x420ebd8e in __unregister_atfork () 

from /lib/tls/libc.so.6

#2  0x42029fb8 in __cxa_finalize () 

from /lib/tls/libc.so.6

#3  0x41fd19fc in __do_global_dtors_aux () 

from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so

#4  0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72-

gcc-3.2/python/pyexpat.so

#5  0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2

#6  0x42029d40 in exit () from /lib/tls/libc.so.6

#7  0x42015708 in __libc_start_main () 

from /lib/tls/libc.so.6



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 02:33:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 02:33:13 2003
Subject: [Python-bugs-list] [ python-Bugs-796219 ] ntpath.expanduser() is
	still wrong
Message-ID: <E1A4E4K-0002i6-00@sc8-sf-web3.sourceforge.net>

Bugs item #796219, was opened at 2003-08-27 13:11
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Tim Peters (tim_one)
Summary: ntpath.expanduser() is still wrong

Initial Comment:
I found a system with the following setup:



- os.getenv("HOME") returns "%USERPROFILE%"

- os.getenv("USERPROFILE") returns the home directory



Currently, ntpath.py doesn't expand ~ correctly in this

case.

The fix is pretty simple, I'll try to submit it if I

have time.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-09-29 23:33

Message:
Logged In: YES 
user_id=341410

I just noticed that I've got some forward slashes in various

paths on my windows machines...here's some updated code:



    def expandfull(var, rem=3):

        if not rem:

            return os.path.expandvars(var)

        a = os.path.expandvars(var)

        b = []

        d = [b.extend(i.split('\')) for i in a.split('/')]

        c = []

        for i in b:

            if '%' in i:

                c.append(expandfull(i), rem-1)

            else:

                c.append(i)

        return '\'.join(c)



----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-30 02:55

Message:
Logged In: YES 
user_id=539787

I stand corrected; multiple backslashes inside a path are not 

merged into one on Windows.  Thank you.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 11:48

Message:
Logged In: YES 
user_id=341410

Sourceforge ate my double-backslashes.

All '\' should be '\\'.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 11:20

Message:
Logged In: YES 
user_id=341410

The code you offered won't work correctly for all

environment variable returns.  An example that would kill

your code:

%SYSTEMROOT%\System32



def expandfull(var, rem=3):

    if not rem:

        return expandvars(var)

    a = expandvars(var)

    b = a.split('\')

    c = []

    for i in b:

        if '%' in i:

            c.append(expandfull(i), rem-1)

        else:

            c.append(i)

    return '\'.join(c)



The above would work properly for all environment variables.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-29 01:38

Message:
Logged In: YES 
user_id=539787

If expandvars worked for nt variable syntax too, then just 

before the expanduser final return, the following code would 

suffice, right?



max_recursion = 3

while '%' in userhome and max_recursion > 0:

    userhome = expandvars(userhome)

    max_recursion -= 1



ignoring the fact that path[1:] could contain variables too.



Shouldn't expandvars be made to work with %var% format 

too?  If yes, I'll offer code.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2003-08-28 00:47

Message:
Logged In: YES 
user_id=92222

This is very common setting on Windows2000 Professional.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 04:48:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 04:48:34 2003
Subject: [Python-bugs-list] [ python-Bugs-811160 ] HP/UX vs configure
Message-ID: <E1A4GB9-0001uy-00@sc8-sf-web2.sourceforge.net>

Bugs item #811160, was opened at 2003-09-23 23:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: HP/UX vs configure

Initial Comment:
configure is busted when building with HP's compiler.

"cc -Ac" is ancient and broken, "cc -Aa" is too anal to

compile it's own system headers, and "cc -Ae" breaks

autoconf.

The problem is the same one as outlined here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100

but in our case, it hits a whole lot of functions.



(basically: AC_CHECK_FUNCS expands to code that ends up

#including limits.h, which ends up including

sys/time.h, which breaks all checks for the various

time related bits.)



The GCC people worked around it with their own version

of the appropriate magic.





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 18:48

Message:
Logged In: YES 
user_id=29957

Tested on HP/UX testdrive systems and it works. Yay! Closing.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-29 18:11

Message:
Logged In: YES 
user_id=29957

assigning to self to test.



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-27 17:40

Message:
Logged In: YES 
user_id=21627

The patch is fine; please apply.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 04:47

Message:
Logged In: YES 
user_id=29957

I'll also attach a patch for the (generated) configure

script, for those folks without autoconf on their systems.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:14

Message:
Logged In: YES 
user_id=29957

argh. sf tracker strikes again. this time for sure.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:13

Message:
Logged In: YES 
user_id=29957

There's three ways we can fix this:

1. Hand-edit configure after running autoconf (yuk)

2. Run a CVS version of autoconf (yuk)

3. Supply an aclocal.m4 in the same way that the gcc guys

used to fix the problem (a bit yuk).



The aclocal fix would only be needed until the next release

of autoconf is out. I've attached an aclocal.m4 that

includes the GCC fix. Trying it here shows that it generates

a "fixed" configure scipt - I've not yet logged onto the HP

testdrive boxes to confirm it absolutely works, but it looks

like the fixes I did by hand in order to get it to work.



MvL, your thoughts? You seem to be the local autoconf guru... 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-24 00:26

Message:
Logged In: YES 
user_id=29957

mwh points out that the snakefarm is having the same problem:

http://www.lysator.liu.se/xenofarm/python/files/792_10/python-testlog.txt

(we discovered and debugged this on one of the

DEC^WDigital^WCompaq^WHP "testdrive" boxes)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:58

Message:
Logged In: YES 
user_id=29957

Oh, and the problem also occurs if you use gcc instead of cc -Ae





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 23:56

Message:
Logged In: YES 
user_id=29957

the functions that fail (erroneously) are

HAVE_CLOCK HAVE_GETTIMEOFDAY HAVE_MKTIME HAVE_SELECT

HAVE_STRFTIME HAVE_STRPTIME HAVE_UTIMES





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 04:51:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 04:51:13 2003
Subject: [Python-bugs-list] [ python-Bugs-814976 ] test_types fails on HP/UX
	ia64
Message-ID: <E1A4GDu-00023u-00@sc8-sf-web2.sourceforge.net>

Bugs item #814976, was opened at 2003-09-30 18: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=814976&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_types fails on HP/UX ia64

Initial Comment:
6. Built-in types

6.1 Truth value testing

6.2 Boolean operations

6.3 Comparisons

6.4 Numeric types (mostly conversions)

6.4.1 32-bit integers

6.4.2 Long integers

6.4.3 Floating point numbers

6.5 Sequence types

6.5.1 Strings

6.5.2 Tuples

6.5.3 Lists

6.5.3a Additional list operations

Traceback (most recent call last):

  File

"/house/arbatpy/Python-2.3.2c1/Lib/test/test_types.py",

line 415, in ?

    else: raise TestFailed, 'list sort compare function

is not callable'

test.test_support.TestFailed: list sort compare

function is not callable



The test in question is definately failing:

>>> z=range(12)

>>> z.sort(2)

>>> 



(it should raise a TypeError).



Anyone? 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 04:53:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 04:53:31 2003
Subject: [Python-bugs-list] [ python-Bugs-814976 ] test_types fails on HP/UX
	ia64
Message-ID: <E1A4GG5-0002Bo-00@sc8-sf-web2.sourceforge.net>

Bugs item #814976, was opened at 2003-09-30 18:51
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_types fails on HP/UX ia64

Initial Comment:
6. Built-in types

6.1 Truth value testing

6.2 Boolean operations

6.3 Comparisons

6.4 Numeric types (mostly conversions)

6.4.1 32-bit integers

6.4.2 Long integers

6.4.3 Floating point numbers

6.5 Sequence types

6.5.1 Strings

6.5.2 Tuples

6.5.3 Lists

6.5.3a Additional list operations

Traceback (most recent call last):

  File

"/house/arbatpy/Python-2.3.2c1/Lib/test/test_types.py",

line 415, in ?

    else: raise TestFailed, 'list sort compare function

is not callable'

test.test_support.TestFailed: list sort compare

function is not callable



The test in question is definately failing:

>>> z=range(12)

>>> z.sort(2)

>>> 



(it should raise a TypeError).



Anyone? 



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 18:53

Message:
Logged In: YES 
user_id=29957

Python 2.3.2c1 (#2, Sep 30 2003, 04:35:11) [C] on hp-ux11

Type "help", "copyright", "credits" or "license" for more

information.

>>> import gc

>>> z=range(12)

>>> z.sort(2)

>>> gc.collect()

TypeError: 'int' object is not callable

>>> 



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 18:52

Message:
Logged In: YES 
user_id=29957

wow. I exited python after the above

z = range(12) 

z.sort(2)

and got

Exception exceptions.TypeError: "'int' object is not

callable" in 'garbage collection' ignored

Fatal Python error: unexpected exception during garbage

collection

ABORT instruction (core dumped)





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 04:52:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 04:57:28 2003
Subject: [Python-bugs-list] [ python-Bugs-814976 ] test_types fails on HP/UX
	ia64
Message-ID: <E1A4GEq-000277-00@sc8-sf-web2.sourceforge.net>

Bugs item #814976, was opened at 2003-09-30 18:51
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_types fails on HP/UX ia64

Initial Comment:
6. Built-in types

6.1 Truth value testing

6.2 Boolean operations

6.3 Comparisons

6.4 Numeric types (mostly conversions)

6.4.1 32-bit integers

6.4.2 Long integers

6.4.3 Floating point numbers

6.5 Sequence types

6.5.1 Strings

6.5.2 Tuples

6.5.3 Lists

6.5.3a Additional list operations

Traceback (most recent call last):

  File

"/house/arbatpy/Python-2.3.2c1/Lib/test/test_types.py",

line 415, in ?

    else: raise TestFailed, 'list sort compare function

is not callable'

test.test_support.TestFailed: list sort compare

function is not callable



The test in question is definately failing:

>>> z=range(12)

>>> z.sort(2)

>>> 



(it should raise a TypeError).



Anyone? 



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 18:52

Message:
Logged In: YES 
user_id=29957

wow. I exited python after the above

z = range(12) 

z.sort(2)

and got

Exception exceptions.TypeError: "'int' object is not

callable" in 'garbage collection' ignored

Fatal Python error: unexpected exception during garbage

collection

ABORT instruction (core dumped)





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 05:29:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 05:29:54 2003
Subject: [Python-bugs-list] [ python-Bugs-814988 ] Tools/scripts/md5sum.py
	should default to rb
Message-ID: <E1A4GpM-0002M4-00@sc8-sf-web3.sourceforge.net>

Bugs item #814988, was opened at 2003-09-30 19:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814988&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tools/scripts/md5sum.py should default to rb

Initial Comment:
Is there any sane reason why Tools/scripts/md5sum.py 

doesn't open files with 'rb' by default? Thomas and I just

spent a bit of time trying to figure out why MD5 checksums

just didn't match up at all - turned out he was using the

version in Tools/scripts/.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814988&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 05:33:28 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 05:33:33 2003
Subject: [Python-bugs-list] [ python-Bugs-814988 ] Tools/scripts/md5sum.py
	should default to rb
Message-ID: <E1A4Gsq-0002Vh-00@sc8-sf-web3.sourceforge.net>

Bugs item #814988, was opened at 2003-09-30 19:29
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814988&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tools/scripts/md5sum.py should default to rb

Initial Comment:
Is there any sane reason why Tools/scripts/md5sum.py 

doesn't open files with 'rb' by default? Thomas and I just

spent a bit of time trying to figure out why MD5 checksums

just didn't match up at all - turned out he was using the

version in Tools/scripts/.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 19:33

Message:
Logged In: YES 
user_id=29957

backported tim's fix for 2.3.2final.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814988&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 05:44:43 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 05:44:48 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A4H3j-00086D-00@sc8-sf-web1.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 21:10
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 19:44

Message:
Logged In: YES 
user_id=29957

Using the HP testdrive system

HP-UX spe169 B.11.11 U 9000/800 1939057856 unlimited-user

license



I did the following with 2.3.2c1:

>>> import ftplib

>>> f = ftplib.FTP()

>>> f.connect('localhost', 21)

'220 spe169.testdrive.hp.com FTP server (Version

1.1.214.4(PHNE_27765) Wed Sep  4 05:59:34 GMT 2002) ready.'

>>> 



Ah. In your example, you have 'hostname'. Is that

_literally_ what you typed? If so, it's looking for a

machine called 'hostname'. I tried that, and got the same

error you got. 



Try it without the single quotes around 'hostname'. 



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:50

Message:
Logged In: YES 
user_id=29957

Hm. I'm obviously having reading difficulties. There's

obviously something else going on entirely. Damn. I will try

to grab some time on one of the HP test boxes to see if I

can figure what's going on...



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd

work for 2.3 and not 2.3.1, unless 2.3.1's script was

generated with a newer version of autoconf - aha. Yes, it was. 

If you could check if the fix in 

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

"makes it all better", that would be great. Put aclocal.m4

alongside configure &c, re-run autoconf, then ./configure ; make



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-27 03:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.



I don't think configure was broken with Python 2.3 - and it 

was with 2.3 that I first noticed the problem.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 05:53:35 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 05:53:38 2003
Subject: [Python-bugs-list] [ python-Bugs-814996 ] OSF/1 test_dbm segfaults
Message-ID: <E1A4HCJ-0000GX-00@sc8-sf-web1.sourceforge.net>

Bugs item #814996, was opened at 2003-09-30 19: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=814996&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: OSF/1 test_dbm segfaults

Initial Comment:
When running regrtest on OSF/1 5.1, I get a segfault in

test_dbm. Running test_dbm alone works. I'll try and

nail down the sequence that causes the crash.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814996&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 08:09:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 08:09:23 2003
Subject: [Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be
	isinf() on openbsd
Message-ID: <E1A4JJf-00035z-00@sc8-sf-web2.sourceforge.net>

Bugs item #815062, was opened at 2003-09-30 22: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=815062&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 08:21:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 08:21:14 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A4JV8-00079F-00@sc8-sf-web1.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 12:10
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 13:21

Message:
Logged In: YES 
user_id=200117

Apologies for not being clear.



I actually used the real hostname (in quotes) of a workstation 

on our local network in place of 'hostname'.



If I use 'localhost' or the hostname of the workstation the 

application is running on, I don't get the error.



If I use the hostname of any other workstation on the local 

network, I do get the error.



Running exactly the same code on Python 2.2.1 works OK for 

all hostnames.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 10:44

Message:
Logged In: YES 
user_id=29957

Using the HP testdrive system

HP-UX spe169 B.11.11 U 9000/800 1939057856 unlimited-user

license



I did the following with 2.3.2c1:

>>> import ftplib

>>> f = ftplib.FTP()

>>> f.connect('localhost', 21)

'220 spe169.testdrive.hp.com FTP server (Version

1.1.214.4(PHNE_27765) Wed Sep  4 05:59:34 GMT 2002) ready.'

>>> 



Ah. In your example, you have 'hostname'. Is that

_literally_ what you typed? If so, it's looking for a

machine called 'hostname'. I tried that, and got the same

error you got. 



Try it without the single quotes around 'hostname'. 



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:50

Message:
Logged In: YES 
user_id=29957

Hm. I'm obviously having reading difficulties. There's

obviously something else going on entirely. Damn. I will try

to grab some time on one of the HP test boxes to see if I

can figure what's going on...



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd

work for 2.3 and not 2.3.1, unless 2.3.1's script was

generated with a newer version of autoconf - aha. Yes, it was. 

If you could check if the fix in 

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

"makes it all better", that would be great. Put aclocal.m4

alongside configure &c, re-run autoconf, then ./configure ; make



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-26 18:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.



I don't think configure was broken with Python 2.3 - and it 

was with 2.3 that I first noticed the problem.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 08:23:56 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 08:24:01 2003
Subject: [Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be
	isinf() on openbsd
Message-ID: <E1A4JXo-0001BT-00@sc8-sf-web3.sourceforge.net>

Bugs item #815062, was opened at 2003-09-30 22:09
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 22:23

Message:
Logged In: YES 
user_id=29957

--- pyport.h    4 Sep 2003 11:59:50 -0000       2.63

+++ pyport.h    30 Sep 2003 12:22:14 -0000

@@ -258,7 +258,7 @@

  *    X is evaluated more than once.

  * Some platforms have better way to spell this, so expect

some #ifdef'ery.

  */

-#ifdef __FreeBSD__

+#if defined(__FreeBSD__) || defined(__OpenBSD__)

 #define Py_OVERFLOWED(X) isinf(X)

 #else



makes test_long and test_complex pass on OpenBSD.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 08:41:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 08:41:34 2003
Subject: [Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be
	isinf() on openbsd
Message-ID: <E1A4Jon-0008Tv-00@sc8-sf-web1.sourceforge.net>

Bugs item #815062, was opened at 2003-09-30 13:09
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-09-30 13:41

Message:
Logged In: YES 
user_id=6656

while setting Py_OVERFLOWED to use isinf does indeed make

the tests pass on openbad, i'd be happier if i understood

why the other definition *doesn't* work...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 13:23

Message:
Logged In: YES 
user_id=29957

--- pyport.h    4 Sep 2003 11:59:50 -0000       2.63

+++ pyport.h    30 Sep 2003 12:22:14 -0000

@@ -258,7 +258,7 @@

  *    X is evaluated more than once.

  * Some platforms have better way to spell this, so expect

some #ifdef'ery.

  */

-#ifdef __FreeBSD__

+#if defined(__FreeBSD__) || defined(__OpenBSD__)

 #define Py_OVERFLOWED(X) isinf(X)

 #else



makes test_long and test_complex pass on OpenBSD.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 08:49:41 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 08:49:46 2003
Subject: [Python-bugs-list] [ python-Bugs-815088 ] dev module index has a
	\UNIX in it
Message-ID: <E1A4Jwj-0002ds-00@sc8-sf-web3.sourceforge.net>

Bugs item #815088, was opened at 2003-09-30 22:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815088&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: dev module index has a \UNIX in it

Initial Comment:
The module index at

http://www.python.org/dev/doc/devel/modindex.html



says:



ossaudiodev (Linux, FreeBSD, possibly other \UNIX-like

systems) 



The \UNIX is probably not meant to be there. 



The same wart is at 

http://www.python.org/doc/2.3.2c1/modindex.html



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815088&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 09:01:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 09:01:21 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A4K7o-0003LC-00@sc8-sf-web3.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 21:10
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 23:01

Message:
Logged In: YES 
user_id=29957

Hm. What's the actual hostname you're trying? I can't get

this failure on HP/UX 11.11, using the HP testdrive box. 



Are you using NIS or some other non-standard method of

hostname lookup? The problem is that there's a fair bit

changed between 2.2 and 2.3's socket module (there was 71

different checkins).



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 22:21

Message:
Logged In: YES 
user_id=200117

Apologies for not being clear.



I actually used the real hostname (in quotes) of a workstation 

on our local network in place of 'hostname'.



If I use 'localhost' or the hostname of the workstation the 

application is running on, I don't get the error.



If I use the hostname of any other workstation on the local 

network, I do get the error.



Running exactly the same code on Python 2.2.1 works OK for 

all hostnames.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 19:44

Message:
Logged In: YES 
user_id=29957

Using the HP testdrive system

HP-UX spe169 B.11.11 U 9000/800 1939057856 unlimited-user

license



I did the following with 2.3.2c1:

>>> import ftplib

>>> f = ftplib.FTP()

>>> f.connect('localhost', 21)

'220 spe169.testdrive.hp.com FTP server (Version

1.1.214.4(PHNE_27765) Wed Sep  4 05:59:34 GMT 2002) ready.'

>>> 



Ah. In your example, you have 'hostname'. Is that

_literally_ what you typed? If so, it's looking for a

machine called 'hostname'. I tried that, and got the same

error you got. 



Try it without the single quotes around 'hostname'. 



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:50

Message:
Logged In: YES 
user_id=29957

Hm. I'm obviously having reading difficulties. There's

obviously something else going on entirely. Damn. I will try

to grab some time on one of the HP test boxes to see if I

can figure what's going on...



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd

work for 2.3 and not 2.3.1, unless 2.3.1's script was

generated with a newer version of autoconf - aha. Yes, it was. 

If you could check if the fix in 

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

"makes it all better", that would be great. Put aclocal.m4

alongside configure &c, re-run autoconf, then ./configure ; make



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-27 03:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.



I don't think configure was broken with Python 2.3 - and it 

was with 2.3 that I first noticed the problem.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 09:05:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 09:05:22 2003
Subject: [Python-bugs-list] [ python-Bugs-814290 ] int() weirdness (Python
	2.3.1, GCC 3.3.1)
Message-ID: <E1A4KBo-0003aA-00@sc8-sf-web3.sourceforge.net>

Bugs item #814290, was opened at 2003-09-29 17:08
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814290&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Church (achurch)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() weirdness (Python 2.3.1, GCC 3.3.1)

Initial Comment:
int() is behaving very strangely for me:

>>> int(42)

42

>>> int(42.5)

0

>>> int(429.777407345)

17126444324755L



What could cause this?  This is from a compile from

source using GCC 3.3.1; turning optimization on or off

does not seem to affect it (-O0, -O2, -O3 all tried).

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 23:05

Message:
Logged In: YES 
user_id=29957

Since it's a glibc bug, closing this bug.



----------------------------------------------------------------------

Comment By: Andrew Church (achurch)
Date: 2003-09-29 18:21

Message:
Logged In: YES 
user_id=527960

i386 (really Pentium 4), glibc 2.2.5.



I think I've located the problem: modf() from libm is

returning bogus values, so this looks like a glibc bug, not

a Python bug.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-29 18:09

Message:
Logged In: YES 
user_id=29957

Which platform is this on? Also if it's a linux machine,

which version of libc is it using?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814290&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 09:09:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 09:10:14 2003
Subject: [Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be
	isinf() on openbsd
Message-ID: <E1A4KG1-0001aI-00@sc8-sf-web1.sourceforge.net>

Bugs item #815062, was opened at 2003-09-30 13:09
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-09-30 14:09

Message:
Logged In: YES 
user_id=6656

it's compiler bogusness, it seems, unless the code in

PyLong_AsDouble is non-ansi in some way that currently

escapes the eye.  compiling -O2 or higher makes test_long

fail; -O or lower makes it pass.



gcc is 2.95.3 fwiw.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 13:41

Message:
Logged In: YES 
user_id=6656

while setting Py_OVERFLOWED to use isinf does indeed make

the tests pass on openbad, i'd be happier if i understood

why the other definition *doesn't* work...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 13:23

Message:
Logged In: YES 
user_id=29957

--- pyport.h    4 Sep 2003 11:59:50 -0000       2.63

+++ pyport.h    30 Sep 2003 12:22:14 -0000

@@ -258,7 +258,7 @@

  *    X is evaluated more than once.

  * Some platforms have better way to spell this, so expect

some #ifdef'ery.

  */

-#ifdef __FreeBSD__

+#if defined(__FreeBSD__) || defined(__OpenBSD__)

 #define Py_OVERFLOWED(X) isinf(X)

 #else



makes test_long and test_complex pass on OpenBSD.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 09:31:31 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 09:31:38 2003
Subject: [Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be
	isinf() on openbsd
Message-ID: <E1A4KbD-0002lP-00@sc8-sf-web1.sourceforge.net>

Bugs item #815062, was opened at 2003-09-30 08:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
>Assigned to: Michael Hudson (mwh)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-30 09:31

Message:
Logged In: YES 
user_id=31435

I can't like the #ifdef solution because C99 says HUGE_VAL is 

returned in overflow cases, not necessarily an infinity.  That's 

why the original macro checks against HUGE_VAL instead of 

using Py_IS_INFINITY(X) (btw, replacing *that* with isinf() 

when possible would be wholly unobjectionable).



Michael, the reason optimization level makes a difference is 

probably an optimization bug:  some platforms define 

HUGE_VAL as a God-awful casted mess, so complicated that 

their own compilers can't deal with it correctly.  So it's 

possible that #define'ing Py_HUGE_VAL to a saner expression 

on this platform would have solved the problem too; as the 

comments before Py_HUGE_VAL say, we use Py_HUGE_VAL 

instead of HUGE_VAL because some platforms screw up 

HUGE_VAL.



An experiment:  with the original definition of 

Py_OVERFLOWED, try #define'ing



#define Py_HUGE_VAL ((double)(HUGE_VAL))



on this box and see what happens.  The thinking is that if 

HUGE_VAL expands to a float expression on this box, 

optimization is most likely to screw up an implicit conversion 

to double; making that conversion explicit may worm around 

an optimization bug then.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 09:09

Message:
Logged In: YES 
user_id=6656

it's compiler bogusness, it seems, unless the code in

PyLong_AsDouble is non-ansi in some way that currently

escapes the eye.  compiling -O2 or higher makes test_long

fail; -O or lower makes it pass.



gcc is 2.95.3 fwiw.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 08:41

Message:
Logged In: YES 
user_id=6656

while setting Py_OVERFLOWED to use isinf does indeed make

the tests pass on openbad, i'd be happier if i understood

why the other definition *doesn't* work...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 08:23

Message:
Logged In: YES 
user_id=29957

--- pyport.h    4 Sep 2003 11:59:50 -0000       2.63

+++ pyport.h    30 Sep 2003 12:22:14 -0000

@@ -258,7 +258,7 @@

  *    X is evaluated more than once.

  * Some platforms have better way to spell this, so expect

some #ifdef'ery.

  */

-#ifdef __FreeBSD__

+#if defined(__FreeBSD__) || defined(__OpenBSD__)

 #define Py_OVERFLOWED(X) isinf(X)

 #else



makes test_long and test_complex pass on OpenBSD.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 09:39:41 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 09:39:47 2003
Subject: [Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be
	isinf() on openbsd
Message-ID: <E1A4Kj7-0003Gn-00@sc8-sf-web1.sourceforge.net>

Bugs item #815062, was opened at 2003-09-30 13:09
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Michael Hudson (mwh)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-09-30 14:39

Message:
Logged In: YES 
user_id=6656

*groan*



HUGE_VAL seems to be defined like so:



extern char __infinity[];

#define HUGE_VAL        (*(double *) __infinity)



adding what you suggest to pyport.h doesn't make any difference.



I can attach the -O and the -O2 assembler for the suspect

code if anyone's interested, but I'm no wizz at x86 assembly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-30 14:31

Message:
Logged In: YES 
user_id=31435

I can't like the #ifdef solution because C99 says HUGE_VAL is 

returned in overflow cases, not necessarily an infinity.  That's 

why the original macro checks against HUGE_VAL instead of 

using Py_IS_INFINITY(X) (btw, replacing *that* with isinf() 

when possible would be wholly unobjectionable).



Michael, the reason optimization level makes a difference is 

probably an optimization bug:  some platforms define 

HUGE_VAL as a God-awful casted mess, so complicated that 

their own compilers can't deal with it correctly.  So it's 

possible that #define'ing Py_HUGE_VAL to a saner expression 

on this platform would have solved the problem too; as the 

comments before Py_HUGE_VAL say, we use Py_HUGE_VAL 

instead of HUGE_VAL because some platforms screw up 

HUGE_VAL.



An experiment:  with the original definition of 

Py_OVERFLOWED, try #define'ing



#define Py_HUGE_VAL ((double)(HUGE_VAL))



on this box and see what happens.  The thinking is that if 

HUGE_VAL expands to a float expression on this box, 

optimization is most likely to screw up an implicit conversion 

to double; making that conversion explicit may worm around 

an optimization bug then.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 14:09

Message:
Logged In: YES 
user_id=6656

it's compiler bogusness, it seems, unless the code in

PyLong_AsDouble is non-ansi in some way that currently

escapes the eye.  compiling -O2 or higher makes test_long

fail; -O or lower makes it pass.



gcc is 2.95.3 fwiw.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 13:41

Message:
Logged In: YES 
user_id=6656

while setting Py_OVERFLOWED to use isinf does indeed make

the tests pass on openbad, i'd be happier if i understood

why the other definition *doesn't* work...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 13:23

Message:
Logged In: YES 
user_id=29957

--- pyport.h    4 Sep 2003 11:59:50 -0000       2.63

+++ pyport.h    30 Sep 2003 12:22:14 -0000

@@ -258,7 +258,7 @@

  *    X is evaluated more than once.

  * Some platforms have better way to spell this, so expect

some #ifdef'ery.

  */

-#ifdef __FreeBSD__

+#if defined(__FreeBSD__) || defined(__OpenBSD__)

 #define Py_OVERFLOWED(X) isinf(X)

 #else



makes test_long and test_complex pass on OpenBSD.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 09:56:30 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 09:56:37 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A4KzO-0004Jc-00@sc8-sf-web1.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 12:10
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 14:56

Message:
Logged In: YES 
user_id=200117

The hostnames I have tried are 'tate_mod' and 'rosalind'.

Lookup is by NIS. I can ping and remote login to these 

workstations using their hostnames.



I have since discovered that if I add an entry to /etc/hosts 

specifying a different hostname 'fred' and rosalind's IP 

address, then f.connect('fred', 21) doesn't give the error.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 14:01

Message:
Logged In: YES 
user_id=29957

Hm. What's the actual hostname you're trying? I can't get

this failure on HP/UX 11.11, using the HP testdrive box. 



Are you using NIS or some other non-standard method of

hostname lookup? The problem is that there's a fair bit

changed between 2.2 and 2.3's socket module (there was 71

different checkins).



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 13:21

Message:
Logged In: YES 
user_id=200117

Apologies for not being clear.



I actually used the real hostname (in quotes) of a workstation 

on our local network in place of 'hostname'.



If I use 'localhost' or the hostname of the workstation the 

application is running on, I don't get the error.



If I use the hostname of any other workstation on the local 

network, I do get the error.



Running exactly the same code on Python 2.2.1 works OK for 

all hostnames.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 10:44

Message:
Logged In: YES 
user_id=29957

Using the HP testdrive system

HP-UX spe169 B.11.11 U 9000/800 1939057856 unlimited-user

license



I did the following with 2.3.2c1:

>>> import ftplib

>>> f = ftplib.FTP()

>>> f.connect('localhost', 21)

'220 spe169.testdrive.hp.com FTP server (Version

1.1.214.4(PHNE_27765) Wed Sep  4 05:59:34 GMT 2002) ready.'

>>> 



Ah. In your example, you have 'hostname'. Is that

_literally_ what you typed? If so, it's looking for a

machine called 'hostname'. I tried that, and got the same

error you got. 



Try it without the single quotes around 'hostname'. 



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:50

Message:
Logged In: YES 
user_id=29957

Hm. I'm obviously having reading difficulties. There's

obviously something else going on entirely. Damn. I will try

to grab some time on one of the HP test boxes to see if I

can figure what's going on...



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd

work for 2.3 and not 2.3.1, unless 2.3.1's script was

generated with a newer version of autoconf - aha. Yes, it was. 

If you could check if the fix in 

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

"makes it all better", that would be great. Put aclocal.m4

alongside configure &c, re-run autoconf, then ./configure ; make



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-26 18:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.



I don't think configure was broken with Python 2.3 - and it 

was with 2.3 that I first noticed the problem.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 10:00:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 10:00:20 2003
Subject: [Python-bugs-list] [ python-Bugs-796219 ] ntpath.expanduser() is
	still wrong
Message-ID: <E1A4L30-0006a1-00@sc8-sf-web3.sourceforge.net>

Bugs item #796219, was opened at 2003-08-27 16: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=796219&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: ntpath.expanduser() is still wrong

Initial Comment:
I found a system with the following setup:



- os.getenv("HOME") returns "%USERPROFILE%"

- os.getenv("USERPROFILE") returns the home directory



Currently, ntpath.py doesn't expand ~ correctly in this

case.

The fix is pretty simple, I'll try to submit it if I

have time.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-30 10:00

Message:
Logged In: YES 
user_id=31435

Assigned back to Guido.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-09-30 02:33

Message:
Logged In: YES 
user_id=341410

I just noticed that I've got some forward slashes in various

paths on my windows machines...here's some updated code:



    def expandfull(var, rem=3):

        if not rem:

            return os.path.expandvars(var)

        a = os.path.expandvars(var)

        b = []

        d = [b.extend(i.split('\')) for i in a.split('/')]

        c = []

        for i in b:

            if '%' in i:

                c.append(expandfull(i), rem-1)

            else:

                c.append(i)

        return '\'.join(c)



----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-30 05:55

Message:
Logged In: YES 
user_id=539787

I stand corrected; multiple backslashes inside a path are not 

merged into one on Windows.  Thank you.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 14:48

Message:
Logged In: YES 
user_id=341410

Sourceforge ate my double-backslashes.

All '\' should be '\\'.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 14:20

Message:
Logged In: YES 
user_id=341410

The code you offered won't work correctly for all

environment variable returns.  An example that would kill

your code:

%SYSTEMROOT%\System32



def expandfull(var, rem=3):

    if not rem:

        return expandvars(var)

    a = expandvars(var)

    b = a.split('\')

    c = []

    for i in b:

        if '%' in i:

            c.append(expandfull(i), rem-1)

        else:

            c.append(i)

    return '\'.join(c)



The above would work properly for all environment variables.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-29 04:38

Message:
Logged In: YES 
user_id=539787

If expandvars worked for nt variable syntax too, then just 

before the expanduser final return, the following code would 

suffice, right?



max_recursion = 3

while '%' in userhome and max_recursion > 0:

    userhome = expandvars(userhome)

    max_recursion -= 1



ignoring the fact that path[1:] could contain variables too.



Shouldn't expandvars be made to work with %var% format 

too?  If yes, I'll offer code.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2003-08-28 03:47

Message:
Logged In: YES 
user_id=92222

This is very common setting on Windows2000 Professional.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 10:24:17 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 10:24:23 2003
Subject: [Python-bugs-list] [ python-Bugs-811028 ] configure: curses busted
	on Freebsd/Mac OSX
Message-ID: <E1A4LQH-0002xo-00@sc8-sf-web2.sourceforge.net>

Bugs item #811028, was opened at 2003-09-23 17:50
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
>Summary: configure: curses busted on Freebsd/Mac OSX

Initial Comment:
Anthony said to log this:



checking ncurses.h presence... yes

configure: WARNING: ncurses.h: present but cannot be 

compiled

configure: WARNING: ncurses.h: check for missing 

prerequisite headers?

configure: WARNING: ncurses.h: proceeding with the 

preprocessor's result

configure: WARNING:     ## 

------------------------------------ ##

configure: WARNING:     ## Report this to bug-

autoconf@gnu.org. ##

configure: WARNING:     ## 

------------------------------------ ##



I'll attach the text of the report and the configure output 

too since I'm pretty sure the above won't be ligible once 

sf's tracker's finished with it.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-01 00:24

Message:
Logged In: YES 
user_id=29957

Looking into it a bit on FreeBSD:

/usr/include/ncurses.h:236: conflicting types for `wchar_t'

/usr/include/stdlib.h:58: previous declaration of `wchar_t'



and poking around a bit I find that stdlib.h defines wchar_t

as an 'int', while ncurses.h defines it as 'unsigned long'. 



This is on FreeBSD 4.8. 



Extracting the failing configure code and making it not

define _XOPEN_EXTENDED_SOURCE makes the test succeed, but I

have no idea if this is an appropriate fix.



----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2003-09-27 18:36

Message:
Logged In: YES 
user_id=6405

(I didn't mention it in the report, only to Anthony : this is on 

OSX)



The patch doesn't alter the configure behaviour.



I can't remember how to run the curses test - "make test" skips 

it (the curses module is built though).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-27 17:53

Message:
Logged In: YES 
user_id=21627

Can you try the patch in python.org/sf/806800 ?

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2003-09-23 18:28

Message:
Logged In: YES 
user_id=6405

"make test" also reports:



test_curses

test test_curses crashed -- _curses.error: curs_set() returned 

ERR



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 18:14

Message:
Logged In: YES 
user_id=29957

creosote (which is a freebsd machine) also sees this.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 10:31:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 10:31:24 2003
Subject: [Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be
	isinf() on openbsd
Message-ID: <E1A4LX2-0008Ln-00@sc8-sf-web3.sourceforge.net>

Bugs item #815062, was opened at 2003-09-30 22:09
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Michael Hudson (mwh)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-01 00:31

Message:
Logged In: YES 
user_id=29957

Making OpenBSD use isinf() makes the compiler not screw it

up, so I'm strongly inclined toward that change for 2.3.2.

Tim, is this ok with you?



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 23:39

Message:
Logged In: YES 
user_id=6656

*groan*



HUGE_VAL seems to be defined like so:



extern char __infinity[];

#define HUGE_VAL        (*(double *) __infinity)



adding what you suggest to pyport.h doesn't make any difference.



I can attach the -O and the -O2 assembler for the suspect

code if anyone's interested, but I'm no wizz at x86 assembly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-30 23:31

Message:
Logged In: YES 
user_id=31435

I can't like the #ifdef solution because C99 says HUGE_VAL is 

returned in overflow cases, not necessarily an infinity.  That's 

why the original macro checks against HUGE_VAL instead of 

using Py_IS_INFINITY(X) (btw, replacing *that* with isinf() 

when possible would be wholly unobjectionable).



Michael, the reason optimization level makes a difference is 

probably an optimization bug:  some platforms define 

HUGE_VAL as a God-awful casted mess, so complicated that 

their own compilers can't deal with it correctly.  So it's 

possible that #define'ing Py_HUGE_VAL to a saner expression 

on this platform would have solved the problem too; as the 

comments before Py_HUGE_VAL say, we use Py_HUGE_VAL 

instead of HUGE_VAL because some platforms screw up 

HUGE_VAL.



An experiment:  with the original definition of 

Py_OVERFLOWED, try #define'ing



#define Py_HUGE_VAL ((double)(HUGE_VAL))



on this box and see what happens.  The thinking is that if 

HUGE_VAL expands to a float expression on this box, 

optimization is most likely to screw up an implicit conversion 

to double; making that conversion explicit may worm around 

an optimization bug then.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 23:09

Message:
Logged In: YES 
user_id=6656

it's compiler bogusness, it seems, unless the code in

PyLong_AsDouble is non-ansi in some way that currently

escapes the eye.  compiling -O2 or higher makes test_long

fail; -O or lower makes it pass.



gcc is 2.95.3 fwiw.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 22:41

Message:
Logged In: YES 
user_id=6656

while setting Py_OVERFLOWED to use isinf does indeed make

the tests pass on openbad, i'd be happier if i understood

why the other definition *doesn't* work...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 22:23

Message:
Logged In: YES 
user_id=29957

--- pyport.h    4 Sep 2003 11:59:50 -0000       2.63

+++ pyport.h    30 Sep 2003 12:22:14 -0000

@@ -258,7 +258,7 @@

  *    X is evaluated more than once.

  * Some platforms have better way to spell this, so expect

some #ifdef'ery.

  */

-#ifdef __FreeBSD__

+#if defined(__FreeBSD__) || defined(__OpenBSD__)

 #define Py_OVERFLOWED(X) isinf(X)

 #else



makes test_long and test_complex pass on OpenBSD.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 10:32:24 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 10:32:29 2003
Subject: [Python-bugs-list] [ python-Bugs-814996 ] OSF/1 test_dbm segfaults
Message-ID: <E1A4LY8-0008Qs-00@sc8-sf-web3.sourceforge.net>

Bugs item #814996, was opened at 2003-09-30 19:53
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814996&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: OSF/1 test_dbm segfaults

Initial Comment:
When running regrtest on OSF/1 5.1, I get a segfault in

test_dbm. Running test_dbm alone works. I'll try and

nail down the sequence that causes the crash.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-01 00:32

Message:
Logged In: YES 
user_id=29957

a short update: this appears to be something bogus with the

OSF/1  dynamic object support with -ldbm. Don't think it's

fixable in a sane way for 2.3.2



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814996&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 10:48:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 10:52:38 2003
Subject: [Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be
	isinf() on openbsd
Message-ID: <E1A4Lo7-000134-00@sc8-sf-web3.sourceforge.net>

Bugs item #815062, was opened at 2003-09-30 08:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-30 10:48

Message:
Logged In: YES 
user_id=31435

I would rather see it work than not work.  The problem is that 

a platform-specific #ifdef will never go away, even after the 

compiler optimization bug is fixed.  It will just sit there 

confusing future maintainers until the universe ends in heat 

death (we should only be so lucky <wink>).



So if it's put in, it needs a lot better commenting than the 

inaccurate



"""

* Some platforms have better way to spell this, so expect 

some #ifdef'ery.

"""



isinf() isn't a better way to spell HUGE_VAL, it's a non-

standard way to spell HUGE_VAL under a specific compiler 

with broken optimization.  All of that should be explained.  

Then at least a future maintainer might try, from time to time, 

to see whether the compiler in question has been fixed yet, 

so that the platform special-casing can be removed.



IOW, this is a pure hack to worm around a broken compiler, 

and should be documented as such.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 10:31

Message:
Logged In: YES 
user_id=29957

Making OpenBSD use isinf() makes the compiler not screw it

up, so I'm strongly inclined toward that change for 2.3.2.

Tim, is this ok with you?



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 09:39

Message:
Logged In: YES 
user_id=6656

*groan*



HUGE_VAL seems to be defined like so:



extern char __infinity[];

#define HUGE_VAL        (*(double *) __infinity)



adding what you suggest to pyport.h doesn't make any difference.



I can attach the -O and the -O2 assembler for the suspect

code if anyone's interested, but I'm no wizz at x86 assembly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-30 09:31

Message:
Logged In: YES 
user_id=31435

I can't like the #ifdef solution because C99 says HUGE_VAL is 

returned in overflow cases, not necessarily an infinity.  That's 

why the original macro checks against HUGE_VAL instead of 

using Py_IS_INFINITY(X) (btw, replacing *that* with isinf() 

when possible would be wholly unobjectionable).



Michael, the reason optimization level makes a difference is 

probably an optimization bug:  some platforms define 

HUGE_VAL as a God-awful casted mess, so complicated that 

their own compilers can't deal with it correctly.  So it's 

possible that #define'ing Py_HUGE_VAL to a saner expression 

on this platform would have solved the problem too; as the 

comments before Py_HUGE_VAL say, we use Py_HUGE_VAL 

instead of HUGE_VAL because some platforms screw up 

HUGE_VAL.



An experiment:  with the original definition of 

Py_OVERFLOWED, try #define'ing



#define Py_HUGE_VAL ((double)(HUGE_VAL))



on this box and see what happens.  The thinking is that if 

HUGE_VAL expands to a float expression on this box, 

optimization is most likely to screw up an implicit conversion 

to double; making that conversion explicit may worm around 

an optimization bug then.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 09:09

Message:
Logged In: YES 
user_id=6656

it's compiler bogusness, it seems, unless the code in

PyLong_AsDouble is non-ansi in some way that currently

escapes the eye.  compiling -O2 or higher makes test_long

fail; -O or lower makes it pass.



gcc is 2.95.3 fwiw.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 08:41

Message:
Logged In: YES 
user_id=6656

while setting Py_OVERFLOWED to use isinf does indeed make

the tests pass on openbad, i'd be happier if i understood

why the other definition *doesn't* work...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 08:23

Message:
Logged In: YES 
user_id=29957

--- pyport.h    4 Sep 2003 11:59:50 -0000       2.63

+++ pyport.h    30 Sep 2003 12:22:14 -0000

@@ -258,7 +258,7 @@

  *    X is evaluated more than once.

  * Some platforms have better way to spell this, so expect

some #ifdef'ery.

  */

-#ifdef __FreeBSD__

+#if defined(__FreeBSD__) || defined(__OpenBSD__)

 #define Py_OVERFLOWED(X) isinf(X)

 #else



makes test_long and test_complex pass on OpenBSD.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 10:48:53 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 10:58:39 2003
Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on
	HP-UX11i
Message-ID: <E1A4Lo5-0007JF-00@sc8-sf-web1.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 21:10
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).



import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)



this raises:



socket.gaierror: (8, 'host nor service provided, or not 

known')



In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.



The same code works OK on Python 2.2.1



If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3





----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-01 00:48

Message:
Logged In: YES 
user_id=29957

Darn. There's probably something Not Quite Right with how

socketmodule.c interacts with HP/UX's NIS, then. I'm not

sure what the problem would be, and I don't have access to a

HP/UX box that uses NIS for hostnames, so I'm not able to

help... 



As previously mentioned, there's a _lot_ of changes been

made to socketmodule.c between 2.2 and 2.3. If you're

CVS-savvy, you might like to try checking out different

versions between 2.200 (the version in 2.2) and 2.270 (the

version in 2.3) to narrow down exactly when the module stops

working.



One thing - "_" isn't supposed to be legal in domain names,

I don't know if that's related (although the other name has

no underscores...)



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 23:56

Message:
Logged In: YES 
user_id=200117

The hostnames I have tried are 'tate_mod' and 'rosalind'.

Lookup is by NIS. I can ping and remote login to these 

workstations using their hostnames.



I have since discovered that if I add an entry to /etc/hosts 

specifying a different hostname 'fred' and rosalind's IP 

address, then f.connect('fred', 21) doesn't give the error.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 23:01

Message:
Logged In: YES 
user_id=29957

Hm. What's the actual hostname you're trying? I can't get

this failure on HP/UX 11.11, using the HP testdrive box. 



Are you using NIS or some other non-standard method of

hostname lookup? The problem is that there's a fair bit

changed between 2.2 and 2.3's socket module (there was 71

different checkins).



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 22:21

Message:
Logged In: YES 
user_id=200117

Apologies for not being clear.



I actually used the real hostname (in quotes) of a workstation 

on our local network in place of 'hostname'.



If I use 'localhost' or the hostname of the workstation the 

application is running on, I don't get the error.



If I use the hostname of any other workstation on the local 

network, I do get the error.



Running exactly the same code on Python 2.2.1 works OK for 

all hostnames.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 19:44

Message:
Logged In: YES 
user_id=29957

Using the HP testdrive system

HP-UX spe169 B.11.11 U 9000/800 1939057856 unlimited-user

license



I did the following with 2.3.2c1:

>>> import ftplib

>>> f = ftplib.FTP()

>>> f.connect('localhost', 21)

'220 spe169.testdrive.hp.com FTP server (Version

1.1.214.4(PHNE_27765) Wed Sep  4 05:59:34 GMT 2002) ready.'

>>> 



Ah. In your example, you have 'hostname'. Is that

_literally_ what you typed? If so, it's looking for a

machine called 'hostname'. I tried that, and got the same

error you got. 



Try it without the single quotes around 'hostname'. 



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:50

Message:
Logged In: YES 
user_id=29957

Hm. I'm obviously having reading difficulties. There's

obviously something else going on entirely. Damn. I will try

to grab some time on one of the HP test boxes to see if I

can figure what's going on...



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd

work for 2.3 and not 2.3.1, unless 2.3.1's script was

generated with a newer version of autoconf - aha. Yes, it was. 

If you could check if the fix in 

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

"makes it all better", that would be great. Put aclocal.m4

alongside configure &c, re-run autoconf, then ./configure ; make



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-27 03:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.



I don't think configure was broken with Python 2.3 - and it 

was with 2.3 that I first noticed the problem.





----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-27 03:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 11:05:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 11:06:00 2003
Subject: [Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be
	isinf() on openbsd
Message-ID: <E1A4M4V-0008N3-00@sc8-sf-web1.sourceforge.net>

Bugs item #815062, was opened at 2003-09-30 22:09
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-01 01:05

Message:
Logged In: YES 
user_id=29957

Have checked in the workaround. Tim, you might want to pad

out the FreeBSD note in the comment a bit, it was your

checkin that put it there in the first place ;)



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-10-01 00:48

Message:
Logged In: YES 
user_id=31435

I would rather see it work than not work.  The problem is that 

a platform-specific #ifdef will never go away, even after the 

compiler optimization bug is fixed.  It will just sit there 

confusing future maintainers until the universe ends in heat 

death (we should only be so lucky <wink>).



So if it's put in, it needs a lot better commenting than the 

inaccurate



"""

* Some platforms have better way to spell this, so expect 

some #ifdef'ery.

"""



isinf() isn't a better way to spell HUGE_VAL, it's a non-

standard way to spell HUGE_VAL under a specific compiler 

with broken optimization.  All of that should be explained.  

Then at least a future maintainer might try, from time to time, 

to see whether the compiler in question has been fixed yet, 

so that the platform special-casing can be removed.



IOW, this is a pure hack to worm around a broken compiler, 

and should be documented as such.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-01 00:31

Message:
Logged In: YES 
user_id=29957

Making OpenBSD use isinf() makes the compiler not screw it

up, so I'm strongly inclined toward that change for 2.3.2.

Tim, is this ok with you?



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 23:39

Message:
Logged In: YES 
user_id=6656

*groan*



HUGE_VAL seems to be defined like so:



extern char __infinity[];

#define HUGE_VAL        (*(double *) __infinity)



adding what you suggest to pyport.h doesn't make any difference.



I can attach the -O and the -O2 assembler for the suspect

code if anyone's interested, but I'm no wizz at x86 assembly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-30 23:31

Message:
Logged In: YES 
user_id=31435

I can't like the #ifdef solution because C99 says HUGE_VAL is 

returned in overflow cases, not necessarily an infinity.  That's 

why the original macro checks against HUGE_VAL instead of 

using Py_IS_INFINITY(X) (btw, replacing *that* with isinf() 

when possible would be wholly unobjectionable).



Michael, the reason optimization level makes a difference is 

probably an optimization bug:  some platforms define 

HUGE_VAL as a God-awful casted mess, so complicated that 

their own compilers can't deal with it correctly.  So it's 

possible that #define'ing Py_HUGE_VAL to a saner expression 

on this platform would have solved the problem too; as the 

comments before Py_HUGE_VAL say, we use Py_HUGE_VAL 

instead of HUGE_VAL because some platforms screw up 

HUGE_VAL.



An experiment:  with the original definition of 

Py_OVERFLOWED, try #define'ing



#define Py_HUGE_VAL ((double)(HUGE_VAL))



on this box and see what happens.  The thinking is that if 

HUGE_VAL expands to a float expression on this box, 

optimization is most likely to screw up an implicit conversion 

to double; making that conversion explicit may worm around 

an optimization bug then.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 23:09

Message:
Logged In: YES 
user_id=6656

it's compiler bogusness, it seems, unless the code in

PyLong_AsDouble is non-ansi in some way that currently

escapes the eye.  compiling -O2 or higher makes test_long

fail; -O or lower makes it pass.



gcc is 2.95.3 fwiw.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 22:41

Message:
Logged In: YES 
user_id=6656

while setting Py_OVERFLOWED to use isinf does indeed make

the tests pass on openbad, i'd be happier if i understood

why the other definition *doesn't* work...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 22:23

Message:
Logged In: YES 
user_id=29957

--- pyport.h    4 Sep 2003 11:59:50 -0000       2.63

+++ pyport.h    30 Sep 2003 12:22:14 -0000

@@ -258,7 +258,7 @@

  *    X is evaluated more than once.

  * Some platforms have better way to spell this, so expect

some #ifdef'ery.

  */

-#ifdef __FreeBSD__

+#if defined(__FreeBSD__) || defined(__OpenBSD__)

 #define Py_OVERFLOWED(X) isinf(X)

 #else



makes test_long and test_complex pass on OpenBSD.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 16:02:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 16:03:05 2003
Subject: [Python-bugs-list] [ python-Bugs-815088 ] dev module index has a
	\UNIX in it
Message-ID: <E1A4Qi3-0001BO-00@sc8-sf-web1.sourceforge.net>

Bugs item #815088, was opened at 2003-09-30 08:49
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815088&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: dev module index has a \UNIX in it

Initial Comment:
The module index at

http://www.python.org/dev/doc/devel/modindex.html



says:



ossaudiodev (Linux, FreeBSD, possibly other \UNIX-like

systems) 



The \UNIX is probably not meant to be there. 



The same wart is at 

http://www.python.org/doc/2.3.2c1/modindex.html



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-30 16:02

Message:
Logged In: YES 
user_id=3066

There are some tool limitations (buglets?) involved here,

but I've worked around the problem for Python 2.3.2 and 2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815088&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 19:29:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 19:29:18 2003
Subject: [Python-bugs-list] [ python-Bugs-811028 ] configure: curses busted
	on Freebsd/Mac OSX
Message-ID: <E1A4Tva-0002BY-00@sc8-sf-web1.sourceforge.net>

Bugs item #811028, was opened at 2003-09-23 17:50
Message generated for change (Comment added) made by richard
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure: curses busted on Freebsd/Mac OSX

Initial Comment:
Anthony said to log this:



checking ncurses.h presence... yes

configure: WARNING: ncurses.h: present but cannot be 

compiled

configure: WARNING: ncurses.h: check for missing 

prerequisite headers?

configure: WARNING: ncurses.h: proceeding with the 

preprocessor's result

configure: WARNING:     ## 

------------------------------------ ##

configure: WARNING:     ## Report this to bug-

autoconf@gnu.org. ##

configure: WARNING:     ## 

------------------------------------ ##



I'll attach the text of the report and the configure output 

too since I'm pretty sure the above won't be ligible once 

sf's tracker's finished with it.



----------------------------------------------------------------------

>Comment By: Richard Jones (richard)
Date: 2003-10-01 09:29

Message:
Logged In: YES 
user_id=6405

The diagnosis on OS X is similar, and the trigger for defining wchar_t in 
stdlib.h is the absence of _ANSI_SOURCE. 
 
Making it not define _XOPEN_SOURCE_EXTENDED also fixes the compile 
as per your FreeBSD fix. 
 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-01 00:24

Message:
Logged In: YES 
user_id=29957

Looking into it a bit on FreeBSD:

/usr/include/ncurses.h:236: conflicting types for `wchar_t'

/usr/include/stdlib.h:58: previous declaration of `wchar_t'



and poking around a bit I find that stdlib.h defines wchar_t

as an 'int', while ncurses.h defines it as 'unsigned long'. 



This is on FreeBSD 4.8. 



Extracting the failing configure code and making it not

define _XOPEN_EXTENDED_SOURCE makes the test succeed, but I

have no idea if this is an appropriate fix.



----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2003-09-27 18:36

Message:
Logged In: YES 
user_id=6405

(I didn't mention it in the report, only to Anthony : this is on 

OSX)



The patch doesn't alter the configure behaviour.



I can't remember how to run the curses test - "make test" skips 

it (the curses module is built though).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-27 17:53

Message:
Logged In: YES 
user_id=21627

Can you try the patch in python.org/sf/806800 ?

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2003-09-23 18:28

Message:
Logged In: YES 
user_id=6405

"make test" also reports:



test_curses

test test_curses crashed -- _curses.error: curs_set() returned 

ERR



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 18:14

Message:
Logged In: YES 
user_id=29957

creosote (which is a freebsd machine) also sees this.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470

From noreply at sourceforge.net  Tue Sep 30 22:32:02 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Sep 30 22:32:05 2003
Subject: [Python-bugs-list] [ python-Bugs-815563 ] bug with ill-formed
	rfc822 attachments
Message-ID: <E1A4WmY-0000qs-00@sc8-sf-web1.sourceforge.net>

Bugs item #815563, was opened at 2003-09-30 22: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=815563&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart D. Gathman (customdesigned)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug with ill-formed rfc822 attachments

Initial Comment:
The following proglet gets an except with the attached

message:

-----te.py--------

import email

import sys



msg = email.message_from_file(sys.stdin)

sys.stdout.write(msg.as_string())

------------------

python2 te.py <failingmsg

Traceback (most recent call last):

  File "te.py", line 4, in ?

    msg = email.message_from_file(sys.stdin)

  File "/usr/lib/python2.2/email/__init__.py", line 63,

in message_from_file

    return Parser(_class, strict=strict).parse(fp)

  File "/usr/lib/python2.2/email/Parser.py", line 64,

in parse

    self._parsebody(root, fp, firstbodyline)

  File "/usr/lib/python2.2/email/Parser.py", line 239,

in _parsebody

    msgobj = self.parsestr(part)

  File "/usr/lib/python2.2/email/Parser.py", line 75,

in parsestr

    return self.parse(StringIO(text),

headersonly=headersonly)

  File "/usr/lib/python2.2/email/Parser.py", line 64,

in parse

    self._parsebody(root, fp, firstbodyline)

  File "/usr/lib/python2.2/email/Parser.py", line 264,

in _parsebody

    msg = self.parse(fp)

  File "/usr/lib/python2.2/email/Parser.py", line 64,

in parse

    self._parsebody(root, fp, firstbodyline)

  File "/usr/lib/python2.2/email/Parser.py", line 205,

in _parsebody

    raise Errors.BoundaryError(

email.Errors.BoundaryError: No terminating boundary and

no trailing empty line

-------------------

The message/rfc822 attachment really is missing the

boundary.  However, that is why it is being returned as

an attachment in the first place!  Is it illegal for

message/rfc822 attachments to have invalid MIME

construction?



I suggest that a message attachment that fails MIME

boundary decoding, should become a plain rfc822 object,

or perhaps a text object.  I don't know.  



Anyway, I get tons of messages with this property that

have to be processed by my Python milter.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815563&group_id=5470

From noreply at sourceforge.net  Sat Sep 20 11:32:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Nov  8 17:09:52 2003
Subject: [ python-Bugs-800710 ] build fails
Message-ID: <E1A0jiT-0006de-00@sc8-sf-web2.sourceforge.net>

Bugs item #800710, was opened at 2003-09-04 23:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470

Category: Installation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Adam Schran (aschran)
Assigned to: Martin v. L?wis (loewis)
Summary: build fails

Initial Comment:
dear python code samurais,



I ran ./configure and make on python 2.3, and got this 

failure on the make.  researched extensively before 

posting to you guys. =)



This problem only happens when installing Python 2.3.  

Python 2.2 installs flawlessly.



This is on a 2-year-old Linux box running slackware, with 

gcc version 2.7.2. 



I was able to get Python 2.3 to install on a newer 

machine with a different linux distrib with no problem. 



here are the results of the .configure and the make. 

Thanks for any help getting Python going on this 

machine! I'll try any suggestions. Adam



azure:~/Python-2.3$ ./configure

checking MACHDEP... linux2

checking EXTRAPLATDIR... 

checking for --without-gcc... no

checking for --with-cxx=<compiler>... no

checking for c++... c++

checking for C++ compiler default output... a.out

checking whether the C++ compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for gcc... gcc

checking for C compiler default output... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking how to run the C preprocessor... gcc -E

checking for AIX... no

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... no

checking for stdint.h... no

checking for unistd.h... yes

checking minix/config.h usability... no

checking minix/config.h presence... no

checking for minix/config.h... no

checking for --with-suffix... 

checking for case-insensitive build directory... no

checking LIBRARY... libpython$(VERSION).a

checking LINKCC... $(PURIFY) $(CC)

checking for --enable-shared... no

checking LDLIBRARY... libpython$(VERSION).a

checking for ranlib... ranlib

checking for ar... ar

checking for a BSD-compatible install... /usr/bin/ginstall -

c

checking for --with-pydebug... no

checking whether gcc accepts -fno-strict-aliasing... no

checking whether gcc accepts -OPT:Olimit=0... no

checking whether gcc accepts -Olimit 1500... no

checking whether pthreads are available without 

options... no

checking whether gcc accepts -Kpthread... no

checking whether gcc accepts -Kthread... no

checking whether gcc accepts -pthread... no

checking whether c++ also accepts flags for thread 

support... no

checking for ANSI C header files... (cached) yes

checking dlfcn.h usability... yes

checking dlfcn.h presence... yes

checking for dlfcn.h... yes

checking fcntl.h usability... yes

checking fcntl.h presence... yes

checking for fcntl.h... yes

checking grp.h usability... yes

checking grp.h presence... yes

checking for grp.h... yes

checking limits.h usability... yes

checking limits.h presence... yes

checking for limits.h... yes

checking langinfo.h usability... yes

checking langinfo.h presence... yes

checking for langinfo.h... yes

checking libintl.h usability... no

checking libintl.h presence... no

checking for libintl.h... no

checking locale.h usability... yes

checking locale.h presence... yes

checking for locale.h... yes

checking ncurses.h usability... no

checking ncurses.h presence... no

checking for ncurses.h... no

checking poll.h usability... no

checking poll.h presence... no

checking for poll.h... no

checking pthread.h usability... yes

checking pthread.h presence... yes

checking for pthread.h... yes

checking signal.h usability... yes

checking signal.h presence... yes

checking for signal.h... yes

checking stdarg.h usability... yes

checking stdarg.h presence... yes

checking for stdarg.h... yes

checking stddef.h usability... yes

checking stddef.h presence... yes

checking for stddef.h... yes

checking for stdlib.h... (cached) yes

checking stropts.h usability... no

checking stropts.h presence... no

checking for stropts.h... no

checking termios.h usability... yes

checking termios.h presence... yes

checking for termios.h... yes

checking thread.h usability... no

checking thread.h presence... no

checking for thread.h... no

checking for unistd.h... (cached) yes

checking utime.h usability... yes

checking utime.h presence... yes

checking for utime.h... yes

checking sys/audioio.h usability... no

checking sys/audioio.h presence... no

checking for sys/audioio.h... no

checking sys/bsdtty.h usability... no

checking sys/bsdtty.h presence... no

checking for sys/bsdtty.h... no

checking sys/file.h usability... yes

checking sys/file.h presence... yes

checking for sys/file.h... yes

checking sys/lock.h usability... no

checking sys/lock.h presence... no

checking for sys/lock.h... no

checking sys/mkdev.h usability... no

checking sys/mkdev.h presence... no

checking for sys/mkdev.h... no

checking sys/modem.h usability... no

checking sys/modem.h presence... no

checking for sys/modem.h... no

checking sys/param.h usability... yes

checking sys/param.h presence... yes

checking for sys/param.h... yes

checking sys/poll.h usability... no

checking sys/poll.h presence... no

checking for sys/poll.h... no

checking sys/select.h usability... no

checking sys/select.h presence... no

checking for sys/select.h... no

checking sys/socket.h usability... yes

checking sys/socket.h presence... yes

checking for sys/socket.h... yes

checking sys/time.h usability... yes

checking sys/time.h presence... yes

checking for sys/time.h... yes

checking sys/times.h usability... yes

checking sys/times.h presence... yes

checking for sys/times.h... yes

checking sys/un.h usability... no

checking sys/un.h presence... yes

configure: WARNING: sys/un.h: present but cannot be 

compiled

configure: WARNING: sys/un.h: check for missing 

prerequisite headers?

configure: WARNING: sys/un.h: proceeding with the 

preprocessor's result

checking for sys/un.h... yes

checking sys/utsname.h usability... yes

checking sys/utsname.h presence... yes

checking for sys/utsname.h... yes

checking sys/wait.h usability... yes

checking sys/wait.h presence... yes

checking for sys/wait.h... yes

checking pty.h usability... no

checking pty.h presence... no

checking for pty.h... no

checking term.h usability... yes

checking term.h presence... yes

checking for term.h... yes

checking libutil.h usability... no

checking libutil.h presence... no

checking for libutil.h... no

checking sys/resource.h usability... yes

checking sys/resource.h presence... yes

checking for sys/resource.h... yes

checking netpacket/packet.h usability... no

checking netpacket/packet.h presence... no

checking for netpacket/packet.h... no

checking sysexits.h usability... yes

checking sysexits.h presence... yes

checking for sysexits.h... yes

checking for dirent.h that defines DIR... yes

checking for library containing opendir... none required

checking whether sys/types.h defines makedev... no

checking for sys/mkdev.h... (cached) no

checking sys/sysmacros.h usability... yes

checking sys/sysmacros.h presence... yes

checking for sys/sysmacros.h... yes

checking for clock_t in time.h... yes

checking for makedev... no

checking Solaris LFS bug... no

checking for mode_t... yes

checking for off_t... yes

checking for pid_t... yes

checking return type of signal handlers... void

checking for size_t... yes

checking for uid_t in sys/types.h... yes

checking for int... yes

checking size of int... 4

checking for long... yes

checking size of long... 4

checking for void *... yes

checking size of void *... 4

checking for char... yes

checking size of char... 1

checking for short... yes

checking size of short... 2

checking for float... yes

checking size of float... 4

checking for double... yes

checking size of double... 8

checking for fpos_t... yes

checking size of fpos_t... 4

checking for long long support... yes

checking for long long... yes

checking size of long long... 8

checking for uintptr_t support... no

checking size of off_t... 4

checking whether to enable large file support... no

checking size of time_t... 4

checking for pthread_t... yes

checking size of pthread_t... 4

checking for --enable-toolbox-glue... no

checking for --enable-framework... no

checking for dyld... no

checking SO... .so

checking LDSHARED... $(CC) -shared

checking CCSHARED... -fPIC

checking LINKFORSHARED... -Xlinker -export-dynamic

checking CFLAGSFORSHARED... 

checking SHLIBS... $(LIBS)

checking for dlopen in -ldl... yes

checking for shl_load in -ldld... no

checking for library containing sem_init... -lpthread

checking for textdomain in -lintl... no

checking for t_open in -lnsl... no

checking for socket in -lsocket... no

checking for --with-libs... no

checking for --with-signal-module... yes

checking for --with-dec-threads... no

checking for --with-threads... yes

checking for _POSIX_THREADS in unistd.h... no

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 for usconfig in -lmpc... no

checking if PTHREAD_SCOPE_SYSTEM is supported... yes

checking for pthread_sigmask... yes

checking if --enable-ipv6 is specified... no

checking for --with-universal-newlines... yes

checking for --with-doc-strings... yes

checking for --with-pymalloc... yes

checking for --with-wctype-functions... no

checking for --with-sgi-dl... no

checking for --with-dl-dld... no

checking for dlopen... yes

checking DYNLOADFILE... dynload_shlib.o

checking MACHDEP_OBJS... MACHDEP_OBJS

checking for alarm... yes

checking for chown... yes

checking for clock... yes

checking for confstr... yes

checking for ctermid... yes

checking for execv... yes

checking for fchdir... yes

checking for fork... yes

checking for fsync... yes

checking for fdatasync... yes

checking for fpathconf... yes

checking for ftime... yes

checking for ftruncate... yes

checking for gai_strerror... no

checking for getgroups... yes

checking for getlogin... yes

checking for getloadavg... no

checking for getpeername... yes

checking for getpgid... yes

checking for getpid... yes

checking for getpriority... yes

checking for getpwent... yes

checking for getwd... yes

checking for kill... yes

checking for killpg... yes

checking for lchown... no

checking for lstat... yes

checking for mkfifo... yes

checking for mknod... yes

checking for mktime... yes

checking for mremap... yes

checking for nice... yes

checking for pathconf... yes

checking for pause... yes

checking for plock... no

checking for poll... no

checking for pthread_init... no

checking for putenv... yes

checking for readlink... yes

checking for realpath... yes

checking for select... yes

checking for setegid... yes

checking for seteuid... yes

checking for setgid... yes

checking for setlocale... yes

checking for setregid... yes

checking for setreuid... yes

checking for setsid... yes

checking for setpgid... yes

checking for setpgrp... yes

checking for setuid... yes

checking for setvbuf... yes

checking for snprintf... yes

checking for sigaction... yes

checking for siginterrupt... yes

checking for sigrelse... no

checking for strftime... yes

checking for strptime... yes

checking for sysconf... yes

checking for tcgetpgrp... yes

checking for tcsetpgrp... yes

checking for tempnam... yes

checking for timegm... yes

checking for times... yes

checking for tmpfile... yes

checking for tmpnam... yes

checking for tmpnam_r... no

checking for truncate... yes

checking for uname... yes

checking for unsetenv... yes

checking for utimes... yes

checking for waitpid... yes

checking for wcscoll... no

checking for _getpty... no

checking for chroot... no

checking for link... yes

checking for symlink... no

checking for ctermid_r... no

checking for flock... yes

checking for getpagesize... no

checking for true... true

checking for inet_aton in -lc... yes

checking for hstrerror... no

checking for inet_aton... yes

checking for inet_pton... no

checking for setgroups... no

checking for openpty... no

checking for openpty in -lutil... no

checking for forkpty... no

checking for forkpty in -lutil... no

checking for fseek64... no

checking for fseeko... no

checking for fstatvfs... no

checking for ftell64... no

checking for ftello... no

checking for statvfs... no

checking for dup2... yes

checking for getcwd... yes

checking for strdup... yes

checking for strerror... yes

checking for memmove... yes

checking for getpgrp... yes

checking for setpgrp... (cached) yes

checking for gettimeofday... yes

checking for major... yes

checking for getaddrinfo... no

checking for getnameinfo... no

checking whether time.h and sys/time.h may both be 

included... yes

checking whether struct tm is in sys/time.h or time.h... 

time.h

checking for struct tm.tm_zone... no

checking for tzname... yes

checking for struct stat.st_rdev... yes

checking for struct stat.st_blksize... yes

checking for struct stat.st_blocks... yes

checking for time.h that defines altzone... no

checking whether sys/select.h and sys/time.h may both 

be included... no

checking for addrinfo... no

checking for sockaddr_storage... no

checking whether char is unsigned... no

checking for gcc option to accept ANSI C... none needed

checking for an ANSI C-conforming const... yes

checking for working volatile... yes

checking for working signed char... yes

checking for prototypes... yes

checking for variable length prototypes and stdarg.h... 

yes

checking for bad exec* prototypes... no

checking if sockaddr has sa_len member... no

checking whether va_list is an array... no

checking for gethostbyname_r... yes

checking gethostbyname_r with 6 args... no

checking gethostbyname_r with 5 args... yes

checking for __fpu_control... yes

checking for --with-fpectl... no

checking for --with-libm=STRING... default LIBM="-lm"

checking for --with-libc=STRING... default LIBC=""

checking for hypot... yes

checking wchar.h usability... no

checking wchar.h presence... no

checking for wchar.h... no

checking what type to use for unicode... unsigned short

checking whether byte ordering is bigendian... no

checking whether right shift extends the sign bit... yes

checking for getc_unlocked() and friends... yes

checking for rl_pre_input_hook in -lreadline... no

checking for rl_completion_matches in -lreadline... no

checking for broken nice()... yes

checking for working tzset()... yes

checking for tv_nsec in struct stat... no

checking whether mvwdelch is an expression... yes

checking whether WINDOW has _flags... yes

checking for /dev/ptmx... no

checking for /dev/ptc... no

checking for socklen_t... no

checking for build directories... done

configure: creating ./config.status

config.status: creating Makefile.pre

config.status: creating Modules/Setup.config

config.status: creating pyconfig.h

creating Setup

creating Setup.local

creating Makefile

azure:~/Python-2.3$ 





azure:~/Python-2.3$ make

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/python.o 

Modules/python.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/python.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/acceler.o 

Parser/acceler.c

In file included from Include/grammar.h:10,

                 from Parser/acceler.c:14:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/acceler.c:13:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar1.o 

Parser/grammar1.c

In file included from Include/grammar.h:10,

                 from Parser/grammar1.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar1.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/listnode.o 

Parser/listnode.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/listnode.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/node.o 

Parser/node.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/node.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parser.o 

Parser/parser.c

In file included from Include/grammar.h:10,

                 from Parser/parser.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/parser.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/parsetok.o 

Parser/parsetok.c

In file included from Include/grammar.h:10,

                 from Parser/parsetok.c:7:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/parsetok.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/bitset.o 

Parser/bitset.c

In file included from Parser/bitset.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/bitset.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/metagrammar.o 

Parser/metagrammar.c

In file included from Include/grammar.h:10,

                 from Parser/metagrammar.c:4:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/metagrammar.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/firstsets.o 

Parser/firstsets.c

In file included from Include/grammar.h:10,

                 from Parser/firstsets.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/firstsets.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/grammar.o 

Parser/grammar.c

In file included from Include/grammar.h:10,

                 from Parser/grammar.c:10:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/grammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Parser/grammar.c: In function `_Py_adddfa':

Parser/grammar.c:45: warning: implicit declaration of 

function `strdup'

Parser/grammar.c:45: warning: assignment makes 

pointer from integer without a cast

Parser/grammar.c: In function `_Py_addlabel':

Parser/grammar.c:105: warning: assignment makes 

pointer from integer without a cast

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgen.o 

Parser/pgen.c

In file included from Include/grammar.h:10,

                 from Parser/pgen.c:11:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgen.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/myreadline.o 

Parser/myreadline.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/myreadline.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer.o 

Parser/tokenizer.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/abstract.o 

Objects/abstract.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/abstract.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/boolobject.o 

Objects/boolobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/boolobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/bufferobject.o 

Objects/bufferobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/bufferobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cellobject.o 

Objects/cellobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cellobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/classobject.o 

Objects/classobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/classobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/cobject.o 

Objects/cobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/cobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/complexobject.o Objects/complexobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/complexobject.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/descrobject.o 

Objects/descrobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/descrobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/enumobject.o 

Objects/enumobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/enumobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/fileobject.o 

Objects/fileobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/fileobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Objects/fileobject.c: In function `file_truncate':

Objects/fileobject.c:618: warning: implicit declaration of 

function `ftruncate'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/floatobject.o 

Objects/floatobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/floatobject.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/frameobject.o 

Objects/frameobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/frameobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/funcobject.o 

Objects/funcobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/funcobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/intobject.o 

Objects/intobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/intobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/iterobject.o 

Objects/iterobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/iterobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/listobject.o 

Objects/listobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/listobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/longobject.o 

Objects/longobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/longobject.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/dictobject.o 

Objects/dictobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/dictobject.c:10:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/methodobject.o Objects/methodobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/methodobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/moduleobject.o 

Objects/moduleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/moduleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/object.o 

Objects/object.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/object.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/obmalloc.o 

Objects/obmalloc.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/obmalloc.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/rangeobject.o 

Objects/rangeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/rangeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/sliceobject.o 

Objects/sliceobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/sliceobject.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/stringobject.o 

Objects/stringobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/stringobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/structseq.o 

Objects/structseq.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/structseq.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/tupleobject.o 

Objects/tupleobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/tupleobject.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/typeobject.o 

Objects/typeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/typeobject.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/weakrefobject.o Objects/weakrefobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/weakrefobject.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o 

Objects/unicodeobject.o Objects/unicodeobject.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodeobject.c:39:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Objects/unicodectype.o 

Objects/unicodectype.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Objects/unicodectype.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/bltinmodule.o 

Python/bltinmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/bltinmodule.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/exceptions.o 

Python/exceptions.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/exceptions.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/ceval.o 

Python/ceval.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/ceval.c:9:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mysnprintf.o 

Python/mysnprintf.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mysnprintf.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o 

Parser/tokenizer_pgen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/tokenizer.c:4,

                 from Parser/tokenizer_pgen.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/printgrammar.o 

Parser/printgrammar.c

In file included from Include/grammar.h:10,

                 from Parser/printgrammar.c:5:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Parser/printgrammar.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Parser/pgenmain.o 

Parser/pgenmain.c

In file included from Include/grammar.h:10,

                 from Parser/pgenmain.c:18:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Parser/pgenmain.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   

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 Objects/obmalloc.o 

Python/mysnprintf.o Parser/tokenizer_pgen.o 

Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl  -

lpthread -o Parser/pgen

Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Py

thon/graminit.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/compile.o 

Python/compile.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/compile.c:12:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/codecs.o 

Python/codecs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/codecs.c:11:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/errors.o 

Python/errors.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/errors.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/errors.c: At top level:

Python/errors.c:602: warning: function declaration isn't 

a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozen.o 

Python/frozen.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozen.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/frozenmain.o 

Python/frozenmain.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/frozenmain.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/future.o 

Python/future.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/future.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getargs.o 

Python/getargs.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getargs.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcompiler.o 

Python/getcompiler.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcompiler.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getcopyright.o 

Python/getcopyright.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getcopyright.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getmtime.o 

Python/getmtime.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getmtime.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPLATFORM='"linux2"' -o 

Python/getplatform.o ./Python/getplatform.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/getplatform.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getversion.o 

Python/getversion.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/getversion.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/graminit.o 

Python/graminit.c

In file included from Include/grammar.h:10,

                 from Python/graminit.c:2:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Include/pgenheaders.h:10,

                 from Python/graminit.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/import.o 

Python/import.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/import.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -I. -o 

Python/importdl.o ./Python/importdl.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Python/importdl.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/marshal.o 

Python/marshal.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/marshal.c:7:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/modsupport.o 

Python/modsupport.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/modsupport.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/mystrtoul.o 

Python/mystrtoul.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/mystrtoul.c:2:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pyfpe.o 

Python/pyfpe.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pystate.o 

Python/pystate.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pystate.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/pythonrun.o 

Python/pythonrun.c

In file included from Include/grammar.h:10,

                 from Python/pythonrun.c:6:

Include/bitset.h:21: warning: `BITSPERBYTE' redefined

/usr/include/values.h:31: warning: this is the location of 

the previous definition

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/pythonrun.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/pythonrun.c: At top level:

Python/pythonrun.c:81: warning: function declaration 

isn't a prototype

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/structmember.o 

Python/structmember.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/structmember.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/symtable.o 

Python/symtable.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/symtable.c:1:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/sysmodule.o 

Python/sysmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/sysmodule.c:17:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

Python/sysmodule.c: In function `PySys_SetArgv':

Python/sysmodule.c:1163: warning: implicit declaration 

of function `readlink'

Python/sysmodule.c:1212: warning: implicit declaration 

of function `realpath'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/traceback.o 

Python/traceback.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/traceback.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/getopt.o 

Python/getopt.c

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/dynload_shlib.o 

Python/dynload_shlib.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/dynload_shlib.c:4:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Python/thread.o 

Python/thread.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Python/thread.c:8:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/config.o 

Modules/config.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/config.c:19:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -DPYTHONPATH='":plat-

linux2:lib-tk"' \

        -DPREFIX='"/usr/local"' \

        -DEXEC_PREFIX='"/usr/local"' \

        -DVERSION='"2.3"' \

        -DVPATH='""' \

        -o Modules/getpath.o ./Modules/getpath.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/getpath.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/getpath.c: In function `calculate_path':

./Modules/getpath.c:454: warning: implicit declaration of 

function `readlink'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/main.o 

Modules/main.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/main.c:3:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE -o Modules/gcmodule.o 

Modules/gcmodule.c

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from Modules/gcmodule.c:21:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/threadmodule.c -o Modules/threadmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/threadmodule.c:5:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/signalmodule.c -o Modules/signalmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/signalmodule.c:6:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/signalmodule.c: In function `signal_handler':

./Modules/signalmodule.c:141: warning: implicit 

declaration of function `siginterrupt'

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -

I./Include  -DPy_BUILD_CORE  -

c ./Modules/posixmodule.c -o Modules/posixmodule.o

/usr/include/sys/stat.h: In function 

`__machdep_sys_fstat':

In file included from Include/pyport.h:157,

                 from Include/Python.h:48,

                 from ./Modules/posixmodule.c:16:

/usr/include/sys/stat.h:172: warning: implicit declaration 

of function `__machdep_sys__fxstat'

./Modules/posixmodule.c: In function `posix_fchdir':

./Modules/posixmodule.c:1132: `fchdir' undeclared (first 

use this function)

./Modules/posixmodule.c:1132: (Each undeclared 

identifier is reported only once

./Modules/posixmodule.c:1132: for each function it 

appears in.)

./Modules/posixmodule.c: In function `posix_fsync':

./Modules/posixmodule.c:1181: `fsync' undeclared (first 

use this function)

./Modules/posixmodule.c: In function `posix_fdatasync':

./Modules/posixmodule.c:1199: `fdatasync' undeclared 

(first use this function)

./Modules/posixmodule.c: In function `posix_nice':

./Modules/posixmodule.c:1722: warning: implicit 

declaration of function `nice'

./Modules/posixmodule.c: In function `posix_seteuid':

./Modules/posixmodule.c:4380: warning: implicit 

declaration of function `seteuid'

./Modules/posixmodule.c: In function `posix_setegid':

./Modules/posixmodule.c:4400: warning: implicit 

declaration of function `setegid'

./Modules/posixmodule.c: In function `posix_setreuid':

./Modules/posixmodule.c:4420: warning: implicit 

declaration of function `setreuid'

./Modules/posixmodule.c: In function `posix_setregid':

./Modules/posixmodule.c:4440: warning: implicit 

declaration of function `setregid'

./Modules/posixmodule.c: In function `posix_readlink':

./Modules/posixmodule.c:4632: warning: implicit 

declaration of function `readlink'

./Modules/posixmodule.c: In function `posix_ftruncate':

./Modules/posixmodule.c:5255: warning: implicit 

declaration of function `ftruncate'

./Modules/posixmodule.c: In function `posix_putenv':

./Modules/posixmodule.c:5312: warning: implicit 

declaration of function `putenv'

./Modules/posixmodule.c: In function `posix_unsetenv':

./Modules/posixmodule.c:5351: warning: implicit 

declaration of function `unsetenv'

make: *** [Modules/posixmodule.o] Error 1

azure:~/Python-2.3$ 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2003-09-20 17:32

Message:
Logged In: YES 
user_id=21627

I've committed the changes as



configure 1.423

configure.in 1.434

pyconfig.h.in 1.85

configure 1.416.4.5

configure.in 1.427.4.5

pyconfig.h.in 1.83.4.2



so this should be fixed now.



As for _machdep_sys__fxstat: this appears to be a bug in

your C library header files. Earlier versions of Python most

likely compiled either because _POSIX_THREADS was not

defined, or because you have changed the header files (e.g.

by installing patches) since.

----------------------------------------------------------------------

Comment By: Adam Schran (aschran)
Date: 2003-09-08 23:54

Message:
Logged In: YES 
user_id=859405

Thank you for the patch, we applied it, and the compile was 

successful.  We then ran "make test", and we noticed some 

failed tests which may or may not be relevant to the current 

issue.  We've attached the output of both "make" and "make 

test".



Regarding the mysterious __machdep_sys_fxstat fuction, I 

recursively grepped through /usr/include/ and only found two 

instances of the function.  Both were calls to the function in 

stat.h, which I have pasted before:



---cut---

#ifdef _POSIX_THREADS



static __inline__ int __machdep_sys_fstat(int __fd, struct 

stat * __statbuf)

{

  return __machdep_sys__fxstat(LINUX_STAT_VERSION, __fd, 

__statbuf);

}



#ifdef _MIT_POSIX_THREADS



static __inline__ int machdep_sys_fstat(int __fd, struct stat 

* __statbuf)

{

  return __machdep_sys__fxstat(LINUX_STAT_VERSION, __fd, 

__statbuf);

}



#endif



#endif

---cut---



Also, if it is important, we did not get any of these warnings 

when we compiled Python 2.2.1 some time ago.





----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-06 16:49

Message:
Logged In: YES 
user_id=21627

Please try the attached patch, and report an update on the

build log. Don't paste the build log into the edit window;

instead, attach it using "Check to Upload and Attach a File:"



Please also investigate



/usr/include/sys/stat.h:172: warning: implicit declaration

of function `__machdep_sys__fxstat'



Can you find __machdep_sys__fxstat anywhere?

----------------------------------------------------------------------

Comment By: Adam Schran (aschran)
Date: 2003-09-05 19:13

Message:
Logged In: YES 
user_id=859405

Loewis - This is what I found in unistd.h, note the __USE_BSD 

definition:



#ifdef  __USE_BSD

/* Change the owner and group of the file that FD is open 

on.  */

extern int __fchown __P ((int __fd,

                          __uid_t __owner, __gid_t __group));

extern int fchown __P ((int __fd,

                        __uid_t __owner, __gid_t __group));

/* Change the process's working directory to the directory

   that FD is open on.  */

extern int __fchdir __P ((int __fd));

extern int fchdir __P ((int __fd));

#endif /* Use BSD.  */





---



The fchdir function appears to be defined, but only if the 

__USE_BSD value is defined.



I grepped through all of thje *.h and *.c files in the Python's 

Modules directory, as well as the top-level Makefile, and 

I could not find any place where that value was set.



I also grepped through /usr/include for other instances of the 

fchdir() function and did not find any.



This is a Linux system, not BSD.  Also, these configure and 

make errors were reproduced on another Linux machine we 

have when we tried installing Python 2.3.



Does this help at all?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-05 07:12

Message:
Logged In: YES 
user_id=21627

We should focus on understanding a single problem at a time.

I propose that we focus on the failure



./Modules/posixmodule.c:1132: `fchdir' undeclared (first

use this function)



Now, this function ought to be declared in

/usr/include/unistd.h. Can you find out whether it is

declared there? If it is, can you find out why the

definition is not visible? If it is not, can you find out

whether it is declared elsewhere?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800710&group_id=5470