[ python-Bugs-1089624 ] Carbon.File.FSCatalogInfo.createDate implementation

[SourceForge.net]

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

Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.File.FSCatalogInfo.createDate implementation

Initial Comment:
In Mac/Modules/file/_Filemodule.c UTCDateTime values are 
converted using these functions:
 
static int
UTCDateTime_Convert(PyObject *v, UTCDateTime *ptr)
{
return PyArg_Parse(v, "(HlH)", &ptr->highSeconds, &ptr-
>lowSeconds, &ptr->fraction);
}

static PyObject *
UTCDateTime_New(UTCDateTime *ptr)
{
return Py_BuildValue("(HlH)", ptr->highSeconds, ptr-
>lowSeconds, ptr->fraction);
}


Shouldn't the format string be "(HLH)" in both cases? The struct 
definition of UTCDateTime contains unsigned times (UInt16, UInt32 
and UInt16).

The same problem is present in Python 2.3


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089624&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 15:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
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?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&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 15:37
Message generated for change (Settings changed) made by saravanand
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: Open
Resolution: None
>Priority: 9
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?

--

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

[ python-Bugs-1089643 ] Carbon.File.FSCatalogInfo.createDate implementation

[SourceForge.net]

Bugs item #1089643, was opened at 2004-12-22 11: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=1089643&group_id=5470

Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.File.FSCatalogInfo.createDate implementation

Initial Comment:
In Mac/Modules/file/_Filemodule.c UTCDateTime values are 
converted using these functions:
 
static int
UTCDateTime_Convert(PyObject *v, UTCDateTime *ptr)
{
return PyArg_Parse(v, "(HlH)", &ptr->highSeconds, &ptr-
>lowSeconds, &ptr->fraction);
}

static PyObject *
UTCDateTime_New(UTCDateTime *ptr)
{
return Py_BuildValue("(HlH)", ptr->highSeconds, ptr-
>lowSeconds, ptr->fraction);
}


Shouldn't the format string be "(HLH)" in both cases? The struct 
definition of UTCDateTime contains unsigned times (UInt16, UInt32 
and UInt16).

The same problem is present in Python 2.3


--

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

[ python-Bugs-1089643 ] Carbon.File.FSCatalogInfo.createDate implementation

[SourceForge.net]

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

Category: Macintosh
Group: Python 2.4
>Status: Deleted
>Resolution: Duplicate
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.File.FSCatalogInfo.createDate implementation

Initial Comment:
In Mac/Modules/file/_Filemodule.c UTCDateTime values are 
converted using these functions:
 
static int
UTCDateTime_Convert(PyObject *v, UTCDateTime *ptr)
{
return PyArg_Parse(v, "(HlH)", &ptr->highSeconds, &ptr-
>lowSeconds, &ptr->fraction);
}

static PyObject *
UTCDateTime_New(UTCDateTime *ptr)
{
return Py_BuildValue("(HlH)", ptr->highSeconds, ptr-
>lowSeconds, ptr->fraction);
}


Shouldn't the format string be "(HLH)" in both cases? The struct 
definition of UTCDateTime contains unsigned times (UInt16, UInt32 
and UInt16).

The same problem is present in Python 2.3


--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-12-22 11:23

Message:
Logged In: YES 
user_id=580910

whoops, submitted the same bug twice

--

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

[ python-Bugs-1085208 ] Installation ends prematurely

[SourceForge.net]

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

Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: anamh0001 (anamh0001)
Assigned to: Martin v. Löwis (loewis)
Summary: Installation ends prematurely

Initial Comment:
Test machine:
Pentium 4M 1.7Ghz
Win XP Pro w/ SP2
512Mb RAM
30Gb HD
.Net Framework 1.0 and 1.1
Windows Scripting Host 5.6

After double clicking the installation file.  It proceeds to 
act like any other Windows Installer.  After accepting 
c:\Python24 as the install directory, I am presented with 
this screen saying that there was an error and that the 
installation has ended prematurely.

FYI, I tried to install over Python 2.3 (as in upgrade) but 
I got the same error.  So I proceeded to uninstall Python 
2.3 and other installed libraries.  I then restarted the PC 
and tried to install Python 2.4 again.  This bug is the 
symptom of this second try.

Please find the screenshot attached showing the final 
screen.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-22 13:41

Message:
Logged In: YES 
user_id=21627

This is fixed for 2.4.1, which will not require VB anymore.

--

Comment By: anamh0001 (anamh0001)
Date: 2004-12-16 16:21

Message:
Logged In: YES 
user_id=1178107

BUG FIXED -- solution below.

1)
BTW I actually thought the installer was looking for 
c:\python24. So I created the folder before running the 
installer again.  But it didnt work.

When I ran the script.  It returned this error:  I used cscript.

c:\x.vbs(2, 7) (null): The specified module could not be found.

2) The version of wscript and cscript is 5.6.0.8825
3) This is latest version because I read that installing the 
latest version of scripting host fixes installation problems.



I managed to fix it.  I registered scrrun.dll by typing:
regsvr32 c:\windows\system32\scrrun.dll

Thanks for all the help..

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-16 14:07

Message:
Logged In: YES 
user_id=21627

Can you please try the following things?

1. Run the script

== SNIP 
Function CheckDir()
  Set FSO = CreateObject("Scripting.FileSystemObject")
  if FSO.FolderExists("c:\python24") then
wscript.echo "1"
  else
wscript.echo "0"
  end if
End Function

CheckDir()
= SNIP ==

in wscript.exe (i.e. save it into c:\x.vbs, then run c:\x.vbs)

2. Report the version of

C:\WINDOWS\SYSTEM32\wscript.exe

(5.6 is too imprecise - could it be that you have 5.6.0.8820?)

3. Install VBScript, from

http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943
-7E4B-4622-86EB-95A22B832CAA&displaylang=en

--

Comment By: anamh0001 (anamh0001)
Date: 2004-12-16 11:04

Message:
Logged In: YES 
user_id=1178107

Please find the msi log file attached.  

I managed to pinpoint the area where it breaks..  It's failing 
on CheckDir with an error 2896.

-
MSI (c) (88:54) [09:50:38:430]: Doing action: CheckDir
Action start 09:50:38: CheckDir.
MSI (c) (88:3C) [09:50:38:440]: Cloaking enabled.
MSI (c) (88:3C) [09:50:38:440]: Attempting to enable all 
disabled priveleges before calling Install on Server
MSI (c) (88:3C) [09:50:38:440]: Connected to service for CA 
interface.
MSI (c) (88:88) [09:50:38:580]: Entering 
MsiProvideComponentFromDescriptor. Descriptor: 2eAq^]D2g
(8V7Xaq(hoRIngresDBMS>M5KDYSUnf(HA*L[xeX)y, PathBuf: 
1C4F348, pcchPathBuf: 1C4F344, pcchArgsOffset: 1C4F2A4
MSI (c) (88:88) [09:50:38:580]: 
MsiProvideComponentFromDescriptor called for component 
{997FA962-E067-11D1-9396-00A0C90F27F9}: returning 
harcoded oleaut32.dll value
MSI (c) (88:88) [09:50:38:580]: 
MsiProvideComponentFromDescriptor is returning: 0
Action ended 09:50:38: CheckDir. Return value 3.
MSI (c) (88:54) [09:50:38:921]: Note: 1: 2262 2: Error 3: -
2147287038 
DEBUG: Error 2896:  Executing action CheckDir failed.
The installer has encountered an unexpected error installing 
this package. This may indicate a problem with this package. 
The error code is 2896. The arguments are: CheckDir, , 
Action ended 09:50:38: SelectDirectoryDlg. Return value 3.
MSI (c) (88:94) [09:50:38:931]: Doing action: FatalError
Action start 09:50:38: FatalError.
Action 09:50:38: FatalError. Dialog created
Action ended 09:50:39: FatalError. Return value 2.
Action ended 09:50:40: INSTALL. Return value 3.
MSI (c) (88:94) [09:50:40:012]: Destroying RemoteAPI 
object.
MSI (c) (88:3C) [09:50:40:012]: Custom Action Manager 
thread ending.

--

Comm

[ python-Bugs-1074873 ] Windows 2.4c1 installer default location issues

[SourceForge.net]

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

Category: Installation
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: dmerrill (davemerrill)
Assigned to: Martin v. Löwis (loewis)
Summary: Windows 2.4c1 installer default location issues

Initial Comment:
On win2k sp4, python-2.4c1.msi defaults to installing
in c:\Python24\, rather than the more usual c:\Program
Files\Python24\ like 2.3.3 did.

When I pointed it to c:\Program Files\Python24\, it
installed there, but I couldn't get IDLE to run; silent
failure. Not sure if there were other similar issues.
Uninstalled, and reinstalled to the default location,
all is (apparently, so far) well.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-22 13:45

Message:
Logged In: YES 
user_id=21627

The IDLE problem is fixed for 2.4.1, by properly supporting 
spaces in the target directory name. The default location is 
not a bug.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 20:45

Message:
Logged In: YES 
user_id=21627

Not sure what the bug is that you are reporting here. It is
intentional that Python installs into c:\python24, not into
Program Files.

The IDLE problem indicates a bug, of course.

--

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2004-12-01 17:30

Message:
Logged In: YES 
user_id=832557

More details on the IDLE issue in bug report 1076861, here



--

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

[ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash

[SourceForge.net]

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

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sebastian Hartte (dark-storm)
Assigned to: Walter Dörwald (doerwalter)
Summary: Incorrect behaviour of StreamReader.readline leads to crash

Initial Comment:
StreamReader.readline in codecs.py misinterprets the
size parameter. (File: codecs.py, Line: 296). 
The reported crash happens if a file processed by the
python tokenizer is using a not built-in codec for
source file encoding (i.e. iso-8859-15) and has lines
that are longer than the define BUFSIZ in stdio.h on
the platform python is compiled on. (On Windows for
MSVC++ this define is 512, thus a line that is longer
than 511 characters should suffice to crash python with
the correct encoding). 
The crash happens because the python core assumes that
the StreamReader.readline method returns a string
shorter than the platforms BUFSIZ macro (512 for MSVC). 

The current StreamReader.readline() looks like this:
---
def readline(self, size=None, keepends=True):

""" Read one line from the input stream and
return the
decoded data.

size, if given, is passed as size argument
to the
read() method.

"""
if size is None:
size = 10
line = u""
while True:
data = self.read(size)
line += data
pos = line.find("\n")
if pos>=0:
self.charbuffer = line[pos+1:] +
self.charbuffer
if keepends:
line = line[:pos+1]
else:
line = line[:pos]
return line
elif not data:
return line
if size<8000:
size *= 2
---

However, the core expects readline() to return at most
a string of the length size. readline() instead passes
size to the read() function.

There are multiple ways of solving this issue. 

a) Make the core reallocate the token memory if the
string returned by the readline function exceeds the
expected size (risky if the line is very long). 

b) Fix, rename, remodel,  change StreamReader.readline.
If no other part of the core or code expects size to do
nothing useful, the following readline() function does
behave correctly with arbitrarily long lines:

---
def readline(self, size=None, keepends=True):

""" Read one line from the input stream and
return the
decoded data.

size, if given, is passed as size argument
to the
read() method.

"""
if size is None:
size = 10
data = self.read(size)
pos = data.find("\n")
if pos>=0:
self.charbuffer = data[pos+1:] +
self.charbuffer
if keepends:
data = data[:pos+1]
else:
data = data[:pos]
return data
else:
return data # Return the data directly
since otherwise 
# we would exceed the given size.
---

Reproducing this bug:
This bug can only be reproduced if your platform does
use a small BUFSIZ for stdio operations (i.e. MSVC), i
didn't check but Linux might use more than 8000 byte
for the default buffer size. That means you would have
to use a line with more than 8000 characters to
reproduce this.

In addition, this bug only shows if the python
libraries StreamReader.readline() method is used, if
internal codecs like Latin-1 are used, there is no
crash since the method isn't used.

I've attached a file that crashes my Python 2.4 on
Windows using the official binary released on
python.org today.

Last but not least here is the assertion that is broken
if python is compiled in debug mode with MSVC++ 7.1:

Assertion failed: strlen(str) < (size_t)size, file
\Python-2.4\Parser\tokenizer.
c, line 367

--

>Comment By: Walter Dörwald (doerwalter)
Date: 2004-12-22 13:56

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/codecs.py 1.36
Lib/test/test_codecs.py 1.16
Misc/NEWS 1.1213
Lib/codecs.py 1.35.2.1
Lib/test/test_codecs.py 1.15.2.1
Misc/NEWS 1.1193.2.9

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-21 16:32

Message:
Logged In: YES 
user_id=38388

Even better. Please check it in. 

Thanks and Merry Christmas :-)

--

Comment By: Walter Dörwald (doerwalter)
Date: 2004-12-21 16:08

Message:
Logged In: YES 
user_id=89016

Here is a third version of the

[ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP

[SourceForge.net]

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

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean M. Brouwers (jbrouwers)
Assigned to: Martin v. Löwis (loewis)
Summary: Bad IDLE shortcut by 2.4 installer on XP

Initial Comment:
There is a problem with the Python 2.4 installer on
Windows XP.

The IDLE shortcut set up by the installer in the
StartUp folder does not work.  If the shortcut is
removed and recreated manually, it works fine.

That was *after* a complete reinstall of Python 2.4 and
after removing the previous version of Python 2.3 on
the machine.  With Python 2.3 present, the IDLE
shortcut installed by Python 2.4 runs the 2.3 version.

See also



and




--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-22 13:58

Message:
Logged In: YES 
user_id=21627

This is now fixed in msi.py 1.19 and 1.16.2.3

--

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2004-12-09 02:16

Message:
Logged In: YES 
user_id=832557

One more piece of data.  We installed Python 2.4 in
directory "C:\Program Files\Python24".  Maybe the space in
the name is causing the problem.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 23:13

Message:
Logged In: YES 
user_id=21627

I've added an entry to

http://www.python.org/2.4/bugs.html

now and hope to fix the problem for 2.4.1.

--

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

[ python-Bugs-1085172 ] Uninstaller should restore file associations if possible

[SourceForge.net]

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

Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: Martin v. Löwis (loewis)
Summary: Uninstaller should restore file associations if possible

Initial Comment:
On installing on Windows, the Python installer
associates .py and .pyw files to the new installation
of python. The installer should cache the previous
associations, and in the event of uninstallation
restore them to their previous values if the
application the are associated with still exists.

This allows for easier migration back to 2.3 in this
case, but also for easier back migration in the case of
installing a beta version of python 2.5 or whatever in
the future.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-16 14:09

Message:
Logged In: YES 
user_id=21627

This is not possible to implement. If you want to not add
associations for 2.4, you need to uncheck the "Register
Extensions" feature in the installer UI.

--

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

[ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP

[SourceForge.net]

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

Category: Installation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jean M. Brouwers (jbrouwers)
Assigned to: Martin v. Löwis (loewis)
Summary: Bad IDLE shortcut by 2.4 installer on XP

Initial Comment:
There is a problem with the Python 2.4 installer on
Windows XP.

The IDLE shortcut set up by the installer in the
StartUp folder does not work.  If the shortcut is
removed and recreated manually, it works fine.

That was *after* a complete reinstall of Python 2.4 and
after removing the previous version of Python 2.3 on
the machine.  With Python 2.3 present, the IDLE
shortcut installed by Python 2.4 runs the 2.3 version.

See also



and




--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-22 13:58

Message:
Logged In: YES 
user_id=21627

This is now fixed in msi.py 1.19 and 1.16.2.3

--

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2004-12-09 02:16

Message:
Logged In: YES 
user_id=832557

One more piece of data.  We installed Python 2.4 in
directory "C:\Program Files\Python24".  Maybe the space in
the name is causing the problem.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 23:13

Message:
Logged In: YES 
user_id=21627

I've added an entry to

http://www.python.org/2.4/bugs.html

now and hope to fix the problem for 2.4.1.

--

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

[ python-Bugs-1079545 ] python-2.4.msi install error

[SourceForge.net]

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

Category: Installation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: maharal (maharal)
Assigned to: Martin v. Löwis (loewis)
Summary: python-2.4.msi install error

Initial Comment:
when I try to install python2.4. using the python-
2.4.msi-file, it stopps with the error message: 
"The installer has encountered an unexpected error 
installing this package. This may inidicate a problem with 
this package. The error code is 2738"



--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-22 13:43

Message:
Logged In: YES 
user_id=21627

I have now made the changes to drop VB for 2.4.1.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-08 23:12

Message:
Logged In: YES 
user_id=21627

Ok, I have added an entry into

http://www.python.org/2.4/bugs.html

For 2.4.1, I will try to do without VB.

--

Comment By: maharal (maharal)
Date: 2004-12-08 15:16

Message:
Logged In: YES 
user_id=1171290

Dear Mr. Löwis, 
Your presumption was right: vbscript 5.6 was all that was 
needed to make the installation run! 
Thanks a lot for your help!
Ralf 


--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-06 22:59

Message:
Logged In: YES 
user_id=21627

Can you please try to install VBScript, from

http://msdn.microsoft.com/downloads/list/webdev.asp

and report whether this works?

--

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

[ python-Bugs-1086642 ] Compile of _socket fails on 2.4

[SourceForge.net]

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

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: A. Stocker (akosprime)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile of _socket fails on 2.4

Initial Comment:
I'm attempting to install Python 2.4 on an SGI Origin
2400 running Irix 6.5.22.  I'm using gcc (3.3) to
compile, and I've tried using three different make
programs (make, smake, and gmake[3.80]) but get the
same error during compilation during the building of
_socket.  There was not a problem building 2.2.1 on
this machine before, we never built 2.3 so I do not
know if the same problem existed.  Here is the relevant
entry from the make:

building '_socket' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared
-fno-strict-aliasing -I.
-I/usr/local/src/Python-2.4/./Include -I/us
r/local/include -I/usr/local/src/Python-2.4/Include
-I/usr/local/src/Python-2.4 -c
/usr/local/src/Python-2.4/Modules/socke
tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o
In file included from
/usr/local/src/Python-2.4/Modules/socketmodule.c:280:
/usr/local/src/Python-2.4/Modules/addrinfo.h:145:1:
warning: "_SS_ALIGNSIZE" redefined
In file included from
/usr/local/src/Python-2.4/Modules/socketmodule.h:8,
 from
/usr/local/src/Python-2.4/Modules/socketmodule.c:223:
/usr/include/sys/socket.h:246:1: warning: this is the
location of the previous definition
/usr/local/src/Python-2.4/Modules/socketmodule.c: In
function `makeipaddr':
/usr/local/src/Python-2.4/Modules/socketmodule.c:853:
warning: implicit declaration of function `getnameinfo'
/usr/local/src/Python-2.4/Modules/socketmodule.c:854:
error: `NI_NUMERICHOST' undeclared (first use in this
function)
/usr/local/src/Python-2.4/Modules/socketmodule.c:854:
error: (Each undeclared identifier is reported only once
/usr/local/src/Python-2.4/Modules/socketmodule.c:854:
error: for each function it appears in.)
/usr/local/src/Python-2.4/Modules/socketmodule.c: In
function `socket_gethostbyname_ex':
/usr/local/src/Python-2.4/Modules/socketmodule.c:2785:
warning: implicit declaration of function `gethostbyname_r'
/usr/local/src/Python-2.4/Modules/socketmodule.c:2785:
warning: assignment makes pointer from integer without
a cast
/usr/local/src/Python-2.4/Modules/socketmodule.c: In
function `socket_gethostbyaddr':
/usr/local/src/Python-2.4/Modules/socketmodule.c:2880:
warning: implicit declaration of function `gethostbyaddr_r'
/usr/local/src/Python-2.4/Modules/socketmodule.c:2881:
warning: assignment makes pointer from integer without
a cast
building '_ssl' extension


--

>Comment By: A. Stocker (akosprime)
Date: 2004-12-22 14:19

Message:
Logged In: YES 
user_id=1179755

All,

I decided to force the issue a bit.  Looking through
socketmodule.c I noticed that there was an SGI specific
check that basically disabled loading the addrinfo.h file,
which is where NI_NUMERICHOST is defined.  So I put the
#define statement from the addrinfo.h file directly in the
socketmodule.c file and the compilation with _socket worked.
 However this seems to be a clunky way to deal with the
situation.  Plus I don't know if there's anything else like
this biting me in the butt (for instance '_locale' doesn't
compile either.)

--

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

[ python-Bugs-974757 ] urllib2's HTTPPasswordMgr and uri's with port numbers

[SourceForge.net]

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

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chris Withers (fresh)
>Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2's HTTPPasswordMgr and uri's with port numbers

Initial Comment:
Python 2.3.3

The title just about sums it up.
If you add a password with a uri containing a port
number using add_password, then it probably won't be
returned by find_user_password.

That's not right ;-)

--

>Comment By: Jeremy Hylton (jhylton)
Date: 2004-12-22 14:27

Message:
Logged In: YES 
user_id=31392

Fixed in rev 1.78 of urllib2


--

Comment By: Chris Withers (fresh)
Date: 2004-11-05 10:08

Message:
Logged In: YES 
user_id=24723

This patch fixes it for me:

--- urllib2.py.cvs  Fri Nov 05 10:02:26 2004
+++ urllib2.py.new  Fri Nov 05 10:05:48 2004
@@ -720,7 +720,7 @@
 return self.retry_http_basic_auth(host,
req, realm)

 def retry_http_basic_auth(self, host, req, realm):
-user,pw = self.passwd.find_user_password(realm, host)
+user,pw = self.passwd.find_user_password(realm,
req.get_full_url())
 if pw is not None:
 raw = "%s:%s" % (user, pw)
 auth = 'Basic %s' %
base64.encodestring(raw).strip()

--

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

[ python-Bugs-1085300 ] Mac Library Modules 1.1.1 Bad Info

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Walrus (unclewalrus)
Assigned to: Brett Cannon (bcannon)
Summary: Mac Library Modules 1.1.1 Bad Info

Initial Comment:
Document states that OS X's TextEdit only saves RTF
files. This is incorrect; you can make a plaintext file
by choosing 'Make Plain Text' from the Format menu.

--

>Comment By: Walrus (unclewalrus)
Date: 2004-12-22 10:28

Message:
Logged In: YES 
user_id=1178211

Mac Library Modules, section 1.1.1, about halfway down.
http://www.python.org/doc/2.4/mac/node5.html

--

Comment By: Brett Cannon (bcannon)
Date: 2004-12-22 00:12

Message:
Logged In: YES 
user_id=357491

Yes, it's true; RTF and plaintext are the two possible output.

Walrus, where exactly in the docs does it claim this?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 16:35

Message:
Logged In: YES 
user_id=80475

Brett, can you verify this and, if true, add an appropriate
note to the docs.

--

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

[ python-Bugs-1067732 ] wininst --install-script leaves residual files on C:Mime-Version: 1.0

[SourceForge.net]

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

Category: Distutils
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: J Livingston (jlivingston)
Assigned to: Thomas Heller (theller)
Summary: wininst --install-script leaves residual files on C:
Initial Comment:
I'm running Python 2.3.4 and using distutils ( 
__revision__ of 1.58 2003/02/19) on WinXP SP2 to 
create a windows .exe installer. Both installation and 
removal of the package result in a residual file on the 
root of C: drive. This seems to be directly related to the 
use of the windows install-script which is provided with 
the --install-script switch.
 
The residual file has a naming convention of sxxx 
where 'xxx' is any alphanumeric combination. There is 
never an extension on the file name. On installation, the 
residual file contains the same text the install-script 
prints in the install screen window. On removal, the 
residual file is empty (the install-script does not print 
anything when removing.)

Users attempting to execute the installer from a 
network drive experience installer crash as they do not 
have file system permission to generate the residual 
file..

--

>Comment By: Thomas Heller (theller)
Date: 2004-12-22 16:50

Message:
Logged In: YES 
user_id=11105

Fixed with rev.  1.1.14.8  PC/bdist_wininst/install.c.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 20:51

Message:
Logged In: YES 
user_id=21627

Thomas, can you take a look? If not, please unassign.

--

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

[ python-Bugs-988022 ] bdist_wininst improvements

[SourceForge.net]

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

Category: Distutils
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: bdist_wininst improvements

Initial Comment:
bdist_wininst installed programs show a ridiculous size
in the Add/Remove programs list.  For example, py2exe
reports 126 MB, and pywin32 reports 113 MB.
This article explains why .


--

>Comment By: Thomas Heller (theller)
Date: 2004-12-22 16:52

Message:
Logged In: YES 
user_id=11105

No time nor interest any more.

--

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

[ python-Bugs-600952 ] Installing w/o admin generates key error

[SourceForge.net]

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

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Phil Rittenhouse (prittenh)
Assigned to: Thomas Heller (theller)
Summary: Installing w/o admin generates key error

Initial Comment:
I encountered the following problem when trying to 
install a package I had generated with distutils 
(Python 2.2 on Win2k, logged in as a user without 
adminstrative priveleges):

When the installer was run, it would go through the 
steps nicely, but towards the end, it generated two 
errors:
"Could not open key
Software\Microsoft\Windows\CurrentVersion\Unins
tall"
"Could not create key  dsp-py2.1"

At first I thought the problem might be the result 
of installing Python as Administrator, and the 
package as just a user, so I re-installed Python as a 
user, but I still got the same error.  I ran my test on 
Win2K with both Python 2.1 and 2.2, and I always 
got the same result.

I tracked the code generating the error to install.c in
distutils-1.0.2/misc (see below).  I did some 
digging and it appears that to use 
KEY_ALL_ACCESS, the code must be running
with Administrator privileges.   I checked the CVS 
archives to see if KEY_ALL_ACCESS is
still being used, and it is.

I made the following changes to install.c (from 
Distutils 1.0.2), recompiled, and it  works now.
796c796
< KEY_CREATE_SUB_KEY,
---
> KEY_ALL_ACCESS,
806c806
<   KEY_WRITE,
---
>   KEY_ALL_ACCESS,
1177c1177
KEY_ALL_ACCESS,
1208c1208
KEY_ALL_ACCESS,


I chose KEY_CREATE_SUB_KEY for the open, since 
that is the only operation that will be performed
on it.   For the new key itself, I chose KEY_WRITE, 
since that was also the minimal operation.  While I
was at it, I changed the code for deleting the 
registry key and value to also use the minimal 
KEY_WRITE.  The last two changes allowed the 
uninstaller to work properly when run as a normal 
user.


--

>Comment By: Thomas Heller (theller)
Date: 2004-12-22 16:54

Message:
Logged In: YES 
user_id=11105

I believe this is long fixed.

--

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

[ python-Bugs-848871 ] Windows installer halts

[SourceForge.net]

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

Category: Windows
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jens Olsson (morr)
Assigned to: Thomas Heller (theller)
Summary: Windows installer halts

Initial Comment:
The Windows installer halts when starting to install files, 
more exactly when installing the file "UNWISE.EXE" and 
the progress bar reads "1%".

Python versions tested:
2.2.3
2.3.1
2.3.2
2.3.2-1

All tested versions behave the same. Since I don't believe 
it's a common bug I attach selected computer specs for 
the system in question. I find it hard to believe it is the 
python windows installer by itself that contains the bug 
but since I haven't experienced this with any other 
installer I submit the bug anyway. It can't be my system 
by itself either.

- Varying the installation options does not seem to help 
(non exhaustive testing done).
- Running install on on specific processor (Hyper 
Threading is enabled) does not change things

Test system summary (see attachment for full specs):
Gigabyte 8KNXP motherboard, intel Northwood 3.0GHz HT, 
2x512MB Corsair 3500, Radeon 9700 AIW, Seagate 
Barracuda 160GB, Windows XP Pro SP1a.

Reproduction steps:
1. Launch installer
2. Click 'next' when asked for directory
3. Click 'next' when asked about backups
4. Click 'next' when asked for component selection
5. Click 'next' when asked for start menu group selection
6. Click 'next' when prompted with the "ready to install" 
screen
7. Observere bug


--

>Comment By: Thomas Heller (theller)
Date: 2004-12-22 16:55

Message:
Logged In: YES 
user_id=11105

No time to struggle with WISE.

--

Comment By: Thomas Heller (theller)
Date: 2004-02-25 20:14

Message:
Logged In: YES 
user_id=11105

Nope, there isn't really progress.  I spend some time in the
wise support news group, but didn't really get a useful
answer.  I have to limit the time I spend on this.

IMO a better thing would be to bring the innosetup script in
CVS up to date with the current inno version - they are at
4.1.x currently, and add code for the missing features.  I
have the impression that innosetup is powerful enough to
handle all that is needed.

The only downside would that probably Python 2.3.4 will be
the only version using this installer, since 2.4 will be
released as MSI file.

--

Comment By: Jens Olsson (morr)
Date: 2004-02-24 10:29

Message:
Logged In: YES 
user_id=917179

Any news on this one? Latest version behaves the same. Is 
there any alternative Windows install procedure that is 
reasonable easy to perform?

--

Comment By: Jens Olsson (morr)
Date: 2003-12-10 12:38

Message:
Logged In: YES 
user_id=917179

I couldn't update comments and didn't have time to figure out 
how I should do it so I hope this attached file will do.

Follow up:

I ran the installer with the suggested /m1 option. The install 
asked for the following directories (in order):

windows 
system
system32
temp
source

All input boxes had default values which seemed reasonable so 
I left them unchanged.

Then the actual installer window showed (as without /m1). 
After submitting the requested information (as reported in the 
inital bugreport) the installer halted when the small window 
titled "installing" showed, at 1% and the file unwise.exe... just 
as before. No question about registring files (besides the five 
windows promting for manual input of directories as described 
above).

No error messages. Just the same behaviour as before with 
some additional directory prompting dialoges at the beginning.

--

Comment By: Thomas Heller (theller)
Date: 2003-12-05 20:49

Message:
Logged In: YES 
user_id=11105

Here is advice I got from a Wise rep:

"""
This sounds like it is hanging at the point that the install
is trying to self register files. You can test this by
running the setup.exe with a /m1.  This will run the install
in manual mode, and prompt when each file is trying to self
register.  This will indicate which file it is trying to
self register, and then the error message.
"""

Can you try this, please, and report the result?

--

Comment By: Thomas Heller (theller)
Date: 2003-12-03 21:58

Message:
Logged In: YES 
user_id=11105

I've asked in the WISE support news group for help, I've
also seen similar behaviour in other software built with WISE.

--

You can respond

[ python-Bugs-895567 ] os.listdir fails for pathprefix \?\d:...

[SourceForge.net]

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

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Guenter Kruschina (kruschina)
>Assigned to: Nobody/Anonymous (nobody)
Summary: os.listdir fails for pathprefix \?\d:...

Initial Comment:
The  function os.listdir() fails with arguments
beggining with \?\... . This is necessary under
windows to switch off pathchecking  for all
Win32-Widecharacter functions. The problem is located
in the posixmodule.

A diff -u will show the solution for this problem:

--- posixmodule.c   2004-01-30 16:51:18.768574400 +0100
+++ posixmodule.c.org   2003-12-03 02:21:01.0 +0100
@@ -1386,7 +1386,7 @@
len = wcslen(wnamebuf);
wch = (len > 0) ?
wnamebuf[len-1] : L'\0';
if (wch != L'/' && wch != L'\'
&& wch != L':')
-   wnamebuf[len++] = L'\';
+   wnamebuf[len++] = L'/';
wcscpy(wnamebuf + len, L"*.*");
if ((d = PyList_New(0)) == NULL)
return NULL;


By the way: The functions isdir..isfile...etc also does
not work with the pathprefix \?
--

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

[ python-Bugs-781614 ] Windows _bsddb link warnings

[SourceForge.net]

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

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Windows _bsddb link warnings

Initial Comment:
Hi,

The PCbuild/readme.txt says this:

'''
XXX We're actually linking against
Release_static\libdb41s.lib.
XXX This yields the following warnings:
"""
Compiling...
_bsddb.c
Linking...
   Creating library ./_bsddb.lib and object ./_bsddb.exp
LINK : warning LNK4049: locally defined symbol
"_malloc" imported
LINK : warning LNK4049: locally defined symbol "_free"
imported
LINK : warning LNK4049: locally defined symbol
"_fclose" imported
LINK : warning LNK4049: locally defined symbol "_fopen"
imported
_bsddb.pyd - 0 error(s), 4 warning(s)
"""
XXX This isn't encouraging, but I don't know what
to do about it.
'''

The cause of this is the fact that libdb41s.lib is
built with the flags for using the "Multithreaded" C
RTL but Python uses the "MUltithreaded DLL" C RTL.  In
other words, libdb is specifying that the C RTL should
be linked statically but Python wants to link to it
statically. 

To avoid these warnings the instructions can be changed
to specify that the builder should change the flags in
the Berkeley_DB project.  Also you should probably link
with the Debug_static\libdb41sd.lib when building the
debug version of Python.


--

Comment By: Thomas Heller (theller)
Date: 2004-02-18 21:18

Message:
Logged In: YES 
user_id=11105

Potentially dangerous - of course.  The question is whether
this is responsible for some bugs or not.

If we cannot link to the DLL then we have to change the
build settings for the static builds of libdb41s.lib.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-02-18 20:58

Message:
Logged In: YES 
user_id=21627

I think we should avoid linking with the DLL if possible; in
some application context, it may be impossible to find the
DLL dynamically, or there might be confusion which DLL to load.

The linker warning means that there is a conflict between
the static (libc.a) and dynamic (msvcr71.dll) version of
_free, etc, which potentially means that we are linking
conflicting copies of the CRT, which is potentially dangerous.

--

Comment By: Thomas Heller (theller)
Date: 2004-02-18 18:41

Message:
Logged In: YES 
user_id=11105

It looks to me like we could link to the import library
build_win32\Release\libdb41.lib instead of  the static
library build_win32\Release_static\libdb41s.lib.

The former is built with 'multithreaded dll' flags.  The
downside is that libdb41.dll plus MSVCP60.DLL would have to
be distributed.

Are the linker warnings a real problem, or only cosmetical?

Of course we have to update the build procedure for 2.4
anyway...

--

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 00:54

Message:
Logged In: YES 
user_id=31435

Thomas, you have any insight into this one?

--

Comment By: Martin v. Löwis (loewis)
Date: 2003-08-01 21:50

Message:
Logged In: YES 
user_id=21627

Can you propose a specific patch?

Also, it would be preferable if changing the source code of
the Sleepycat distribution would not be necessary.

--

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

[ python-Bugs-886492 ] Python 2.2.3 crashes using popen2 to spawn lots of children

[SourceForge.net]

Bugs item #886492, was opened at 2004-01-28 21:33
Message generated for change (Settings changed) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886492&group_id=5470

Category: Windows
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Terhaar-Yonkers (frankty)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.2.3 crashes using popen2 to spawn lots of children

Initial Comment:
WinPython 2.3.3 crashes when using popen2 to spawn
*lots* of children > 100.

Running the test case on either W2k or Wxp causes
Python 2.3.3 to crash.  Looking at the drwatson file,
it appears to be a race condition where the child is in
the process of crashing, while the popen2 code in
posixmodule.c is attempting to PyFile_SetBufSize() on
one of the pipes.  Evil juju in ntdll.dll ..

I've no idea what system resource is being exhausted
(heap memory?) causing the crash.

If you look at the hacks in posixmodule.c, the Python
crash can be eliminated by simply commenting out the
calls to PyFile_SetBufSize.  There is still the problem
of resource exhaustion.  To gain more child processes I
included a hack such that with the setting of an
env-var (NOPYCMD) popen2 will NOT use cmd.exe /c to run
a child, but simply run the child command as passed
(yeah, I know that is has to be an absolute path or in
the CWD then ..).

I'm sure there is a better way to eliminate the cmd.exe
/c - like maybe a new method: popen2.popenXabspath ..

In any case, it appears we have an NT kernel bug
combined with an inefficient way of doing popen2 that
is making a mess.  I started doing some exploration of
heap_chunk_size to attack to resource issue but haven't
gotten very far.

As for *why* I'm doing this, it's because we're using
Pyton as a system simulator tool to emulate a large
pile of PCs.  The actual work *must* be done by
external .exe code that cannot be changed.

The attached zip contains a test case, the posixmodule
hack, drwatson file and a sample program written in
VisC++ which does basically the same as the Python test
case.

cheers,

- Frank



--

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

[ python-Feature Requests-1089955 ] optparse .error() should print options list

[SourceForge.net]

Feature Requests item #1089955, was opened at 2004-12-22 18:53
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=1089955&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Orr (hierro)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse .error() should print options list

Initial Comment:
Why doesn't optparse.OptionParser.error() print the
list of correct options along with the error message
and usage?  This is what the user needs to know
whenever there's an error.  One can override this in a
subclass, but it's frustrating to have to do it every
time.  

To do this, change the first line in
OptionParser.error() from:

self.print_usage(sys.stderr)

to:

self.print_help(sys.stderr)
print >>sys.stderr

--

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

[ python-Bugs-1066490 ] special methods become static

[SourceForge.net]

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

Category: Type/class unification
Group: Python 2.3
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Kevin Quick (kquick)
Assigned to: Michael Hudson (mwh)
Summary: special methods become static

Initial Comment:
This *may* be a duplicate of 729913, but there's either additional
info here, or this is actually different.

The issue is that any special method (e.g. __call__, __str__, etc.)
defined for a new-style (i.e. object-based) class seems to be static
(i.e. unchangeable) with some special lookup applied for that method,
but this doesn't seem to be the case for regular methods.

class A:
  def foo(self): return 1
  def __call__(self): return 2
  def bar(self): return 3
  def adjust(self):
self.foo = self.bar
self.__call__ = self.bar

a = A()
print a.foo(), a()
a.adjust()
print a.foo(), a()

Will print:
1 2
3 3

But if the A is turned into a new-style class by changing the
first line:

class A(object):

then the printed results are:
1 2
3 2

To the best of my understanding of the migration from classic classes 
to new-style classes (and metaclassing), this shouldn't occur.  I have 
also tried various name munging for the special method (e.g. setting 
_B__call__, using setattr, etc.), but I haven't found the special trick 
yet.

The attached script shows the example in more detail.


--

>Comment By: Kevin Quick (kquick)
Date: 2004-12-22 12:00

Message:
Logged In: YES 
user_id=6133

Thanks for the clarifcation.  However IMHO it is wrong to have different 
behavior for different methods.

To wit, if I defined a method, it is a bound method, and ergo a "self" initial 
argument is automatically supplied.  However, a __repr__, even though I 
define it, acts as an unbound method, with the self argument having a default 
of the current instance but overrideable if an argument is supplied on the call.
This means that the argument evaluation/passing is different for these types
of builtins as opposed to other methods, both of which I have defined myself.

This just doesn't seem right to me, which is why I'm re-opening this bug 
report... sorry to be annoying, but this definitely seems inconsistent and a 
better explanation.

My current workaround is to do the following:

class foo:
  def __str__(self):
return my_str()
  def my_str(self):
return 'something'

So that I can do "foo.my_str = lambda self: return 'something else'".

When what I should be able to do is:

class foo:
  def __str__(self):
return 'something'

...
foo.__str__ = lambda self: return 'something else'


--

Comment By: Michael Hudson (mwh)
Date: 2004-11-16 01:22

Message:
Logged In: YES 
user_id=6656

Oh, sorry, I think I got that a bit wrong.  The issue is more with 
bound/unbound methods -- given 

class O(object):
 def __repr__(self):
   ...

should O.__repr__ be a bound method (O is an instance of type) 
or an unbound method so O.__repr__(O()) does what you expect?

Python chooses the latter, but this means that you can't implement 
the builtin function repr as 

def repr(o):
return o.__repr__()

Hope this helps, a little at least.

--

Comment By: Kevin Quick (kquick)
Date: 2004-11-15 07:29

Message:
Logged In: YES 
user_id=6133

OK, I didn't find anything documenting this change anywhere (obviously).

I read Guido's description of new-classes (www.python.org/2.2/descrintro.py)
and the various documentation, but either I overlooked it therein or it's 
talked 
about somewhere else.

I'm curious as to why special methods are treated specially in regards to this 
lookup.  Specifically for your example, why wouldn't you just use the 
__repr__ attribute of o if it exists, instead of o's class, just like it does 
for 
non-special methods?  Can you briefly explain this or provide me with a
reference?

Leaving this closed is OK with me since it's apparently known and expected... 
I'd just like to understand it a bit better.  Sorry for the bandwidth, and 
Thanks!


--

Comment By: Michael Hudson (mwh)
Date: 2004-11-15 00:16

Message:
Logged In: YES 
user_id=6656

The change you are observing is that special methods are now 
only looked up on the *class* of the object concerned.  This, or 
something like this is actually unavoidable -- in

>>> repr(o)

what do you do if both o and the type of o define a __repr__ 
method?

There are articles on new-style classes out there that should 
explain this in more depth.  It probably could/should be 
documented better in the core -- there are bugs open to that 
effect already.

Closing.

-

[ python-Bugs-1089974 ] mmap missing offset parameter

[SourceForge.net]

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

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: James Y Knight (foom)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap missing offset parameter

Initial Comment:
For some reason, the author of the MMap module didn't see fit to 
expose the "offset" parameter of the mmap syscall to python. It 
would be really nice if it had that. Currently, it's always set to 0.

m_obj->data = mmap(NULL, map_size,
   prot, flags,
   fd, 0);


--

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

[ python-Bugs-1089978 ] exec scoping problem

[SourceForge.net]

Bugs item #1089978, was opened at 2004-12-22 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=1089978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Quick (kquick)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec scoping problem

Initial Comment:
Python 2.3.3 (#1, Oct 18 2004, 16:10:24) 
[GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] 
on linux2

Using exec on a code object with an "in ..." statement to specify locals 
and globals does not appear to set the globals for any code objects 
called by the exec'd code object.

As a workaround, I can exec a file object containing the relevant code 
objects and the scope appears to work, although the following issues are 
noted (these are possibly separate bugs, but all demonstrated by the 
attached... let me know if you'd like separate bugreport submissions, but 
I figured it was easiest to start with one in case I'm way off base in some 
fundamental way).

1. exec won't process an opened .pyc file, only a .py file.  However, the 
module's __file__ attribute will specify the .pyc or the .py, depending 
on which one is more recent.  This forces me to reset the extension to 
.py at all times.  It also means that if I use this technique I must ensure 
that the .py is always available relative to the .pyc.

2. The exec'd file needs the addition of a "if __name__ == '__main__'" 
to invoke the functionality I want.  This makes sense for exec'ing a 
file, but because I'm forced to exec the file to get globals scoped as I 
wanted, rather than using the code object, I am then limited to that 
single function invocation for any __name__ == "__main__" 
invocation of the file.

3. Specifying "in locals()" for the code object invocation has no 
adverse (or positive) effect, but specifying it for the file object seems 
to cause the interpreter to recurse the *current* file, not the exec'd file 
(this is Test #5 in the attachment).


--

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

[ python-Bugs-1090076 ] Defaults in ConfigParser.get overrides section values

[SourceForge.net]

Bugs item #1090076, was opened at 2004-12-22 19: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=1090076&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defaults in ConfigParser.get overrides section values

Initial Comment:
ConfigParser.get has an optional argument vars that -
according to the docstring- "which must be a dictionary 
whose contents overrides any pre-existing defaults."
I understand that it overrides the default values, but 
should not override an actual value existing in the file. 
That is, given this contents:

[DEFAULT]
key1=default1

[section]
key2=value2

vars={'key1:vars1','key2:vars2'}

cfg.get('section','key1',0,vars) gives 'vars1' (ok)

cfg.get('section','key2',0,vars) gives 'vars2' (wrong, 
should be 'value2', since key2 is actually in the section 
and no default is needed).

To correct this behavior, simply move this two lines of 
code up in ConfigParser.get (ConfigParser.py), just below 
the first line and before the first try/except:

# Update with the entry specific variables
if vars is not None:
d.update(vars)


--

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

[ python-Bugs-1090139 ] presentation typo in lib: 6.21.4.2 How callbacks are called

[SourceForge.net]

Bugs item #1090139, was opened at 2004-12-22 17: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=1090139&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jesse Weinstein (weinsteinj)
Assigned to: Nobody/Anonymous (nobody)
Summary: presentation typo in lib: 6.21.4.2 How callbacks are called

Initial Comment:
On the page:
http://docs.python.org/lib/optparse-how-callbacks-called.html
the text: 
args
should be changed to:
args
to match the rest of the items on the page.  This may
require changing the LaTeX.

--

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