[ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map

[SourceForge.net]

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

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: saravanand (saravanand)
Assigned to: Nobody/Anonymous (nobody)
Summary: _DummyThread() objects not freed from threading._active map

Initial Comment:
Problem Background:
===

I have Python Server module (long running) which 
accepts calls from several Python Clients over socket 
interface and forwards the call to a C++ component.  
This C++ component gives the reponses back to Python 
Server in a separate thread(created by C++ module) via 
callback.

In the Python Callback implementation, the responses 
are sent to client in a synchronised manner using Python 
primitive threading.Semaphore.  This Synchronisation is 
required as the C++ component can deliver parallel 
responses in different C++ threads.

Here, the Python Server creates the semaphore object 
per client when the client request arrives (in Python 
thread).  This same object is acquired & released in the 
C++ callback thread(s).

Here we observed that Windows Events are getting 
created whenever the acquire method is executed in the 
Python Callback implementation in the context of C++ 
thread. But the same event is not freed by the Python 
Interpreter even after the termination of the C++ 
thread.   Because of this, a Windows Event handles are 
getting leaked in the Python Server.  

Problem Description:
==
When we checked the Python module threading.py, we 
found that, every time a non-python thread (in our case 
C++ created thread), enters python and accessesn a 
primitive in threading module (eg: Semaphore, RLock), 
python looks for an entry for this thread in the _active 
map using thread ID as the Key. Since no  entry exists 
for such C++ created threads, a _DummyThread object 
is created and added to the _active map for this C++ 
thread. 

For every _DummyThread object that is created, there is 
a corresponding Windows Event also getting created.

Since this entry is never removed from the _active map 
even after the termination of the C++ thread ( as we 
could make out from the code in threading.py),for 
every "unique" C++ thread that enters python, a 
Windows Event is allocated and this manifests as 
continuous increase in the Handle count in my Python 
server ( as seen in Windows PerfMon/Task Manager).

Is there a way to avoid this caching in Python 
Interpreter? Why cant Python remove this entry from 
the map when the C++ thread terminates. Or if Python 
can't get to know about the thread termination, should 
it not implement some kind of Garbage collection for the 
entries in this Map (especially entries for the 
_DummyThread objects).

Does this require a correction in Python 
modulethreading.py?

or is this caching behaviour by design?

--

>Comment By: Brett Cannon (bcannon)
Date: 2005-01-05 23:19

Message:
Logged In: YES 
user_id=357491

What does Semaphore have to do with _DummyThread and 
currentThread?

And as for win32api, that is not part of the Python stdlib and thus I have 
no way of commenting on that.

For C++ threads to call into Python code, I would not say that is bad 
specifically.  You were just trying to get thread info for non-Python 
threads and that was leading to _DummyThread instances to be created 
as designed and you just didn't want that.  Calling Python code is fine, 
just don't expect it to know about your C++ threads as much as you 
seem to want it to.

And please leave this bug closed.  If free to submit a patch to change 
semantics, but that does not affect this bug report.

--

Comment By: saravanand (saravanand)
Date: 2005-01-05 02:54

Message:
Logged In: YES 
user_id=1181691

I tried the following workaround which is working (causes no 
handle leaks)

Workaround is to change threading.semaphore to Windows 
Extension module APIs win32event.CreateMutex(),  
win32event.WaitForSingleObject and win32event.ReleaseMutex
()

After this change, there are no handle leaks. So, my 
questions are:
1) Is this workaround OK or are there any other issues 
regarding the win32api usage ?
2) you suggested to create minimal python wrappers for C++ 
code and call C++ from python (instead of C++ thread 
callbacks). So I would like to know,  in general, whether it is a 
bad idea for c++ threads to callback into Python. If yes, what 
are the issues (apart from the handle leak mentioned before). 
If no, I would like to live with the above workaround.

Thanks in advance

--

Comment By: saravanand (saravanand)
Date: 2005-01-05 02:29

Message:
Logged In: YES 
user_id

[ python-Bugs-1095802 ] "Macintosh" references in the docs need to be checked.

[SourceForge.net]

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Macintosh" references in the docs need to be checked.

Initial Comment:
As of 2.4 Python no longer runs on MacOS9 or earlier. We need to 
go through all the documentation loooking for references to 
"macintosh", "mac", "apple", "macos" and such to check whether 
these references are still valid.

--

>Comment By: Jack Jansen (jackjansen)
Date: 2005-01-06 10:59

Message:
Logged In: YES 
user_id=45365

"Macintosh" is fine as a reference, but we need to check that the tekst is 
actually relevant to OSX. There may be lots of things that can go, 
referring to non-virtual memory or :-separated filenames, or resource 
forks, or whatever. Or, at the very least, it may need rewording.

As to darwin: I wouldn't cater for that. Technically it's nice to support it, 
but I'd be surprised if there were a 1000 people out there actually 
running it.

--

Comment By: Brett Cannon (bcannon)
Date: 2005-01-06 08:21

Message:
Logged In: YES 
user_id=357491

Should we change the mentions to "OS X" or "darwin"?  It would help 
remove any possible misunderstanding of OS 9 support and make sure 
we caught all doc mentions.  Could also help specify and difference 
between Darwin and OS X explicitly.

--

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

[ python-Bugs-1071597 ] configure problem on HP-UX 11.11

[SourceForge.net]

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

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure problem on HP-UX 11.11

Initial Comment:
Python 2.4c1 has this problem (but if I recall, so did 2.3.3)_ 
 
Using gcc 3.3.3 to build on HP-UX 11.11, the  
configure out of the box is a bit off, resulting in a failed build, due 
to missing thread symbols: 
 
/usr/ccs/bin/ld: Unsatisfied symbols: 
   PyThread_acquire_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_exit_thread (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_allocate_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_free_lock (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_start_new_thread (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_release_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_get_thread_ident (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread__init_thread (first referenced in 
libpython2.4.a(thread.o)) (code) 
collect2: ld returned 1 exit status 
 
A workaround is to manually edit pyconfig.h, adding  
#define _POSIX_THREADS 
 
(The reason it is not picked up is that unistd.h on HP-UX has this 
comment: 
 
/ 
 * The following defines are specified in the standard, but are not 
yet 
 * implemented: 
 * 
 *_POSIX_THREADS can't be defined until all 
 *   features are implemented 
) 
 
The implementation seems however to be sufficiently complete 
to permit compiling and running Python with _POSIX_THREADS. 
 
While I'm editing pyconfig.h, I also comment out 
_POSIX_C_SOURCE definition, as it will result in lots of 
compilation warnings, of the style: 
 
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -I. -I../Python-2.4c1/Include  
-DPy_BUILD_CORE -o 
Objects/frameobject.o ../Python-2.4c1/Objects/frameobject.c 
In file included from ../Python-2.4c1/Include/Python.h:8, 
 from ../Python-2.4c1/Objects/frameobject.c:4: 
pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined 
:6:1: warning: this is the location of the 
previous definition 
 
 
 
So, to recapitulate:  After configure, add  
#define _POSIX_THREADS 
and comment out 
#define _POSIX_C_SOURCE 200112L 
 
That will give you a Python working rather well,  
with "make test" producing: 
 
251 tests OK. 
1 test failed: 
test_pty 
38 tests skipped: 
test_aepack test_al test_applesingle test_bsddb 
test_bsddb185 
test_bsddb3 test_cd test_cl test_codecmaps_cn 
test_codecmaps_hk 
test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw 
test_curses 
test_dl test_gdbm test_gl test_imgfile test_largefile 
test_linuxaudiodev test_locale test_macfs test_macostools 
test_nis 
test_normalization test_ossaudiodev test_pep277 test_plistlib 
test_scriptpackages test_socket_ssl test_socketserver 
test_sunaudiodev test_tcl test_timeout test_urllib2net 
test_urllibnet test_winreg test_winsound 
1 skip unexpected on hp-ux11: 
test_tcl 
 
 
 

--

>Comment By: Harri Pasanen (harripasanen)
Date: 2005-01-06 11:01

Message:
Logged In: YES 
user_id=77088

Note that the _POSIX_C_SOURCE is also defined for gcc 3.4.3 on 
HP-UX 11.23 (Itanium).   I don't know if it defined for all the gcc 
platforms, as it would only show up if the definition in pyconfig.h is 
different from what the gcc driver uses. 

--

Comment By: Harri Pasanen (harripasanen)
Date: 2005-01-05 14:46

Message:
Logged In: YES 
user_id=77088

_POSIX_C_SOURCE appears to come from the gcc driver, along with a 
few other macros. 
 
If I add "-v" to compilation, the output expands to: 
 
Reading specs 
from /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/specs 
Configured 
with: /scratch/zack/pkgbuild/3.3.1/hpux-11/gcc-3.3.3/configure 
--enable-languages=c,c++ --enable-threads=posix --disable-nls 
--with-gnu-as --without-gnu-ld --with-as=/usr/local/bin/as 
--prefix=/usr/local 
Thread model: posix 
gcc version 3.3.3 
 /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/cc1 -quiet -v -I. 
-I./Include -D__GNUC__=3 -D__GNUC_MINOR__=3 
-D__GNUC_PATCHLEVEL__=3 -D_REENTRANT -D_THREAD_SAFE 
-D_POSIX_C_SOURCE=199506L -DNDEBUG -DPy_BUILD_CORE 
Modules/python.c -quiet -dumpbase python.c -auxbase-strip 
Modules/python.o -g -O3 -Wall -Wstrict-prototypes -version 
-fno-strict-aliasing -o /var/tmp//ccLnAhZ0.s 
GNU C ve

[ python-Bugs-1097229 ] Example needed in os.stat()

[SourceForge.net]

Bugs item #1097229, was opened at 2005-01-06 11: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=1097229&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Facundo Batista (facundobatista)
Assigned to: Nobody/Anonymous (nobody)
Summary: Example needed in os.stat()

Initial Comment:
As the repr() of an os.stat() object is *exactly* equal
to a tuple, it's not clear at first in the
documentation how to use its attributes:

>>> import os
>>> statinfo = os.stat('somefile.txt')
>>> statinfo
(33188, 422511L, 769L, 1, 1032, 100, 926L, 1105022698,
1105022732, 1105022732)
>>> statinfo.st_size
926L
>>>

So I propose to put this example in the stat docs.

--

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

[ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map

[SourceForge.net]

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: saravanand (saravanand)
Assigned to: Nobody/Anonymous (nobody)
Summary: _DummyThread() objects not freed from threading._active map

Initial Comment:
Problem Background:
===

I have Python Server module (long running) which 
accepts calls from several Python Clients over socket 
interface and forwards the call to a C++ component.  
This C++ component gives the reponses back to Python 
Server in a separate thread(created by C++ module) via 
callback.

In the Python Callback implementation, the responses 
are sent to client in a synchronised manner using Python 
primitive threading.Semaphore.  This Synchronisation is 
required as the C++ component can deliver parallel 
responses in different C++ threads.

Here, the Python Server creates the semaphore object 
per client when the client request arrives (in Python 
thread).  This same object is acquired & released in the 
C++ callback thread(s).

Here we observed that Windows Events are getting 
created whenever the acquire method is executed in the 
Python Callback implementation in the context of C++ 
thread. But the same event is not freed by the Python 
Interpreter even after the termination of the C++ 
thread.   Because of this, a Windows Event handles are 
getting leaked in the Python Server.  

Problem Description:
==
When we checked the Python module threading.py, we 
found that, every time a non-python thread (in our case 
C++ created thread), enters python and accessesn a 
primitive in threading module (eg: Semaphore, RLock), 
python looks for an entry for this thread in the _active 
map using thread ID as the Key. Since no  entry exists 
for such C++ created threads, a _DummyThread object 
is created and added to the _active map for this C++ 
thread. 

For every _DummyThread object that is created, there is 
a corresponding Windows Event also getting created.

Since this entry is never removed from the _active map 
even after the termination of the C++ thread ( as we 
could make out from the code in threading.py),for 
every "unique" C++ thread that enters python, a 
Windows Event is allocated and this manifests as 
continuous increase in the Handle count in my Python 
server ( as seen in Windows PerfMon/Task Manager).

Is there a way to avoid this caching in Python 
Interpreter? Why cant Python remove this entry from 
the map when the C++ thread terminates. Or if Python 
can't get to know about the thread termination, should 
it not implement some kind of Garbage collection for the 
entries in this Map (especially entries for the 
_DummyThread objects).

Does this require a correction in Python 
modulethreading.py?

or is this caching behaviour by design?

--

>Comment By: Tim Peters (tim_one)
Date: 2005-01-06 12:16

Message:
Logged In: YES 
user_id=31435

Presumably, by changing threading.Semaphore to stop using 
any code from threading.py, then threading.currentThread() 
never gets called and so a _DummyThread is never created 
then.

I expect the reason a _DummyThread causes Event leaks is 
just that Thread.__init__ always ends up allocating a Python 
lock (Thread.__block), which allocates a Windows Event 
under the covers.

It *could* be that Thread.__block is never actually used for 
dummy threads, in which case we could avoid allocating it in 
that case (or could get rid of it right way in 
_DummyThread.__init__).  The dummy thread would still clog 
the _active dict, but wouldn't leak Events then.

It's certainly true that Python has no way to know when a 
thread it didn't start goes away.

--

Comment By: Brett Cannon (bcannon)
Date: 2005-01-06 02:19

Message:
Logged In: YES 
user_id=357491

What does Semaphore have to do with _DummyThread and 
currentThread?

And as for win32api, that is not part of the Python stdlib and thus I have 
no way of commenting on that.

For C++ threads to call into Python code, I would not say that is bad 
specifically.  You were just trying to get thread info for non-Python 
threads and that was leading to _DummyThread instances to be created 
as designed and you just didn't want that.  Calling Python code is fine, 
just don't expect it to know about your C++ threads as much as you 
seem to want it to.

And please leave this bug closed.  If free to submit a patch to change 
semantics, but that does not affect this bug report.

--

Comment By: saravanand (saravanand)
Date: 2005-01-05 05:54

Message:
Logged In: YES 
user_id=1181691

I tried the following work

[ python-Bugs-1097229 ] Example needed in os.stat()

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Facundo Batista (facundobatista)
>Assigned to: Facundo Batista (facundobatista)
Summary: Example needed in os.stat()

Initial Comment:
As the repr() of an os.stat() object is *exactly* equal
to a tuple, it's not clear at first in the
documentation how to use its attributes:

>>> import os
>>> statinfo = os.stat('somefile.txt')
>>> statinfo
(33188, 422511L, 769L, 1, 1032, 100, 926L, 1105022698,
1105022732, 1105022732)
>>> statinfo.st_size
926L
>>>

So I propose to put this example in the stat docs.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2005-01-06 21:13

Message:
Logged In: YES 
user_id=21627

Sure, go ahead.

--

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

[ python-Bugs-1085069 ] gethostbyaddr on redhat for multiple hostnames

[SourceForge.net]

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

Category: None
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Dave Kirby (davekirby)
Assigned to: Nobody/Anonymous (nobody)
Summary: gethostbyaddr on redhat for multiple hostnames

Initial Comment:

When running socket.gethostbyaddr against a host with
multiple hostnames assigned to it, the behaviour does
not work as advertised under Red Hat linux (tested with
Fedora Core 2 and Red Hat 8 - other versions of Linux
have not been tested).  

calling socket.gethostbyaddr from Windows or Mac OS X
against a test machine set up with multiple hosts gives
the correct result:

>>> socket.gethostbyaddr('1.2.3.4')
('testhost2', ['testhost7', 'testhost', 'testhost1',
'testhost3', 'testhost4', 'testhost6', 'testhost5'],
['1.2.3.4'])
>>> 

(The real IP address and hostnames have been changed
for security).

running the same thing from Linux only gives a single
hostname, and the alias list is empty.  Repeated calls
to the same function cycles through the hostnames (or
picks them at random):

>>> socket.gethostbyaddr('1.2.3.4')
('testhost', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost1', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost3', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost4', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost6', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost5', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost2', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost7', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost', [], ['1.2.3.4'])

This behaviour has been seen with Python 2.2.1, 2.3.3
and 2.4-RC2.

This is probably a bug in the underlying C function. 
According to the Linux man page, the POSIX
gethostbyaddr has been superceded by getipnodebyaddr. 
This behaviour should at least be documented, and if
possible fixed by using the new function.





--

>Comment By: Martin v. Löwis (loewis)
Date: 2005-01-06 21:28

Message:
Logged In: YES 
user_id=21627

This is indeed likely a bug in the underlying C library (or
a misconfiguration of the system, see /etc/hosts). As Python
exposes the function more-or-less as-is, I'm closing this as
a third-party bug.

It is true that gethostbyaddr was superceded by
getipnodebyaddr at some point. Meanwhile, this, in turn, was
superceded by getaddrinfo/getnameinfo, which Python exposes.

--

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

[ python-Bugs-1082874 ] Unable to see Python binary

[SourceForge.net]

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

Category: Installation
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Prabal Rakshit (prabal_rakshit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to see Python binary

Initial Comment:
After extracting the Python-2.3.3.tar we could get the 
appropriate folder structure. 
We then executed the configure script. Therafter when 
we execute the make command the Python binary is not 
created in /usr/local/bin.

Any pointers??

--

>Comment By: Martin v. Löwis (loewis)
Date: 2005-01-06 21:31

Message:
Logged In: YES 
user_id=21627

Most likely, "make install" was missing. Closing this report
as invalid.

--

Comment By: Gregory H. Ball (greg_ball)
Date: 2004-12-13 16:45

Message:
Logged In: YES 
user_id=11365

Are you running "make install" after "make" ?

You could try explicitly giving an installation prefix:

./configure --prefix=/usr/local

Otherwise you can look for newly created files like this:

find /usr -mmin -5

Hope this helps.

--

Comment By: Danny Yoo (dyoo)
Date: 2004-12-10 22:19

Message:
Logged In: YES 
user_id=49843

The 'make install' target will copy the built binary to
'/usr/local/bin'.  Did you try 'make install' yet?


--

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

[ python-Bugs-1078245 ] Python2.4: building '_socket' extension fails with `INET_ADD

[SourceForge.net]

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

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Ströder (stroeder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python2.4: building '_socket' extension fails with `INET_ADD

Initial Comment:
HI!

I'm trying to build Python2.4 on a rather old Debian
machine. 
Building _socket fails (see below) although I tried to use

configure --disable-ipv6

I've added

#define INET_ADDRSTRLEN 16

to Modules/socketmodule.h which made it work. There
were no problems compiling Python2.2 on the very same
machine.

Ciao, Michael.

-- snip
--
building '_socket' extension
gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -I. -I/tmp/Python-2.4/./Include
-I/user/W3311/local/include -I/usr/local/include
-I/tmp/Python-2.4/Include -I/tmp/Python-2.4 -c
/tmp/Python-2.4/Modules/socketmodule.c -o build/t
emp.linux-i686-2.4/socketmodule.o
/tmp/Python-2.4/Modules/socketmodule.c: In function
`socket_inet_ntop':
/tmp/Python-2.4/Modules/socketmodule.c:3350:
`INET_ADDRSTRLEN' undeclared (first use this function)
/tmp/Python-2.4/Modules/socketmodule.c:3350: (Each
undeclared identifier is reported only once
/tmp/Python-2.4/Modules/socketmodule.c:3350: for each
function it appears in.)
/tmp/Python-2.4/Modules/socketmodule.c:3350: size of
array `ip' has non-integer type 

--

>Comment By: Martin v. Löwis (loewis)
Date: 2005-01-06 21:35

Message:
Logged In: YES 
user_id=21627

There are already a few attempts to define ADDRSTRLEN if it
is missing. Maybe we should just merge them into one, and
define it if it is not defined, independent of the system.

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-12-13 14:19

Message:
Logged In: YES 
user_id=29957

How old a debian release is this? It sounds like it's a just
a broken system header, and I'm not entirely convinced that
adding this to the already-large collection of #ifdefs in
socketmodule is a path to happiness.



--

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

[ python-Bugs-1083177 ] Change in signal function in the signal module

[SourceForge.net]

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

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary H. Loechelt (loechelt)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Change in signal function in the signal module

Initial Comment:
The signal function of the signal module handles
arguments differently in Python 2.4 than in Python 2.3.
 I am running on an HP-UX 11 workstation.  If I set a
handler for a signal that cannot be trapped, like KILL
(signal 9), the signal function accepts the argument in
Python 2.3 but ignores the operation.  However, if I do
the same thing in Python 2.4, the signal function
rejects the argument and raises a RuntimeError.

I am not sure if this change in behavior is intentional
or not.  It makes sense in one way to complain about an
invalid argument (as in Python 2.4) rather than just
ignore the operation (as in Python 2.3).  However, I
did not find this change in either the documentation or
the release notes, and it caught me by surprise. 
Granted, the stricter argument checking probably caught
a sloppy line of coding.  Still, some kind of user
warning would have been nice if this was an intentional
change.

I am enclosing a simple Python script which illustrates
the problem.  It finishes normally when using Python
2.3 and raises a RuntimeError when using Python 2.4:

Traceback (most recent call last):
  File "set_signals.py", line 7, in ?
signal.signal(signal.SIGKILL, dummy)
RuntimeError: (22, 'Invalid argument')

Gary H. Loechelt


--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-12-13 08:16

Message:
Logged In: YES 
user_id=29957

This is a deliberate change - "errors should not pass
silently". I agree that it should get better visibility.
Perhaps an entry in amk's what's new document in the section
on Porting to 2.4

would be appropriate. AMK? (I've added a comment to the
document as a reminder)


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-10 22:32

Message:
Logged In: YES 
user_id=80475

On WinME, I appropriately get an AttributeError consistently
for Py2.2, Py2.3, and Py2.4.

Anthony, you've made the most recent updates to the
signalmodule.  What do you think?

--

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

[ python-Bugs-1091740 ] garbage collector still documented as optional

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Raymond Hettinger (rhettinger)
Summary: garbage collector still documented as optional

Initial Comment:
Section 3.2 of the library reference, first paragraph, says
"The gc module is only available if the interpreter was
built with the optional cyclic garbage detector"

However according to Misc/NEWS, "Compiling out the
cyclic garbage collector is no longer an option" as of
Python 2.3 alpha 1.



--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-06 19:51

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=1091740&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1088077 ] [PATCH] tty needs a way to restore the terminal mode.

[SourceForge.net]

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

Category: Python Library
>Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Meyer (mwm)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] tty needs a way to restore the terminal mode.

Initial Comment:
tty provides a nice, simple interface for setting the terminal to raw
or cbreak modes. However, it doesn't provide a way to put the terminal
back in the mode it was in before that change. Every responsible
application should leave the terminal in the mode it found it in -
unless the application is called sttty, of course. tty needs a
"setsane" function.



--

Comment By: Mike Meyer (mwm)
Date: 2004-12-19 16:28

Message:
Logged In: YES 
user_id=93910

The patch to add the setsane method is in patch #1088078.

--

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

[ python-Bugs-1093389 ] mapitags.PROP_TAG() doesn't account for new longs

[SourceForge.net]

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

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Hildebrand (hildjj)
>Assigned to: Mark Hammond (mhammond)
Summary: mapitags.PROP_TAG() doesn't account for new longs

Initial Comment:
Test case: 

>>> from win32com.mapi.mapitags import *
>>> PROP_TAG(PT_LONG, 0x8041)
2151743491L

Should be:
-2143223805L

or, alternately, the rest of the mapi interfaces should
know about unsigned ints.

--

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

[ python-Bugs-1071094 ] some latex reject the pdfinfo macro while generating html

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc-Antoine Parent (maparent)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: some latex reject the pdfinfo  macro while generating html

Initial Comment:
I was building the documentation on OSX. I use the latest LaTeX 
2004 from Wierda's teTeX. There is a pdfinfo command in Doc/
texinputs/manual.cls and Doc/texinputs/howto.cls which chokes my 
version of latex.

edited log follows:

TEXINPUTS=/.../Python-2.4c1/Doc/commontex: python /.../Python
-2.4c1/Doc/tools/mkhowto --html --about html/stdabout.dat --
iconserver ../icons --favicon ../icons/pyfav.png --address "See 
About this document... for 
information on suggesting changes." --up-link ../index.html --up-
title "Python Documentation Index" --global-module-index "../
modindex.html" --dvips-safe --dir html/api api/api.tex
+++ TEXINPUTS=/.../Python-2.4c1/
Doc/api:/.../Python-2.4c1/Doc/
commontex:/.../Python-2.4c1/Doc/
paper-letter:/.../Python-2.4c1/Doc/
texinputs:
+++ latex api
*** Session transcript and error messages are in /.../Python
-2.4c1/Doc/html/api/api.how.
*** Exited with status 1.
The relevant lines from the transcript are:

+++ latex api
This is pdfeTeX, Version 3.141592-1.20a-2.2 (Web2C 7.5.3)
output format initialized to DVI
entering extended mode
(/.../Python-2.4c1/Doc/api/api.tex
LaTeX2e <2003/12/01>
Babel  and hyphenation patterns for american, french, 
german, ngerman, nohyphenation, loaded.
(/.../Python-2.4c1/Doc/texinputs/manual.cls
Document Class: manual 1998/03/03 Document class (Python 
manual)
(/.../Python-2.4c1/Doc/texinputs/pypaper.sty
(/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/times.sty)
Using Times instead of Computer Modern.
) (/usr/local/teTeX/share/texmf.tetex/tex/latex/fancybox/
fancybox.sty
Style option: `fancybox' v1.3 <2000/09/19> (tvz)
) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/report.cls
Document Class: report 2004/02/16 v1.4f Standard LaTeX 
document class
(/usr/local/teTeX/share/texmf.tetex/tex/latex/base/size10.clo))
(/.../Python-2.4c1/Doc/texinputs/fancyhdr.sty)
Using fancier footers than usual.
(/.../Python-2.4c1/Doc/texinputs/fncychap.sty)
Using fancy chapter headings.
(/.../Python-2.4c1/Doc/texinputs/python.sty
(/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/longtable.sty)
(/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/verbatim.sty)
(/usr/local/teTeX/share/texmf.tetex/tex/latex/base/alltt.sty)))
(/.../Python-2.4c1/Doc/commontex/boilerplate.tex
(/.../Python-2.4c1/Doc/commontex/patchlevel.tex))
Writing index file api.idx
No file api.aux.
(/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/ot1ptm.fd)
pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
 { \def \{, } \pdfinfo 
  { /Author ([EMAIL PROTECTED] ) /Title ([EMAIL 
PROTECTED] ) } }
l.12 \maketitle
   
No pages of output.
Transcript written on api.log.
*** Session transcript and error messages are in /.../Python
-2.4c1/Doc/html/api/api.how.
*** Exited with status 1.
make: *** [html/api/api.html] Error 1


--

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

[ python-Bugs-1016563 ] urllib2 bug in proxy auth

[SourceForge.net]

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

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Christoph Mussenbrock (mussenbrock)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 bug in proxy auth

Initial Comment:
in urllib2.py:

line 502 should be:
... user_pass = base64.encodestring('%s:%s' % (unquote
(user), unquote(password))).strip()

the '.strip()' is missing in the current version ("2.1").

this makes an additonal '\n' at the end of user_pass.
So there will be an empty line in the http header, which 
is buggy.

(see also line 645, where the .strip() is right in place!).

Best regards,

Christoph

--

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

[ python-Bugs-989337 ] test_descr fails on win2k

[SourceForge.net]

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

Category: Python Library
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_descr fails on win2k

Initial Comment:
>>> from test import test_descr
>>> test_descr.verbose = 1
>>> test_descr.test_main()
Testing weakref segfault...
Testing SF bug 551412 ...
Testing SF bug 570483...
Testing list operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing dict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking a[b]=c
Testing dict constructor ...
Testing dir() ...
Testing int operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing long operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing float operations...
checking a >= b
checking a - b
checking a > b
checking a ** b
checking a < b
checking a != b
checking a + b
checking a <= b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking int(a)
checking - a
checking float(a)
checking + a
checking long(a)
checking abs(a)
Testing complex operations...
checking a - b
checking a ** b
checking a != b
checking a + b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking - a
checking + a
checking abs(a)
Testing spamlist operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing spamdict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking repr(a)
checking a[b]=c
Testing Python subclass of dict...
pydict stress test ...
Testing Python subclass of list...
Testing __metaclass__...
Testing Python subclass of module...
Testing multiple inheritance...
Testing error messages for MRO disagreement...
Testing multiple inheritance special cases...
Testing ex5 from C3 switch discussion...
Testing MRO monotonicity...
Testing consistentcy with EPG...
Testing object class...
Testing __slots__...
Testing __dict__ and __weakref__ in __slots__...
Testing class attribute propagation...
Testing errors...
Testing class methods...
Testing C-based class methods...
Testing static methods...
Testing C-based static methods...
Testing classic classes...
Testing computed attributes...
Testing __new__ slot override...
Testing mro() and overriding it...
Testing operator overloading...
Testing methods...
Testing special operators...

Traceback (most recent call last):
  File "", line 1, in -toplevel-
test_descr.test_main()
  File "C:\apps\Python24\lib\test\test_descr.py", line
4024, in test_main
specials()
  File "C:\apps\Python24\lib\test\test_descr.py", line
1875, in specials
print Letter('w')
PicklingError: Can't pickle : attribute lookup
test.test_descr.Letter failed
>>> 

This is Python 2.4a1 on win2k pro

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-06 20:19

Message:
Logged In: YES 
user_id=80475

Do you still have a problem with this in Py2.4 final ?

--

Comment By: Miki Tebeka (tebeka)
Date: 2004-10-17 11:00

Message:
Logged In: YES 
user_id=358087

Still here in Python-2.4b1

--

Comment By: Miki Tebeka (tebeka)
Date: 2004-07-19 00:09

Message:
Logged In: YES 
user_id=358087

Sorry, forgot that I've upgraded to winXP the other day.
This *is* winXP pro SP1

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-18 14:46

Message:
Logged In: YES 
user_id=80475

I cannot reproduce this on either WinME or WinXP.

--

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

[ python-Bugs-991708 ] test_imp failure

[SourceForge.net]

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

Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_imp failure

Initial Comment:
With threads disabled under fedore core 1

uname -r
2.4.22-1.2188.nptlsmp

./python -E -tt ./Lib/test/regrtest.py -vv test_imp
test_imp
test test_imp failed -- expected imp.lock_held() to be True
1 test failed:
test_imp

Looks shallow. :)


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-06 20:25

Message:
Logged In: YES 
user_id=80475

This was fixed by Brett on 12/4/04.

--

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

[ python-Bugs-971238 ] test_timeout failure on trunk

[SourceForge.net]

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

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_timeout failure on trunk

Initial Comment:
On current-CVS trunk, Fedora Core 2:

testBlockingThenTimeout (__main__.CreationTestCase) ... ok
testFloatReturnValue (__main__.CreationTestCase) ... ok
testObjectCreation (__main__.CreationTestCase) ... ok
testRangeCheck (__main__.CreationTestCase) ... ok
testReturnType (__main__.CreationTestCase) ... ok
testTimeoutThenBlocking (__main__.CreationTestCase) ... ok
testTypeCheck (__main__.CreationTestCase) ... ok
testAcceptTimeout (__main__.TimeoutTestCase) ... ok
testConnectTimeout (__main__.TimeoutTestCase) ... FAIL
testRecvTimeout (__main__.TimeoutTestCase) ... ok
testRecvfromTimeout (__main__.TimeoutTestCase) ... ok
testSend (__main__.TimeoutTestCase) ... ok
testSendall (__main__.TimeoutTestCase) ... ok
testSendto (__main__.TimeoutTestCase) ... ok

==
FAIL: testConnectTimeout (__main__.TimeoutTestCase)
--
Traceback (most recent call last):
  File "Lib/test/test_timeout.py", line 121, in
testConnectTimeout
"timeout (%g) is more than %g seconds more than
expected (%g)"
AssertionError: timeout (13.3079) is more than 2
seconds more than expected (0.001)

--
Ran 14 tests in 36.437s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_timeout.py", line 192, in ?
test_main()
  File "Lib/test/test_timeout.py", line 189, in test_main
test_support.run_unittest(CreationTestCase,
TimeoutTestCase)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 290, in run_unittest
run_suite(suite, testclass)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 275, in run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "Lib/test/test_timeout.py", line 121, in
testConnectTimeout
"timeout (%g) is more than %g seconds more than
expected (%g)"
AssertionError: timeout (13.3079) is more than 2
seconds more than expected (0.001)


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-06 20:27

Message:
Logged In: YES 
user_id=80475

Anthony, is this still a valid report?

--

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

[ python-Bugs-767111 ] AttributeError thrown by urllib.open_http

[SourceForge.net]

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

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Stuart Bishop (zenzen)
Assigned to: A.M. Kuchling (akuchling)
Summary: AttributeError thrown by urllib.open_http

Initial Comment:
In 2.3b2, looks like an error condition isn't being picked up 
on line 300 or 301 of urllib.py.

The code that triggered this traceback was simply:
url = urllib.urlopen(action, data)


Traceback (most recent call last):
  File "autospamrep.py", line 170, in ?
current_page = handle_spamcop_page(current_page)
  File "autospamrep.py", line 140, in handle_spamcop_page
url = urllib.urlopen(action, data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 78, in urlopen
return opener.open(url, data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 183, in open
return getattr(self, name)(url, data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 308, in open_http
return self.http_error(url, fp, errcode, errmsg, headers, 
data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 323, in http_error
return self.http_error_default(url, fp, errcode, errmsg, 
headers)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 551, in http_error_default
return addinfourl(fp, headers, "http:" + url)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 837, in __init__
addbase.__init__(self, fp)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 787, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-06 20:37

Message:
Logged In: YES 
user_id=80475

Andrew, are you still working on this one?

--

Comment By: Rob Probin (robzed)
Date: 2004-03-18 18:43

Message:
Logged In: YES 
user_id=1000470

The file pointer (fp) is None (inside urllib) from httplib. This appears to 
be caused by a BadStatusLine exception in getreply() (line1016 httplib). 

This sets self.file to self._conn.sock.makefile('rb', 0) then does a 
self.close() which sets self.file to None. 

Being new to this peice of code, I'm not sure whether it's urllib assuming 
the file isn't going to be closed, or the BadStatusLine exception clearing 
the file. Certainly it looks like the error -1 is not being trapped by 
open_http() in urllib upon calling h.getreply() and assuming that the file 
still exists even in an error condition?

It maybe a coincidence but it appears to occur more when a web browser 
on the same machine is refreshing. 

Regards
Rob


--

Comment By: Rob Probin (robzed)
Date: 2004-03-17 17:24

Message:
Logged In: YES 
user_id=1000470

""" 
This comment is program to reproduce the problem. Sorry it's not an 
attachment - as a relative Sourceforge newbie I have no idea how to 
attach to an existing bug. More notes available via email if required - 
including all local variables for each function from post mortem.

As said before, seems to be fp = None. Although the exception is caused 
by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside 
open_http()

This is repeatable, but you may have to run this more than once. 
(Apologies to noaa.gov).

*** PLEASE: Run only where absolutely necessary for reproduction of 
bug!!! ***

"""

""" Attribute Error test case  - Python 2.3 """

import urllib

url = "http://adds.aviationweather.noaa.gov/metars/index.php";

params = urllib.urlencode({ "station_ids" : "KJFK", 
"hoursStr" : "most recent only", 
"std_trans" : "standard", 
"chk_metars" : "on",
"submit":"Submit"})

print "test"

for i in range(1, 1000):
x = urllib.urlopen(url, params)
string = x.read()
print i

"""
Local variables for middle level routine...

classURLopener
open_http(self, url, data=None)
args('User-agent', 'Python-urllib/1.15')
authNone
data
'hoursStr=most+recent+only&station_ids=KJFK&std_trans=standard&sub
mit=Submit&chk_metars=on'
errcode -1
errmsg  ''
fp  None
h   
headers None
host'adds.aviationweather.noaa.gov'
h

[ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header

[SourceForge.net]

Bugs item #1097597, was opened at 2005-01-06 18: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=1097597&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Schachter (razmatazz)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleHTTPServer sends wrong Content-Length header

Initial Comment:
On Microsoft Windows, text files use \r\n for newline.
The SimpleHTTPServer class's "send_head()" method opens
files with "r" or "rb" mode depending on the MIME type.
Files opened in "r" mode will have \r\n -> \n
translation performed automatically, so the stream of
bytes sent to the client will be smaller than the size
of the file on disk.

Unfortunately, the send_head() method sets the
Content-Length header using the file size on disk,
without compensating for the \r\n -> \n translation.

I remedied this on my copy thusly:

  if mode == "r":
content = f.read()
contentLength = str(len(content))
f.seek(0)
  else:
contentLength = str(os.fstat(f.fileno())[6])

  self.send_header("Content-Length", contentLength)
 
This may not be as inefficient as it seems: the entire
file was going to be read in anyway for the newline
translation.

Hmmm. The code could be slightly simpler:

 if mode == "r":
contentLength = len(f.read())
f.seek(0)
  else:
contentLength = os.fstat(f.fileno())[6]

  self.send_header("Content-Length",
str(contentLength))


The documentation for SimpleHTTPServer in Python 2.3.4
for Windows says:

   A 'Content-type:' with the guessed content type is
   output, and then a blank line, signifying end of 
   headers, and then the contents of the file. The file
   is always opened in binary mode.

Actually, after Content-type, the Content-Length header
is sent.

It would probably be nice if "Content-Length" was
"Content-length" or if "Content-type" was
"Content-Type", for consistency. The latter is probably
best, per RFC 2016.


By the way, clients weren't caching the files I sent. I
added another line after the Content-Length handling:

  self.send_header("Expires", "Fri, 31 Dec 2100
12:00:00 GMT")

This is egregiously wrong in the general case and just
fine in my case.

--

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

[ python-Bugs-1097229 ] Example needed in os.stat()

[SourceForge.net]

Bugs item #1097229, was opened at 2005-01-06 11:39
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097229&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Facundo Batista (facundobatista)
Assigned to: Facundo Batista (facundobatista)
Summary: Example needed in os.stat()

Initial Comment:
As the repr() of an os.stat() object is *exactly* equal
to a tuple, it's not clear at first in the
documentation how to use its attributes:

>>> import os
>>> statinfo = os.stat('somefile.txt')
>>> statinfo
(33188, 422511L, 769L, 1, 1032, 100, 926L, 1105022698,
1105022732, 1105022732)
>>> statinfo.st_size
926L
>>>

So I propose to put this example in the stat docs.

--

>Comment By: Facundo Batista (facundobatista)
Date: 2005-01-06 23:51

Message:
Logged In: YES 
user_id=752496

Changed the docs, commited to CVS.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-01-06 17:13

Message:
Logged In: YES 
user_id=21627

Sure, go ahead.

--

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

[ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map

[SourceForge.net]

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: saravanand (saravanand)
Assigned to: Nobody/Anonymous (nobody)
Summary: _DummyThread() objects not freed from threading._active map

Initial Comment:
Problem Background:
===

I have Python Server module (long running) which 
accepts calls from several Python Clients over socket 
interface and forwards the call to a C++ component.  
This C++ component gives the reponses back to Python 
Server in a separate thread(created by C++ module) via 
callback.

In the Python Callback implementation, the responses 
are sent to client in a synchronised manner using Python 
primitive threading.Semaphore.  This Synchronisation is 
required as the C++ component can deliver parallel 
responses in different C++ threads.

Here, the Python Server creates the semaphore object 
per client when the client request arrives (in Python 
thread).  This same object is acquired & released in the 
C++ callback thread(s).

Here we observed that Windows Events are getting 
created whenever the acquire method is executed in the 
Python Callback implementation in the context of C++ 
thread. But the same event is not freed by the Python 
Interpreter even after the termination of the C++ 
thread.   Because of this, a Windows Event handles are 
getting leaked in the Python Server.  

Problem Description:
==
When we checked the Python module threading.py, we 
found that, every time a non-python thread (in our case 
C++ created thread), enters python and accessesn a 
primitive in threading module (eg: Semaphore, RLock), 
python looks for an entry for this thread in the _active 
map using thread ID as the Key. Since no  entry exists 
for such C++ created threads, a _DummyThread object 
is created and added to the _active map for this C++ 
thread. 

For every _DummyThread object that is created, there is 
a corresponding Windows Event also getting created.

Since this entry is never removed from the _active map 
even after the termination of the C++ thread ( as we 
could make out from the code in threading.py),for 
every "unique" C++ thread that enters python, a 
Windows Event is allocated and this manifests as 
continuous increase in the Handle count in my Python 
server ( as seen in Windows PerfMon/Task Manager).

Is there a way to avoid this caching in Python 
Interpreter? Why cant Python remove this entry from 
the map when the C++ thread terminates. Or if Python 
can't get to know about the thread termination, should 
it not implement some kind of Garbage collection for the 
entries in this Map (especially entries for the 
_DummyThread objects).

Does this require a correction in Python 
modulethreading.py?

or is this caching behaviour by design?

--

>Comment By: Brett Cannon (bcannon)
Date: 2005-01-06 19:36

Message:
Logged In: YES 
user_id=357491

Ah, I didn't notice that Semaphore uses a Condition lock which uses an 
RLock which calls currentThread before and gets a lock from 
thread.allocate_lock which probably uses an Event on Windows.  I also 
noticed that if __debug__ is set than the _note method uses it as well.

It looks like Thread.__block can't be called for a _DummyThread since 
the only places self.__block is used is in Thread.__stop (which is called 
in Thread.__bootstrap which is called by Thread.start which will raise an 
AssertionError since Thread.__started will be set to True thanks to 
_DummyThread.__init__) and in Thread.join which is overridden in 
_DummyThread.  So it looks like deleting the key should be safe in 
_DummyThread.__init__.

Probably wouldn't hurt to delete self.__stderr while we are at it since it 
never gets used either and thus is basically a ref leak.  Sound good to 
you, Tim?

--

Comment By: Tim Peters (tim_one)
Date: 2005-01-06 09:16

Message:
Logged In: YES 
user_id=31435

Presumably, by changing threading.Semaphore to stop using 
any code from threading.py, then threading.currentThread() 
never gets called and so a _DummyThread is never created 
then.

I expect the reason a _DummyThread causes Event leaks is 
just that Thread.__init__ always ends up allocating a Python 
lock (Thread.__block), which allocates a Windows Event 
under the covers.

It *could* be that Thread.__block is never actually used for 
dummy threads, in which case we could avoid allocating it in 
that case (or could get rid of it right way in 
_DummyThread.__init__).  The dummy thread would still clog 
the _active dict, but wouldn't leak Events then.

It's certainly true that Python has no way to know when a 
thread it didn't start goes 

[ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map

[SourceForge.net]

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: saravanand (saravanand)
Assigned to: Nobody/Anonymous (nobody)
Summary: _DummyThread() objects not freed from threading._active map

Initial Comment:
Problem Background:
===

I have Python Server module (long running) which 
accepts calls from several Python Clients over socket 
interface and forwards the call to a C++ component.  
This C++ component gives the reponses back to Python 
Server in a separate thread(created by C++ module) via 
callback.

In the Python Callback implementation, the responses 
are sent to client in a synchronised manner using Python 
primitive threading.Semaphore.  This Synchronisation is 
required as the C++ component can deliver parallel 
responses in different C++ threads.

Here, the Python Server creates the semaphore object 
per client when the client request arrives (in Python 
thread).  This same object is acquired & released in the 
C++ callback thread(s).

Here we observed that Windows Events are getting 
created whenever the acquire method is executed in the 
Python Callback implementation in the context of C++ 
thread. But the same event is not freed by the Python 
Interpreter even after the termination of the C++ 
thread.   Because of this, a Windows Event handles are 
getting leaked in the Python Server.  

Problem Description:
==
When we checked the Python module threading.py, we 
found that, every time a non-python thread (in our case 
C++ created thread), enters python and accessesn a 
primitive in threading module (eg: Semaphore, RLock), 
python looks for an entry for this thread in the _active 
map using thread ID as the Key. Since no  entry exists 
for such C++ created threads, a _DummyThread object 
is created and added to the _active map for this C++ 
thread. 

For every _DummyThread object that is created, there is 
a corresponding Windows Event also getting created.

Since this entry is never removed from the _active map 
even after the termination of the C++ thread ( as we 
could make out from the code in threading.py),for 
every "unique" C++ thread that enters python, a 
Windows Event is allocated and this manifests as 
continuous increase in the Handle count in my Python 
server ( as seen in Windows PerfMon/Task Manager).

Is there a way to avoid this caching in Python 
Interpreter? Why cant Python remove this entry from 
the map when the C++ thread terminates. Or if Python 
can't get to know about the thread termination, should 
it not implement some kind of Garbage collection for the 
entries in this Map (especially entries for the 
_DummyThread objects).

Does this require a correction in Python 
modulethreading.py?

or is this caching behaviour by design?

--

>Comment By: Tim Peters (tim_one)
Date: 2005-01-06 23:15

Message:
Logged In: YES 
user_id=31435

Right, thread.allocate_lock() does allocate an Event on 
Windows.  On other platforms it allocates other kinds of 
limited resource (one way or another, it has to grab some 
kind of locking object from the operating system, and the 
supply of those is typically finite).

Looking it over, I agree Thread.__block won't be used by a 
dummy thread.  I also  note that the use of "assert 
False" in _DummyThread.join() is plain bizarre.  It's a user 
error to try to join a dummy thread, not an internal invariant 
we believe *cannot* occur.  Guido misused (IMO) `assert` in 
several places in this module, but its use in join() is way over 
the edge.

Anyway, ya, I think it would be good to change this.  I don't 
really understand the point to nuking Thread.__stderr -- 
typically, sys.stderr is a single object over the life of a 
program, and doesn't go away until the program ends.  That 
is, I doubt the reference is keeping anything alive that would 
have gone away otherwise.

--

Comment By: Brett Cannon (bcannon)
Date: 2005-01-06 22:36

Message:
Logged In: YES 
user_id=357491

Ah, I didn't notice that Semaphore uses a Condition lock which uses an 
RLock which calls currentThread before and gets a lock from 
thread.allocate_lock which probably uses an Event on Windows.  I also 
noticed that if __debug__ is set than the _note method uses it as well.

It looks like Thread.__block can't be called for a _DummyThread since 
the only places self.__block is used is in Thread.__stop (which is called 
in Thread.__bootstrap which is called by Thread.start which will raise an 
AssertionError since Thread.__started will be set to True thanks to 
_DummyThread.__init__) and in Thread.join which is overridden in 
_DummyThread.  So 

[ python-Feature Requests-1087418 ] long int bitwise ops speedup (patch included)

[SourceForge.net]

Feature Requests item #1087418, was opened at 2004-12-18 00:22
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 4
Submitted By: Gregory Smith (gregsmith)
>Assigned to: Nobody/Anonymous (nobody)
Summary: long int bitwise ops speedup (patch included)

Initial Comment:

The 'inner loop' for applying bitwise ops to longs is quite
inefficient.

The improvement in the attached diff is
 - 'a' is never shorter than 'b' (result: only test 1
   loop index condition instead of 3)
 - each operation ( & | ^ ) has its own loop, instead
   of switch inside loop
- I found that, when this is done, a lot
of things can be simplified, resulting in further speedup,
and the resulting code is not very much longer than
before (my libpython2.4.dll  .text got 140 bytes longer).

Operations on longs of a few thousand bits appear
to be 2 ... 2.5 times faster with this patch.
I'm not 100% sure the code is right, but it passes
test_long.py, anyway.



--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-07 01:54

Message:
Logged In: YES 
user_id=80475

Patch Review


On Windows using MSC 6.0, I could only reproduce about a
small speedup at around 300 bits. 

While the patch is short, it adds quite a bit of complexity
to the routine.  Its correctness is not self-evident or
certain.  Even if correct, it is likely to encumber future
maintenance.

Unless you have important use cases and feel strongly about
it, I think this one should probably not go in.

An alternative to submit a patch that limits its scope to
factoring  out the innermost switch/case.  I tried that and
found that the speedup is microscopic.  I suspect that that
one unpredictable branch is not much of a bottleneck.  More
time is likely spent on creating z.

--

Comment By: Gregory Smith (gregsmith)
Date: 2005-01-03 14:54

Message:
Logged In: YES 
user_id=292741

I originally timed this on a cygwin system, I've since found
that cygwin timings tend to be strange and possibly
misleading. On a RH8 system, I'm seeing speedup of x3.5 with
longs of ~1500 bits and larger, and x1.5 speedup with only
about 300 bits. Times were measured with timeit.Timer(
'a|b', 'a=...; b=...')
Increase in .text size is likewise about 120 bytes.



--

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