From fdrake@beopen.com  Sat Jul  1 07:39:27 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Sat, 1 Jul 2000 02:39:27 -0400 (EDT)
Subject: [Python-bugs-list] Bug (typo) in ntpath.getatime (PR#345)
In-Reply-To: <20000602224351.630A61CE5D@dinsdale.python.org>
References: <20000602224351.630A61CE5D@dinsdale.python.org>
Message-ID: <14685.37407.798235.739210@cj42289-a.reston1.va.home.com>

db3l@fitlinxx.com writes:
 > Full_Name: David Bolen
 > Version: 1.5.2
 > OS: Windows NT 4.0 SP4
 > Submission from: (NULL) (208.247.212.11)
 > 
 > 
 > Line 186 in file Lib/ntpath.py in the Python 1.5.2 distribution (part of the
 > getatime() function):
 > 
 >     return st[stat.ST_MTIME]
 > 
 > incorrect indexes the stat structure by ST_MTIME rather than ST_ATIME.

David,
  Sorry for the delay in responding; I've fixed this in the source
repository.
  Thanks for reporting this!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Sat Jul  1 07:38:55 2000
From: fdrake@beopen.com (fdrake@beopen.com)
Date: Sat,  1 Jul 2000 02:38:55 -0400 (EDT)
Subject: [Python-bugs-list] Bug (typo) in ntpath.getatime (PR#345)
Message-ID: <20000701063855.28F8E1CE17@dinsdale.python.org>

db3l@fitlinxx.com writes:
 > Full_Name: David Bolen
 > Version: 1.5.2
 > OS: Windows NT 4.0 SP4
 > Submission from: (NULL) (208.247.212.11)
 > 
 > 
 > Line 186 in file Lib/ntpath.py in the Python 1.5.2 distribution (part of the
 > getatime() function):
 > 
 >     return st[stat.ST_MTIME]
 > 
 > incorrect indexes the stat structure by ST_MTIME rather than ST_ATIME.

David,
  Sorry for the delay in responding; I've fixed this in the source
repository.
  Thanks for reporting this!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member





From root@theporch.com  Mon Jul  3 13:49:10 2000
From: root@theporch.com (root@theporch.com)
Date: Mon,  3 Jul 2000 08:49:10 -0400 (EDT)
Subject: [Python-bugs-list] pty.re bug in cvs version  (7/3/00) (PR#379)
Message-ID: <20000703124910.BA7931CE02@dinsdale.python.org>

Full_Name: Phillip Porch
Version: 2.0b1
OS: SCO Openserver 5.0.5
Submission from: p3.theporch.com (207.234.31.45)


When compiling and testing the current cvs version of python (7/3/00), I
received a failure in test_pty. I ran ./python Lib/test/test_pty.py and it
showed a NameError: _slave_open called from line 28 in Lib/pty.py.  In looking
at the code, it appeared it was a typo and needed to be slave_open instead of
_slave_open. I changed it to slave_open and the test now runs fine.




From fdrake@beopen.com  Mon Jul  3 14:46:12 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 3 Jul 2000 09:46:12 -0400 (EDT)
Subject: [Python-bugs-list] pty.re bug in cvs version  (7/3/00) (PR#379)
In-Reply-To: <20000703124910.BA7931CE02@dinsdale.python.org>
References: <20000703124910.BA7931CE02@dinsdale.python.org>
Message-ID: <14688.39204.907438.798445@cj42289-a.reston1.va.home.com>

root@theporch.com writes:
 > When compiling and testing the current cvs version of python (7/3/00), I
 > received a failure in test_pty. I ran ./python Lib/test/test_pty.py and it

Phillip,
  Thanks for reporting this!  I've fixed it in CVS; please let us know
if you see any further problems with this.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Mon Jul  3 14:45:40 2000
From: fdrake@beopen.com (fdrake@beopen.com)
Date: Mon,  3 Jul 2000 09:45:40 -0400 (EDT)
Subject: [Python-bugs-list] pty.re bug in cvs version  (7/3/00) (PR#379)
Message-ID: <20000703134540.34DB11CFD2@dinsdale.python.org>

root@theporch.com writes:
 > When compiling and testing the current cvs version of python (7/3/00), I
 > received a failure in test_pty. I ran ./python Lib/test/test_pty.py and it

Phillip,
  Thanks for reporting this!  I've fixed it in CVS; please let us know
if you see any further problems with this.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member





From 2jerry@writeme.com  Mon Jul  3 22:14:03 2000
From: 2jerry@writeme.com (2jerry@writeme.com)
Date: Mon,  3 Jul 2000 17:14:03 -0400 (EDT)
Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380)
Message-ID: <20000703211403.140771CF0E@dinsdale.python.org>

Full_Name: Jerome VACHER
Version: 1.5.2  (win32api build 129)
OS: pc win98
Submission from: ppp-55.dialup-166.worldonline.fr (212.83.166.55)


next to code:
full_path_lst = map(os.path.abspath, sys.path)

according to that sys.path include the source directory at the first place of
sys.path.

I noticed that if I call the module in its own directory (python -i module.py)
 the first item of sys.path is ''.
That all ok: abspath function in os module call getcwd() function if path is
Null.
... 
good day for UNIX like men (as me :))
...
but in NT or WIN 98 workstation:
os.path.abspath call :win32api.GetFullPathName(path)  in ntpath module 
and 
win32api.GetFullPathName('')   return '' and not current directory.

Maybe is it a functionality .. but is os-depend functionality available for a
longtime ?

Jerome.vacher alias Jerry the foolish dracomorpheus.






From naris@ensim.com  Tue Jul  4 02:29:26 2000
From: naris@ensim.com (naris@ensim.com)
Date: Mon,  3 Jul 2000 21:29:26 -0400 (EDT)
Subject: [Python-bugs-list] memory bloat in binary file upload (PR#381)
Message-ID: <20000704012926.6DBE11CFB3@dinsdale.python.org>

Full_Name: Naris Siamwalla
Version: 1.5.2
OS: RedHat 6.1
Submission from: (NULL) (64.13.83.163)


read_lines_to_outerboundary chews up memory.
there's a while (1) loop that does a readline(), which
is probably not good, as you could have a binary file that
doesn't have an endline til the end, and thus readline would
read the entire file into memory.  i did the following:
dd'd a 100MB /dev/zero file and used zope to upload it.
it chewed up a large amount of memory.

there seems to be bug reports about text files and windows
systems (and needing to use python -u), but this problem
is unrelated.  i am using a unix browser -> unix web server.




From chriss@dnastar.com  Tue Jul  4 02:32:57 2000
From: chriss@dnastar.com (chriss@dnastar.com)
Date: Mon,  3 Jul 2000 21:32:57 -0400 (EDT)
Subject: [Python-bugs-list] <limits.h> (PR#382)
Message-ID: <20000704013257.EF2921CFB3@dinsdale.python.org>

#include <limits.h>
#endif

Full_Name: Christopher Stern
Version: 1.6a
OS: MacOS
Submission from: chris-mac.dnastar.com (198.150.22.77)


Several source files have recently begun unsin macros from <limits.h> without
including <limits.h>

#ifdef HAVE_LIMITS_H
#include <limits.h>
#endif

Some files have now been fixed (e.g. myreadline) but 
  selectmodule.c
  socketmodule.c 
still need the include added.




From mhammond@skippinet.com.au  Tue Jul  4 07:19:30 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Tue, 4 Jul 2000 16:19:30 +1000
Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380)
In-Reply-To: <20000703211403.140771CF0E@dinsdale.python.org>
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEIMCPAA.mhammond@skippinet.com.au>

Can anyone else here confirm that:

a) os.abspath('') on Linux does indeed return the CWD.
b) It is supposed to :-)

If confirmed, this would be a bug in ntpath.py.  It catches win32api
exceptions, and returns the input name in that case.  This would be
triggered by:

>>> win32api.GetFullPathName('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
pywintypes.api_error: (127, 'GetFullPathName', 'The specified procedure
could not be found.')

Is this indeed something we should fix?

Mark.

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> 2jerry@writeme.com
> Sent: Tuesday, 4 July 2000 7:14 AM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] win32api.GetFullPathName (build 129)
> (PR#380)
>
>
> Full_Name: Jerome VACHER
> Version: 1.5.2  (win32api build 129)
> OS: pc win98
> Submission from: ppp-55.dialup-166.worldonline.fr (212.83.166.55)
>
>
> next to code:
> full_path_lst = map(os.path.abspath, sys.path)
>
> according to that sys.path include the source directory at the
> first place of
> sys.path.
>
> I noticed that if I call the module in its own directory (python
> -i module.py)
>  the first item of sys.path is ''.
> That all ok: abspath function in os module call getcwd()
> function if path is
> Null.
> ...
> good day for UNIX like men (as me :))
> ...
> but in NT or WIN 98 workstation:
> os.path.abspath call :win32api.GetFullPathName(path)  in ntpath module
> and
> win32api.GetFullPathName('')   return '' and not current directory.
>
> Maybe is it a functionality .. but is os-depend functionality
> available for a
> longtime ?
>
> Jerome.vacher alias Jerry the foolish dracomorpheus.
>
>
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list



From mhammond@skippinet.com.au  Tue Jul  4 07:20:39 2000
From: mhammond@skippinet.com.au (mhammond@skippinet.com.au)
Date: Tue,  4 Jul 2000 02:20:39 -0400 (EDT)
Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380)
Message-ID: <20000704062039.CFAC01CD67@dinsdale.python.org>

Can anyone else here confirm that:

a) os.abspath('') on Linux does indeed return the CWD.
b) It is supposed to :-)

If confirmed, this would be a bug in ntpath.py.  It catches win32api
exceptions, and returns the input name in that case.  This would be
triggered by:

>>> win32api.GetFullPathName('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
pywintypes.api_error: (127, 'GetFullPathName', 'The specified procedure
could not be found.')

Is this indeed something we should fix?

Mark.

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> 2jerry@writeme.com
> Sent: Tuesday, 4 July 2000 7:14 AM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] win32api.GetFullPathName (build 129)
> (PR#380)
>
>
> Full_Name: Jerome VACHER
> Version: 1.5.2  (win32api build 129)
> OS: pc win98
> Submission from: ppp-55.dialup-166.worldonline.fr (212.83.166.55)
>
>
> next to code:
> full_path_lst = map(os.path.abspath, sys.path)
>
> according to that sys.path include the source directory at the
> first place of
> sys.path.
>
> I noticed that if I call the module in its own directory (python
> -i module.py)
>  the first item of sys.path is ''.
> That all ok: abspath function in os module call getcwd()
> function if path is
> Null.
> ...
> good day for UNIX like men (as me :))
> ...
> but in NT or WIN 98 workstation:
> os.path.abspath call :win32api.GetFullPathName(path)  in ntpath module
> and
> win32api.GetFullPathName('')   return '' and not current directory.
>
> Maybe is it a functionality .. but is os-depend functionality
> available for a
> longtime ?
>
> Jerome.vacher alias Jerry the foolish dracomorpheus.
>
>
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list





From gregor@hoffleit.de  Tue Jul  4 17:07:09 2000
From: gregor@hoffleit.de (gregor@hoffleit.de)
Date: Tue,  4 Jul 2000 12:07:09 -0400 (EDT)
Subject: [Python-bugs-list] Pth: test_fork1 fails, test_thread slow (PR#383)
Message-ID: <20000704160709.6A7DE1D0A9@dinsdale.python.org>

Full_Name: Gregor Hoffleit
Version: CVS version (06/04/00)
OS: Debian potato (i386)
Submission from: (NULL) (194.123.185.76)


When I use the current CVS version of Python to build on a Debian potato
system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see
below),
and test_thread takes significantly longer to complete than when I build the 
same sources with native LinuxThreads.


When running test.regrtest.main(), this happens:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import regrtest
  >>> regrtest.main()
  test_grammar
  test_opcodes
...
  test_extcall
  test_fcntl
  test_fork1
  test test_fork1 crashed -- exceptions.AssertionError : 
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 32, in f    time.sleep(SHORTSLEEP)
  TypeError: illegal argument type for built-in operation
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  test_format
  test_gc
...


When running test.test_fork1(), I get this:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import test_fork1
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "./Lib/test/test_fork1.py", line 68, in ?
      main()
    File "./Lib/test/test_fork1.py", line 44, in main
      assert a == range(NUM_THREADS)
  AssertionError
  >>>


test_thread takes very long to complete (5 min compared to 40 sec with 
LinuxThreads); when you look at the following log, you'll see that it tends
to calls the threads serially !?

clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
task 1 will run for 2.1 sec
task 1 done
creating task 4
task 2 will run for 3.2 sec
creating task 5
task 2 done
creating task task 3 will run for 9.1 6
sec
task 3 done
creating task 7
task 4 will run for 2.5 sec
task 4 done
creating task 8
task 5 will run for 0.9 sec
task 5 done
creating task 9
task 6 will run for 7.4 sec
task 6 done
creating task 10
waiting for all tasks to complete
task 7 will run for 5.3 sec
task 7 done
task 8 will run for 2.6 sec
task 8 done
task 9 will run for 2.7 sec
task 9 done
task 10 will run for 0.9 sec
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 0 entering barrier 0
task 1 will run for 6.2 sec
task 1 entering barrier 0
task 7 will run for 7.0 sec
task 7 entering barrier 0
task 3 will run for 5.9 sec
task 3 entering barrier 0
task 4 will run for 4.5 sec
task 4 entering barrier 0
task 5 will run for 9.2 sec
task 5 entering barrier 0
task 6 will run for 1.4 sec
task 6 entering barrier 0
task 2 will run for 6.0 sec
task 2 entering barrier 0
task 8 will run for 2.4 sec
task 8 entering barrier 0
task 9 will run for 9.6 sec
task 9 entering barrier 0
task 9 leaving barrier 0
task 0 leaving barrier 0
task task 1 leaving barrier 0
0 will run for 0.0 sec
task 0 entering barrier 1
task 7 leaving barrier 0
task 9 will run for 0.8 sec
task 9 entering barrier task 3 leaving barrier 0
1
task 1 task 4 leaving barrier 0
will run for 6.1 sec
task 5 leaving barrier 0
task 1 entering barrier 1
task 6 leaving barrier 0
task 7 will run for 7.9 sec
task 2 leaving barrier 0
task 7 entering barrier 1
task 3 task 8 leaving barrier 0
will run for 7.8 sec
task 3 entering barrier 1
task 4 will run for 5.7 sec
task 4 entering barrier 1
task 5 will run for 2.0 sec
task 5 entering barrier 1
task 6 will run for 0.5 sec
task 6 entering barrier 1
task 2 will run for 7.4 sec
task 2 entering barrier 1
task 8 will run for 1.0 sec
task 8 entering barrier 1
task 8 leaving barrier 1
task 7 leaving barrier 1
task 9 leaving barrier 1
task 1 leaving barrier 1
task 8 will run for 6.9 sec
task 0 leaving barrier 1
task 8 entering barrier 2
task 0 will run for task 4 leaving barrier 1 0.0 sec

task 7 will run for 4.3 sec task 0 entering barrier
2
task 3 leaving barrier 1
task 7 entering barrier 2
task 5 leaving barrier 1
task 6 leaving barrier 1 task 9 will run for
8.2 sec
task task 2 leaving barrier 9 entering barrier 2
1
task 5 will run for 8.9 sec
task 5 entering barrier 2
task 2 will run for 8.3 sec
task 2 entering barrier 2
task 3 will run for 4.5 sec
task 3 entering barrier 2
task 1 will run for 7.0 sec
task 1 entering barrier 2
task 6 will run for 1.9 sec
task 6 entering barrier 2
task 4 will run for 0.2 sec
task 4 entering barrier 2
task 4 leaving barrier 2
task 8 leaving barrier 2
task 9 leaving barrier 2
task 7 leaving barrier 2
task 5 leaving barrier 2
task 0 leaving barrier 2
task 2 leaving barrier 2
task 3 leaving barrier 2
task 1 leaving barrier 2
task 6 leaving barrier 2
all tasks done



while this is the log of the same test with Python 1.5.2 and LinuxThreads:

clapton:3> python
Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for all tasks to complete
task 1 will run for 8.9 sec
task 2 will run for 8.3 sec
task 3 will run for 9.1 sec
task 5 will run for 6.0 sec
task 4 will run for 7.5 sec
task 6 will run for 4.7 sec
task 7 will run for 4.2 sec
task 8 will run for 7.0 sec
task 9 will run for 8.7 sec
task 10 will run for 9.5 sec
task 7 done
task 6 done
task 5 done
task 8 done
task 4 done
task 2 done
task 9 done
task 1 done
task 3 done
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 1 will run for 2.8 sec
task 0 entering barrier 0
task 2 will run for 5.3 sec
task 3 will run for 9.2 sec
task 5 will run for 8.0 sec
task 4 will run for 8.9 sec
task 6 will run for 5.0 sec
task 7 will run for 1.3 sec
task 8 will run for 5.6 sec
task 9 will run for 4.7 sec
task 7 entering barrier 0
task 1 entering barrier 0
task 9 entering barrier 0
task 6 entering barrier 0
task 2 entering barrier 0
task 8 entering barrier 0
task 5 entering barrier 0
task 4 entering barrier 0
task 3 entering barrier 0
task 3 leaving barrier 0
task 3 will run for 0.1 sec
task 0 leaving barrier 0
task 0 will run for 0.0 sec
task 7 leaving barrier 0
task 7 will run for 6.6 sec
task 1 leaving barrier 0
task 1 will run for 1.0 sec
task 9 leaving barrier 0
task 9 will run for 8.2 sec
task 6 leaving barrier 0
task 6 will run for 1.0 sec
task 2 leaving barrier 0
task 2 will run for 9.2 sec
task 8 leaving barrier 0
task 8 will run for 4.4 sec
task 5 leaving barrier 0
task 5 will run for 9.6 sec
task 4 leaving barrier 0
task 4 will run for 1.7 sec
task 0 entering barrier 1
task 3 entering barrier 1
task 1 entering barrier 1
task 6 entering barrier 1
task 4 entering barrier 1
task 8 entering barrier 1
task 7 entering barrier 1
task 9 entering barrier 1
task 2 entering barrier 1
task 5 entering barrier 1
task 5 leaving barrier 1
task 5 will run for 6.6 sec
task 0 leaving barrier 1
task 0 will run for 0.0 sec
task 3 leaving barrier 1
task 3 will run for 8.5 sec
task 1 leaving barrier 1
task 1 will run for 0.1 sec
task 6 leaving barrier 1
task 6 will run for 4.7 sec
task 4 leaving barrier 1
task 4 will run for 4.7 sec
task 8 leaving barrier 1
task 8 will run for 1.7 sec
task 7 leaving barrier 1
task 7 will run for 1.8 sec
task 9 leaving barrier 1
task 9 will run for 2.8 sec
task 2 leaving barrier 1
task 2 will run for 3.3 sec
task 0 entering barrier 2
task 1 entering barrier 2
task 8 entering barrier 2
task 7 entering barrier 2
task 9 entering barrier 2
task 2 entering barrier 2
task 6 entering barrier 2
task 4 entering barrier 2
task 5 entering barrier 2
task 3 entering barrier 2
task 3 leaving barrier 2
task 0 leaving barrier 2
task 1 leaving barrier 2
task 8 leaving barrier 2
task 7 leaving barrier 2
task 9 leaving barrier 2
task 2 leaving barrier 2
task 6 leaving barrier 2
task 4 leaving barrier 2
task 5 leaving barrier 2
all tasks done
>>> 






From fdrake@beopen.com  Tue Jul  4 18:34:24 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 4 Jul 2000 13:34:24 -0400 (EDT)
Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEIMCPAA.mhammond@skippinet.com.au>
References: <20000703211403.140771CF0E@dinsdale.python.org>
 <ECEPKNMJLHAPFFJHDOJBOEIMCPAA.mhammond@skippinet.com.au>
Message-ID: <14690.8224.975440.341303@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > Can anyone else here confirm that:
 > 
 > a) os.abspath('') on Linux does indeed return the CWD.

  Yes, that's right.

 > b) It is supposed to :-)

  I think that's the right thing to do.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Tue Jul  4 18:34:04 2000
From: fdrake@beopen.com (fdrake@beopen.com)
Date: Tue,  4 Jul 2000 13:34:04 -0400 (EDT)
Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380)
Message-ID: <20000704173404.7BBEB1D0BD@dinsdale.python.org>

Mark Hammond writes:
 > Can anyone else here confirm that:
 > 
 > a) os.abspath('') on Linux does indeed return the CWD.

  Yes, that's right.

 > b) It is supposed to :-)

  I think that's the right thing to do.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member





From billtut@microsoft.com  Tue Jul  4 21:07:30 2000
From: billtut@microsoft.com (billtut@microsoft.com)
Date: Tue,  4 Jul 2000 16:07:30 -0400 (EDT)
Subject: [Python-bugs-list] \ud800 crashes interpreter (PR#384)
Message-ID: <20000704200730.617431D0CE@dinsdale.python.org>

Full_Name: Bill Tutt
Version: CVS
OS: NT
Submission from: tide70.microsoft.com (131.107.3.70)


u'\ud800' causes the interpreter to crash
example:
print u'\ud800'
What happens:
The code failes to compile because while adding the constant, the unicode_hash
function is called which for some reason requires the UTF-8 string format.

The conversion to UTF-8 fails (completly bogus), the compiler only notes that
compilation failed, and cleared the stored exception info.

When compilatino finishes it remembered that it failed, and returns.
The interpreter then proceeds to crash in PyErr_NormalizeException() because the
UTF-8 conversion exception info isn't there anymore.

Suggested fix:
Changing the UTF-8 conversion code to emit 4 bytes for surrogate characters.







From aron@gweep.net  Wed Jul  5 00:07:56 2000
From: aron@gweep.net (aron@gweep.net)
Date: Tue,  4 Jul 2000 19:07:56 -0400 (EDT)
Subject: [Python-bugs-list] fd.readlines() hangs (via popen3) (PR#385)
Message-ID: <20000704230756.6CC0A1CD19@dinsdale.python.org>

Full_Name: Aron Atkins
Version: 1.5.2
OS: Red Hat Linux 6.1 (2.1.12-20)
Submission from: h0048546291af.ne.mediaone.net (24.147.211.161)


The following scripts cause a hang at the denoted line. To execute
this code, copy the first bit to master.py and the second to slave.py
(both should be in the same directory). Then, "cd" to that directory
and "python master.py".

Manually killing the program is necessary.

This script has also been tested on a Solaris 5.7 box and worked.

---master.py---
import popen2

r,w,e = popen2.popen3 ( 'python slave.py' )
r.readlines() # Hangs here
e.readlines()
r.close()
e.close()
w.close()

---end---

---slave.py---
import sys

e = sys.stderr.write
w = sys.stdout.write

e(400*'this is a test\n')
w(400*'this is another test\n')
---end---




From 2jerry@writeme.com  Wed Jul  5 10:58:04 2000
From: 2jerry@writeme.com (2jerry@writeme.com)
Date: Wed,  5 Jul 2000 05:58:04 -0400 (EDT)
Subject: [Python-bugs-list] popen2.popen3 and win32pipe.popen3 has unconsistancy interface. (PR#386)
Message-ID: <20000705095804.4A3EE1CE26@dinsdale.python.org>

Full_Name: Jerome.vacher
Version: 1.5.2 (build 129)
OS: Sun, SGI, NT, Win98
Submission from: thotsc10.thomson-csf.fr (195.101.37.183)


Hello,
this is my second bug submission in 2 days and my second bug submission in my
life :)
Is it a bug ? 
Where is the bug ?

posix     : popen2.popen3(output, input, error)
win32pipe : win32pipe.popen3(input, output, error)

Need an ntpopen.py module as ntpath.py do ? oh cool idea for the dude who does
it.
I used next code to continue using popen3 in that situation but what a shame to
do so.

[...]
def CC_popen3(commande, mode):
  global nb                                   # forget this .. this is just to
  if V: print __module__+": IN CC_popen3",nb  # capture number of open pipe 
  nb = nb + 1                                 # seem to hang popen2.popen3
after
                                              # about 170 calls.
                                              # (no further expert so forget)
  if sys.platform == "win32":
    from win32pipe import popen3
    (i,o,e) = popen3(commande, mode)
    return (i,o,e)
  elif os.name == "posix":
    from popen2 import popen3
    (o,i,e) = popen3(commande, mode)
    return (i,o,e)
  else:
    raise CC_env_error, "env: CC_popen3 : ERROR : Unsupported Operating System"
[...]

QUESTION / DISCUSSION:
 what is the best way ? (i,o,e) or (o,i,e) ? i choose (i,o,e) cause this is a
reading behaviour and is more comprehensive. I know that choose is subjective.
 So what need the futur to be ?
 Tel me that convergence is THE way. never mind about the order ;-)

Jerome.vacher 
jerome.vacher@tts.thomson-csf.com / jvacher@on-x.com
Alias Jerry 'the foolish dracomorpheus'.




From markus.oberhumer@jk.uni-linz.ac.at  Wed Jul  5 14:28:54 2000
From: markus.oberhumer@jk.uni-linz.ac.at (markus.oberhumer@jk.uni-linz.ac.at)
Date: Wed,  5 Jul 2000 09:28:54 -0400 (EDT)
Subject: [Python-bugs-list] PRIVATE: minor SRE regex incompatibility (PR#387)
Message-ID: <20000705132854.DCFC01CD3E@dinsdale.python.org>

Full_Name: Markus F.X.J. Oberhumer
Version: python CVS
OS: all
Submission from: n456p017.adsl.highway.telekom.at (62.47.0.241)


In python 1.5.2 re.py had a default parameter "count=0" for
RegexpObject.sub(...). 
This is incosistent with the current sre implementation which epects 3
arguments.
Ditto for subn.




From markus.oberhumer@jk.uni-linz.ac.at  Wed Jul  5 14:38:12 2000
From: markus.oberhumer@jk.uni-linz.ac.at (markus.oberhumer@jk.uni-linz.ac.at)
Date: Wed,  5 Jul 2000 09:38:12 -0400 (EDT)
Subject: [Python-bugs-list] PRIVATE: various minor Tkinter things (PR#388)
Message-ID: <20000705133812.76FC11CD1B@dinsdale.python.org>

Full_Name: Markus F.X.J. Oberhumer
Version: python CVS
OS: all
Submission from: n456p017.adsl.highway.telekom.at (62.47.0.241)


Tkinter.Wm.wm_state() lacks a missing "newstate=None" optional parameter.

Tkinter.Text lacks some important methods: [xy]view_moveto, [xy]view_scroll

Canvas.CanvasItem & Canvas.Group:
  - bind lacks an optional "add" param
  - unbind lacks an optional "funcid" param
  - tkraise/lower should call self.canvas.tag_XXXX
  - bbox() return value is inconsistent with Canvas.bbox()




From calvin@users.sourceforge.net  Wed Jul  5 15:46:19 2000
From: calvin@users.sourceforge.net (calvin@users.sourceforge.net)
Date: Wed,  5 Jul 2000 10:46:19 -0400 (EDT)
Subject: [Python-bugs-list] compile error in fileobject.c: getline redefined (PR#389)
Message-ID: <20000705144619.54D191CF26@dinsdale.python.org>

Full_Name: Bastian Kleineidam
Version: 2.0b1 CVS 5.7.2000
OS: Debian Linux 2.2
Submission from: earth.cs.uni-sb.de (134.96.252.92)


getline definition on Linux conflicts with the one in fileobject.c:

compile log snippet
================================================================
gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H   -c -o fileobject.o
fileobject.c
fileobject.c:587: conflicting types for `getline'
/usr/include/bits/stdio.h:102: previous declaration of `getline'
make[1]: *** [fileobject.o] Error 1
make[1]: Leaving directory `/usr/local/src/python/dist/src/Objects'
make: *** [Objects] Error 2
================================================================

bits/stdio.h snippet:
================================================================
# ifdef __USE_GNU
/* Like `getdelim', but reads up to a newline.  */
__STDIO_INLINE _IO_ssize_t
getline (char **__lineptr, size_t *__n, FILE *__stream) __THROW
{
  return __getdelim (__lineptr, __n, '\n', __stream);
}
# endif /* GNU */
================================================================

Setup.local:
================================================================
readline readline.c -lreadline -ltermcap
crypt cryptmodule.c # -lcrypt   # crypt(3); needs -lcrypt on some systems
nis nismodule.c -lnsl   # Sun yellow pages -- not everywhere
termios termios.c       # Steen Lumholt's termios module
resource resource.c     # Jeremy Hylton's rlimit interface
audioop audioop.c       # Operations on audio samples
imageop imageop.c       # Operations on images
SSL=/usr
socket socketmodule.c \
        -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
        -L$(SSL)/lib -lssl -lcrypto
GMP=/usr
mpz mpzmodule.c -I$(GMP)/include -L$(GMP)/lib -lgmp
linuxaudiodev linuxaudiodev.c
timing timingmodule.c
syslog syslogmodule.c           # syslog daemon interface
_curses _cursesmodule.c -lncurses -ltermcap
gdbm gdbmmodule.c -lgdbm
#bsddb bsddbmodule.c -ldb
zlib zlibmodule.c -lz
================================================================

System:
================================================================
Debian 2.2 'potato'
Kernel 2.2.17pre6
GNU C Library 2.1.3
================================================================





From mal@lemburg.com  Wed Jul  5 16:09:52 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 05 Jul 2000 17:09:52 +0200
Subject: [Python-bugs-list] compile error in fileobject.c: getline redefined
 (PR#389)
References: <20000705144619.54D191CF26@dinsdale.python.org>
Message-ID: <39634FC0.FCED86C3@lemburg.com>

calvin@users.sourceforge.net wrote:
> 
> Full_Name: Bastian Kleineidam
> Version: 2.0b1 CVS 5.7.2000
> OS: Debian Linux 2.2
> Submission from: earth.cs.uni-sb.de (134.96.252.92)
> 
> getline definition on Linux conflicts with the one in fileobject.c:
> 
> compile log snippet
> ================================================================
> gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H   -c -o fileobject.o
> fileobject.c
> fileobject.c:587: conflicting types for `getline'
> /usr/include/bits/stdio.h:102: previous declaration of `getline'
> make[1]: *** [fileobject.o] Error 1
> make[1]: Leaving directory `/usr/local/src/python/dist/src/Objects'
> make: *** [Objects] Error 2
> ================================================================
> 
> bits/stdio.h snippet:
> ================================================================
> # ifdef __USE_GNU
> /* Like `getdelim', but reads up to a newline.  */
> __STDIO_INLINE _IO_ssize_t
> getline (char **__lineptr, size_t *__n, FILE *__stream) __THROW
> {
>   return __getdelim (__lineptr, __n, '\n', __stream);
> }
> # endif /* GNU */
> ================================================================


Looks like this was introduced by the new #define _GNU_SOURCE
in Python.h.

I'll fix the function name -- it's much too generic anyway.
 
> Setup.local:
> ================================================================
> readline readline.c -lreadline -ltermcap
> crypt cryptmodule.c # -lcrypt   # crypt(3); needs -lcrypt on some systems
> nis nismodule.c -lnsl   # Sun yellow pages -- not everywhere
> termios termios.c       # Steen Lumholt's termios module
> resource resource.c     # Jeremy Hylton's rlimit interface
> audioop audioop.c       # Operations on audio samples
> imageop imageop.c       # Operations on images
> SSL=/usr
> socket socketmodule.c \
>         -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
>         -L$(SSL)/lib -lssl -lcrypto
> GMP=/usr
> mpz mpzmodule.c -I$(GMP)/include -L$(GMP)/lib -lgmp
> linuxaudiodev linuxaudiodev.c
> timing timingmodule.c
> syslog syslogmodule.c           # syslog daemon interface
> _curses _cursesmodule.c -lncurses -ltermcap
> gdbm gdbmmodule.c -lgdbm
> #bsddb bsddbmodule.c -ldb
> zlib zlibmodule.c -lz
> ================================================================
> 
> System:
> ================================================================
> Debian 2.2 'potato'
> Kernel 2.2.17pre6
> GNU C Library 2.1.3
> ================================================================
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Wed Jul  5 16:10:44 2000
From: mal@lemburg.com (mal@lemburg.com)
Date: Wed,  5 Jul 2000 11:10:44 -0400 (EDT)
Subject: [Python-bugs-list] compile error in fileobject.c: getline redefined (PR#390)
Message-ID: <20000705151044.D8A691CD6D@dinsdale.python.org>

calvin@users.sourceforge.net wrote:
> 
> Full_Name: Bastian Kleineidam
> Version: 2.0b1 CVS 5.7.2000
> OS: Debian Linux 2.2
> Submission from: earth.cs.uni-sb.de (134.96.252.92)
> 
> getline definition on Linux conflicts with the one in fileobject.c:
> 
> compile log snippet
> ================================================================
> gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H   -c -o fileobject.o
> fileobject.c
> fileobject.c:587: conflicting types for `getline'
> /usr/include/bits/stdio.h:102: previous declaration of `getline'
> make[1]: *** [fileobject.o] Error 1
> make[1]: Leaving directory `/usr/local/src/python/dist/src/Objects'
> make: *** [Objects] Error 2
> ================================================================
> 
> bits/stdio.h snippet:
> ================================================================
> # ifdef __USE_GNU
> /* Like `getdelim', but reads up to a newline.  */
> __STDIO_INLINE _IO_ssize_t
> getline (char **__lineptr, size_t *__n, FILE *__stream) __THROW
> {
>   return __getdelim (__lineptr, __n, '\n', __stream);
> }
> # endif /* GNU */
> ================================================================


Looks like this was introduced by the new #define _GNU_SOURCE
in Python.h.

I'll fix the function name -- it's much too generic anyway.
 
> Setup.local:
> ================================================================
> readline readline.c -lreadline -ltermcap
> crypt cryptmodule.c # -lcrypt   # crypt(3); needs -lcrypt on some systems
> nis nismodule.c -lnsl   # Sun yellow pages -- not everywhere
> termios termios.c       # Steen Lumholt's termios module
> resource resource.c     # Jeremy Hylton's rlimit interface
> audioop audioop.c       # Operations on audio samples
> imageop imageop.c       # Operations on images
> SSL=/usr
> socket socketmodule.c \
>         -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
>         -L$(SSL)/lib -lssl -lcrypto
> GMP=/usr
> mpz mpzmodule.c -I$(GMP)/include -L$(GMP)/lib -lgmp
> linuxaudiodev linuxaudiodev.c
> timing timingmodule.c
> syslog syslogmodule.c           # syslog daemon interface
> _curses _cursesmodule.c -lncurses -ltermcap
> gdbm gdbmmodule.c -lgdbm
> #bsddb bsddbmodule.c -ldb
> zlib zlibmodule.c -lz
> ================================================================
> 
> System:
> ================================================================
> Debian 2.2 'potato'
> Kernel 2.2.17pre6
> GNU C Library 2.1.3
> ================================================================
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From a4men@mediaone.net  Thu Jul  6 03:54:32 2000
From: a4men@mediaone.net (a4men@mediaone.net)
Date: Wed,  5 Jul 2000 22:54:32 -0400 (EDT)
Subject: [Python-bugs-list] "g" force research (PR#391)
Message-ID: <20000706025432.786C31CF2E@dinsdale.python.org>

--=200007052225=
Content-Type: text/plain;charset=US-ASCII

I am researching a history of "g forces" and their physiological effect on humans.

Because of your position, it might be good exposure and publicity for you and your organization, if you would like to help me with information.  I would credit you for any specific information used, of course, and I would be glad to include a specific mention or personal reference for your interest.

My focus is man confronting increasingly higher "g forces" from  1900 to 2000, in areas including an everyday "normal" environment up to one of high performance aerospace maneuvers.



My research is looking for the answers to these questions:

	What are the effects at each stage of -3 to +11 "g's" on the human body?

	What is the range of "g's" that can be encountered in an automobile, 
		a bungee jump, a roller coaster, an airplane and aerospace launches?

	What are the specific "g's" and the specific maneuvers which cause them above the 			normal environment and 	what are the procedures used to cope with them?



Any type of information that would help me "fill in any of the spaces" with relevant details 
would really be appreciated...a specific maneuver - a turn, angle, rise/fall, acceleration or 
speed resulting in a discrete g force in your environment, what it does to the body and 
whatever relevant info you want to include about it.  


The finished product may have some value in promotion or marketing for you as well, and if you let me know I would be glad to keep you informed upon completion.

Also any sources you may know of would be of tremendous help.


Thank you very much

Andy Foreman
a4men@mediaone.net


--=200007052225=--





From jon@dstc.edu.au  Thu Jul  6 05:32:47 2000
From: jon@dstc.edu.au (jon@dstc.edu.au)
Date: Thu,  6 Jul 2000 00:32:47 -0400 (EDT)
Subject: [Python-bugs-list] PyOS_AfterFork (PR#392)
Message-ID: <20000706043247.B11F61CF1C@dinsdale.python.org>

Full_Name: Jonathan Giddy
Version: 1.5.2 - 2.0b1
OS: Solaris and Linux
Submission from: duck.its.monash.edu.au (130.194.11.183)


In posixmodule.c:posix_fork, the function PyOS_AfterFork is called for
both the parent and the child, despite the docs stating that it should
be called in the new (child) process.

This causes problems in the parent since the forking thread becomes the 
main thread according to the signal module.

e.g. the following program fails with the frustrating message:
"ValueError: signal only works in main thread"

import os, signal, threading

def foo():
    pid = os.fork()
    if pid:
        os.wait(pid, 0)
    else:
        os._exit(0)

def handler(signo, frame):
    pass

def main():
    t = threading.Thread(target=foo)
    t.start()
    t.join()  # optional
    signal.signal(signal.SIGTERM, handler)

main()





From fdrake@beopen.com  Thu Jul  6 06:44:12 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 6 Jul 2000 01:44:12 -0400 (EDT)
Subject: [Python-bugs-list] PyOS_AfterFork (PR#392)
In-Reply-To: <20000706043247.B11F61CF1C@dinsdale.python.org>
References: <20000706043247.B11F61CF1C@dinsdale.python.org>
Message-ID: <14692.7340.246227.140997@cj42289-a.reston1.va.home.com>

jon@dstc.edu.au writes:
 > In posixmodule.c:posix_fork, the function PyOS_AfterFork is called for
 > both the parent and the child, despite the docs stating that it should
 > be called in the new (child) process.
 > 
 > This causes problems in the parent since the forking thread becomes the 
 > main thread according to the signal module.
 > 
 > e.g. the following program fails with the frustrating message:
 > "ValueError: signal only works in main thread"

  After making the appropriate change in posixmodule.c, I get:


Exception in thread Thread-1:
Traceback (most recent call last):
  File "./../Lib/threading.py", line 376, in __bootstrap
    self.run()
  File "./../Lib/threading.py", line 364, in run
    apply(self.__target, self.__args, self.__kwargs)
  File "fork-signal.py", line 6, in foo
    os.wait(pid, 0)
TypeError: wait requires exactly 0 arguments; 2 given


  You're still right about the bug in posix_fork(), I think.  I'll
check in the fix (patch below) once someone else confirms this.
  Thanks for reporting this!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member

Index: Modules/posixmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v
retrieving revision 2.141
diff -c -r2.141 posixmodule.c
*** Modules/posixmodule.c	2000/06/30 23:58:05	2.141
--- Modules/posixmodule.c	2000/07/06 05:43:33
***************
*** 1755,1761 ****
  	pid = fork();
  	if (pid == -1)
  		return posix_error();
! 	PyOS_AfterFork();
  	return PyInt_FromLong((long)pid);
  }
  #endif
--- 1755,1762 ----
  	pid = fork();
  	if (pid == -1)
  		return posix_error();
! 	if (pid == 0)
! 		PyOS_AfterFork();
  	return PyInt_FromLong((long)pid);
  }
  #endif



From fdrake@beopen.com  Thu Jul  6 06:43:53 2000
From: fdrake@beopen.com (fdrake@beopen.com)
Date: Thu,  6 Jul 2000 01:43:53 -0400 (EDT)
Subject: [Python-bugs-list] PyOS_AfterFork (PR#392)
Message-ID: <20000706054353.007E71CED7@dinsdale.python.org>

jon@dstc.edu.au writes:
 > In posixmodule.c:posix_fork, the function PyOS_AfterFork is called for
 > both the parent and the child, despite the docs stating that it should
 > be called in the new (child) process.
 > 
 > This causes problems in the parent since the forking thread becomes the 
 > main thread according to the signal module.
 > 
 > e.g. the following program fails with the frustrating message:
 > "ValueError: signal only works in main thread"

  After making the appropriate change in posixmodule.c, I get:


Exception in thread Thread-1:
Traceback (most recent call last):
  File "./../Lib/threading.py", line 376, in __bootstrap
    self.run()
  File "./../Lib/threading.py", line 364, in run
    apply(self.__target, self.__args, self.__kwargs)
  File "fork-signal.py", line 6, in foo
    os.wait(pid, 0)
TypeError: wait requires exactly 0 arguments; 2 given


  You're still right about the bug in posix_fork(), I think.  I'll
check in the fix (patch below) once someone else confirms this.
  Thanks for reporting this!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member

Index: Modules/posixmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v
retrieving revision 2.141
diff -c -r2.141 posixmodule.c
*** Modules/posixmodule.c	2000/06/30 23:58:05	2.141
--- Modules/posixmodule.c	2000/07/06 05:43:33
***************
*** 1755,1761 ****
  	pid = fork();
  	if (pid == -1)
  		return posix_error();
! 	PyOS_AfterFork();
  	return PyInt_FromLong((long)pid);
  }
  #endif
--- 1755,1762 ----
  	pid = fork();
  	if (pid == -1)
  		return posix_error();
! 	if (pid == 0)
! 		PyOS_AfterFork();
  	return PyInt_FromLong((long)pid);
  }
  #endif





From guido@beopen.com  Thu Jul  6 06:52:32 2000
From: guido@beopen.com (guido@beopen.com)
Date: Thu,  6 Jul 2000 01:52:32 -0400 (EDT)
Subject: [Python-bugs-list] PyOS_AfterFork (PR#392)
Message-ID: <20000706055232.0E7151CDA4@dinsdale.python.org>

> In posixmodule.c:posix_fork, the function PyOS_AfterFork is called for
> both the parent and the child, despite the docs stating that it should
> be called in the new (child) process.
> 
> This causes problems in the parent since the forking thread becomes the 
> main thread according to the signal module.
> 
> e.g. the following program fails with the frustrating message:
> "ValueError: signal only works in main thread"
> 
> import os, signal, threading
> 
> def foo():
>     pid = os.fork()
>     if pid:
>         os.wait(pid, 0)
>     else:
>         os._exit(0)
> 
> def handler(signo, frame):
>     pass
> 
> def main():
>     t = threading.Thread(target=foo)
>     t.start()
>     t.join()  # optional
>     signal.signal(signal.SIGTERM, handler)
> 
> main()

Yech!  You're right.  The code I wrote to call PyOS_AfterFork()
incorrectly assumed only the main thread would fork.

Fred: your fix is almost right -- there's a second call to
PyOS_AfterFork() in posixmodule.c (in forkpty()) that needs similar
treatment.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)




From fdrake@beopen.com  Thu Jul  6 07:02:33 2000
From: fdrake@beopen.com (fdrake@beopen.com)
Date: Thu,  6 Jul 2000 02:02:33 -0400 (EDT)
Subject: [Python-bugs-list] PyOS_AfterFork (PR#392)
Message-ID: <20000706060233.0726A1CEC2@dinsdale.python.org>

Guido van Rossum writes:
 > Fred: your fix is almost right -- there's a second call to
 > PyOS_AfterFork() in posixmodule.c (in forkpty()) that needs similar
 > treatment.

  Ok.  I'll check this in as soon as the test suite completes, and
clear the bug.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member





From guido@beopen.com  Thu Jul  6 16:44:27 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 06 Jul 2000 10:44:27 -0500
Subject: [Python-bugs-list] popen2.popen3 and win32pipe.popen3 has unconsistancy interface. (PR#386)
In-Reply-To: Your message of "Wed, 05 Jul 2000 05:58:04 -0400."
 <20000705095804.4A3EE1CE26@dinsdale.python.org>
References: <20000705095804.4A3EE1CE26@dinsdale.python.org>
Message-ID: <200007061544.KAA13515@cj20424-a.reston1.va.home.com>

> posix     : popen2.popen3(output, input, error)
> win32pipe : win32pipe.popen3(input, output, error)

[He's referring to the order of the output variables]

> Need an ntpopen.py module as ntpath.py do ? oh cool idea for the dude who does
> it.
> I used next code to continue using popen3 in that situation but what a shame to
> do so.
> 
> [...]
> def CC_popen3(commande, mode):
>   global nb                                   # forget this .. this is just to
>   if V: print __module__+": IN CC_popen3",nb  # capture number of open pipe 
>   nb = nb + 1                                 # seem to hang popen2.popen3
> after
>                                               # about 170 calls.
>                                               # (no further expert so forget)
>   if sys.platform == "win32":
>     from win32pipe import popen3
>     (i,o,e) = popen3(commande, mode)
>     return (i,o,e)
>   elif os.name == "posix":
>     from popen2 import popen3
>     (o,i,e) = popen3(commande, mode)
>     return (i,o,e)
>   else:
>     raise CC_env_error, "env: CC_popen3 : ERROR : Unsupported Operating System"
> [...]
> 
> QUESTION / DISCUSSION:
>  what is the best way ? (i,o,e) or (o,i,e) ? i choose (i,o,e) cause this is a
> reading behaviour and is more comprehensive. I know that choose is subjective.
>  So what need the futur to be ?
>  Tel me that convergence is THE way. never mind about the order ;-)

It's hard to fix either win32pipe or popen2, but it seems that (i,o,e)
is the proper order.  popen2 did it the other way historically,
probably because o was more important -- but that was a bad mistake
that we'll have to live with.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)


From guido@beopen.com  Thu Jul  6 15:44:20 2000
From: guido@beopen.com (guido@beopen.com)
Date: Thu,  6 Jul 2000 10:44:20 -0400 (EDT)
Subject: [Python-bugs-list] popen2.popen3 and win32pipe.popen3 has unconsistancy interface. (PR#386)
Message-ID: <20000706144420.799EF1CEFA@dinsdale.python.org>

> posix     : popen2.popen3(output, input, error)
> win32pipe : win32pipe.popen3(input, output, error)

[He's referring to the order of the output variables]

> Need an ntpopen.py module as ntpath.py do ? oh cool idea for the dude who does
> it.
> I used next code to continue using popen3 in that situation but what a shame to
> do so.
> 
> [...]
> def CC_popen3(commande, mode):
>   global nb                                   # forget this .. this is just to
>   if V: print __module__+": IN CC_popen3",nb  # capture number of open pipe 
>   nb = nb + 1                                 # seem to hang popen2.popen3
> after
>                                               # about 170 calls.
>                                               # (no further expert so forget)
>   if sys.platform == "win32":
>     from win32pipe import popen3
>     (i,o,e) = popen3(commande, mode)
>     return (i,o,e)
>   elif os.name == "posix":
>     from popen2 import popen3
>     (o,i,e) = popen3(commande, mode)
>     return (i,o,e)
>   else:
>     raise CC_env_error, "env: CC_popen3 : ERROR : Unsupported Operating System"
> [...]
> 
> QUESTION / DISCUSSION:
>  what is the best way ? (i,o,e) or (o,i,e) ? i choose (i,o,e) cause this is a
> reading behaviour and is more comprehensive. I know that choose is subjective.
>  So what need the futur to be ?
>  Tel me that convergence is THE way. never mind about the order ;-)

It's hard to fix either win32pipe or popen2, but it seems that (i,o,e)
is the proper order.  popen2 did it the other way historically,
probably because o was more important -- but that was a bad mistake
that we'll have to live with.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)




From lhudson@geminidataloggers.com  Fri Jul  7 10:59:20 2000
From: lhudson@geminidataloggers.com (lhudson@geminidataloggers.com)
Date: Fri,  7 Jul 2000 05:59:20 -0400 (EDT)
Subject: [Python-bugs-list] Empty unicode string as utf-16 (PR#393)
Message-ID: <20000707095920.C96F31CFF3@dinsdale.python.org>

Full_Name: Lawrence Hudson
Version: 1.6a2
OS: Win2k Professional
Submission from: mailhost.oriongroup.co.uk (194.200.199.161)


Encoding an empty unicode string as utf-16 produces some unusual results:

Python 1.6a2 (#0, Jun 30 2000, 16:33:35) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> a = u''
>>> a.encode('utf-16')
'\007\000'
>>> a.encode('utf-16')
'ut'
>>> a.encode('utf-16')
'ut'
>>> a.encode('utf-16')
'ut'
>>>
>>>
>>> a.encode('utf16')
'\007\000'
>>> a.encode('utf16')
'ut'
>>> a.encode('utf16')
'ut'
>>>
>>>
>>> a.encode('utf-16-le')
''
>>> a.encode('utf-16-le')
''
>>>
>>>
>>> a.encode('utf-16-be')
''
>>> a.encode('utf-16-be')
''
>>>
>>>




From mal@lemburg.com  Fri Jul  7 11:51:43 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 07 Jul 2000 12:51:43 +0200
Subject: [Python-bugs-list] Empty unicode string as utf-16 (PR#393)
References: <20000707095920.C96F31CFF3@dinsdale.python.org>
Message-ID: <3965B63F.948B3EAF@lemburg.com>

lhudson@geminidataloggers.com wrote:
> 
> Full_Name: Lawrence Hudson
> Version: 1.6a2
> OS: Win2k Professional
> Submission from: mailhost.oriongroup.co.uk (194.200.199.161)
> 
> Encoding an empty unicode string as utf-16 produces some unusual results:
> 
> Python 1.6a2 (#0, Jun 30 2000, 16:33:35) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> a = u''
> >>> a.encode('utf-16')
> '\007\000'
> >>> a.encode('utf-16')
> 'ut'
> >>> a.encode('utf-16')
> 'ut'
> >>> a.encode('utf-16')
> 'ut'
> >>>
> >>>
> >>> a.encode('utf16')
> '\007\000'
> >>> a.encode('utf16')
> 'ut'
> >>> a.encode('utf16')
> 'ut'
> >>>
> >>>
> >>> a.encode('utf-16-le')
> ''
> >>> a.encode('utf-16-le')
> ''
> >>>
> >>>
> >>> a.encode('utf-16-be')
> ''
> >>> a.encode('utf-16-be')
> ''
> >>>
> >>>

Thanks. I'll checkin a patch which resolves this later today.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Fri Jul  7 11:52:05 2000
From: mal@lemburg.com (mal@lemburg.com)
Date: Fri,  7 Jul 2000 06:52:05 -0400 (EDT)
Subject: [Python-bugs-list] Empty unicode string as utf-16 (PR#393)
Message-ID: <20000707105205.AD4B91CFF8@dinsdale.python.org>

lhudson@geminidataloggers.com wrote:
> 
> Full_Name: Lawrence Hudson
> Version: 1.6a2
> OS: Win2k Professional
> Submission from: mailhost.oriongroup.co.uk (194.200.199.161)
> 
> Encoding an empty unicode string as utf-16 produces some unusual results:
> 
> Python 1.6a2 (#0, Jun 30 2000, 16:33:35) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> a = u''
> >>> a.encode('utf-16')
> '\007\000'
> >>> a.encode('utf-16')
> 'ut'
> >>> a.encode('utf-16')
> 'ut'
> >>> a.encode('utf-16')
> 'ut'
> >>>
> >>>
> >>> a.encode('utf16')
> '\007\000'
> >>> a.encode('utf16')
> 'ut'
> >>> a.encode('utf16')
> 'ut'
> >>>
> >>>
> >>> a.encode('utf-16-le')
> ''
> >>> a.encode('utf-16-le')
> ''
> >>>
> >>>
> >>> a.encode('utf-16-be')
> ''
> >>> a.encode('utf-16-be')
> ''
> >>>
> >>>

Thanks. I'll checkin a patch which resolves this later today.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From akuchlin@mems-exchange.org  Fri Jul  7 14:03:05 2000
From: akuchlin@mems-exchange.org (akuchlin@mems-exchange.org)
Date: Fri,  7 Jul 2000 09:03:05 -0400 (EDT)
Subject: [Python-bugs-list] profile.py: self-profiling bug (PR#394)
Message-ID: <20000707130305.994451D045@dinsdale.python.org>

Full_Name: A.M. Kuchling
Version: 2.0cvs
OS: 
Submission from: cnri-7-237.cnri.reston.va.us (132.151.7.237)


Reported by jtravis@cse.unl.edu (Jon Travis) in comp.lang.python:

There is a small bug while running some of
the profiling code from within the profiler.  
Specifically:

import profile
x = profile.Profile()
x.run("x.dump_stats('/tmp/foo')")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "./Lib/profile.py", line 347, in run
    return self.runctx(cmd, dict, dict)
  File "./Lib/profile.py", line 353, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "./Lib/profile.py", line 322, in dump_stats
    self.create_stats()
  File "./Lib/profile.py", line 327, in create_stats
    self.simulate_cmd_complete()
  File "./Lib/profile.py", line 312, in simulate_cmd_complete
    self.t = self.get_time() - t
  File "./Lib/profile.py", line 191, in trace_dispatch_i
    if self.dispatch[event](frame,t):
  File "./Lib/profile.py", line 248, in trace_dispatch_return
    pt, ptt, pct, pfn, pframe, pcur = rcur
TypeError: unpack non-sequence

I have a small 2 liner fix, but I doubt it is correct,
merely a band-aid, so I won't post it.

-- Jon







From mhammond@skippinet.com.au  Sun Jul  9 04:51:24 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sat, 8 Jul 2000 23:51:24 -0400
Subject: [Python-bugs-list] popen2.popen3 and win32pipe.popen3 has unconsistancy interface. (PR#386)
In-Reply-To: <20000705095804.4A3EE1CE26@dinsdale.python.org>
Message-ID: <ECEPKNMJLHAPFFJHDOJBKEBGDAAA.mhammond@skippinet.com.au>

Its not a bug - but it is a shame.

afaik, win32pipe.popen3 predates opoen2.popen3.

However, fixing either of these would have a backwards compatibility issue
that we simply can not address, or accept.

Mark.

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> 2jerry@writeme.com
> Sent: Wednesday, 5 July 2000 5:58 AM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] popen2.popen3 and win32pipe.popen3 has
> unconsistancy interface. (PR#386)
>
>
> Full_Name: Jerome.vacher
> Version: 1.5.2 (build 129)
> OS: Sun, SGI, NT, Win98
> Submission from: thotsc10.thomson-csf.fr (195.101.37.183)
>
>
> Hello,
> this is my second bug submission in 2 days and my second bug
> submission in my
> life :)
> Is it a bug ?
> Where is the bug ?
>
> posix     : popen2.popen3(output, input, error)
> win32pipe : win32pipe.popen3(input, output, error)
>
> Need an ntpopen.py module as ntpath.py do ? oh cool idea for the
> dude who does
> it.
> I used next code to continue using popen3 in that situation but
> what a shame to
> do so.
>
> [...]
> def CC_popen3(commande, mode):
>   global nb                                   # forget this ..
> this is just to
>   if V: print __module__+": IN CC_popen3",nb  # capture number
> of open pipe
>   nb = nb + 1                                 # seem to hang
> popen2.popen3
> after
>                                               # about 170 calls.
>                                               # (no further
> expert so forget)
>   if sys.platform == "win32":
>     from win32pipe import popen3
>     (i,o,e) = popen3(commande, mode)
>     return (i,o,e)
>   elif os.name == "posix":
>     from popen2 import popen3
>     (o,i,e) = popen3(commande, mode)
>     return (i,o,e)
>   else:
>     raise CC_env_error, "env: CC_popen3 : ERROR : Unsupported
> Operating System"
> [...]
>
> QUESTION / DISCUSSION:
>  what is the best way ? (i,o,e) or (o,i,e) ? i choose (i,o,e)
> cause this is a
> reading behaviour and is more comprehensive. I know that choose
> is subjective.
>  So what need the futur to be ?
>  Tel me that convergence is THE way. never mind about the order ;-)
>
> Jerome.vacher
> jerome.vacher@tts.thomson-csf.com / jvacher@on-x.com
> Alias Jerry 'the foolish dracomorpheus'.
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list
>



From papadopo@shfj.cea.fr  Thu Jul 13 11:12:05 2000
From: papadopo@shfj.cea.fr (papadopo@shfj.cea.fr)
Date: Thu, 13 Jul 2000 06:12:05 -0400 (EDT)
Subject: [Python-bugs-list] netrc.py rejects passwords (PR#395)
Message-ID: <20000713101205.B04181CE8C@dinsdale.python.org>

Full_Name: Dimitri Papadopoulos
Version: 1.5.2
OS: Solaris 7
Submission from: pendragon.shfj.cea.fr (132.166.81.1)


Hi,

Bug report open/243 shows that netrc.py chokes on '-' in hostnames.
It also chokes on '@' in passwords. Using '@' in passwords is legitimate
because you send your e-mail address when logging in as 'anonymous'.

Changing
	lexer.wordchars = lexer.wordchars + '.-'
to
	lexer.wordchars = lexer.wordchars + '.-@'
fixes the problem but allows for '@' in hostnames...This probably
doesn't matter: it's better to have a working netrc.py than strictly
checking the validity of tokens. Strict checking can be implemented
later on.

--Dimitri





From jeremy@beopen.com  Fri Jul 14 02:18:15 2000
From: jeremy@beopen.com (jeremy@beopen.com)
Date: Thu, 13 Jul 2000 21:18:15 -0400 (EDT)
Subject: [Python-bugs-list] Re: memory bloat in binary file upload (PR#396)
Message-ID: <20000714011815.ED4AA1CF53@dinsdale.python.org>

>read_lines_to_outerboundary chews up memory.
>there's a while (1) loop that does a readline(), which
>is probably not good, as you could have a binary file that
>doesn't have an endline til the end, and thus readline would
>read the entire file into memory.  i did the following:
>dd'd a 100MB /dev/zero file and used zope to upload it.
>it chewed up a large amount of memory.

It sounds like the bug you're reporting is with a particular
application that is calling readline when it shouldn't.  Is it a Zope
bug?  Python doesn't contain a read_lines_to_outerboundary function,
and it sounds like readline is behaving as it is supposed to.

Jeremy




From jeremy@beopen.com  Fri Jul 14 02:42:48 2000
From: jeremy@beopen.com (jeremy@beopen.com)
Date: Thu, 13 Jul 2000 21:42:48 -0400 (EDT)
Subject: [Python-bugs-list] bad pos value on match object (PR#397)
Message-ID: <20000714014248.812451CF53@dinsdale.python.org>

Full_Name: Jeremy Hylton
Version: CVS Thu Jul 13 21:43:09 EDT 2000
OS: 
Submission from: w042.z064000252.bwi-md.dsl.cnc.net (64.0.252.42)
Submitted by: jeremy


The pos attribute of a match object is supposed to match the value of
the optional pos argument passed to match or search.  The default
value of the argument is zero.  The current implementation sets pos to
be the start of the match instead.

This program demonstrates:

import re
buf = "abcdef"
rx = re.compile("b(c)")
mo = rx.search(buf)
print mo.pos, mo.endpos
print mo.start(1), mo.end(1)

bitdiddle:/tmp> python1.5 retest.py 
0 6
2 3
bitdiddle:/tmp> python retest.py 
1 6
2 3





From ingo.adler@synacon.ch  Fri Jul 14 10:10:26 2000
From: ingo.adler@synacon.ch (ingo.adler@synacon.ch)
Date: Fri, 14 Jul 2000 05:10:26 -0400 (EDT)
Subject: [Python-bugs-list] memory leak in loops (PR#398)
Message-ID: <20000714091026.6C77B1CDAA@dinsdale.python.org>

Full_Name: ingo adler
Version: 1.5.2
OS: win nt
Submission from: megazh-d-201.agrinet.ch (212.28.158.201)


I have a simple loop, which produces memory leaks at every call (36 bytes):

{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();

    initxmodulec();

    PyRun_SimpleString("print \"... Python started ...\"");

    PyRun_SimpleString("import xmodule");
    PyRun_SimpleString("from xmodule import *");

// The Loop
    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
    );




    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();
}

X and Y are my classes implemented in C++, connected to Python via Swig Shadow
Classes:

class X {

public:
    float getNumber()
    {
        return 12.2;
    }
};

class Y {
    X* pX;

public:
    Y()
    {
        pX = new X;
    }

    ~Y()
    {
        delete pX;
    }

    X* getX()
    {
        return pX;
    }
};

The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
problem with swig1.1).

I tested the application with "CodeGuard", which shows the memory leaks.
For every call in the loop there is an entry like this (I translated it to
English):

Error. 0x300010 (Thread 0x013B):
resource leak: memory block (0x15422F0) was never released

memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
call stack:
   0x0045ED5D(=pythontest.exe:0x01:05DD5D)
G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
   0x00401EFD(=pythontest.exe:0x01:000EFD)
G:\Projects\src\fortuna\test\xmodule_wrap.c#769
   0x0040255D(=pythontest.exe:0x01:00155D)
G:\Projects\src\fortuna\test\xmodule_wrap.c#941
   0x0041BA79(=pythontest.exe:0x01:01AA79)
G:\Projects\src\fortuna\Python\Python\ceval.c#2359
   0x0041B912(=pythontest.exe:0x01:01A912)
G:\Projects\src\fortuna\Python\Python\ceval.c#2324
   0x0040EE3E(=pythontest.exe:0x01:00DE3E)
G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12


The Code for line 941:

#define Y_getX(_swigobj)  (_swigobj->getX())
static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
    Y  *_arg0;
    PyObject  *_resultobj,*_argo0=0;
    X  *_result;
    self = self;
    if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) 
        return NULL;
    if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
NULL;
    _result = (X *)Y_getX(_arg0);
/*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
    return _resultobj;
}

The Code for line 769:

SWIGSTATICRUNTIME(PyObject *)
SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
  char result[512];
  PyObject *robj;
  if (!ptr) {
    Py_INCREF(Py_None);
    return Py_None;
  }
#ifdef SWIG_COBJECT_TYPES
  robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
#else
  SWIG_MakePtr(result,ptr,type);
/*769*/  robj = PyString_FromString(result);
#endif
  return robj;
}


Ingo Adler




From mal@lemburg.com  Fri Jul 14 10:22:51 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 14 Jul 2000 11:22:51 +0200
Subject: [Python-bugs-list] memory leak in loops (PR#398)
References: <20000714091026.6C77B1CDAA@dinsdale.python.org>
Message-ID: <396EDBEB.5575B651@lemburg.com>

ingo.adler@synacon.ch wrote:
> 
> Full_Name: ingo adler
> Version: 1.5.2
> OS: win nt
> Submission from: megazh-d-201.agrinet.ch (212.28.158.201)
> 
> I have a simple loop, which produces memory leaks at every call (36 bytes):
> 
> {
>     Py_SetProgramName("pythontest.exe");
>     Py_Initialize();
> 
>     initxmodulec();
> 
>     PyRun_SimpleString("print \"... Python started ...\"");
> 
>     PyRun_SimpleString("import xmodule");
>     PyRun_SimpleString("from xmodule import *");
> 
> // The Loop
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"

Could be that SWIG doesn't get a chance to cleanup the shadow
object for x and y. Try adding

del x,y

as final script line.

Note that SWIG uses Python strings to represent pointers in
C++. It uses an internal table to store these.

>     );
> 
>     PyRun_SimpleString("print \"... Python finished ...\"");
>     Py_Finalize();
> }
> 
> X and Y are my classes implemented in C++, connected to Python via Swig Shadow
> Classes:
> 
> class X {
> 
> public:
>     float getNumber()
>     {
>         return 12.2;
>     }
> };
> 
> class Y {
>     X* pX;
> 
> public:
>     Y()
>     {
>         pX = new X;
>     }
> 
>     ~Y()
>     {
>         delete pX;
>     }
> 
>     X* getX()
>     {
>         return pX;
>     }
> };
> 
> The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
> problem with swig1.1).
> 
> I tested the application with "CodeGuard", which shows the memory leaks.
> For every call in the loop there is an entry like this (I translated it to
> English):
> 
> Error. 0x300010 (Thread 0x013B):
> resource leak: memory block (0x15422F0) was never released
> 
> memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
> call stack:
>    0x0045ED5D(=pythontest.exe:0x01:05DD5D)
> G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
>    0x00401EFD(=pythontest.exe:0x01:000EFD)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#769
>    0x0040255D(=pythontest.exe:0x01:00155D)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#941
>    0x0041BA79(=pythontest.exe:0x01:01AA79)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2359
>    0x0041B912(=pythontest.exe:0x01:01A912)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2324
>    0x0040EE3E(=pythontest.exe:0x01:00DE3E)
> G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12
> 
> The Code for line 941:
> 
> #define Y_getX(_swigobj)  (_swigobj->getX())
> static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
>     Y  *_arg0;
>     PyObject  *_resultobj,*_argo0=0;
>     X  *_result;
>     self = self;
>     if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0))
>         return NULL;
>     if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
> NULL;
>     _result = (X *)Y_getX(_arg0);
> /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
>     return _resultobj;
> }
> 
> The Code for line 769:
> 
> SWIGSTATICRUNTIME(PyObject *)
> SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
>   char result[512];
>   PyObject *robj;
>   if (!ptr) {
>     Py_INCREF(Py_None);
>     return Py_None;
>   }
> #ifdef SWIG_COBJECT_TYPES
>   robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
> #else
>   SWIG_MakePtr(result,ptr,type);
> /*769*/  robj = PyString_FromString(result);
> #endif
>   return robj;
> }
> 
> Ingo Adler
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Fri Jul 14 10:23:00 2000
From: mal@lemburg.com (mal@lemburg.com)
Date: Fri, 14 Jul 2000 05:23:00 -0400 (EDT)
Subject: [Python-bugs-list] memory leak in loops (PR#398)
Message-ID: <20000714092300.C2F9A1CDE2@dinsdale.python.org>

ingo.adler@synacon.ch wrote:
> 
> Full_Name: ingo adler
> Version: 1.5.2
> OS: win nt
> Submission from: megazh-d-201.agrinet.ch (212.28.158.201)
> 
> I have a simple loop, which produces memory leaks at every call (36 bytes):
> 
> {
>     Py_SetProgramName("pythontest.exe");
>     Py_Initialize();
> 
>     initxmodulec();
> 
>     PyRun_SimpleString("print \"... Python started ...\"");
> 
>     PyRun_SimpleString("import xmodule");
>     PyRun_SimpleString("from xmodule import *");
> 
> // The Loop
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"

Could be that SWIG doesn't get a chance to cleanup the shadow
object for x and y. Try adding

del x,y

as final script line.

Note that SWIG uses Python strings to represent pointers in
C++. It uses an internal table to store these.

>     );
> 
>     PyRun_SimpleString("print \"... Python finished ...\"");
>     Py_Finalize();
> }
> 
> X and Y are my classes implemented in C++, connected to Python via Swig Shadow
> Classes:
> 
> class X {
> 
> public:
>     float getNumber()
>     {
>         return 12.2;
>     }
> };
> 
> class Y {
>     X* pX;
> 
> public:
>     Y()
>     {
>         pX = new X;
>     }
> 
>     ~Y()
>     {
>         delete pX;
>     }
> 
>     X* getX()
>     {
>         return pX;
>     }
> };
> 
> The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
> problem with swig1.1).
> 
> I tested the application with "CodeGuard", which shows the memory leaks.
> For every call in the loop there is an entry like this (I translated it to
> English):
> 
> Error. 0x300010 (Thread 0x013B):
> resource leak: memory block (0x15422F0) was never released
> 
> memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
> call stack:
>    0x0045ED5D(=pythontest.exe:0x01:05DD5D)
> G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
>    0x00401EFD(=pythontest.exe:0x01:000EFD)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#769
>    0x0040255D(=pythontest.exe:0x01:00155D)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#941
>    0x0041BA79(=pythontest.exe:0x01:01AA79)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2359
>    0x0041B912(=pythontest.exe:0x01:01A912)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2324
>    0x0040EE3E(=pythontest.exe:0x01:00DE3E)
> G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12
> 
> The Code for line 941:
> 
> #define Y_getX(_swigobj)  (_swigobj->getX())
> static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
>     Y  *_arg0;
>     PyObject  *_resultobj,*_argo0=0;
>     X  *_result;
>     self = self;
>     if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0))
>         return NULL;
>     if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
> NULL;
>     _result = (X *)Y_getX(_arg0);
> /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
>     return _resultobj;
> }
> 
> The Code for line 769:
> 
> SWIGSTATICRUNTIME(PyObject *)
> SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
>   char result[512];
>   PyObject *robj;
>   if (!ptr) {
>     Py_INCREF(Py_None);
>     return Py_None;
>   }
> #ifdef SWIG_COBJECT_TYPES
>   robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
> #else
>   SWIG_MakePtr(result,ptr,type);
> /*769*/  robj = PyString_FromString(result);
> #endif
>   return robj;
> }
> 
> Ingo Adler
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From ingo.adler@synacon.ch  Fri Jul 14 11:40:42 2000
From: ingo.adler@synacon.ch (Ingo Adler)
Date: Fri, 14 Jul 2000 11:40:42 +0100
Subject: [Python-bugs-list] memory leak in loops (PR#398)
References: <20000714091026.6C77B1CDAA@dinsdale.python.org> <396EDBEB.5575B651@lemburg.com>
Message-ID: <396EEE29.A66F7EDF@synacon.ch>

This is a multi-part message in MIME format.
--------------6D29988B97CCE77010389AE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > // The Loop
> >     PyRun_SimpleString(
> >         "y = Y()\n"
> >         "for i in range(1000):\n"
> >         "\tx = y.getX()\n"
> >         "\tx.getNumber()\n"
>
> Could be that SWIG doesn't get a chance to cleanup the shadow
> object for x and y. Try adding
>
> del x,y
>
> as final script line.
>
> Note that SWIG uses Python strings to represent pointers in
> C++. It uses an internal table to store these.
>

I changed the code to:

    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
        "\tdel x\n"
    );

It doesn't change anything.

The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
y.getX() is memory leak free.

Ingo Adler

--------------6D29988B97CCE77010389AE2
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------6D29988B97CCE77010389AE2--



From ingo.adler@synacon.ch  Fri Jul 14 10:39:42 2000
From: ingo.adler@synacon.ch (ingo.adler@synacon.ch)
Date: Fri, 14 Jul 2000 05:39:42 -0400 (EDT)
Subject: [Python-bugs-list] memory leak in loops (PR#398)
Message-ID: <20000714093942.5C1B61CDFD@dinsdale.python.org>

This is a multi-part message in MIME format.
--------------6D29988B97CCE77010389AE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > // The Loop
> >     PyRun_SimpleString(
> >         "y = Y()\n"
> >         "for i in range(1000):\n"
> >         "\tx = y.getX()\n"
> >         "\tx.getNumber()\n"
>
> Could be that SWIG doesn't get a chance to cleanup the shadow
> object for x and y. Try adding
>
> del x,y
>
> as final script line.
>
> Note that SWIG uses Python strings to represent pointers in
> C++. It uses an internal table to store these.
>

I changed the code to:

    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
        "\tdel x\n"
    );

It doesn't change anything.

The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
y.getX() is memory leak free.

Ingo Adler

--------------6D29988B97CCE77010389AE2
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------6D29988B97CCE77010389AE2--





From mal@lemburg.com  Fri Jul 14 11:13:13 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 14 Jul 2000 12:13:13 +0200
Subject: [Python-bugs-list] memory leak in loops (PR#398)
References: <20000714092300.C2F9A1CDE2@dinsdale.python.org>
Message-ID: <396EE7B9.D8CA068F@lemburg.com>

Ingo Adler wrote:
> 
> > > // The Loop
> > >     PyRun_SimpleString(
> > >         "y = Y()\n"
> > >         "for i in range(1000):\n"
> > >         "\tx = y.getX()\n"
> > >         "\tx.getNumber()\n"
> >
> > Could be that SWIG doesn't get a chance to cleanup the shadow
> > object for x and y. Try adding
> >
> > del x,y
> >
> > as final script line.
> >
> > Note that SWIG uses Python strings to represent pointers in
> > C++. It uses an internal table to store these.
> >
> 
> I changed the code to:
> 
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"
>         "\tdel x\n"
>     );
> 
> It doesn't change anything.
> 
> The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
> y.getX() is memory leak free.

Two other possibilities:

1. Python interns the string object used by SWIG to represent
the point. It should then free the memory in the Py_Finalize()
call. If it doesn't, there's a bug to be found ;-)

2. SWIG has the leak. Try using the alternative method of
defining SWIG_COBJECT_TYPES (don't know how this is done --
it seems to be new in SWIG).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Fri Jul 14 11:13:50 2000
From: mal@lemburg.com (mal@lemburg.com)
Date: Fri, 14 Jul 2000 06:13:50 -0400 (EDT)
Subject: [Python-bugs-list] memory leak in loops (PR#398)
Message-ID: <20000714101350.109CF1CDE2@dinsdale.python.org>

Ingo Adler wrote:
> 
> > > // The Loop
> > >     PyRun_SimpleString(
> > >         "y = Y()\n"
> > >         "for i in range(1000):\n"
> > >         "\tx = y.getX()\n"
> > >         "\tx.getNumber()\n"
> >
> > Could be that SWIG doesn't get a chance to cleanup the shadow
> > object for x and y. Try adding
> >
> > del x,y
> >
> > as final script line.
> >
> > Note that SWIG uses Python strings to represent pointers in
> > C++. It uses an internal table to store these.
> >
> 
> I changed the code to:
> 
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"
>         "\tdel x\n"
>     );
> 
> It doesn't change anything.
> 
> The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
> y.getX() is memory leak free.

Two other possibilities:

1. Python interns the string object used by SWIG to represent
the point. It should then free the memory in the Py_Finalize()
call. If it doesn't, there's a bug to be found ;-)

2. SWIG has the leak. Try using the alternative method of
defining SWIG_COBJECT_TYPES (don't know how this is done --
it seems to be new in SWIG).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From ingo.adler@synacon.ch  Fri Jul 14 12:45:02 2000
From: ingo.adler@synacon.ch (Ingo Adler)
Date: Fri, 14 Jul 2000 12:45:02 +0100
Subject: [Python-bugs-list] memory leak in loops (PR#398)
References: <20000714091026.6C77B1CDAA@dinsdale.python.org> <396EDBEB.5575B651@lemburg.com>
Message-ID: <396EFD3E.7AB566B0@synacon.ch>

This is a multi-part message in MIME format.
--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I could reproduce the problem with Developer Studio 6.0.

If anyone wants the project to test it - I can provide it.

Ingo Adler

--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------82393A6779ADCFC3A2ADE19E--



From ingo.adler@synacon.ch  Fri Jul 14 11:44:02 2000
From: ingo.adler@synacon.ch (ingo.adler@synacon.ch)
Date: Fri, 14 Jul 2000 06:44:02 -0400 (EDT)
Subject: [Python-bugs-list] memory leak in loops (PR#398)
Message-ID: <20000714104402.3BAAD1CE8C@dinsdale.python.org>

This is a multi-part message in MIME format.
--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I could reproduce the problem with Developer Studio 6.0.

If anyone wants the project to test it - I can provide it.

Ingo Adler

--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------82393A6779ADCFC3A2ADE19E--





From guido@beopen.com  Fri Jul 14 16:05:35 2000
From: guido@beopen.com (guido@beopen.com)
Date: Fri, 14 Jul 2000 11:05:35 -0400 (EDT)
Subject: [Python-bugs-list] Re: memory bloat in binary file upload (PR#396)
Message-ID: <20000714150535.14E751CEBF@dinsdale.python.org>

> >read_lines_to_outerboundary chews up memory.
> >there's a while (1) loop that does a readline(), which
> >is probably not good, as you could have a binary file that
> >doesn't have an endline til the end, and thus readline would
> >read the entire file into memory.  i did the following:
> >dd'd a 100MB /dev/zero file and used zope to upload it.
> >it chewed up a large amount of memory.
> 
> It sounds like the bug you're reporting is with a particular
> application that is calling readline when it shouldn't.  Is it a Zope
> bug?  Python doesn't contain a read_lines_to_outerboundary function,
> and it sounds like readline is behaving as it is supposed to.

Actually, read_lines_to_outerboundary() is a method of class
FieldStorage in cgi.py.

But I think it's a Zope problem if this is being used for uploading
binary files!  Look at the logic in read_single():

    def read_single(self):
        """Internal: read an atomic part."""
        if self.length >= 0:
            self.read_binary()
            self.skip_lines()
        else:
            self.read_lines()
        self.file.seek(0)

(Where read_lines() calls read_lines_to_outerboundary().)

It seems that somehow the length field is not set.  This suggests a
problem in the browser that sent the data, or in Zope.  I'd need more
documentation before believing it's a Python bug.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)




From crislipm@earthlink.net  Mon Jul 17 01:40:26 2000
From: crislipm@earthlink.net (crislipm@earthlink.net)
Date: Sun, 16 Jul 2000 20:40:26 -0400 (EDT)
Subject: [Python-bugs-list] IDLE (PR#400)
Message-ID: <20000717004026.02F851CF89@dinsdale.python.org>

Full_Name: Mark Crislip
Version: 1.5.2
OS: Linuxppc, Suse dist
Submission from: c398054-a.potlnd1.or.home.com (24.12.168.223)


more for curiosity/FYI

Using 1.5.2 (the version that came with the suse linuxppc) and IDLE 0.5 on an
ibook (version 2).

IDLE causes the keyboard to stop working (I am not certain which, if any action,
causes this, but it is reproducable) and the problem continues when I warm boot
back to the MAC OS.  Have to do a cold boot to get keyboard to respond again.





From andyg@one.net.au  Mon Jul 17 09:26:13 2000
From: andyg@one.net.au (andyg@one.net.au)
Date: Mon, 17 Jul 2000 04:26:13 -0400 (EDT)
Subject: [Python-bugs-list] combination of socket.gethostbyname and os.system hangs program (PR#401)
Message-ID: <20000717082613.A960B1D0B4@dinsdale.python.org>

Full_Name: Andy Gayton
Version: Python 1.5.2 (#3, Jun 29 2000, 15:52:04)  [GCC 2.8.1] on sunos5
OS: SunOS psol002 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise
Submission from: syd-cache01.one.net.au (203.101.17.53)


A combination of socket.gethostbyname and os.system appears to hang
python intermittently.  We run Dec and Sun systems - it only appears
to be a problem with sun systems.

The following is the simplest way I can reproduce the problem:

test.py:
--------------------------------
#!/usr/local/bin/python
import os
import socket
print socket.gethostbyname( "a hostname (but not localhost)" )
os.system("echo fred")

hang.sh:
--------------------------------
#!/bin/ksh
while true ; do
  ./test.py
done

output:
---------------------------------
10.666.666.666
fred
10.666.666.666
fred
... eventually ...
10.666.666.666
<hung>

If "a hostname" is "localhost" it doesn't hang.  For anything else which it 
can successfully resolve, it seems to hang.

Thanks !
Andy.




From infotop@takas.lt  Mon Jul 17 11:38:46 2000
From: infotop@takas.lt (infotop@takas.lt)
Date: Mon, 17 Jul 2000 06:38:46 -0400 (EDT)
Subject: [Python-bugs-list] Info from MediaPrint Ltd. (PR#402)
Message-ID: <20000717103846.276FC1D052@dinsdale.python.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01BFEFE9.3C81A110
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0014_01BFEFE9.3C81A110"


------=_NextPart_001_0014_01BFEFE9.3C81A110
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable


Dear Ladies and Gentelmen,
marking 5 years anniversaries of our firm,
MediaPrint Ltd. studios of design we offer to you to make
Web Pages &  advertising banner's on not to the really good prices,=20
more detailed information
You will find to these addresses:
=20
http://www.medienprint.com
http://mediaprint.int-ltd.net
=20
The attention ! This letter is intended for constant=20
the clients of our firm, if this letter is casual=20
has appeared at you, the request to inform us about it.

Yours faithfully,
Dipl.-Designer
Mr. V.Michejevas

Tel.:   +370 2 315 732
Fax:   +370 2 315 733

IPhone: +370 2 315 733
GSM: +370 88 42410
ICQ #   72223197
=20
http://mediaprint.int-ltd.net=20

------=_NextPart_001_0014_01BFEFE9.3C81A110
Content-Type: text/html;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251"><BASE=20
href=3D"file://D:\Program Files\Common Files\Microsoft =
Shared\Stationery\">
<STYLE>BODY {
	BACKGROUND-POSITION: left top; FONT-SIZE: 10pt; MARGIN-LEFT: 75px; =
COLOR: #000000; BACKGROUND-REPEAT: repeat-y; FONT-FAMILY: Arial
}
</STYLE>

<META content=3D"MSHTML 5.50.4030.2400" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#fffbf0 =
background=3Dcid:001201bfefd8$78f43d30$300adbc1@boss>
<DIV><FONT face=3DArial size=3D2><BR><STRONG>Dear Ladies and =
Gentelmen,<BR>marking 5=20
years anniversaries of our firm,<BR>MediaPrint Ltd. studios of design we =
offer=20
to you to make<BR>Web Pages &amp;&nbsp; advertising&nbsp;banner's on not =
to the=20
really good prices, <BR></STRONG>more detailed information<BR>You will =
find to=20
these addresses:<BR>&nbsp;<BR><A=20
href=3D"http://www.medienprint.com">http://www.medienprint.com</A><BR><A =

href=3D"http://mediaprint.int-ltd.net">http://mediaprint.int-ltd.net</A><=
BR>&nbsp;<BR><STRONG>The=20
attention ! </STRONG>This letter is intended for constant <BR>the =
clients of our=20
firm, if this letter is casual <BR>has appeared at you, the request to =
inform us=20
about it.</FONT></DIV><FONT face=3DArial size=3D2>
<DIV><BR>Yours faithfully,</DIV>
<DIV>Dipl.-Designer<BR>Mr. V.Michejevas<BR><BR>Tel.:&nbsp;&nbsp; +370 2 =
315=20
732<BR>Fax:&nbsp;&nbsp; +370 2 315 733<BR><BR>IPhone: +370 2 315 =
733<BR>GSM:=20
+370 88 42410<BR>ICQ #&nbsp;&nbsp; 72223197<BR>&nbsp;<BR><A=20
href=3D"http://mediaprint.int-ltd.net">http://mediaprint.int-ltd.net</A> =

</FONT></DIV></BODY></HTML>

------=_NextPart_001_0014_01BFEFE9.3C81A110--

------=_NextPart_000_0013_01BFEFE9.3C81A110
Content-Type: image/gif;
	name="info_mpinfo.gif"
Content-Transfer-Encoding: base64
Content-ID: <001201bfefd8$78f43d30$300adbc1@boss>

R0lGODdh9wM8APcAADkYEP///+Pj4+OxIdK5qeOIIXNCGHNSM+O5c7FzIXtSOYhrQrmIM5lzUtqp
WsKIQmtCCNqxZtrS0qGAM8KQUrGhiOOQM5BmGFIpEPPamamAQtqxQuvMgMJ7GJBmM2tCIeOZQvPa
sfPMmeOhIYhSGNKQM8KZQuPa0sKQGPPr6+OxM3NSIXNaOevCa7GAGLGIOdqhSuOhM5lmGGs5GNKA
GGtKIeOpUtKpOf/jzNqQIaFzGEohEOOZIbF7KYhmM8KZOamASmtKCGtCGOuxUrGAM7mpmYhmKVo5
GPPaqbmAQuuxSuPCSvPSgPPMiMKIIaFzM+OpQv/rwvPjufPMoZBaGIBSKdKpQtKZGHtSKXNmSuvC
e7GAKWtSIWtKM//z0v/r0plzKWtKEOvCZuuxZuvCSvPSkNKQKWtaM+vj4+OQIeOIKXtKGHNKGHNa
M+uxa7l7GLF7GJBzQsKIM7mQM7mIOcyQQsKQQmtCEOOxZtra0ql7OeOZM5BmIVozGFIzEFIpGPPa
oeOxQvPCgMKAIcJ7IZBrM2tCKeuhQuOhQvPjsfPSmeOpIeOhKYhaGNKZM+Pj2uPa2v/z8/Pz6+O5
OeOxOXtSGHNmOXNaQvPCc+vMc+vCc7mAGLGQOdqpUuOpM+OhOaFmGJlrGJlmIdqIIdKIGGtKKeup
UtqhM//rzNqZIaF7GKFzIUopGEohGOOZKWtSCOu5UuuxWpBmKfPjqfPSiPPMkMKIKeupSuOpSv/j
ufPSoZBaIYhaIdKZIXtaKfPCe+vMe7mAIWtaKWtSKf/z2v/r2qFzKWtSEGtKGOu5ZtKZKevr4+OQ
KXNKIeu5a7l7IbF7IcKQM7mQOeOZOVIzGOO5QuOxSvPMgJBrOeuhSuOhSuOpKdKZOfPz83taIXtS
IXNmQrmIGOOpOaFrGJlrIdKIIeupWtqhOdqZKeu5WpBrKf/jwvPSqYhaKfPMe7mIKbmAKaF7KWtS
GOvr6+u5c8KQOeO5SqFrIWAhI00PgEyphFWNUBLx1GboiwAAAGDYbSH5BAAAAAAALAAAAAD3AzwA
AAj/AIekSycmmRhMYjJhcueuiTsmZSKWyTBxFqBZs3LNipIoihSNs5BkUBSxiclf7jBhSjYm3ZhY
pkwpuXXrkM09a1gQiBSgp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK
HUu2rNmfBMWoRZiSYUMmTSZOzGARY8aNUXJpRAIIkAiSZUwyVDmGZaxYQ0zRrLnnEDMLewzoPEu5
suXLmDNr3sy5s+fPoEOLHk06qMFkbN0yWS03g+uLdvVG4Wh31kiJTVASHiPmMOIhNG0e2gPZ1R41
bHTyLM28ufPn0KNLn069uvXrzg8uVA2xtevaG3NF/7lrl6SIWk0EudO9svfhxLeyCbdgwZV9ZmnS
SCaAvb///wAGKOCABBZoIHUKcVcGExS5RhddGOmVS0d2AUJRYOmt98tKhZmDmGLBDUecca4wY2Ia
zLBhyU4HtujiizDGKOOMNNZIGUOrdTeXg7HJlghIFo2kiEkOpbRSMsm8F5MS2dQ0nGP1nYhfGjzs
Z+OVWGap5ZZcdumlZg/puGNtEtIGkpAYCtKESpi8FEs6QyQGok2QWWCilPkxw0OJKrL45Z+ABiro
oIQWKqCOPEKYkY93uUZSLeipt+FKh2Hy4ZyO7bFHiXiiyMOenwYxWVbzQJKHBKhKIEAKhrbq6quw
xuEqa5YRJRrbRhTa5RpuDKGEmm+INenkIcZpeueJnvKgJ6g5+VmVABJAksJyPaXwCCTzzKrtttx2
6+23lzmo6KKzAWmbRIGhNOlLSR7GZIjFcooffq6k4Qqo+LrSp1UpSHBCN0R1A4kA4BZs8MEIJ4zw
dz3SVmEGtZQRcZEqudFSLMnAFx9jxG56Z34l8kDlvaCO4MoIIyTnbFSSqIoUJGgoLPPMNNdsM41k
znaXRn3hlpuRhbl02GLBaeqxBSimkYABrTTdygcJpMEIDyNMXXXKK1LVL8FJ5QHwzYJ+DfbYZJf/
7SK5ZmJEEWBEAp1MOu8Bp9h8mrqCNH5qzNAKNbskcM8uMwDwQQ4nX42yytQ+1U0eXCclsNlUJY5d
N92kMM/lkHtW6qmprpr556AHMGHa57LNHpJw+wZck8Ixs2mJSedHDSv3MGOfK4y48k4rffDACMq/
M1JJ1lJBIoHkAURy+XLdUAuJ2KEP1Tzll1uerX+RSOJTJMskPk8KlCMf/VbQSpu4tdiOr37NeTW6
64JFriv00DTJZxOJ8oKcRjOt2MJMDrtoBgkSIIMc7G4XvqPa716hnKjMQwLLCIqpVuU1NETLJ/OI
4Pim1415oGEekkBeB6FnnREGoIPX64nYKnc5/xCGb31V6de/AjYwGNrwYLq6DYYcwqaWJClOmLoJ
iT5GLx6UoxUINMMfeOe0Z/CgCn9gxCK2sYgqVmJUUDmBBIASCeNdT2CnSmEkGpc5yzXvJ5JglQol
8b0Tgu8/lEseCH/yRsqxkVqUY2EKJBHHGyalZWQkCsz86BQOkrBFhySkRRTBSAwNhkMYi5PGhEMs
1x3LRCID1S5aYbs+tMIYuEtAK4LBiE20wglTXIQKFnHFlTGli5AAivHIaLwZqjCQCaOc9VLoE+h1
g40eXMY8qHe55i0jkdSJBE9+Sa1IfM16HzwjCTsIPsvt8YyEpKPLuoZMPy4TfN/7Xhx/qUYY6f+y
hdkEDHrcoR7CtOs3cxNOsaJERGWByhUG6AMj0NGKZsSgak4Y5TYY0YoErHIACG2lA7fZkwdKAHqm
iuX2cKmtb/Iyedubh+RayEcUXjNbbOwJT44JxxMGYJi9VOEwldnRcLbQcmiQHE8yyDzxgW5xFKVh
Nk9qzTx2g6RcPOFFD5S97XXvJ+LE5ufiIhi3wW0MQBxWxxzjCjWgaEp6stenTNaMDzAioLsYgQq+
2op3jGARrSDHCAagArYy0JVLEUAeyhkACeRBoj4xHl5PmFNCcZCNZgTYL1eYxwCgAQ0kzF4e2/gT
6i0zAAIYanWyla03YhRgKYiZCoU6vRRYs3r/AQgsZy/bwaNuNnPGQ57yNKpC53XTZuecY2ODQr1o
GhadHoyRCVE4WxXusqM2lVl61qQSjKUuFkoIImQ81qllLYsRh2AEIwwgBEbYAokqGAEPAuqE35UV
oeAdHn+gYiqxtSx9P7ErLyWhWUE5k3qW66jlJEe5D9IRpQLoJsAw10sW9kR7iP1PtmLG3wGf9IsA
k0QIgxpCFFbOjTzho0hResJzgu+1B3ugBn8ywRRU8IIN3bDCOMjY1vrEckBhIWvRYD3/ooGP2sut
bgGmPO2dWLC/ZK0KLdzRmU0KSW87TEwWc5NM2eduWP3UvXAn3aptYxes2IYr9saDbahgHN8N/8Yp
29rWAYg3uEcRwAmo9cA8pBhV0Muvl96bwcLO1MZu/ODlYjznQ7KqvULBrIh5ktmGQhbO1nGmMzXa
QWcGIKSeM2lj86jGmbJ2wJrt4IFjqujG1vHCGN6WFrnoRRWaSgJi7CuscGzGpLZWxMPE7GGDEk7K
qZkn7yVpjPHsImWecMEifeblovnYxorTmnwEc6yO9M6YYIo4xrpTAaZEsiUHjxHb2IYntgGNVvTA
E1VoxRFkoLdW3MMJzTgCeAcwCS9j0SnGExu0tvgTubLbJ++eEYkprWhnsng57P3goIeZRs9Clq4p
/mk3WSXM2bZZ0CGdXH+VF76VkpThJ+1jT/+4tt/r3TmFA7YsZas3UsH2l5ogFHarYClLhgaglisU
9Z8EHVoUsviFPwV4bRubxgMjc5kirjBr9Swjj1NY0SNkKXxbGE56b++kplVqrIKsJKINZ7kW4MHd
8qRVZuTOZNCN9rStvI0+RNEV3mgaNfjgtO92GaGvWJHIiYIGr/mk7YH0117n8QgXTS+cF0bq9VAa
TBBmqxv5ZdVPgTJgQAdcshg8MB2TR2MMAlw6vmTVSvvIWHEuI7MZ9CBrJa/GAYvN8283LIsdvl/L
3nexSV27lx5IRodC9K4/GSOgMPu1EeaYlwL37TLkHMEM7nGooJdeaHUs0oifUHmPPxBlW17afFWn
NOiV+2wbRWvCZZYWj4ZSXRAztamoYzVZ9rHaIaItba5P2xO7+0Av2DoAK4/AyuM+u3gXWs5S7dWC
edhwJOINIBXn3YQfh3QNdXGCpUYvd1KBxCpqlmcnRG+9xngNWHvIhGIlREcSVli+hYGd5UH+Fkcs
tmM/Bz6mdVKG1ViadUc/hU76Rlv89V6qZyNyRVd2tVcnB2K3dCUz5UzWg2kU+Hke9GDd8EGIxT3C
pFisMl/SA3HCV2gpxUaCNWgv2B8GVmAlyF9xpGAydWj7BoTTcmhfo4SMZmr/fzJkUtUxr4Mny+Js
0rV156cCVuaGXCdKrMAHKOAEdrgF69dW5YZQKqACrRSFXMQ46fVui9NpPeF21bGB6FRpKbV74LNa
GSSAPRFBC0iCQiV5tKZLyDQ9xzROElZpyvOAtGV6kBd7/GVGvZRweYZSOIdpJVaAvWR98pVCFRd9
hiVMzVNnoaVB2rNviqV0WVJePnFeF6VeaERrBhKG18RbeaZZkdhTKFZjd+dLyBcwJ2V4s4WEOxZ9
zKNgLyJohRaOh5YtiTZNjFZ8y0OCqyZUkyaKGehGGIglrENJjFA39aEGyKJV9yJd0FZ+btiHABmQ
bNULm1R2rPAO4wZebTV//1FhPD+xDKrSQQ8lMLG0DOjVHHZkeokVYMe0byiGBstAUssQY4ZVTpK3
QoaWAt2jiq3ljQzIiEJlaL2EUq/1c9JhamxEMEGIeyUWFJGgjSnlTHCWi+Ukk3q3Y9mjRgoYPg5G
WZq1gBlEMMv0UsGWaQQiZmRmV2f2UO1mldDBZtZzVBMoTgeWW04oR0iHbxnoWLPFkoenX3K0QtJj
kwVCWAyXi8ZEY3wncZC1Wad4W4l3gCT4Uh1XaYsVX4DYH4cQA0/CA913SZ5iO8qCO+PnCdPWh54Q
kALJZez3Dp75DuvHfnrIZX+4ULj3CCDJPAIwMIk5FhwEVM2zTFwjeNQ0Wv8o9lMhpD0FRz3Tw1P9
pZFBR2fNpHOH1E01xoh7ZJRBIQlANR3ZE06RBVOReGJGJxT2RRSphm9fdGst5EwPN1uHOVOsImhW
SHDVw4oyxnjD9D155yLp5hPrBhTuBhT8Fx0qtmGHhFLAhUKVhYvPmUZseXwPtmNypFFKmGuSNhSO
5lMaqVI01k10OSCRF3HvNYADGHMfJEwryHl+FmAdKjYxc1hmxD2lZ2ep5lEvVCDLZR978Bi2IyX1
0mzSFW0BqQQqMAmToASTcKNcxpkJ+aOi+Y8MGRWn0pqVQWLfc4GKd1LLtI6U1WK5d3x3VGGoWGGO
F4sUpkzUY1KVI5cNhY3/NUloemdoSEqY1wGOC7qTILQMlSgUiTYUiLVCO9dQh0VgO/d3sFYtOuZT
JwSbALMqMyVYcjaVH/ibBVcgbQeigpheJzB3dScasghNX7QcEEdqK9VGQfdSB/ZebzSVeMSE2xhx
oNpfiPeFGDVhgmeBMAkU/nYg0HNNFbZCmNZaLMRitFmSICg2IkhmJdhLJ0howoQ5K5hiLZii/YFs
JmIn9WJV9gJ+0MUIKmCjN6qj1IqjOAqQ7MeHormtfTgAl7kNk1CaUUFyn4GksHqdsRhamoVibVYt
vsl4n4hjMpmOloaupUes5bRbskpfRRGJy2RvlAhOSXpNyikgOTZCu3Rh/8zTnG7qoQ0lcex1PaE4
jt7ZQrt3qIRHV7q0PYKVVPxZPb7Ek7N6HQ9Uf5Bwf3alf/V5pJxqOcLUY772TUIVYKi3jI0GMCTV
cLGZR98kgQPKeJXjgjZZgMkHocuHQb1XFBhLINCzWnq6Qm7pa40Xc4f5fPkqi+eUUsXkbyB5qS60
i/+lnhoFXNRxJ3ZyIlalJ7ZjL64QXdtgo9ZKBpMgt3Sro5qJrQqprXAobZ5goza6AsQjFaXClUYh
MCoXFYz2QcmnUuK0WiE1nSRIgVKaaqMlQmrKEy9mbytYe/P1hT1JihNGQo+3TGyEWMUUTtbnlQXy
TZ7lUpezeysFp7w0Rv/El6AP20cdJGfRVFmP1kFD+ZMoeYmXuIG5KIS4N5Oj+5WL2hOo0kt3BWo+
gYhkQWLA1ni9ZFk6mC0Qpzx9amN5FK97RKCUO1opJrlutKeOi1H0mq/ICIxIFTN01WeGZ32ap3x5
l5MNKLJE8ZPEt1lCiaVFmZ8IlpTuml93t54n9ZRfE5WXRZW9WRqW9KJ58im207ZrSK1koARksMEb
rME6uqM72q1d1qN8SH7SdgjR2rc3ugINRBWmgoy+CgnYWEhQGHsPSZMqhndJykJkSmHNo4pxhEc0
KXiZl1me9UbFJKBiqkKdOJPva4lvR0KptksvNcCa82mds7hmIZRHTHT/O+ydJISu6opUDNumbxRY
HlSJePlxq2VvicOJgGWKZ8ywsdpqBfsZDukTEJlfD0Q5JxsAFol4VWFIi+ZbgFaA33NYbTRnqean
3NNYiiVhLTiKAhBgmKp5y0HEOFYteFZ5P+GwpzUUKZBf3rOeH0uV/QsWm5MqqqLFVvGclhOdmidi
mQVmYsxqKZpwggVMwGq9mxWevkmeX2SerSZH7TVo1NSenoGPa9use2Ifh7AInnAIc6vBHMzBOprB
OOq3m8mZU0R+lonCfqsE5KwE3xC4VDG42EJoHnSyOac4Fwic1SLL2atgwcY8xpdHeLalp5VjPAGV
xfuI/VxiJCo2TotB/3jWZ/kKgI43TApbGuXThSd2LYJsGVy8ni20KozGsPzFydBTqIy4m/bsrlGq
pawSUuYrpZuoPdZDX/QVhPFlrJrxQKeZmrfEmlxRWBubUjqnuMSUpC7EaONZmP8FqnzZE9fJd7vG
gR95qbylq/DbS62nvUAB0n4mFCN1TF58eUKVRlh4x2AR0edD0V+BpjanpszZpkHxptYpcUy4wHW6
qex4Rpm8pzrtp/8WqPl7p1atS0uLGfkhMpLJopV5C3N7zYjdwXBrt9gqwovACNNWmZZJzodQztSs
wVjQwleRxpX8CJ9IFXKqsY7WYLl4yFhaexPLpWJUXz/IU3wmUg6rVP89WcnyiWe7118E81LWlIXP
IUP6VUOQyngeudS/trTfg0exjVT5usQAqD0Cx70dvVl0vGjHHRQt5oKjuliXZ6RZUaSXkThF2F/D
17rNA5Q2bIW12Vqr3XJtJAA2Nkd1CqufKMYvxksvtkJ4xl4wKVs3FltePD1eDdaU4ds0dLg57YQO
/VIpGqVDUcnQM76Hdp0Ti4LBmkFdKxQ9udMQSE2op+C+5msjSxb2UsHlMAPN0AwzQA11cOIHgOJ/
4Asn3lV8c+IGwAY03gwG0Ax+sAvUNgM5/uOtsArhrAKVnaPknMGwMASZPV4YSbMM27E2hrVMuZ1z
xGYf114de6ir9dH/KURX9J1z99bTijtn56uk1QFILwPDo6GluuSyRexSdBTAGWXQEP5gX4Q5ACPG
7wXKKWZ8edZRvPxBzk14qusV5HqkmFON2zNT+Omb30vlSglZPitixRuScq1GPzWcGMRLuIhUZKTf
M1mhFcbn0efQg+WOnYHmRzFIFu1GrUvFsOu+SD27kSXESKWBmqd5koaE6/m7GjmVRPyILFS89cvT
whtUXZEGHrMHVVAChyAOJqBt0sDBnNAKHrAEZLAEG9AKhhAIZEAJ304JAIltrRAZniBde7ANMVAD
fSDO5UzOOQoLsJAOyeAL4ABXo8GKrXpa4buqKhRgd0abkeChcH1o/75KZv0+ibSo3GOauBUe0wom
69exNUohvc7JeJ+VsGS+iviNex15Yl2Oe4MWMM1TnUGlr4X2uoQGupUxuJlmuFtRc0satsNHoIcE
8ICMYDrWpLXXUJG16Q++8CD/xET/70+4PB7VuiIUHRTPTZ/Bxa1LdATL4LNOR51cxq+KWamWxij5
czyL9NUJxz2JfHpmjiD3wFWRO3tgmbtADdzwAtTA7dRQClbACXFv7RtQCqzQNDUABiXwAULQVV2l
N6zgBLtgBh9gAB/QDIfAP+9+5Eog77BgEGLgC+eGkSoVi3+6wBEWThq6d47+7wYvUk08YSb44F4q
R8cETSyWRq02PZfc/Rw4tRSPY7AZT2bZGbtM7EscjU2p7b2fzUWU884Gl4mGlYs1zxkvHDBoIMNd
4blaC5ih9XG1ul+3FYq+288RlK8jGMcn1uhDD/J0DtS5fnlnGasSb5/LixS1TxoX/bEa7ddBb/Uf
na83fGsuKXhAZdLjmPwAEUBgt0iSuglEiLCbpAAp5s2LlDAAQYnduqFxaJCiRI4d/wXGOORJiRJu
1EyUamWp0zBqneyxKuXBCJ1Whko9OfLEWKsPH4R8mNHT2D1Zu3h+YHVrB7WRZJSQGUImXbpkYqyK
aWOJQESPXb1+BRsWYYoA88oybBhgWQA0aNEcRDMvLsaHE7lyfHsQ4cO7F/VOnPe32zyyAh0+RBw4
RQqKf8U+hhxZclhIEu4ijMR34F1Ijid/Bh1aosPDcgMbdHg5tcLACVtvLFu44sHVHsnWxWwRjeGy
u0X/7jivMiS+g9FAgrQWuFezZtvydm5W7UHChNEsEyCdIcG7mS26/i7Qu0KMrmU7lgRx4uBl1R+S
npdeI8XLy+3br1w/QGb1dhF2vv8vQK8iioSgwdyLi7BuUmjPvL7eUsg81gocqLUAtluGoOakizDD
riwiTL/DDDSwv/XYS0E/ryZpigwyCrGnlCOWcLEUMgLxoJU51CFCR0oosUUdUVp5hxEjGYmBkUNE
MWZIbm4xQolWSnlKCViGGIKqq8TABBNftBIwzODYKsss6swSAK3XJmLNoK7kcgxO8hK6KAXU5BxI
EjsjUVFMP8WcRwLlEoIkDwFSyOMiCSDZa9A/HxXNwPQCS8zObtoTzLcK9XNTou5ODE+hSDyM0CGB
nHMUUsnkEkAANB7pFFKydquLtuYK42ux+RYMlaP3XINwU9fQOvU8xkpDbNLF9oT/TVVnIQs01QAK
PTRRNBZt9FlI+bRoQYfaaw8+DhuSjULxLNwvMMFuq9BMtsYt0K8Py/JMIY0mNW07idANy0V/yaiB
DJj8XUGJXbhhpQY91NFRBVs+MGMVnz4woJkZ+ngnBlHk+KCVQJT4gJtWfBkCFlimsiodLsVwp2VL
WNhKW/tS9DCvsggkjE2PcLONVMPU0zC795YpzVKZjw7zBAk8rUy6bgqVgMNIBEC66rD45FNc0zJK
IdiJ1uo154q6MnWggwRwjLrCNKzXarc7Ygiiwb6LbyLGzA0uRbK9bghtzHy+SF2HyhPPocEYsyii
tt9mXGmmox4IaqmpZtxPAhes/67oh4itCN3A6czwrrIbGrfEDwlCo8/9ADuoW4geaq9AxiD710UP
yEhJiY8ruaEVbnxphQE+WvHEExKMdIWR5A8ZwZM/mjmkmWk+oOYWJdqxo5U4TlZZDJW7xMSd8N15
mYDKJaOQbrmJPZC5ZVSfe730ElTW27vPxx995CSqjHKBKjuBYPyXPwLy6ULVWYYkiEaYZaxlXGzh
nM48sqD9/GV2mznciUxEwLdRaHYXKRCxDOeVri2OdXSCiOK6ITQGLitzHIShRyKxP0JJYIAAFGAM
H4U50tzlIYkLTF989rU4bSQzXEHLQhYXL2nRqTdje0tmSBcZf5mMDB+wAgDAQP8JFhmAAa1QhyNa
EQ0htCIG23heDHbRjGYYgA0Wa8UBDiGEW7DCELAwATY00IoHdO8q7mBZy5gwyAXATHU6/IvcNNSX
2nRkMRWJl2neUx2DSMKAOsTkVwI1wEBJwDGFYhRmBpjJ/CkuI61BzGLk5RqvXESCgFEcVwo0Sz2R
smqJXGTYNjiaXdIpLhb5VoJSqSdV0seWmdykayTgSULlIZTiGeUx/6S1X95JNSaK315a50PZ0MlW
qrsNvHQDHU2JpXZ0wII0WtEOJVBiFWDoQStYcYpvbKMZrTADI4ziilYAoBX//Ccr6lCCDwyhFTnx
gB6w0QogbGl8LXPHIJlQhvL/STNC9qrQX0b1QG8KU0GTRBx3LDpSiQggD92UgDP5hy2FRJOkpUxP
aXzFHFolxFQmpNdLd0gnvWWwQnqb4GsieZi46Ck+vCrIJXVqS5OiVKU1fOZEXLrUAEnqh5UyCKbm
NCGOxAozX+1Wr+wyRFudii1N9IqLYEEGBoDBEeKYQCvi0YNVlEAZwyOHK2JAiJ64ogq2iIEcqHEA
cUABCta7gQJMQAYK2IECFDCHA+Kwg1h0qWXhk2gZmJCBDIDjEjGz6GXkdak4kYVEqUQMrzRCVdb+
J1EIkcSiHpjScUminK21pXuK2ahmySUtXeEbboGDt/itUiBEo1O8iFqdAw3G/yCzFO5LC/WX2BJH
IrRNiG2j+yisRYKalCyhQsBWWo6YcHTf8VuExMa2yDyFEkr4xo+UsI1WkOMDnmCEJ97RCj4caUj3
6ME2DqGCZvThFu8dSSFMcKWp+JECrAACRCM6yDJUmLMZKKT5RhqnuKilmMulFGFUqdTttlYAJ/Bh
SiuyTMekt8SYlF3mEvNL2KSnLF7p8IsjZdPyyMW0BZrLew6kGMThTcdLPXGK87BiZiLExUfmbkRi
Oo8ELpBBDpTIc5z4IbLg7YJ2yaDrDtmRH03iFLughAqKxwpW7GIbRiJEK3qgJEYM6QPiGPAhdvAB
61WpGSfz3lWS4Q48tKIBgv+kcBkyoGjOziILhtzw6thzkbcsJnOJg7KOK/MXASyzpHlYWkJCnelj
LshNBZmxupiDU1J3JYmZIRoa3nLVH/JKrK1u7aad7OmEmHTUAvk1rlVlyvig8j2MCS5HffnKwcRS
PAYqSDfFwiIlrIIBh9hGtu9pC+bVuRW2MJIn4okFPI9kB4ZoyhBs4IFk+BF84WNFHDLL6AvPwt5Z
+CxJqZwY6uiF1cKmKhpeKxCBj1ICJ4jqPB4BcJJaJKYHWaCCYINchodlkunp92YqDmWB/6Xg10W4
axa+8aqhWqb7oumNx+KuN/1bIuJQgQp2sYdsH4IRfWgFI0agJBIQKSSe0EPMK54wEiVEoxUeMNlU
HqCBq3QpExBtQStYUGF6N9reuchFFsABWotyZ8wkx22gZCOcqF4rD4OKRLDB3nVvuYfKv1w7CQ0U
d1yLfS80JHhK0a52ujNOt4jj7WV8K+0suzwhntiGJ75BjYoZAOesoAYbZxBQNnasFTuoARtqIE8N
AFoMLxjsAUTfDNGLns0NqLq9r56LKEQhC2Dqe+xLaShRj7obzoScQAYue5JizVuG533whRsJ2iOE
1xPBPYd2L3yrxVhrpsG0QGysbITk//gxAh5BOT5gsWb8hBzNAEoNPvAE8P/kA0Y4wAdsYghs+FEM
yVDAAQwh/9LPvwuXSL3qWT+LXCQC31xnvgB0lspIiGWwocHwpKdhlGWwLgF0wAeEwGchQIQwQLQJ
FIvYHwakvgg8GlM7CFRDDBpbtcjQOeThAeVxhUNIwRjwBHEQhwMjOiWwBqhoMPcLpPFhgibQwarL
ANWztyjAukSIAnvLMA40wvsIlNJ5hOvgihWCBAH4uiOUwimkwrLIvYFYwvcZCAF4wiisQmdxOAXx
MCGbOML7ip07EpujOVconkNQAjdEsGqwknTIEhtkmYfKwYliNEUDBCTQPyCMgkTIBf97ywBAAAdI
+8JEDAtQ80JFdMRHjEBGhMSXAiatWQa4g4wTtDnl8YRDCIk8U4EYpEHPazoukbB5u7AeBAT+w7rW
4z/VK8RF8ywNm8Ra3A+8s8Vc1EXhm6Go2sVj8j1VkgzlYYQ9KJ42HAkVcIoqgQpYiIV2q4qqwIRA
QjQ9TMUefMX+6z8gVD1FoLomyLBG/EUHFI4ma6UnHMd0VMew07WveJqpWkdbSsH8OsYBe8OR6LOk
qwqHkrAJs7Br1L9ZAMRBJESqK4MmcIdfaAOYiUdFLJTb8iVIiKCGpMiKjKGH/JDjmEiLzKT8yrMY
rJKnKJlA48dT1MN/xEZWxDpthEX/g9TBXxCfrABAjuTAciQOuZEL5EArmuTJnpQZmyyOnEwOnzym
TlQBNwxFUaxDkuSSh0I0qktFH+Q/IXzFWeAsb/RGHbysLsGCfCPKI2QVV4EV4PvKsjTL3wjLV/Gq
s4ShciM6p3CKk9nHpnPKecu/1Wu9QRzEWPTGg4TJLnGDZEiGWMACrRBHtkTMxFTMxWTMMBEHJUhK
MriFklEZ93PKp+RBH2zFqiTEvvRL8cGEqoiF0RwCLGDIxkTN1FTN1WTNr2gRK+GeLTFFk9ysu8RL
QSTIWfDMz+wSwUyH0YyFIbiFFdi6w2zN40TO5FTOWiQ6BvOjZJjGuhykRbPNVqRKIUKkTs1CSPBJ
hjFot1gwB+G8hVv4htNczvNEz/RUTyoMCAA7

------=_NextPart_000_0013_01BFEFE9.3C81A110--





From falk.lehmann@gmx.net  Tue Jul 18 02:59:57 2000
From: falk.lehmann@gmx.net (falk.lehmann@gmx.net)
Date: Mon, 17 Jul 2000 21:59:57 -0400 (EDT)
Subject: [Python-bugs-list] compiling on WinNT (PR#403)
Message-ID: <20000718015957.C42711D12C@dinsdale.python.org>

Full_Name: Falk
Version: 1.6a2
OS: WinNT 4.0
Submission from: (NULL) (207.105.30.37)


I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.
The compiler stops with some warnings and an error message:
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2081) : error C2099: initializer
is not a constant

K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4047:
'function' : 'int ' differs in levels of indirection from 'void *'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4024: 'memset'
: different types for formal and actual parameter 2
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4047:
'function' : 'int ' differs in levels of indirection from 'void *'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4024: 'memset'
: different types for formal and actual parameter 2
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1933) : warning C4101: 'str' :
unreferenced local variable
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2083) : warning C4047:
'initializing' : 'int ' differs in levels of indirection from 'char [4]'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2084) : warning C4047:
'initializing' : 'char *' differs in levels of indirection from 'unsigned int '
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2087) : warning C4047:
'initializing' : 'int ' differs in levels of indirection from 'void (__cdecl
*)(struct _object *)'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2089) : warning C4047:
'initializing' : 'int (__cdecl *)(struct _object *,struct _iobuf *,int )'
differs in levels of indirection from 'struct _object *(__cdecl *)(struct
_object *,char *)'

Thanks in advance for fixing (at least the error).

Falk




From mhammond@skippinet.com.au  Tue Jul 18 03:16:54 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Mon, 17 Jul 2000 22:16:54 -0400
Subject: [Python-bugs-list] memory leak in loops (PR#398)
In-Reply-To: <20000714104402.3BAAD1CE8C@dinsdale.python.org>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEFADBAA.mhammond@skippinet.com.au>

> I could reproduce the problem with Developer Studio 6.0.
>
> If anyone wants the project to test it - I can provide it.

If you can repro the problem in just a few lines of C/C++ code but with no
SWIG generated code, I would be interested.  Otherwise, I suggest you do
some more work to narrow the problem down some more; as described, there is
still too much work to be done to narrow down the problem to the cause for
me to be interested (or anyone else given the feedback to date!)

Mark.



From mhammond@skippinet.com.au  Tue Jul 18 03:17:28 2000
From: mhammond@skippinet.com.au (mhammond@skippinet.com.au)
Date: Mon, 17 Jul 2000 22:17:28 -0400 (EDT)
Subject: [Python-bugs-list] memory leak in loops (PR#398)
Message-ID: <20000718021728.BE26C1D226@dinsdale.python.org>

> I could reproduce the problem with Developer Studio 6.0.
>
> If anyone wants the project to test it - I can provide it.

If you can repro the problem in just a few lines of C/C++ code but with no
SWIG generated code, I would be interested.  Otherwise, I suggest you do
some more work to narrow the problem down some more; as described, there is
still too much work to be done to narrow down the problem to the cause for
me to be interested (or anyone else given the feedback to date!)

Mark.





From flight@debian.org  Wed Jul 19 16:38:18 2000
From: flight@debian.org (flight@debian.org)
Date: Wed, 19 Jul 2000 11:38:18 -0400 (EDT)
Subject: [Python-bugs-list] test_re fails in CVS from 07/19/00 (PR#404)
Message-ID: <20000719153818.90D571CE86@dinsdale.python.org>

Full_Name: Gregor Hoffleit
Version: 2.0 CVS (07/19/00)
OS: Debian GNU/Linux 2.2
Submission from: p3e9d03da.dip0.t-ipconnect.de (62.157.3.218)


A few weeks ago I noticed that the CVS version of Python 2.0 fails in test_re.
This is with Debian GNU/Linux 2.2 (libc 2.1.3 FWIW). 

When running test.regrtest.main(), the error message is:

  test test_re failed --
     Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"

When running test.test_re() standalone, the error goes like this:

Python 2.0b1 (#0, Jul 19 2000, 10:24:07)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from test import test_re
Running tests on re.search and re.match
Running tests on re.sub
Running tests on symbolic references
Running tests on re.subn
Running tests on re.split
Running tests on re.findall
Running tests on re.match
Running tests on re.escape
Pickling a RegexObject instance
Running re_tests test suite
=== Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')
=== Fails on case-insensitive match ('^(.+)?B', 'AB', 0, 'g1', 'A')
=== Fails on locale-sensitive match ('^(.+)?B', 'AB', 0, 'g1', 'A')
=== Failed incorrectly ('(a+)+\\1', 'aa', 0, 'found+"-"+g1', 'aa-a')
=== Fails on case-insensitive match ('(a+)+\\1', 'aa', 0, 'found+"-"+g1',
'aa-a')
=== Fails on locale-sensitive match ('(a+)+\\1', 'aa', 0, 'found+"-"+g1',
'aa-a')
=== Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')
=== Fails on case-insensitive match ('^(.+)?B', 'AB', 0, 'g1', 'A')
=== Fails on locale-sensitive match ('^(.+)?B', 'AB', 0, 'g1', 'A')






From mwtraha@sandia.gov  Wed Jul 19 20:17:55 2000
From: mwtraha@sandia.gov (mwtraha@sandia.gov)
Date: Wed, 19 Jul 2000 15:17:55 -0400 (EDT)
Subject: [Python-bugs-list] Tkinter Toplevel (PR#405)
Message-ID: <20000719191755.371C91D240@dinsdale.python.org>

Full_Name: Michael Trahan
Version: Python 1.5.2
OS: sunos5 and win32
Submission from: sahp949.sandia.gov (134.253.26.8)


There appears to be a problem with the Toplevel routine in Tkinter. This code
snippet:

	from Tkinter import *

	root = Tk ()
	root.title = "Toplevel"

	Label (root, text = "This is the main (default) Toplevel").pack (pady = 10)

	t1 = Toplevel (root)
	Label (t1, text = "This is a child of root").pack (padx = 10, pady = 10)

produces this error:

	    t1 = Toplevel (root)
	  File "...Tkinter.py", line 1119, in __init__
	    self.title(root.title())
	TypeError: call of non-function (type string)

Modifying line 1119 of Tkinter.py from

	self.title(root.title())

to

	self.title(root.title)

fixes the problem.




From howard_b_golden@yahoo.com  Fri Jul 21 01:18:21 2000
From: howard_b_golden@yahoo.com (howard_b_golden@yahoo.com)
Date: Thu, 20 Jul 2000 20:18:21 -0400 (EDT)
Subject: [Python-bugs-list] "Fix" os.system() on Windows (PR#406)
Message-ID: <20000721001821.DB1481CF57@dinsdale.python.org>

Full_Name: Howard B. Golden
Version: 1.5.2
OS: Windows 9x/NT/2000
Submission from: ns.littoncorp.com (208.19.110.2)


On Windows 9x/NT/2000, os.system() doesn't return the exit code because
COMMAND.COM doesn't.

To make os.system() on Windows work like os.system() on Unix (a Good Idea-TM),
implement os.system on Windows using code similar to what was suggested by Cary
Evans in http://www.python.org/pipermail/python-list/1999-May/009409.html .

(Note: It seems to me that this change is consistent with the recent change to
posixmodule.c to make os.popen() work the same on Windows as Unix.)




From mhammond@skippinet.com.au  Sun Jul 23 04:46:02 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sun, 23 Jul 2000 13:46:02 +1000
Subject: [Python-bugs-list] "Fix" os.system() on Windows (PR#406)
In-Reply-To: <20000721001821.DB1481CF57@dinsdale.python.org>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEKFDBAA.mhammond@skippinet.com.au>

> To make os.system() on Windows work like os.system() on Unix (a
> Good Idea-TM),
> implement os.system on Windows using code similar to what was
> suggested by Cary
> Evans in
> http://www.python.org/pipermail/python-list/1999-May/009409.html .

I'm afraid there is a backwards compatibility issue here.  Existing code
that uses a command.com builtin command will break.  Eg, the following code
works now, but would not work with the proposed patch.

os.system("copy whatever somewhereelse")

> (Note: It seems to me that this change is consistent with the
> recent change to
> posixmodule.c to make os.popen() work the same on Windows as Unix.)

I agree in principle - however, any fix must not break existing code.

Interestingly, this bug in Windows appears to be fixed in Windows 2000.
Eg:

>>> os.system('python.exe -c "import sys;sys.exit(2)')
'python.exe' is not recognized as an internal or external command,
operable program or batch file.
1
>>> os.system('\\src\\python-cvs\\pcbuild\\python.exe -c "import
sys;sys.exit(2)')
2
>>> os.system('\\src\\python-cvs\\pcbuild\\python.exe -c "import
sys;sys.exit(255)')
255
>>>

Mark.



From mhammond@skippinet.com.au  Sun Jul 23 04:47:13 2000
From: mhammond@skippinet.com.au (mhammond@skippinet.com.au)
Date: Sat, 22 Jul 2000 23:47:13 -0400 (EDT)
Subject: [Python-bugs-list] "Fix" os.system() on Windows (PR#406)
Message-ID: <20000723034713.993AF1D1A3@dinsdale.python.org>

> To make os.system() on Windows work like os.system() on Unix (a
> Good Idea-TM),
> implement os.system on Windows using code similar to what was
> suggested by Cary
> Evans in
> http://www.python.org/pipermail/python-list/1999-May/009409.html .

I'm afraid there is a backwards compatibility issue here.  Existing code
that uses a command.com builtin command will break.  Eg, the following code
works now, but would not work with the proposed patch.

os.system("copy whatever somewhereelse")

> (Note: It seems to me that this change is consistent with the
> recent change to
> posixmodule.c to make os.popen() work the same on Windows as Unix.)

I agree in principle - however, any fix must not break existing code.

Interestingly, this bug in Windows appears to be fixed in Windows 2000.
Eg:

>>> os.system('python.exe -c "import sys;sys.exit(2)')
'python.exe' is not recognized as an internal or external command,
operable program or batch file.
1
>>> os.system('\\src\\python-cvs\\pcbuild\\python.exe -c "import
sys;sys.exit(2)')
2
>>> os.system('\\src\\python-cvs\\pcbuild\\python.exe -c "import
sys;sys.exit(255)')
255
>>>

Mark.





From tim_one@email.msn.com  Sun Jul 23 06:06:45 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sun, 23 Jul 2000 01:06:45 -0400
Subject: [Python-bugs-list] "Fix" os.system() on Windows (PR#406)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEKFDBAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEGHGLAA.tim_one@email.msn.com>

[Mark Hammond]
> I'm afraid there is a backwards compatibility issue here.  Existing
> code that uses a command.com builtin command will break.

Indeed, Tcl contains thousands of lines of miserable Win-specific code
trying to make their version of "system" work correctly.  It's A Project!

> ...
> Interestingly, this bug in Windows appears to be fixed in
> Windows 2000.

IIRC, the correct exit code comes back in NT too -- a command.com vs cmd.exe
thing (command.com *always* returns a 0 exit code).  MS's "system" does
return the exit code of the thing it spawns, so it's the command shell that
screws us, not Python's or MS's implementation of "system".  The easiest fix
is to buy a "real shell" and set COMSPEC to point to it (the MS system uses
COMSPEC to figure out which shell to spawn).  Here on Win98:

C:\tmp>type testit.cpp
int
main()
{
    return 32;
}

C:\tmp>cl testit.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

testit.cpp
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:testit.exe
testit.obj

C:\tmp>set COMSPEC=\tmp\testit.exe

C:\tmp>\python16\python
Python 1.6a2 (#0, Apr  6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> os.system("blah")
32
>>>

That shows Win98 does indeed return the exit code of the shell that gets
spawned -- this is a command.com bug.  In the absence of a shell that works
correctly, not much Python can do about it.





From tim_one@email.msn.com  Sun Jul 23 06:06:56 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Sun, 23 Jul 2000 01:06:56 -0400 (EDT)
Subject: [Python-bugs-list] "Fix" os.system() on Windows (PR#406)
Message-ID: <20000723050656.E08921D1CD@dinsdale.python.org>

[Mark Hammond]
> I'm afraid there is a backwards compatibility issue here.  Existing
> code that uses a command.com builtin command will break.

Indeed, Tcl contains thousands of lines of miserable Win-specific code
trying to make their version of "system" work correctly.  It's A Project!

> ...
> Interestingly, this bug in Windows appears to be fixed in
> Windows 2000.

IIRC, the correct exit code comes back in NT too -- a command.com vs cmd.exe
thing (command.com *always* returns a 0 exit code).  MS's "system" does
return the exit code of the thing it spawns, so it's the command shell that
screws us, not Python's or MS's implementation of "system".  The easiest fix
is to buy a "real shell" and set COMSPEC to point to it (the MS system uses
COMSPEC to figure out which shell to spawn).  Here on Win98:

C:\tmp>type testit.cpp
int
main()
{
    return 32;
}

C:\tmp>cl testit.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

testit.cpp
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:testit.exe
testit.obj

C:\tmp>set COMSPEC=\tmp\testit.exe

C:\tmp>\python16\python
Python 1.6a2 (#0, Apr  6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> os.system("blah")
32
>>>

That shows Win98 does indeed return the exit code of the shell that gets
spawned -- this is a command.com bug.  In the absence of a shell that works
correctly, not much Python can do about it.







From dpo@club-internet.fr  Sun Jul 23 13:12:18 2000
From: dpo@club-internet.fr (dpo@club-internet.fr)
Date: Sun, 23 Jul 2000 08:12:18 -0400 (EDT)
Subject: [Python-bugs-list] os.makedirs (PR#407)
Message-ID: <20000723121218.6C5981CFC7@dinsdale.python.org>

Full_Name: Dimitri Papadopoulos
Version: 1.5.2
OS: RedHat 6.2
Submission from: bas1-92.idf3-1.club-internet.fr (195.36.247.92)


Hi,

Suppose you have an existing directory, like /tmp.
Using os.makedirs you're able to create directory /tmp/foo/
but you cannot create directory /tmp/foo/booh/.

The important thing here is the terminal `/' in the directory
name and the fact that os.makedirs will create one directory
but will if the depth of the directories to create is more
that one.

Of course I have removed the terminal `/' in my code, but I feel
this is not consistent.


Here is a patch:

--- /usr/lib/python1.5/os.py-   Tue Feb  1 22:32:50 2000
+++ /usr/lib/python1.5/os.py    Sun Jul 23 14:07:41 2000
@@ -109,9 +109,10 @@
 
     """
     head, tail = path.split(name)
-    if head and tail and not path.exists(head):
+    if head and not path.exists(head):
         makedirs(head, mode)
-    mkdir(name, mode)
+    if tail:
+        mkdir(name, mode)
 
 def removedirs(name):
     """removedirs(path) -> None


And here is an example program to reproduce the problem:

#!/usr/bin/python

import os.path
import os

p1 = '/tmp/'
p2 = '/tmp/foo/'
p3 = '/tmp/foo/pooh/'


if os.path.exists(p1):
	print p1 + ' EXISTS'
else:
	print p1 + ' DOES NOT EXIST'

print

try:
	os.makedirs(p2)
except (OSError):
	print 'os.makedirs(' + p2 + ') FAILED'
else:
	print 'os.makedirs(' + p2 + ') SUCEEDED'
if os.path.exists(p2):
	print p2 + ' EXISTS'
	os.removedirs(p2)
else:
	print p2 + ' DOES NOT EXIST'

print

try:
	os.makedirs(p3)
except (OSError):
	print 'os.makedirs(' + p3 + ') FAILED'
else:
	print 'os.makedirs(' + p3 + ') SUCEEDED'
if os.path.exists(p3):
	print p3 + ' EXISTS'
	os.removedirs(p3)
else:
	print p3 + ' DOES NOT EXIST'

print





From thomas.mangin@free.fr  Sun Jul 23 13:39:26 2000
From: thomas.mangin@free.fr (thomas.mangin@free.fr)
Date: Sun, 23 Jul 2000 08:39:26 -0400 (EDT)
Subject: [Python-bugs-list] isdir bad behaviouring (PR#408)
Message-ID: <20000723123926.A734B1D085@dinsdale.python.org>

Full_Name: Thomas Mangin
Version: 1.5.2
OS: Linux
Submission from: thomas.legend-internet.net (194.164.54.222)


This report is not a "Bug" report but more a library "Misbehaviouring" report.
I am concern about os.path.isdir return code. (this can probably applied to
isfile)

The return code express a boolean value : the file is a directory or not.

But I notice that if you don't have read access into the directory where the
file is stored, the function always return 0.
Or the path can refer a directory, returning 0 simply isn't right.

I beleve an exception must be raised to inform the programmer about this access
right problem and must be silently ignored.





From pierre@saiph.com  Sun Jul 23 18:42:00 2000
From: pierre@saiph.com (pierre@saiph.com)
Date: Sun, 23 Jul 2000 13:42:00 -0400 (EDT)
Subject: [Python-bugs-list] cStringIO lacks the readlines method (PR#409)
Message-ID: <20000723174200.902E01D0E1@dinsdale.python.org>

Full_Name: pierre Imbaud
Version: 1.5.2
OS: sparc solaris
Submission from: (NULL) (204.193.147.15)


cStringIO is supposed to be the C version of  For some reason,
it does not provide the readlines method.
The obvious turnaround is to use StringIO instead: no hurry to fix,
at least on my side.




From howard_b_golden@yahoo.com  Sun Jul 23 21:29:35 2000
From: howard_b_golden@yahoo.com (Howard B. Golden)
Date: Sun, 23 Jul 2000 13:29:35 -0700 (PDT)
Subject: [Python-bugs-list] "Fix" os.system() on Windows (PR#406)
Message-ID: <20000723202935.26488.qmail@web1605.mail.yahoo.com>

Tim Peters wrote:
> [Mark Hammond]
> > I'm afraid there is a backwards compatibility issue here. 
> Existing
> > code that uses a command.com builtin command will break.
> 
> Indeed, Tcl contains thousands of lines of miserable Win-specific
> code
> trying to make their version of "system" work correctly.  It's A
> Project!

So it can be done, but it's not a simple fix, because you have to
distinguish between command.com builtin commands and external
commands.  I'll look at Tcl to see what's involved.  It sounds like
it's far more trouble than it's worth!  It is my "wish" to clean up
MS's design glitches, but I guess they put them there for a reason
(incompatibility, perhaps?).

> > Interestingly, this bug in Windows appears to be fixed in
> > Windows 2000.

I'll check.

> IIRC, the correct exit code comes back in NT too -- a command.com
> vs cmd.exe
> thing (command.com *always* returns a 0 exit code).

I had this problem on NT 4.0, too (presumably with cmd.exe).  I'll
double check.

> MS's "system"
> does
> return the exit code of the thing it spawns, so it's the command
> shell that
> screws us, not Python's or MS's implementation of "system".  The
> easiest fix
> is to buy a "real shell" and set COMSPEC to point to it (the MS
> system uses
> COMSPEC to figure out which shell to spawn).

Buying a "real shell" is a great idea, in general, but it doesn't fix
the problem on Windows in general, unless you can get everyone to buy
the shell, too.

Thanks to you both for considering the suggestion!

Howard

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/


From howard_b_golden@yahoo.com  Sun Jul 23 21:29:36 2000
From: howard_b_golden@yahoo.com (howard_b_golden@yahoo.com)
Date: Sun, 23 Jul 2000 16:29:36 -0400 (EDT)
Subject: [Python-bugs-list] "Fix" os.system() on Windows (PR#406)
Message-ID: <20000723202936.1123D1D133@dinsdale.python.org>

Tim Peters wrote:
> [Mark Hammond]
> > I'm afraid there is a backwards compatibility issue here. 
> Existing
> > code that uses a command.com builtin command will break.
> 
> Indeed, Tcl contains thousands of lines of miserable Win-specific
> code
> trying to make their version of "system" work correctly.  It's A
> Project!

So it can be done, but it's not a simple fix, because you have to
distinguish between command.com builtin commands and external
commands.  I'll look at Tcl to see what's involved.  It sounds like
it's far more trouble than it's worth!  It is my "wish" to clean up
MS's design glitches, but I guess they put them there for a reason
(incompatibility, perhaps?).

> > Interestingly, this bug in Windows appears to be fixed in
> > Windows 2000.

I'll check.

> IIRC, the correct exit code comes back in NT too -- a command.com
> vs cmd.exe
> thing (command.com *always* returns a 0 exit code).

I had this problem on NT 4.0, too (presumably with cmd.exe).  I'll
double check.

> MS's "system"
> does
> return the exit code of the thing it spawns, so it's the command
> shell that
> screws us, not Python's or MS's implementation of "system".  The
> easiest fix
> is to buy a "real shell" and set COMSPEC to point to it (the MS
> system uses
> COMSPEC to figure out which shell to spawn).

Buying a "real shell" is a great idea, in general, but it doesn't fix
the problem on Windows in general, unless you can get everyone to buy
the shell, too.

Thanks to you both for considering the suggestion!

Howard

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/




From tim_one@email.msn.com  Sun Jul 23 21:42:46 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sun, 23 Jul 2000 16:42:46 -0400
Subject: [Python-bugs-list] "Fix" os.system() on Windows (PR#406)
In-Reply-To: <20000723202935.26488.qmail@web1605.mail.yahoo.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEHNGLAA.tim_one@email.msn.com>

[Howard B. Golden]
> So it can be done, but it's not a simple fix, because you have to
> distinguish between command.com builtin commands and external
> commands.  I'll look at Tcl to see what's involved.  It sounds like
> it's far more trouble than it's worth!

Alas, it's much worse than just guessing which cmds are builtin on your
current flavor of Windows.

> It is my "wish" to clean up MS's design glitches, but I guess they
> put them there for a reason (incompatibility, perhaps?).

Not really.  DOS and Windows ran on much feebler systems than, e.g., Unix
ever ran on, and MS has decades of backward compatibility to worry about
too.  For example, you'll find a bunch of code in the Tcl source trying to
fake pipes on versions of Windows too old to support them directly (Tcl's
flavor of "system" is called "exec", and tries to give robust portable
meaning to the usual cmdline metasymbols too, like ">" and "|").  The *kind*
of executable under Windows can also make a difference, as stuff compiled
for the 16-bit subsystem can act differently than that compiled for the
32-bit one, and the ancient Win32s subsystem throws in its own surprises.
Tcl tries to make sense out of all of that -- and you *do* need to make
sense of it all if you want it to be as usable as it is under Unix.  Even
so, the Tcl manpages bristle with warnings about things that can still go
wrong with "exec" under Windows.  It's simply a mess.

> ...
> Buying a "real shell" is a great idea, in general, but it doesn't fix
> the problem on Windows in general, unless you can get everyone to buy
> the shell, too.

Right -- there's no clear way out of this.

> Thanks to you both for considering the suggestion!

Oh, it's been under consideration for years <wink>.  Last time somebody got
excited about this was 1-2 years ago.  They ran off to look at the Tcl
source too, and were never heard from again <wink/sigh>.




From tim_one@email.msn.com  Sun Jul 23 21:42:58 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Sun, 23 Jul 2000 16:42:58 -0400 (EDT)
Subject: [Python-bugs-list] "Fix" os.system() on Windows (PR#406)
Message-ID: <20000723204258.8AB2C1CDBB@dinsdale.python.org>

[Howard B. Golden]
> So it can be done, but it's not a simple fix, because you have to
> distinguish between command.com builtin commands and external
> commands.  I'll look at Tcl to see what's involved.  It sounds like
> it's far more trouble than it's worth!

Alas, it's much worse than just guessing which cmds are builtin on your
current flavor of Windows.

> It is my "wish" to clean up MS's design glitches, but I guess they
> put them there for a reason (incompatibility, perhaps?).

Not really.  DOS and Windows ran on much feebler systems than, e.g., Unix
ever ran on, and MS has decades of backward compatibility to worry about
too.  For example, you'll find a bunch of code in the Tcl source trying to
fake pipes on versions of Windows too old to support them directly (Tcl's
flavor of "system" is called "exec", and tries to give robust portable
meaning to the usual cmdline metasymbols too, like ">" and "|").  The *kind*
of executable under Windows can also make a difference, as stuff compiled
for the 16-bit subsystem can act differently than that compiled for the
32-bit one, and the ancient Win32s subsystem throws in its own surprises.
Tcl tries to make sense out of all of that -- and you *do* need to make
sense of it all if you want it to be as usable as it is under Unix.  Even
so, the Tcl manpages bristle with warnings about things that can still go
wrong with "exec" under Windows.  It's simply a mess.

> ...
> Buying a "real shell" is a great idea, in general, but it doesn't fix
> the problem on Windows in general, unless you can get everyone to buy
> the shell, too.

Right -- there's no clear way out of this.

> Thanks to you both for considering the suggestion!

Oh, it's been under consideration for years <wink>.  Last time somebody got
excited about this was 1-2 years ago.  They ran off to look at the Tcl
source too, and were never heard from again <wink/sigh>.






From services@mail.internetseer.com  Mon Jul 24 08:22:58 2000
From: services@mail.internetseer.com (services@mail.internetseer.com)
Date: Mon, 24 Jul 2000 03:22:58 -0400 (EDT)
Subject: [Python-bugs-list] Your web site has been mapped (PR#410)
Message-ID: <20000724072258.7A4991CF46@dinsdale.python.org>

Freewire has added your web site to its map of the World Wide Web.  Freewire will continue to monitor millions of links and web sites every day during its ongoing web survey.

If it is important for you to know that your site is connected to the web at all times, Freewire has arranged with InternetSeer.com to notify you when your site does not respond.  This means that, AT NO CHARGE; InternetSeer.com will monitor your Web site every hour and send notification to you by email whenever your site is not connected to the Web. There are NO current or future charges associated with this service.

To begin your FREE monitoring NOW, activate your account at:
http://www.internetseer.com/signup.asp?email=bugs-py@python.org

Mark McLellan
Chief Technology Officer
Freewire.com

Is your web site status important to you? I'd love your comments. If you prefer not to receive any future notices that result from our ongoing survey please let me know by returning this email with the word "remove" in the subject line.

=============================================
##Remove: bugs-py@python.org##




From papadopo@shfj.cea.fr  Mon Jul 24 11:14:56 2000
From: papadopo@shfj.cea.fr (papadopo@shfj.cea.fr)
Date: Mon, 24 Jul 2000 06:14:56 -0400 (EDT)
Subject: [Python-bugs-list] sys.platform (PR#411)
Message-ID: <20000724101456.E9DD81D0FD@dinsdale.python.org>

Full_Name: Dimitri Papadopoulos
Version: 1.5.2
OS: Linux
Submission from: pendragon.shfj.cea.fr (132.166.81.1)


Hi,

sys.platform is not documented enough.

Its value is:
- 'linux-i386' on RedHat 6.2 
- 'linux2' on SuSE 6.4
- 'linux1' on other Linux systems?

Especially the difference between RedHat 6.2 and SuSE 6.4 is annoying.
Theses systems are compatible after all...





From guido@beopen.com  Mon Jul 24 14:02:08 2000
From: guido@beopen.com (guido@beopen.com)
Date: Mon, 24 Jul 2000 09:02:08 -0400 (EDT)
Subject: [Python-bugs-list] sys.platform (PR#411)
Message-ID: <20000724130208.7EDFF1CE90@dinsdale.python.org>

> sys.platform is not documented enough.
> 
> Its value is:
> - 'linux-i386' on RedHat 6.2 
> - 'linux2' on SuSE 6.4
> - 'linux1' on other Linux systems?
> 
> Especially the difference between RedHat 6.2 and SuSE 6.4 is annoying.
> Theses systems are compatible after all...

The RedHat folks apparently patch the value to have that value -- it's
not supposed to be that way.  Not much we can do about this...

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)




From papadopo@shfj.cea.fr  Mon Jul 24 14:39:34 2000
From: papadopo@shfj.cea.fr (papadopo@shfj.cea.fr)
Date: Mon, 24 Jul 2000 09:39:34 -0400 (EDT)
Subject: [Python-bugs-list] sys.platform (PR#411)
Message-ID: <20000724133934.C59571CE24@dinsdale.python.org>

> > sys.platform is not documented enough.
> > 
> > Its value is:
> > - 'linux-i386' on RedHat 6.2 
> > - 'linux2' on SuSE 6.4
> > - 'linux1' on other Linux systems?
> > 
> > Especially the difference between RedHat 6.2 and SuSE 6.4 is annoying.
> > Theses systems are compatible after all...
> 
> The RedHat folks apparently patch the value to have that value -- it's
> not supposed to be that way.  Not much we can do about this...

I see... Bloody RedHat folks!

Then I guess `linux 1' means libc5 and `linux2' means glibc but
then maybe this could be documented too. In contrast `sunos5' is
quite clear. On all Solaris machines `uname -sr` yields SunOS 5.*.

Dimitri





From guido@beopen.com  Mon Jul 24 16:00:39 2000
From: guido@beopen.com (guido@beopen.com)
Date: Mon, 24 Jul 2000 11:00:39 -0400 (EDT)
Subject: [Python-bugs-list] test_re fails in CVS from 07/19/00 (PR#404)
Message-ID: <20000724150039.1AA581CEB8@dinsdale.python.org>

> A few weeks ago I noticed that the CVS version of Python 2.0 fails in test_re.
> This is with Debian GNU/Linux 2.2 (libc 2.1.3 FWIW). 
> 
> When running test.regrtest.main(), the error message is:
> 
>   test test_re failed --
>      Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"

Yes, we know.  This is a reminder for Fredrik Lundh that he needs to
fix SRE.  We will make sure the released version won't have this
problem!

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)




From guido@beopen.com  Mon Jul 24 16:00:00 2000
From: guido@beopen.com (guido@beopen.com)
Date: Mon, 24 Jul 2000 11:00:00 -0400 (EDT)
Subject: [Python-bugs-list] Tkinter Toplevel (PR#405)
Message-ID: <20000724150000.3991B1CF78@dinsdale.python.org>

> There appears to be a problem with the Toplevel routine in Tkinter. This code
> snippet:
> 
> 	from Tkinter import *
> 
> 	root = Tk ()
> 	root.title = "Toplevel"
> 
> 	Label (root, text = "This is the main (default) Toplevel").pack (pady = 10)
> 
> 	t1 = Toplevel (root)
> 	Label (t1, text = "This is a child of root").pack (padx = 10, pady = 10)
> 
> produces this error:
> 
> 	    t1 = Toplevel (root)
> 	  File "...Tkinter.py", line 1119, in __init__
> 	    self.title(root.title())
> 	TypeError: call of non-function (type string)
> 
> Modifying line 1119 of Tkinter.py from
> 
> 	self.title(root.title())
> 
> to
> 
> 	self.title(root.title)
> 
> fixes the problem.

The bug is in your code.

Instead of

	root.title = "Toplevel"

you should use

	root.wm_title("Toplevel")

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)




From mal@lemburg.com  Mon Jul 24 16:18:44 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 24 Jul 2000 17:18:44 +0200
Subject: [Python-bugs-list] sys.platform (PR#411)
References: <20000724133934.C59571CE24@dinsdale.python.org>
Message-ID: <397C5E54.7E39AF83@lemburg.com>

papadopo@shfj.cea.fr wrote:
> 
> > > sys.platform is not documented enough.
> > >
> > > Its value is:
> > > - 'linux-i386' on RedHat 6.2
> > > - 'linux2' on SuSE 6.4
> > > - 'linux1' on other Linux systems?
> > >
> > > Especially the difference between RedHat 6.2 and SuSE 6.4 is annoying.
> > > Theses systems are compatible after all...
> >
> > The RedHat folks apparently patch the value to have that value -- it's
> > not supposed to be that way.  Not much we can do about this...
> 
> I see... Bloody RedHat folks!
> 
> Then I guess `linux 1' means libc5 and `linux2' means glibc but
> then maybe this could be documented too. In contrast `sunos5' is
> quite clear. On all Solaris machines `uname -sr` yields SunOS 5.*.

If you need more detailed platform information, try platform.py
which you can download from my Python Pages.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Mon Jul 24 16:19:02 2000
From: mal@lemburg.com (mal@lemburg.com)
Date: Mon, 24 Jul 2000 11:19:02 -0400 (EDT)
Subject: [Python-bugs-list] sys.platform (PR#411)
Message-ID: <20000724151902.319561D17E@dinsdale.python.org>

papadopo@shfj.cea.fr wrote:
> 
> > > sys.platform is not documented enough.
> > >
> > > Its value is:
> > > - 'linux-i386' on RedHat 6.2
> > > - 'linux2' on SuSE 6.4
> > > - 'linux1' on other Linux systems?
> > >
> > > Especially the difference between RedHat 6.2 and SuSE 6.4 is annoying.
> > > Theses systems are compatible after all...
> >
> > The RedHat folks apparently patch the value to have that value -- it's
> > not supposed to be that way.  Not much we can do about this...
> 
> I see... Bloody RedHat folks!
> 
> Then I guess `linux 1' means libc5 and `linux2' means glibc but
> then maybe this could be documented too. In contrast `sunos5' is
> quite clear. On all Solaris machines `uname -sr` yields SunOS 5.*.

If you need more detailed platform information, try platform.py
which you can download from my Python Pages.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From Dimitri PAPADOPOULOS-ORFANOS <papadopo@shfj.cea.fr>  Mon Jul 24 16:30:27 2000
From: Dimitri PAPADOPOULOS-ORFANOS <papadopo@shfj.cea.fr> (Dimitri PAPADOPOULOS-ORFANOS)
Date: Mon, 24 Jul 2000 17:30:27 +0200 (MET DST)
Subject: [Python-bugs-list] sys.platform (PR#411)
Message-ID: <200007241530.RAA21606@orcanie.shfj.cea.fr>

> > I see... Bloody RedHat folks!
> > 
> > Then I guess `linux 1' means libc5 and `linux2' means glibc but
> > then maybe this could be documented too. In contrast `sunos5' is
> > quite clear. On all Solaris machines `uname -sr` yields SunOS 5.*.
> 
> If you need more detailed platform information, try platform.py
> which you can download from my Python Pages.

Hello,

I don't need more detailed information, I just believe that
the value of sys.platform should be documented a bit in the
library reference.

Thanks,
Dimitri



From papadopo@shfj.cea.fr  Mon Jul 24 16:33:07 2000
From: papadopo@shfj.cea.fr (papadopo@shfj.cea.fr)
Date: Mon, 24 Jul 2000 11:33:07 -0400 (EDT)
Subject: [Python-bugs-list] sys.platform (PR#411)
Message-ID: <20000724153307.558511CD2C@dinsdale.python.org>

> > I see... Bloody RedHat folks!
> > 
> > Then I guess `linux 1' means libc5 and `linux2' means glibc but
> > then maybe this could be documented too. In contrast `sunos5' is
> > quite clear. On all Solaris machines `uname -sr` yields SunOS 5.*.
> 
> If you need more detailed platform information, try platform.py
> which you can download from my Python Pages.

Hello,

I don't need more detailed information, I just believe that
the value of sys.platform should be documented a bit in the
library reference.

Thanks,
Dimitri





From guido@beopen.com  Mon Jul 24 16:35:27 2000
From: guido@beopen.com (guido@beopen.com)
Date: Mon, 24 Jul 2000 11:35:27 -0400 (EDT)
Subject: [Python-bugs-list] compiling on WinNT (PR#403)
Message-ID: <20000724153527.4F32A1CD26@dinsdale.python.org>

> I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.

Please try the current CVS tree (on its way to 2.0); we have no
problems compiling this on VC 6.0.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)




From Falk.Lehmann@gmx.net  Mon Jul 24 18:46:46 2000
From: Falk.Lehmann@gmx.net (Falk.Lehmann@gmx.net)
Date: Mon, 24 Jul 2000 13:46:46 -0400 (EDT)
Subject: [Python-bugs-list] compiling on WinNT (PR#403)
Message-ID: <20000724174646.747AE1D1DD@dinsdale.python.org>

[magical fwd by GvR]

Guido,
sorry, but forgot to write, that I switched on the USE_SSL macro.
And then the _socket module does not compile.

Falk

> > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.
> 
> Please try the current CVS tree (on its way to 2.0); we have no
> problems compiling this on VC 6.0.
> 
> --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
> 




From guido@beopen.com  Mon Jul 24 19:00:40 2000
From: guido@beopen.com (guido@beopen.com)
Date: Mon, 24 Jul 2000 14:00:40 -0400 (EDT)
Subject: [Python-bugs-list] compiling on WinNT (PR#403)
Message-ID: <20000724180040.096391D1E1@dinsdale.python.org>

> sorry, but forgot to write, that I switched on the USE_SSL macro.
> And then the _socket module does not compile.

It appears that the Python SSL code hasn't been ported to Windows.
We'll add this to our TODO list, but it's low priority...  Perhaps you
could give it a shot yourself?  See www.python.org/patches/ for how to
contribute.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)




From JeffH@conversa.com  Mon Jul 24 21:59:00 2000
From: JeffH@conversa.com (JeffH@conversa.com)
Date: Mon, 24 Jul 2000 16:59:00 -0400 (EDT)
Subject: [Python-bugs-list] raw strings (PR#412)
Message-ID: <20000724205900.9E0611CDCC@dinsdale.python.org>

Full_Name: Jeffrey Holle
Version: 1.5.2
OS: NT 4.0 sp5
Submission from: (NULL) (63.99.162.140)


The raw string syntax does not work if the last character in string is the
escape character '\'.

There is a work around.  using the normal literal string with a double escape.




From fdrake@beopen.com  Mon Jul 24 22:05:18 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 24 Jul 2000 17:05:18 -0400 (EDT)
Subject: [Python-bugs-list] raw strings (PR#412)
In-Reply-To: <20000724205900.9E0611CDCC@dinsdale.python.org>
References: <20000724205900.9E0611CDCC@dinsdale.python.org>
Message-ID: <14716.44942.379158.104002@cj42289-a.reston1.va.home.com>

JeffH@conversa.com writes:
 > The raw string syntax does not work if the last character in string is the
 > escape character '\'.

  This is a documented limitation, and is not considered a bug.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Mon Jul 24 22:05:26 2000
From: fdrake@beopen.com (fdrake@beopen.com)
Date: Mon, 24 Jul 2000 17:05:26 -0400 (EDT)
Subject: [Python-bugs-list] raw strings (PR#412)
Message-ID: <20000724210526.4FCF01CD88@dinsdale.python.org>

JeffH@conversa.com writes:
 > The raw string syntax does not work if the last character in string is the
 > escape character '\'.

  This is a documented limitation, and is not considered a bug.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member





From tim_one@email.msn.com  Mon Jul 24 22:29:01 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Mon, 24 Jul 2000 17:29:01 -0400
Subject: [Python-bugs-list] raw strings (PR#412)
In-Reply-To: <20000724205900.9E0611CDCC@dinsdale.python.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEKNGLAA.tim_one@email.msn.com>

> Full_Name: Jeffrey Holle
> Version: 1.5.2
> OS: NT 4.0 sp5
> Submission from: (NULL) (63.99.162.140)
>
>
> The raw string syntax does not work if the last character in string is the
> escape character '\'.
>
> There is a work around.  using the normal literal string with a
> double escape.

Not a bug.  It's not that the last character can't be a backslash, it's that
a raw string can't end with an odd number of backslashes.  See the Python
FAQ for more details on this.




From tim_one@email.msn.com  Mon Jul 24 22:29:12 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 24 Jul 2000 17:29:12 -0400 (EDT)
Subject: [Python-bugs-list] raw strings (PR#412)
Message-ID: <20000724212912.B0CF51CDDC@dinsdale.python.org>

> Full_Name: Jeffrey Holle
> Version: 1.5.2
> OS: NT 4.0 sp5
> Submission from: (NULL) (63.99.162.140)
>
>
> The raw string syntax does not work if the last character in string is the
> escape character '\'.
>
> There is a work around.  using the normal literal string with a
> double escape.

Not a bug.  It's not that the last character can't be a backslash, it's that
a raw string can't end with an odd number of backslashes.  See the Python
FAQ for more details on this.






From ingo.adler@synacon.ch  Tue Jul 25 00:34:22 2000
From: ingo.adler@synacon.ch (Ingo Adler)
Date: Tue, 25 Jul 2000 01:34:22 +0200
Subject: [Python-bugs-list] memory leak in loops (PR#398)
References: <ECEPKNMJLHAPFFJHDOJBCEFADBAA.mhammond@skippinet.com.au>
Message-ID: <397CD27E.20816EDA@synacon.ch>

This is a multi-part message in MIME format.
--------------72A23DA082087CB843E12C92
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mark,

I could repro the memory leaks (they seem to be the same) with a much smaller
program:

int main(int argc, char* argv[])
{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();
    PyRun_SimpleString("print \"... Python started ...\"");
    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();

    return 0;
}

There seems to be a more general problem, which includes my special problem.

Output of Code Guard (translated to English). BoundsChecker shows the same
leaks.

Ingo

Output:

Memory Block (0x014EB9B4) [Size: 37 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043AD37(=pythontest.exe:0x01:039D37)
D:\projects\Python\Python\marshal.c#624
   0x0042BC54(=pythontest.exe:0x01:02AC54)
D:\projects\Python\Python\import.c#575

------------------------------------------
Error 00078. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E4858) was never freed

Memory Block (0x014E4858) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x00433896(=pythontest.exe:0x01:032896)
D:\projects\Python\Objects\moduleobject.c#56
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00079. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47D0) was never freed

Memory Block (0x014E47D0) [Size: 28 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00433CB3(=pythontest.exe:0x01:032CB3)
D:\projects\Python\Objects\object.c#122
   0x00424115(=pythontest.exe:0x01:023115)
D:\projects\Python\Objects\dictobject.c#124
   0x004367D3(=pythontest.exe:0x01:0357D3)
D:\projects\Python\Objects\stringobject.c#1075
   0x00425418(=pythontest.exe:0x01:024418)
D:\projects\Python\Objects\dictobject.c#1087
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428

------------------------------------------
Error 00080. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47AC) was never freed

Memory Block (0x014E47AC) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00081. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E46E4) was never freed

Memory Block (0x014E46E4) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x004240F7(=pythontest.exe:0x01:0230F7)
D:\projects\Python\Objects\dictobject.c#120
   0x0043C27B(=pythontest.exe:0x01:03B27B)
D:\projects\Python\Python\pythonrun.c#132
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00082. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x1524000) was never freed

Memory Block (0x01524000) [Size: 12288 Byte] was assigned with malloc
Aufrufhierarchie:
   0x004243A7(=pythontest.exe:0x01:0233A7)
D:\projects\Python\Objects\dictobject.c#280
   0x004245C4(=pythontest.exe:0x01:0235C4)
D:\projects\Python\Objects\dictobject.c#370
   0x00436837(=pythontest.exe:0x01:035837)
D:\projects\Python\Objects\stringobject.c#1086
   0x00415CA9(=pythontest.exe:0x01:014CA9)
D:\projects\Python\Python\compile.c#249
   0x0043AC12(=pythontest.exe:0x01:039C12)
D:\projects\Python\Python\marshal.c#578
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504

------------------------------------------
Error 00083. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC9C) was never freed

Memory Block (0x014EFC9C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EE6(=pythontest.exe:0x01:010EE6)
D:\projects\Python\Objects\classobject.c#126
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00084. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC74) was never freed

Memory Block (0x014EFC74) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411ED6(=pythontest.exe:0x01:010ED6)
D:\projects\Python\Objects\classobject.c#125
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00085. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC4C) was never freed

Memory Block (0x014EFC4C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EC6(=pythontest.exe:0x01:010EC6)
D:\projects\Python\Objects\classobject.c#124
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00086. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F19CC) was never freed

Memory Block (0x014F19CC) [Size: 47 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00431E97(=pythontest.exe:0x01:030E97)
D:\projects\Python\Objects\listobject.c#309
   0x0041137E(=pythontest.exe:0x01:01037E)
D:\projects\Python\Python\ceval.c#2512
   0x0040F906(=pythontest.exe:0x01:00E906)
D:\projects\Python\Python\ceval.c#1503
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324
   0x0042BAD4(=pythontest.exe:0x01:02AAD4)
D:\projects\Python\Python\import.c#485

------------------------------------------
Error 00087. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F596C) was never freed

Memory Block (0x014F596C) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x0042CED6(=pythontest.exe:0x01:02BED6)
D:\projects\Python\Python\import.c#1513
   0x0042CD19(=pythontest.exe:0x01:02BD19)
D:\projects\Python\Python\import.c#1441
   0x0042CE6A(=pythontest.exe:0x01:02BE6A)
D:\projects\Python\Python\import.c#1489
   0x00409B32(=pythontest.exe:0x01:008B32)
D:\projects\Python\Python\bltinmodule.c#65

------------------------------------------
Error 00088. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EB870) was never freed

Memory Block (0x014EB870) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB76(=pythontest.exe:0x01:039B76)
D:\projects\Python\Python\marshal.c#567

------------------------------------------
Error 00089. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFBDC) was never freed

Memory Block (0x014EFBDC) [Size: 34 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411C9E(=pythontest.exe:0x01:010C9E)
D:\projects\Python\Objects\classobject.c#58
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00090. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E74C4) was never freed

Memory Block (0x014E74C4) [Size: 988 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00430B62(=pythontest.exe:0x01:02FB62)
D:\projects\Python\Objects\intobject.c#113
   0x00430BFD(=pythontest.exe:0x01:02FBFD)
D:\projects\Python\Objects\intobject.c#163
   0x0040C6FC(=pythontest.exe:0x01:00B6FC)
D:\projects\Python\Python\bltinmodule.c#2404
   0x0043C29A(=pythontest.exe:0x01:03B29A)
D:\projects\Python\Python\pythonrun.c#136
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00091. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E96C4) was never freed

Memory Block (0x014E96C4) [Size: 174 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0042B0D9(=pythontest.exe:0x01:02A0D9) D:\projects\Python\PC\getpathp.c#403

   0x0042B2D5(=pythontest.exe:0x01:02A2D5) D:\projects\Python\PC\getpathp.c#508

   0x0043E40C(=pythontest.exe:0x01:03D40C)
D:\projects\Python\Python\sysmodule.c#413
   0x0043C2CA(=pythontest.exe:0x01:03B2CA)
D:\projects\Python\Python\pythonrun.c#142
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00092. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EF660) was never freed

Memory Block (0x014EF660) [Size: 36 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0042BA54(=pythontest.exe:0x01:02AA54)
D:\projects\Python\Python\import.c#466
   0x0042BF73(=pythontest.exe:0x01:02AF73)
D:\projects\Python\Python\import.c#724
   0x0042C876(=pythontest.exe:0x01:02B876)
D:\projects\Python\Python\import.c#1202
   0x0042D51E(=pythontest.exe:0x01:02C51E)
D:\projects\Python\Python\import.c#1755

------------------------------------------
Error 00093. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x15211C8) was never freed

Memory Block (0x015211C8) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x004129EE(=pythontest.exe:0x01:0119EE)
D:\projects\Python\Objects\classobject.c#517
   0x004246DD(=pythontest.exe:0x01:0236DD)
D:\projects\Python\Objects\dictobject.c#419
   0x0042546E(=pythontest.exe:0x01:02446E)
D:\projects\Python\Objects\dictobject.c#1103
   0x0043DF2E(=pythontest.exe:0x01:03CF2E)
D:\projects\Python\Python\sysmodule.c#95

------------------------------------------
Aufgerufene Funktionen:
 delete (35 Mal)
 getchar (1 Mal)
 fflush (2 Mal)
 fputs (2 Mal)
 fwrite (2 Mal)
 vsprintf (2 Mal)
 strrchr (14 Mal)
 fclose (14 Mal)
 strspn (251 Mal)
 fread (2021 Mal)
 _fgetc (40 Mal)
 fstat (7 Mal)
 fopen (72 Mal)
 strncmp (19 Mal)
 strcmp (423 Mal)
 stat (21 Mal)
 strncpy (32 Mal)
 strchr (125 Mal)
 sprintf (2 Mal)
 memcmp (1349 Mal)
 memset (133 Mal)
 strcpy (834 Mal)
 strlen (784 Mal)
 SysFreeMem (87 Mal)
 SysGetMem (87 Mal)
 realloc (88 Mal)
 memcpy (837 Mal)
 delete[] (2 Mal)
 free (4936 Mal)
 new[] (14 Mal)
 new (40 Mal)
 calloc (5 Mal)
 malloc (4946 Mal)
Verwendete Resource-Arten:
 Datei-Stream (14 Allocs, 5 max)
 Datei-Handle (14 Allocs, 5 max)
 Objekt-Array (14 Allocs, 13 max)
 Objekt (40 Allocs, 28 max)
 Memory Block (5039 Allocs, 2448 max)
Verwendete Module:
 00400000 07/25/2000 01:06:08 G:\Projects\src\bin\pythontest.exe
 0CD00000 02/03/2000 06:00:00 g:\programme\borland\cbuilder5\bin\CG32.DLL
 201A0000 02/22/2000 05:20:00 C:\WINNT.45\TRAYHOOK.dll
 32500000 02/03/2000 06:00:00 G:\Projects\src\bin\CC3250MT.DLL
 40000000 02/03/2000 05:01:00 C:\WINNT.45\System32\VCL50.BPL
 41000000 02/03/2000 06:00:00 G:\Projects\src\bin\BORLNDMM.DLL
 52180000 08/09/1996 00:00:00 C:\WINNT.45\system32\version.dll
 61220000 12/07/1999 16:03:46 G:\Programme\Microsoft
 Hardware\Mouse\MSH_ZWF.dll
 65340000 02/18/2000 16:16:02 C:\WINNT.45\system32\oleaut32.dll
 70970000 05/09/1998 13:57:06 C:\WINNT.45\system32\SHELL32.dll
 70BD0000 03/18/1999 00:00:00 C:\WINNT.45\system32\SHLWAPI.dll
 71190000 07/22/1999 21:09:08 C:\WINNT.45\system32\MSIDLE.DLL
 71590000 03/18/1999 00:00:00 C:\WINNT.45\system32\COMCTL32.dll
 73060000 05/13/1999 12:05:00 C:\WINNT.45\System32\winspool.drv
 77660000 05/13/1999 12:05:00 C:\WINNT.45\System32\MSWSOCK.dll
 77666C35 05/13/1999 12:05:00 C:\WINNT.45\system32\wsock32.dll
 77690000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2HELP.dll
 776A0000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2_32.dll
 77710000 05/13/1999 12:05:00 C:\WINNT.45\system32\mpr.dll
 77920000 05/13/1999 12:05:00 C:\WINNT.45\System32\oledlg.dll
 779B0000 08/09/1996 00:00:00 C:\WINNT.45\system32\LZ32.dll
 77B80000 05/13/1999 12:05:00 C:\WINNT.45\system32\ole32.dll
 77D80000 05/13/1999 12:05:00 C:\WINNT.45\system32\comdlg32.dll
 77DC0000 05/13/1999 12:05:00 C:\WINNT.45\system32\ADVAPI32.dll
 77E10000 05/13/1999 12:05:00 C:\WINNT.45\system32\RPCRT4.dll
 77E70000 05/13/1999 12:05:00 C:\WINNT.45\system32\user32.dll
 77ED0000 05/13/1999 12:05:00 C:\WINNT.45\system32\GDI32.dll
 77F00000 05/13/1999 12:05:00 C:\WINNT.45\system32\kernel32.dll
 77F70000 05/13/1999 12:05:00 C:\WINNT.45\System32\ntdll.dll
 78000000 12/07/1999 05:00:00 C:\WINNT.45\system32\MSVCRT.dll
==========================================



Mark Hammond wrote:

> > I could reproduce the problem with Developer Studio 6.0.
> >
> > If anyone wants the project to test it - I can provide it.
>
> If you can repro the problem in just a few lines of C/C++ code but with no
> SWIG generated code, I would be interested.  Otherwise, I suggest you do
> some more work to narrow the problem down some more; as described, there is
> still too much work to be done to narrow down the problem to the cause for
> me to be interested (or anyone else given the feedback to date!)
>
> Mark.

--------------72A23DA082087CB843E12C92
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;fax:+41-41-7103244
tel;work:+41-41-8111500
x-mozilla-html:FALSE
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
fn:Ingo Adler
end:vcard

--------------72A23DA082087CB843E12C92--



From ingo.adler@synacon.ch  Tue Jul 25 00:33:18 2000
From: ingo.adler@synacon.ch (ingo.adler@synacon.ch)
Date: Mon, 24 Jul 2000 19:33:18 -0400 (EDT)
Subject: [Python-bugs-list] memory leak in loops (PR#398)
Message-ID: <20000724233318.336C01CE2F@dinsdale.python.org>

This is a multi-part message in MIME format.
--------------72A23DA082087CB843E12C92
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mark,

I could repro the memory leaks (they seem to be the same) with a much smaller
program:

int main(int argc, char* argv[])
{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();
    PyRun_SimpleString("print \"... Python started ...\"");
    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();

    return 0;
}

There seems to be a more general problem, which includes my special problem.

Output of Code Guard (translated to English). BoundsChecker shows the same
leaks.

Ingo

Output:

Memory Block (0x014EB9B4) [Size: 37 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043AD37(=pythontest.exe:0x01:039D37)
D:\projects\Python\Python\marshal.c#624
   0x0042BC54(=pythontest.exe:0x01:02AC54)
D:\projects\Python\Python\import.c#575

------------------------------------------
Error 00078. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E4858) was never freed

Memory Block (0x014E4858) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x00433896(=pythontest.exe:0x01:032896)
D:\projects\Python\Objects\moduleobject.c#56
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00079. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47D0) was never freed

Memory Block (0x014E47D0) [Size: 28 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00433CB3(=pythontest.exe:0x01:032CB3)
D:\projects\Python\Objects\object.c#122
   0x00424115(=pythontest.exe:0x01:023115)
D:\projects\Python\Objects\dictobject.c#124
   0x004367D3(=pythontest.exe:0x01:0357D3)
D:\projects\Python\Objects\stringobject.c#1075
   0x00425418(=pythontest.exe:0x01:024418)
D:\projects\Python\Objects\dictobject.c#1087
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428

------------------------------------------
Error 00080. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47AC) was never freed

Memory Block (0x014E47AC) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00081. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E46E4) was never freed

Memory Block (0x014E46E4) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x004240F7(=pythontest.exe:0x01:0230F7)
D:\projects\Python\Objects\dictobject.c#120
   0x0043C27B(=pythontest.exe:0x01:03B27B)
D:\projects\Python\Python\pythonrun.c#132
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00082. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x1524000) was never freed

Memory Block (0x01524000) [Size: 12288 Byte] was assigned with malloc
Aufrufhierarchie:
   0x004243A7(=pythontest.exe:0x01:0233A7)
D:\projects\Python\Objects\dictobject.c#280
   0x004245C4(=pythontest.exe:0x01:0235C4)
D:\projects\Python\Objects\dictobject.c#370
   0x00436837(=pythontest.exe:0x01:035837)
D:\projects\Python\Objects\stringobject.c#1086
   0x00415CA9(=pythontest.exe:0x01:014CA9)
D:\projects\Python\Python\compile.c#249
   0x0043AC12(=pythontest.exe:0x01:039C12)
D:\projects\Python\Python\marshal.c#578
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504

------------------------------------------
Error 00083. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC9C) was never freed

Memory Block (0x014EFC9C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EE6(=pythontest.exe:0x01:010EE6)
D:\projects\Python\Objects\classobject.c#126
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00084. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC74) was never freed

Memory Block (0x014EFC74) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411ED6(=pythontest.exe:0x01:010ED6)
D:\projects\Python\Objects\classobject.c#125
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00085. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC4C) was never freed

Memory Block (0x014EFC4C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EC6(=pythontest.exe:0x01:010EC6)
D:\projects\Python\Objects\classobject.c#124
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00086. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F19CC) was never freed

Memory Block (0x014F19CC) [Size: 47 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00431E97(=pythontest.exe:0x01:030E97)
D:\projects\Python\Objects\listobject.c#309
   0x0041137E(=pythontest.exe:0x01:01037E)
D:\projects\Python\Python\ceval.c#2512
   0x0040F906(=pythontest.exe:0x01:00E906)
D:\projects\Python\Python\ceval.c#1503
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324
   0x0042BAD4(=pythontest.exe:0x01:02AAD4)
D:\projects\Python\Python\import.c#485

------------------------------------------
Error 00087. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F596C) was never freed

Memory Block (0x014F596C) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x0042CED6(=pythontest.exe:0x01:02BED6)
D:\projects\Python\Python\import.c#1513
   0x0042CD19(=pythontest.exe:0x01:02BD19)
D:\projects\Python\Python\import.c#1441
   0x0042CE6A(=pythontest.exe:0x01:02BE6A)
D:\projects\Python\Python\import.c#1489
   0x00409B32(=pythontest.exe:0x01:008B32)
D:\projects\Python\Python\bltinmodule.c#65

------------------------------------------
Error 00088. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EB870) was never freed

Memory Block (0x014EB870) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB76(=pythontest.exe:0x01:039B76)
D:\projects\Python\Python\marshal.c#567

------------------------------------------
Error 00089. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFBDC) was never freed

Memory Block (0x014EFBDC) [Size: 34 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411C9E(=pythontest.exe:0x01:010C9E)
D:\projects\Python\Objects\classobject.c#58
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00090. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E74C4) was never freed

Memory Block (0x014E74C4) [Size: 988 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00430B62(=pythontest.exe:0x01:02FB62)
D:\projects\Python\Objects\intobject.c#113
   0x00430BFD(=pythontest.exe:0x01:02FBFD)
D:\projects\Python\Objects\intobject.c#163
   0x0040C6FC(=pythontest.exe:0x01:00B6FC)
D:\projects\Python\Python\bltinmodule.c#2404
   0x0043C29A(=pythontest.exe:0x01:03B29A)
D:\projects\Python\Python\pythonrun.c#136
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00091. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E96C4) was never freed

Memory Block (0x014E96C4) [Size: 174 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0042B0D9(=pythontest.exe:0x01:02A0D9) D:\projects\Python\PC\getpathp.c#403

   0x0042B2D5(=pythontest.exe:0x01:02A2D5) D:\projects\Python\PC\getpathp.c#508

   0x0043E40C(=pythontest.exe:0x01:03D40C)
D:\projects\Python\Python\sysmodule.c#413
   0x0043C2CA(=pythontest.exe:0x01:03B2CA)
D:\projects\Python\Python\pythonrun.c#142
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00092. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EF660) was never freed

Memory Block (0x014EF660) [Size: 36 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0042BA54(=pythontest.exe:0x01:02AA54)
D:\projects\Python\Python\import.c#466
   0x0042BF73(=pythontest.exe:0x01:02AF73)
D:\projects\Python\Python\import.c#724
   0x0042C876(=pythontest.exe:0x01:02B876)
D:\projects\Python\Python\import.c#1202
   0x0042D51E(=pythontest.exe:0x01:02C51E)
D:\projects\Python\Python\import.c#1755

------------------------------------------
Error 00093. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x15211C8) was never freed

Memory Block (0x015211C8) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x004129EE(=pythontest.exe:0x01:0119EE)
D:\projects\Python\Objects\classobject.c#517
   0x004246DD(=pythontest.exe:0x01:0236DD)
D:\projects\Python\Objects\dictobject.c#419
   0x0042546E(=pythontest.exe:0x01:02446E)
D:\projects\Python\Objects\dictobject.c#1103
   0x0043DF2E(=pythontest.exe:0x01:03CF2E)
D:\projects\Python\Python\sysmodule.c#95

------------------------------------------
Aufgerufene Funktionen:
 delete (35 Mal)
 getchar (1 Mal)
 fflush (2 Mal)
 fputs (2 Mal)
 fwrite (2 Mal)
 vsprintf (2 Mal)
 strrchr (14 Mal)
 fclose (14 Mal)
 strspn (251 Mal)
 fread (2021 Mal)
 _fgetc (40 Mal)
 fstat (7 Mal)
 fopen (72 Mal)
 strncmp (19 Mal)
 strcmp (423 Mal)
 stat (21 Mal)
 strncpy (32 Mal)
 strchr (125 Mal)
 sprintf (2 Mal)
 memcmp (1349 Mal)
 memset (133 Mal)
 strcpy (834 Mal)
 strlen (784 Mal)
 SysFreeMem (87 Mal)
 SysGetMem (87 Mal)
 realloc (88 Mal)
 memcpy (837 Mal)
 delete[] (2 Mal)
 free (4936 Mal)
 new[] (14 Mal)
 new (40 Mal)
 calloc (5 Mal)
 malloc (4946 Mal)
Verwendete Resource-Arten:
 Datei-Stream (14 Allocs, 5 max)
 Datei-Handle (14 Allocs, 5 max)
 Objekt-Array (14 Allocs, 13 max)
 Objekt (40 Allocs, 28 max)
 Memory Block (5039 Allocs, 2448 max)
Verwendete Module:
 00400000 07/25/2000 01:06:08 G:\Projects\src\bin\pythontest.exe
 0CD00000 02/03/2000 06:00:00 g:\programme\borland\cbuilder5\bin\CG32.DLL
 201A0000 02/22/2000 05:20:00 C:\WINNT.45\TRAYHOOK.dll
 32500000 02/03/2000 06:00:00 G:\Projects\src\bin\CC3250MT.DLL
 40000000 02/03/2000 05:01:00 C:\WINNT.45\System32\VCL50.BPL
 41000000 02/03/2000 06:00:00 G:\Projects\src\bin\BORLNDMM.DLL
 52180000 08/09/1996 00:00:00 C:\WINNT.45\system32\version.dll
 61220000 12/07/1999 16:03:46 G:\Programme\Microsoft
 Hardware\Mouse\MSH_ZWF.dll
 65340000 02/18/2000 16:16:02 C:\WINNT.45\system32\oleaut32.dll
 70970000 05/09/1998 13:57:06 C:\WINNT.45\system32\SHELL32.dll
 70BD0000 03/18/1999 00:00:00 C:\WINNT.45\system32\SHLWAPI.dll
 71190000 07/22/1999 21:09:08 C:\WINNT.45\system32\MSIDLE.DLL
 71590000 03/18/1999 00:00:00 C:\WINNT.45\system32\COMCTL32.dll
 73060000 05/13/1999 12:05:00 C:\WINNT.45\System32\winspool.drv
 77660000 05/13/1999 12:05:00 C:\WINNT.45\System32\MSWSOCK.dll
 77666C35 05/13/1999 12:05:00 C:\WINNT.45\system32\wsock32.dll
 77690000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2HELP.dll
 776A0000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2_32.dll
 77710000 05/13/1999 12:05:00 C:\WINNT.45\system32\mpr.dll
 77920000 05/13/1999 12:05:00 C:\WINNT.45\System32\oledlg.dll
 779B0000 08/09/1996 00:00:00 C:\WINNT.45\system32\LZ32.dll
 77B80000 05/13/1999 12:05:00 C:\WINNT.45\system32\ole32.dll
 77D80000 05/13/1999 12:05:00 C:\WINNT.45\system32\comdlg32.dll
 77DC0000 05/13/1999 12:05:00 C:\WINNT.45\system32\ADVAPI32.dll
 77E10000 05/13/1999 12:05:00 C:\WINNT.45\system32\RPCRT4.dll
 77E70000 05/13/1999 12:05:00 C:\WINNT.45\system32\user32.dll
 77ED0000 05/13/1999 12:05:00 C:\WINNT.45\system32\GDI32.dll
 77F00000 05/13/1999 12:05:00 C:\WINNT.45\system32\kernel32.dll
 77F70000 05/13/1999 12:05:00 C:\WINNT.45\System32\ntdll.dll
 78000000 12/07/1999 05:00:00 C:\WINNT.45\system32\MSVCRT.dll
==========================================



Mark Hammond wrote:

> > I could reproduce the problem with Developer Studio 6.0.
> >
> > If anyone wants the project to test it - I can provide it.
>
> If you can repro the problem in just a few lines of C/C++ code but with no
> SWIG generated code, I would be interested.  Otherwise, I suggest you do
> some more work to narrow the problem down some more; as described, there is
> still too much work to be done to narrow down the problem to the cause for
> me to be interested (or anyone else given the feedback to date!)
>
> Mark.

--------------72A23DA082087CB843E12C92
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;fax:+41-41-7103244
tel;work:+41-41-8111500
x-mozilla-html:FALSE
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
fn:Ingo Adler
end:vcard

--------------72A23DA082087CB843E12C92--





From sk8erFlirt69@aol.com  Wed Jul 26 09:26:35 2000
From: sk8erFlirt69@aol.com (sk8erFlirt69@aol.com)
Date: Wed, 26 Jul 2000 04:26:35 -0400 (EDT)
Subject: [Python-bugs-list] She is a bitch!! (PR#413)
Message-ID: <20000726082635.A0DA21CF41@dinsdale.python.org>

Full_Name: Dasha Anne Jessee
Version: 1.6a2
OS: 
Submission from: spider-to021.proxy.aol.com (152.163.204.51)


her s/n is  kenzerellie on aol and need to get the shit kicked out of her how
ever you can give the worst you can.




From arb@anand.org  Wed Jul 26 17:23:33 2000
From: arb@anand.org (arb@anand.org)
Date: Wed, 26 Jul 2000 12:23:33 -0400 (EDT)
Subject: [Python-bugs-list] mailbox module's maildir class broken? (PR#414)
Message-ID: <20000726162333.258911D094@dinsdale.python.org>

Full_Name: Anand Buddhdev
Version: 1.5.2
OS: i386-Redhat-linux 6.2
Submission from: (NULL) (194.75.251.29)


I'm using the "mailbox" module that comes with python. I'm trying to use the
maildir class in there, but I think it's not following the maildir protocol
properly. The maildir protocol specifies that in a Maildir, a message file
can have any name that is unique, as long as it doesn't begin with a period.
However, the maildir class looks for valid message filenames, by checking to
see if the filename has more than 1 period in it, ie. consists of 3 or more
sections separated by periods. Typically, this is the sort of name one finds
in a Maildir, because the Maildir protocol page describes one simple way of
creating a unique filename, ie. by using the timestamp, pid of the writer, and
the hostname. However, when I insert messages into a maildir which don't follow
that system of generating unique filenames,  the maildir class
of the module doesn't see them. Additioanlly, it _does_ see message files which
begin with a period, eg. .12345678.1234.hostname. This is also a violation of
the
maildir protocol. I believe that a maildir reader should simply look at all
files in a maildir, no matter what the name, except for those that begin with a
period.




From guido@beopen.com  Wed Jul 26 23:31:29 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 26 Jul 2000 17:31:29 -0500
Subject: [Python-bugs-list] mailbox module's maildir class broken? (PR#414)
In-Reply-To: Your message of "Wed, 26 Jul 2000 12:23:33 -0400."
 <20000726162333.258911D094@dinsdale.python.org>
References: <20000726162333.258911D094@dinsdale.python.org>
Message-ID: <200007262231.RAA03129@cj20424-a.reston1.va.home.com>

> I'm using the "mailbox" module that comes with python. I'm trying to
> use the maildir class in there, but I think it's not following the
> maildir protocol properly. The maildir protocol specifies that in a
> Maildir, a message file can have any name that is unique, as long as
> it doesn't begin with a period.  However, the maildir class looks
> for valid message filenames, by checking to see if the filename has
> more than 1 period in it, ie. consists of 3 or more sections
> separated by periods. Typically, this is the sort of name one finds
> in a Maildir, because the Maildir protocol page describes one simple
> way of creating a unique filename, ie. by using the timestamp, pid
> of the writer, and the hostname. However, when I insert messages
> into a maildir which don't follow that system of generating unique
> filenames, the maildir class of the module doesn't see
> them. Additioanlly, it _does_ see message files which begin with a
> period, eg. .12345678.1234.hostname. This is also a violation of the
> maildir protocol. I believe that a maildir reader should simply look
> at all files in a maildir, no matter what the name, except for those
> that begin with a period.

You're probably right.  I've never used that code, and according to
the logs it was contributed to Mike Meyer (no email known).  Perhaps
you would be willing to create a patch?  See
http://www.python.org/patches/ for submission guidelines.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)


From guido@beopen.com  Wed Jul 26 22:31:49 2000
From: guido@beopen.com (guido@beopen.com)
Date: Wed, 26 Jul 2000 17:31:49 -0400 (EDT)
Subject: [Python-bugs-list] mailbox module's maildir class broken? (PR#414)
Message-ID: <20000726213149.2ABD81CF47@dinsdale.python.org>

> I'm using the "mailbox" module that comes with python. I'm trying to
> use the maildir class in there, but I think it's not following the
> maildir protocol properly. The maildir protocol specifies that in a
> Maildir, a message file can have any name that is unique, as long as
> it doesn't begin with a period.  However, the maildir class looks
> for valid message filenames, by checking to see if the filename has
> more than 1 period in it, ie. consists of 3 or more sections
> separated by periods. Typically, this is the sort of name one finds
> in a Maildir, because the Maildir protocol page describes one simple
> way of creating a unique filename, ie. by using the timestamp, pid
> of the writer, and the hostname. However, when I insert messages
> into a maildir which don't follow that system of generating unique
> filenames, the maildir class of the module doesn't see
> them. Additioanlly, it _does_ see message files which begin with a
> period, eg. .12345678.1234.hostname. This is also a violation of the
> maildir protocol. I believe that a maildir reader should simply look
> at all files in a maildir, no matter what the name, except for those
> that begin with a period.

You're probably right.  I've never used that code, and according to
the logs it was contributed to Mike Meyer (no email known).  Perhaps
you would be willing to create a patch?  See
http://www.python.org/patches/ for submission guidelines.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)




From arb@anand.org  Thu Jul 27 18:28:17 2000
From: arb@anand.org (Anand Buddhdev)
Date: Thu, 27 Jul 2000 18:28:17 +0100
Subject: [Python-bugs-list] mailbox module's maildir class broken? (PR#414)
In-Reply-To: <200007262231.RAA03129@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 26, 2000 at 05:31:29PM -0500
References: <20000726162333.258911D094@dinsdale.python.org> <200007262231.RAA03129@cj20424-a.reston1.va.home.com>
Message-ID: <20000727182817.D25048@anand.org>

On Wed, Jul 26, 2000 at 05:31:29PM -0500, Guido van Rossum wrote:

> > I'm using the "mailbox" module that comes with python. I'm trying to
> > use the maildir class in there, but I think it's not following the
> > maildir protocol properly. The maildir protocol specifies that in a
> > Maildir, a message file can have any name that is unique, as long as
> > it doesn't begin with a period.  However, the maildir class looks
> > for valid message filenames, by checking to see if the filename has
> > more than 1 period in it, ie. consists of 3 or more sections
> > separated by periods. Typically, this is the sort of name one finds
> > in a Maildir, because the Maildir protocol page describes one simple
> > way of creating a unique filename, ie. by using the timestamp, pid
> > of the writer, and the hostname. However, when I insert messages
> > into a maildir which don't follow that system of generating unique
> > filenames, the maildir class of the module doesn't see
> > them. Additioanlly, it _does_ see message files which begin with a
> > period, eg. .12345678.1234.hostname. This is also a violation of the
> > maildir protocol. I believe that a maildir reader should simply look
> > at all files in a maildir, no matter what the name, except for those
> > that begin with a period.
> 
> You're probably right.  I've never used that code, and according to
> the logs it was contributed to Mike Meyer (no email known).  Perhaps
> you would be willing to create a patch?  See
> http://www.python.org/patches/ for submission guidelines.

Hello Guido,

Thanks for looking at my bug report.

Well, I can try to make the patches. I'm fairly new to python, so I don't
know how long it will take me, but I need to use the module, so I'll
certainly have to modify it. I'll come back to you when I've produced
something presentable.

-- 
Anand


From arb@anand.org  Thu Jul 27 18:28:45 2000
From: arb@anand.org (arb@anand.org)
Date: Thu, 27 Jul 2000 13:28:45 -0400 (EDT)
Subject: [Python-bugs-list] mailbox module's maildir class broken? (PR#414)
Message-ID: <20000727172845.E02911D128@dinsdale.python.org>

On Wed, Jul 26, 2000 at 05:31:29PM -0500, Guido van Rossum wrote:

> > I'm using the "mailbox" module that comes with python. I'm trying to
> > use the maildir class in there, but I think it's not following the
> > maildir protocol properly. The maildir protocol specifies that in a
> > Maildir, a message file can have any name that is unique, as long as
> > it doesn't begin with a period.  However, the maildir class looks
> > for valid message filenames, by checking to see if the filename has
> > more than 1 period in it, ie. consists of 3 or more sections
> > separated by periods. Typically, this is the sort of name one finds
> > in a Maildir, because the Maildir protocol page describes one simple
> > way of creating a unique filename, ie. by using the timestamp, pid
> > of the writer, and the hostname. However, when I insert messages
> > into a maildir which don't follow that system of generating unique
> > filenames, the maildir class of the module doesn't see
> > them. Additioanlly, it _does_ see message files which begin with a
> > period, eg. .12345678.1234.hostname. This is also a violation of the
> > maildir protocol. I believe that a maildir reader should simply look
> > at all files in a maildir, no matter what the name, except for those
> > that begin with a period.
> 
> You're probably right.  I've never used that code, and according to
> the logs it was contributed to Mike Meyer (no email known).  Perhaps
> you would be willing to create a patch?  See
> http://www.python.org/patches/ for submission guidelines.

Hello Guido,

Thanks for looking at my bug report.

Well, I can try to make the patches. I'm fairly new to python, so I don't
know how long it will take me, but I need to use the module, so I'll
certainly have to modify it. I'll come back to you when I've produced
something presentable.

-- 
Anand




From rmcgowan@veritas.com  Thu Jul 27 23:34:27 2000
From: rmcgowan@veritas.com (rmcgowan@veritas.com)
Date: Thu, 27 Jul 2000 18:34:27 -0400 (EDT)
Subject: [Python-bugs-list] configure --program-suffix does not work (PR#415)
Message-ID: <20000727223427.1ABAF1D181@dinsdale.python.org>

Full_Name: Bob McGowan
Version: 1.5.2
OS: Cygwin 1.1.2 on WinNT 4.0 SP5
Submission from: goldengate-bridge.veritas.com (63.197.92.2)


I am trying to build Python 1.5.2 under the latest Cygwin release (1.1.2) and I
have a problem with needing the .exe extension.

The configure script has (and gives help on) the option --program-suffix= which
allows an option suffix such as .exe.  It did not work when I first tried it
though I did find a Makefile option EXE= with a comment to add .exe to it.

Investigation of the scripts shows two issues, actually.  Configure does not
have a substitute command for this option (it has one for
'--program-transform-name' for example).  A line of the form:

   s%@program_suffix@%$program_suffix%g

is needed in configure, around line number 5858 and following (I have no idea
what to do with configure.in to get it there).

And the Makefile.in files that have EXE= need to add the search string:

   EXE=@program_suffix@

I looked at the CVS tree (I hope correctly) and found a configure ver 1.131,
which is still this way and I could not find any mention of 'program-suffix' in
either a bug or newsgroup search.




From andyg@one.net.au  Fri Jul 28 00:33:01 2000
From: andyg@one.net.au (andyg@one.net.au)
Date: Thu, 27 Jul 2000 19:33:01 -0400 (EDT)
Subject: [Python-bugs-list] Follow up to bug platformbug/401 (PR#416)
Message-ID: <20000727233301.797E41D1B2@dinsdale.python.org>

I'm not sure how I am to reply to Jeremy's notes in regards to my posted
bug.
Hopefully this will be successful.

I've include a copy of the details of the bug below.  In reply to Jeremy's
notes;

Hi, thanks for replying ;)
I'm not sure if it is a configuration problem.  I can reproduce the problem
on all sun
boxes I have tried, including some badly set up systems installed a couple
of years
ago, and a recently installed system set up by a sun expert.

Note, it's not the socket.gethostbyname call which hangs the system.  You
can pretty much do whatever you like between the socket.gethostbyname call
and the
os.system call and everything will be fine.  It's during the os.system call
that python
hangs.  Although without the prior socket.gethostbyname call, the os.system
call will
never hang.  After it has hung there are two python instances in memory.
Here's a
ps taken while the process is hang :

   andyg  9766 23356  0 17:03:18 pts/12   0:00 /usr/local/bin/python
./fred.py
   andyg  9767  9766  0 17:03:18 pts/12   0:00 /usr/local/bin/python
./fred.py

If you kill the child nicely, the parent continues on executing code after
the os.system call.
However, if you upset the parent by hitting ctrl-c in the hang screen for
instance, the child
will no longer respond to a nice kill.  The parent will remain hang.  It
then requires a kill -9 against
the child to get rid of both process.  This brings the parent back to the
command prompt.

Just a thought - could this have anything to do with python1.5.2's known
problem with cleaning
up after popen2 commands on sun machines ?

The hostnames which hang are being resolved from the /etc/hosts file.
socket.gethostbyname
doesn't seem to resolve things which I can resolve with nslookup, but which
aren't in the /etc/hosts
file (perhaps I am using it wrong?).  I put a host which is definately in a
different domain in the
/etc/hosts file (www.yahoo.com 204.71.200.74).  It hang as well.

Thanks for your help.

Andy.
-----------------------------------
Logged in as guest

Viewing platformbug/401
Full headers

From: andyg@one.net.au
Subject: combination of socket.gethostbyname and os.system hangs program
Compose reply
Download message

Move To:
0 replies:
0 followups:

Private message: yes  no

Notes:

Notification:
This sounds like a configuration problem on your local machine, although I
don't
have a Solaris box to test it on.  How is the hostname that is hanging being
looked up?  Do you get the same behavior if you use a different name
service,
e.g. a name in a different domain?

From: andyg@one.net.au
To: bugs-py@python.org
Subject: combination of socket.gethostbyname and os.system hangs program
Date: Mon, 17 Jul 2000 04:26:12 -0400 (EDT)

Full_Name: Andy Gayton
Version: Python 1.5.2 (#3, Jun 29 2000, 15:52:04)  [GCC 2.8.1] on sunos5
OS: SunOS psol002 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise
Submission from: syd-cache01.one.net.au (203.101.17.53)


A combination of socket.gethostbyname and os.system appears to hang
python intermittently.  We run Dec and Sun systems - it only appears
to be a problem with sun systems.

The following is the simplest way I can reproduce the problem:

test.py:
--------------------------------
#!/usr/local/bin/python
import os
import socket
print socket.gethostbyname( "a hostname (but not localhost)" )
os.system("echo fred")

hang.sh:
--------------------------------
#!/bin/ksh
while true ; do
  ./test.py
done

output:
---------------------------------
10.666.666.666
fred
10.666.666.666
fred
... eventually ...
10.666.666.666
<hung>

If "a hostname" is "localhost" it doesn't hang.  For anything else which it
can successfully resolve, it seems to hang.

Thanks !
Andy.


Up to top level
incoming   irreproducible   notabug   open   platformbug   request
resolved   trash   3rdpartybug

Logged in as guest
-----------------------------------------





From daishi@cs.berkeley.edu  Fri Jul 28 03:45:25 2000
From: daishi@cs.berkeley.edu (daishi@cs.berkeley.edu)
Date: Thu, 27 Jul 2000 22:45:25 -0400 (EDT)
Subject: [Python-bugs-list] fix for freezing problem (PR#417)
Message-ID: <20000728024525.9D1B81D037@dinsdale.python.org>

Full_Name: daishi harada
Version: cvs (2.0/1.6?)
OS: linux 2.2 (debian/frozen)
Submission from: c894332-a.pinol1.sfba.home.com (24.12.42.18)


Attempting to freeze in the cvs version of Python appears to fail because of
the addition of:
	Modules/config.c.in L40:       {"exceptions", NULL}, 
with respect to earlier versions of Python. In particular, freezing fails
because an
	extern void initexceptions();
ends up being placed in the config.c generated by Tools/freeze/makeconfig.py,
and this is unbound. I have "fixed" this by simply adding 'exceptions' to the
never list on L6 of makeconfig.py. Things appear to work (or at least
properly freeze), but I have not extensively verified correct operation.





From crystalc@interlog.com  Fri Jul 28 04:13:12 2000
From: crystalc@interlog.com (crystalc@interlog.com)
Date: Thu, 27 Jul 2000 23:13:12 -0400 (EDT)
Subject: [Python-bugs-list] command line i/o redirection under Client 32v3.01 (Novell NetWare) (PR#418)
Message-ID: <20000728031312.212681CFE0@dinsdale.python.org>

Full_Name: Brian Alexander
Version: 1.5.2
OS: Windows 98SE
Submission from: ip254.toronto26.dialup.canada.psi.net (154.11.83.254)


Running the following command when source and destination files reside on a
NetWare 3.12 server seems to cause trouble for Novell's client software (Client
32, version 3.01) under Windows 98SE:

python jlines.py 12 < input.txt | python bsr.py "SYS_ID = -1" -v > cc_tmp_1.txt

This command line, executed from a DOS box, works perfectly if the files
involved are in the current directory on the host computer. When the current
directory containing the files is on a NetWare volume, input.txt gets written to
stdout line by line, instead of being read into to jlines.py. After one line
appears, processing stops and may be continued by pressing the return key.
Eventually, after 10 or 12 presses, the return key just produces beeps and the
operation must be abandoned.






From tim_one@email.msn.com  Fri Jul 28 04:35:18 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 27 Jul 2000 23:35:18 -0400
Subject: [Python-bugs-list] command line i/o redirection under Client 32v3.01 (Novell NetWare) (PR#418)
In-Reply-To: <20000728031312.212681CFE0@dinsdale.python.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEIKGMAA.tim_one@email.msn.com>

While I'm sympathetic, what makes you believe this has anything to do with
Python?  That is, wouldn't the same thing happen if you were running Perl or
C?  Python has no idea where stdin and stdout are directed, and no control
over command.com's (the Win98 shell) treatment of "<", "|" and ">".  In
other words, you may well have a found a Microsoft or Novell bug here, but
there's no evidence of a Python bug.

What happens if you do

    more < input.txt | more > cc_tmp_1.txt

when the files are on a NetWare volume?

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> crystalc@interlog.com
> Sent: Thursday, July 27, 2000 11:13 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] command line i/o redirection under Client
> 32v3.01 (Novell NetWare) (PR#418)
>
>
> Full_Name: Brian Alexander
> Version: 1.5.2
> OS: Windows 98SE
> Submission from: ip254.toronto26.dialup.canada.psi.net (154.11.83.254)
>
>
> Running the following command when source and destination files
> reside on a
> NetWare 3.12 server seems to cause trouble for Novell's client
> software (Client
> 32, version 3.01) under Windows 98SE:
>
> python jlines.py 12 < input.txt | python bsr.py "SYS_ID = -1" -v
> > cc_tmp_1.txt
>
> This command line, executed from a DOS box, works perfectly if the files
> involved are in the current directory on the host computer. When
> the current
> directory containing the files is on a NetWare volume, input.txt
> gets written to
> stdout line by line, instead of being read into to jlines.py.
> After one line
> appears, processing stops and may be continued by pressing the return key.
> Eventually, after 10 or 12 presses, the return key just produces
> beeps and the
> operation must be abandoned.
>
>
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list




From tim_one@email.msn.com  Fri Jul 28 04:36:17 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Thu, 27 Jul 2000 23:36:17 -0400 (EDT)
Subject: [Python-bugs-list] command line i/o redirection under Client 32v3.01 (Novell NetWare) (PR#418)
Message-ID: <20000728033617.6A44D1CFCC@dinsdale.python.org>

While I'm sympathetic, what makes you believe this has anything to do with
Python?  That is, wouldn't the same thing happen if you were running Perl or
C?  Python has no idea where stdin and stdout are directed, and no control
over command.com's (the Win98 shell) treatment of "<", "|" and ">".  In
other words, you may well have a found a Microsoft or Novell bug here, but
there's no evidence of a Python bug.

What happens if you do

    more < input.txt | more > cc_tmp_1.txt

when the files are on a NetWare volume?

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> crystalc@interlog.com
> Sent: Thursday, July 27, 2000 11:13 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] command line i/o redirection under Client
> 32v3.01 (Novell NetWare) (PR#418)
>
>
> Full_Name: Brian Alexander
> Version: 1.5.2
> OS: Windows 98SE
> Submission from: ip254.toronto26.dialup.canada.psi.net (154.11.83.254)
>
>
> Running the following command when source and destination files
> reside on a
> NetWare 3.12 server seems to cause trouble for Novell's client
> software (Client
> 32, version 3.01) under Windows 98SE:
>
> python jlines.py 12 < input.txt | python bsr.py "SYS_ID = -1" -v
> > cc_tmp_1.txt
>
> This command line, executed from a DOS box, works perfectly if the files
> involved are in the current directory on the host computer. When
> the current
> directory containing the files is on a NetWare volume, input.txt
> gets written to
> stdout line by line, instead of being read into to jlines.py.
> After one line
> appears, processing stops and may be continued by pressing the return key.
> Eventually, after 10 or 12 presses, the return key just produces
> beeps and the
> operation must be abandoned.
>
>
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list






From guido@beopen.com  Fri Jul 28 11:35:16 2000
From: guido@beopen.com (guido@beopen.com)
Date: Fri, 28 Jul 2000 06:35:16 -0400 (EDT)
Subject: [Python-bugs-list] fix for freezing problem (PR#417)
Message-ID: <20000728103516.1EE361D159@dinsdale.python.org>

> Full_Name: daishi harada
> Version: cvs (2.0/1.6?)
> OS: linux 2.2 (debian/frozen)
> Submission from: c894332-a.pinol1.sfba.home.com (24.12.42.18)
> 
> Attempting to freeze in the cvs version of Python appears to fail because of
> the addition of:
> 	Modules/config.c.in L40:       {"exceptions", NULL}, 
> with respect to earlier versions of Python. In particular, freezing fails
> because an
> 	extern void initexceptions();
> ends up being placed in the config.c generated by Tools/freeze/makeconfig.py,
> and this is unbound. I have "fixed" this by simply adding 'exceptions' to the
> never list on L6 of makeconfig.py. Things appear to work (or at least
> properly freeze), but I have not extensively verified correct operation.

Thanks!  I've fixed this in the CVS tree now.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)




From guido@beopen.com  Fri Jul 28 11:43:32 2000
From: guido@beopen.com (guido@beopen.com)
Date: Fri, 28 Jul 2000 06:43:32 -0400 (EDT)
Subject: [Python-bugs-list] command line i/o redirection under Client 32v3.01 (Novell NetWare) (PR#418)
Message-ID: <20000728104332.8A7001D13A@dinsdale.python.org>

> Full_Name: Brian Alexander
> Version: 1.5.2
> OS: Windows 98SE
> Submission from: ip254.toronto26.dialup.canada.psi.net (154.11.83.254)
> 
> Running the following command when source and destination files reside on a
> NetWare 3.12 server seems to cause trouble for Novell's client software (Client
> 32, version 3.01) under Windows 98SE:
> 
> python jlines.py 12 < input.txt | python bsr.py "SYS_ID = -1" -v > cc_tmp_1.txt
> 
> This command line, executed from a DOS box, works perfectly if the files
> involved are in the current directory on the host computer. When the current
> directory containing the files is on a NetWare volume, input.txt gets written to
> stdout line by line, instead of being read into to jlines.py. After one line
> appears, processing stops and may be continued by pressing the return key.
> Eventually, after 10 or 12 presses, the return key just produces beeps and the
> operation must be abandoned.

Hm, this looks like a bug in NetWare rather than in Python.  I have no
idea how Python could cause this.

In any case, since I know nobody out here with NetWare, I don't know
how we could investigate further...

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)




From postbox@counter4all.com  Fri Jul 28 15:28:57 2000
From: postbox@counter4all.com (postbox@counter4all.com)
Date: Fri, 28 Jul 2000 10:28:57 -0400 (EDT)
Subject: [Python-bugs-list] RE: Professional statistics for your homepage (PR#419)
Message-ID: <20000728142857.7092E1D207@dinsdale.python.org>

Hi bugs-py@python.org

Check http://www.counter4all.com/omcounter.asp





From jeff.richards@whiplashnow.com  Fri Jul 28 17:56:12 2000
From: jeff.richards@whiplashnow.com (jeff.richards@whiplashnow.com)
Date: Fri, 28 Jul 2000 12:56:12 -0400 (EDT)
Subject: [Python-bugs-list] escaping '\' (PR#420)
Message-ID: <20000728165612.EDCE11D254@dinsdale.python.org>

Full_Name: Jeff Richards
Version: 1.5.2
OS: NT4
Submission from: michael.divineinterventures.com (208.203.56.130)


Backslash does not work as per language spec.

Example:  "\\hello\world"
result:   '\\hello\\world'  - Extra backslash added, first backslash not 
collapsed

Example: "\\hello\\world"
Result   "\\hello\\world"  - No backslashes are collapsed

Example: "hello\there" 
Result:  "hello\011there" - \t converted to \011, this is correct

Example: "\hello\\there" 
Result:  "\\hello\\there" - \\t converted to \\t, this is wrong, first \
converted to \\ - this is wrong






From tim_one@email.msn.com  Sat Jul 29 09:33:09 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 29 Jul 2000 04:33:09 -0400
Subject: [Python-bugs-list] escaping '\' (PR#420)
In-Reply-To: <20000728165612.EDCE11D254@dinsdale.python.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENFGMAA.tim_one@email.msn.com>

Jeff, if you don't send an actual program or screen dump showing the
problem, we can't reproduce it or (often) guess what you mean.

In this case, you're almost certainly suffering from an illusion due to
typing the examples at an interactive command prompt (but since you didn't
show us exactly what you did, I can't be sure of that).  Read the docs for
the difference between str() and repr(); raw expressions at an interactive
prompt are automatically run through repr() before display.  Or ponder this
actual screen dump:

>>> "\\hello\\"
'\\hello\\'
>>> print "\\hello\\"
\hello\
>>> len("\\hello\\")
7
>>>

All the cases you present work as documented -- but not the way you *think*
they do!

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> jeff.richards@whiplashnow.com
> Sent: Friday, July 28, 2000 12:56 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] escaping '\' (PR#420)
>
>
> Full_Name: Jeff Richards
> Version: 1.5.2
> OS: NT4
> Submission from: michael.divineinterventures.com (208.203.56.130)
>
>
> Backslash does not work as per language spec.
>
> Example:  "\\hello\world"
> result:   '\\hello\\world'  - Extra backslash added, first backslash not
> collapsed
>
> Example: "\\hello\\world"
> Result   "\\hello\\world"  - No backslashes are collapsed
>
> Example: "hello\there"
> Result:  "hello\011there" - \t converted to \011, this is correct
>
> Example: "\hello\\there"
> Result:  "\\hello\\there" - \\t converted to \\t, this is wrong, first \
> converted to \\ - this is wrong
>
>
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list




From tim_one@email.msn.com  Sat Jul 29 09:33:17 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Sat, 29 Jul 2000 04:33:17 -0400 (EDT)
Subject: [Python-bugs-list] escaping '\' (PR#420)
Message-ID: <20000729083317.F28AA1D24A@dinsdale.python.org>

Jeff, if you don't send an actual program or screen dump showing the
problem, we can't reproduce it or (often) guess what you mean.

In this case, you're almost certainly suffering from an illusion due to
typing the examples at an interactive command prompt (but since you didn't
show us exactly what you did, I can't be sure of that).  Read the docs for
the difference between str() and repr(); raw expressions at an interactive
prompt are automatically run through repr() before display.  Or ponder this
actual screen dump:

>>> "\\hello\\"
'\\hello\\'
>>> print "\\hello\\"
\hello\
>>> len("\\hello\\")
7
>>>

All the cases you present work as documented -- but not the way you *think*
they do!

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> jeff.richards@whiplashnow.com
> Sent: Friday, July 28, 2000 12:56 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] escaping '\' (PR#420)
>
>
> Full_Name: Jeff Richards
> Version: 1.5.2
> OS: NT4
> Submission from: michael.divineinterventures.com (208.203.56.130)
>
>
> Backslash does not work as per language spec.
>
> Example:  "\\hello\world"
> result:   '\\hello\\world'  - Extra backslash added, first backslash not
> collapsed
>
> Example: "\\hello\\world"
> Result   "\\hello\\world"  - No backslashes are collapsed
>
> Example: "hello\there"
> Result:  "hello\011there" - \t converted to \011, this is correct
>
> Example: "\hello\\there"
> Result:  "\\hello\\there" - \\t converted to \\t, this is wrong, first \
> converted to \\ - this is wrong
>
>
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list






From bwhite@cch.com.au  Mon Jul 31 08:11:18 2000
From: bwhite@cch.com.au (bwhite@cch.com.au)
Date: Mon, 31 Jul 2000 03:11:18 -0400 (EDT)
Subject: [Python-bugs-list] popen2.Popen3.wait() hangs (PR#421)
Message-ID: <20000731071118.DB81D1CF4D@dinsdale.python.org>

Full_Name: Brian White
Version: 1.5.2
OS: SunOS 5.5.1
Submission from: hades.cch.com.au (203.18.39.1)


I think this is probably the same bug as #385 - I do have a little more detail
however. I was looking for a way to "attach" extra info to #385 and failed.

For me, the wait action was hanging when the process I was running was
generating too much standard output.

To test it, I wrote one utility called "dots" to generate N dots:

 #!/usr/local/bin/python
 
 import sys
 
 if len( sys.argv) <= 1:
    print "Prints out the specified number of dots"
 else:
    numdots = int( sys.argv[1] )
    sys.stdout.write( "." * numdots )


And another called popen3test :

 #!/usr/local/bin/python
 
 import sys, popen2
 
 if len( sys.argv) <= 1:
    print "Test for popen3 - specified stdout size"
 else:
    charsize = int( sys.argv[1] )
    bufsize  = -1
  
    if len( sys.argv ) > 2:
       bufsize = int( sys.argv[2] )
 
    popper = popen2.Popen3( "dots " + str(charsize) , bufsize = bufsize )
    popper.wait() # It HANGS HERE
 
    sys.stdout.writelines( popper.fromchild.readlines() )


I then ran this as "popen3test <N> <BS>" where
  N   is the number of bytes of stdout it generates
  BS  is the bufsize
with various values of N and BS

From this I was able to determine that 
   1) For N <= 10240  it works fine
      For N >  10240  it hangs
   2) The value of BS is immaterial 

The traceback on ^C was

 Traceback (innermost last):
   File "popen3test", line 15, in ?
     popper.wait()
   File "/usr/local/lib/python1.5/popen2.py", line 65, in wait
     pid, sts = os.waitpid(self.pid, 0)
 KeyboardInterrupt







From jan@cendio.se  Mon Jul 31 19:06:26 2000
From: jan@cendio.se (jan@cendio.se)
Date: Mon, 31 Jul 2000 14:06:26 -0400 (EDT)
Subject: [Python-bugs-list] signal()/sigaction() [signalmodule.c] (PR#422)
Message-ID: <20000731180626.415461CFA4@dinsdale.python.org>

Full_Name: Jan Danielsson
Version: Python-1.6a2
OS: Linux RedHat6.0 Kernel 2.2.5
Submission from: skorpan.cendio.se (193.180.23.65)


Some calls to siginterrupt() are missing somewhere in the
file signalmodule.c and this makes the initial interrupt
character not interrupt the read system call.

Example:

% ./python
Python 1.6a2 (#1, Jul 31 2000, 17:28:30)  [GCC egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 

At this point: enter your keyboard interrupt character (^C), nothing
happens.  Hit return and the following is written:

Traceback (most recent call last):
  File "<stdin>", line 0, in ?
KeyboardInterrupt
>>> 

If the keyboard interrupt character is typed once again the responce
is immediate:

KeyboardInterrupt
>>>

Maybe the following patch or part of it could be useful to fix
the problem?

--- Python-1.6a2/Modules/signalmodule.c Mon Dec 21 20:32:39 1998
+++ Python-1.6a2.patched/Modules/signalmodule.c Mon Jul 31 19:54:31 2000
@@ -113,6 +113,35 @@
 
 
 ^L
+#ifdef HAVE_SIGACTION
+static RETSIGTYPE * my_signal(int signum, RETSIGTYPE(* handler)())
+{
+       struct sigaction act;
+       struct sigaction old_act;
+       memset(&act, 0, sizeof(act));
+       memset(&old_act, 0, sizeof(old_act));
+       act.sa_handler = handler;
+       if (sigaction(signum, &act, &old_act) == -1) {
+               return SIG_ERR;
+       }
+       return old_act.sa_handler;
+}
+#else
+#ifdef HAVE_SIGINTERRUPT
+static RETSIGTYPE * my_signal(int sig_num, RETSIGTYPE(* handler)())
+{
+       RETSIGTYPE * old_handler;
+       siginterrupt(sig_num, 1);
+       old_handler = signal(sig_num, handler);
+       return old_handler;
+}
+#else
+#define my_signal signal
+#endif
+#endif
+
+
+
 static PyObject *
 signal_default_int_handler(self, arg)
        PyObject *self;
@@ -153,10 +182,7 @@
                return;
        }
 #endif
-#ifdef HAVE_SIGINTERRUPT
-       siginterrupt(sig_num, 1);
-#endif
-       (void)signal(sig_num, &signal_handler);
+       (void)my_signal(sig_num, &signal_handler);
 }
 
 
@@ -243,10 +269,7 @@
        }
        else
                func = signal_handler;
-#ifdef HAVE_SIGINTERRUPT
-       siginterrupt(sig_num, 1);
-#endif
-       if (signal(sig_num, func) == SIG_ERR) {
+       if (my_signal(sig_num, func) == SIG_ERR) {
                PyErr_SetFromErrno(PyExc_RuntimeError);
                return NULL;
        }
@@ -399,7 +422,7 @@
                Py_INCREF(IntHandler);
                Py_DECREF(Handlers[SIGINT].func);
                Handlers[SIGINT].func = IntHandler;
-               old_siginthandler = signal(SIGINT, &signal_handler);
+               old_siginthandler = my_signal(SIGINT, &signal_handler);
        }
 
 #ifdef SIGHUP
@@ -586,7 +609,7 @@
        int i;
        PyObject *func;
 
-       signal(SIGINT, old_siginthandler);
+       my_signal(SIGINT, old_siginthandler);
        old_siginthandler = SIG_DFL;
 
        for (i = 1; i < NSIG; i++) {
@@ -595,7 +618,7 @@
                Handlers[i].func = NULL;
                if (i != SIGINT && func != NULL && func != Py_None &&
                    func != DefaultHandler && func != IgnoreHandler)
-                       signal(i, SIG_DFL);
+                       my_signal(i, SIG_DFL);
                Py_XDECREF(func);
        }